Web Plain Vanilla

 (plainvanillaweb.com)
2 puntos por GN⁺ 2025-05-12 | 1 comentarios | Compartir por WhatsApp
  • Explica las técnicas básicas de desarrollo web usando solo HTML, CSS y JavaScript
  • Presenta cómo implementar sitios y aplicaciones únicamente con tecnologías web estándar, sin herramientas de build ni frameworks
  • Aborda métodos de estructuración y estilizado aprovechando Web Components y funciones modernas de CSS
  • Busca un entorno de desarrollo simple y beneficios a largo plazo, sin la complejidad ni la carga de mantenimiento de los frameworks
  • Es un tutorial dirigido principalmente a desarrolladores que ya dominan las tecnologías estándar de la web

Resumen de Plain Vanilla Web

Es un resumen de las principales técnicas para crear sitios y aplicaciones en el desarrollo web usando solo tecnologías web estándar, sin herramientas de build ni frameworks

  • Explica un entorno que utiliza únicamente editor, navegador y estándares web
  • Presenta una estructura que permite el despliegue a producción sin configuración inicial ni lógica del lado del servidor

Temas tratados

1. Componentes (Components)

  • Explica cómo combinar Web Components en elementos de alto nivel usando solo HTML, JavaScript y CSS
  • Muestra una forma de reemplazar el enfoque de componentes de frameworks como React o Vue

2. Estilizado (Styling)

  • Explica cómo aprovechar el poder de CSS moderno para sustituir la comodidad que ofrecen CSS Modules, PostCSS y SASS
  • Presenta conceptos de estilos estructurados y modulares, dejando atrás el CSS clásico

3. Sitios (Sites)

  • Explica cómo estructurar proyectos web con base en Web Components y desplegarlos sin herramientas de build ni servidor
  • Presenta un flujo de despliegue práctico y simple

4. Aplicaciones (Applications)

  • Explica cómo crear una aplicación web de una sola página usando únicamente técnicas vanilla
  • Describe enfoques de ruteo y manejo de estado

Público recomendado

Está dirigido a desarrolladores que ya pueden manejar HTML, CSS y JavaScript hasta cierto punto

  • Para quienes recién comienzan en el desarrollo web, recomienda rutas de aprendizaje básicas como Odin Project o MDN

¿Por qué el enfoque vanilla?

Los frameworks modernos permiten obtener rápidamente funciones potentes y bien estructuradas, pero vienen acompañados de una mayor complejidad en las herramientas y los frameworks, además de una carga constante de mantenimiento

  • El enfoque Plain Vanilla sacrifica parte de la comodidad a corto plazo a cambio de beneficios a largo plazo como la simplicidad y un mantenimiento prácticamente nulo
  • Los navegadores actuales hacen realmente posible este enfoque gracias a su excelente soporte de estándares web

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-05-12
Opiniones en Hacker News

  • Ya me salí del debate de “¿vanilla o framework?” y ahora pienso más bien desde la perspectiva de: “¿de verdad esto necesita un sitio web?”
    Cuando empiezas a dudar de si una app web, especialmente en el mundo B2B SaaS, realmente necesita ser web, descubres que puedes llevar bastante lejos un negocio sin tocar el navegador
    La mayor parte del tiempo que dediqué a crear sitios y apps se fue en UI/UX de administración, es decir, en la parte donde el administrador cambia campos en la base de datos para que la aplicación se comporte según las expectativas del cliente
    En muchos casos, darle al negocio una simple plantilla de configuración (un archivo de Excel, por ejemplo) e insertar o combinar directamente los resultados en tablas SQL es mucho más rápido, sencillo y evita trabajo inútil
    La web solo ofrece una forma de UI/UX. El correo electrónico o los archivos de texto plano son incluso más flexibles

    • A menudo veo consultoras digital-first que en B2B pierden agilidad por construir webapps innecesariamente sofisticadas
      Sobre todo pasa con compradores como organismos gubernamentales, que muchas veces no entienden bien lo que compran y terminan pagando de más
      Quienes hacen las compras necesitan más formación sobre lo que realmente hace falta
    • Yo vendo urnas funerarias en línea. Mi sitio solo tiene un enlace de correo electrónico. No hay carrito de compras
      Una tienda física de urnas no tiene carrito, así que ¿por qué tendría que tenerlo la tienda virtual?
      También al comprar herramientas especializadas de carpintería en línea, simplemente llené un formulario y recibí las piezas junto con la factura, y ni siquiera importaba si quería pagar de inmediato o no
      Hay muchas formas de comercio tanto en línea como fuera de línea, y si observas a la gente que vive de maneras interesantes, puedes encontrarlas por todas partes
    • Para herramientas internas que no pasan de ser casi puro CRUD, la web es más útil cuando un consultor externo la hace de una sola vez o cuando el equipo interno no puede mantenerla para siempre
      Si tienes aunque sea un poco de capacidad de mantenimiento, una plantilla de Excel + scripts personalizados simples resulta mucho más flexible.
      Es muy efectivo si al final los usuarios son del tipo que de todos modos trabaja a nivel de datos crudos
    • En B2B, antes de SaaS, el 100% funcionaba así
      Y todavía hoy el 99% de B2B sigue este modelo

  • No estoy en contra de los frameworks. Solo siento que en muchos casos no hacen falta
    Siempre me pareció extraño tener que agregar 100 KB de JS antes siquiera de escribir una línea de código
    Con mi equipo construimos https://restofworld.org sin ningún framework
    Las encuestas, el outreach y el feedback por correo fueron muy positivos tanto en usabilidad como en experiencia de lectura
    Más adelante podríamos usar un framework, pero hasta ahora vanilla JS nos ha funcionado muy bien

    • Este comentario es un buen ejemplo de la desconexión que siempre aparece en estas discusiones
      Por un lado están quienes construyen grandes webapps en equipos de más de 30 personas, y si oyen “sin framework” enseguida aparecen dudas sobre cómo resolver funciones esenciales a gran escala
      Pero la respuesta es que esas funciones ni siquiera son necesarias, y como esto se usa para algo tipo blog, desde el inicio no hacía falta un framework
      En cambio, quienes no tienen experiencia real con webapps enormes piensan “¿por qué la gente usa frameworks?”
      La web es realmente un conjunto muy diverso de software.
      Por eso, cuando se habla de frameworks, creo que hay que aclarar con precisión de qué tipo de software se está hablando
      En este caso, esto es un blog de WordPress
    • La página está excelente y carga muy bien, pero esto no tiene relación con el enfoque que describía el TFA
      Se está usando WordPress, que es un framework grande, solo que renderizado de forma estática
      El TFA hablaba de no usar ninguna build tool y de apoyarse solo en estándares web modernos. Solo editor, navegador y estándares web
    • “¿Por qué tendría que agregar 100 KB de JS sin haber escrito una sola línea de código?”
      En las apps empresariales donde he trabajado, 100 KB no es algo que preocupe en absoluto
      Casi siempre eran aplicaciones grandes hechas por varios equipos, usando React y similares.
      En Lob/B2B a nadie le importa la carga inicial de la página
      Los usuarios usan la app todos los días y, en la mayoría de los casos, cargan los assets estáticos directamente desde la caché del navegador
      Si usas un framework inteligente como Next.js, el contenido se divide por rutas en chunks inmutables
      El render inicial es HTML estático, así que desde la perspectiva del usuario la hidratación ni se nota
    • El sitio está muy bien. También encontré buenos artículos
      Pero cuando veo que estos ejemplos en la discusión vanilla vs framework siempre son sitios de noticias o artículos, pienso “yo de todos modos no habría usado un framework para eso”, porque no entran en la categoría de apps complejas
      Al final, los ejemplos reales deberían ser apps más interactivas
      Últimamente prefiero usar solo un framework y patrones consistentes, minimizando otras dependencias
    • Una de las ventajas de esta estructura es que navegar hacia atrás y hacia adelante en el historial del navegador es rapidísimo
      En iPhone ya me había acostumbrado demasiado a que al volver atrás se recargara toda la página
    • ¡Felicidades! Creo que asegurar la usabilidad es lo número uno
      Pero los desarrolladores se obsesionan por diversión con loading screens, componentes hidratados, animaciones excesivas y modales molestos
    • No sé si sea por no usar framework, pero al navegar atrás/adelante la URL cambia de inmediato y la página no se actualiza, así que uno se queda en el mismo artículo
      Además, el scroll infinito es fatal para la usabilidad porque dificulta seguir dónde estás usando la posición de la barra de desplazamiento
    • Rest of World funciona muy rápido incluso en Australia, y es un sitio de noticias fantástico que veo por primera vez.
      Mis felicitaciones por haber participado en su construcción
    • La estética de generar páginas estáticas con WordPress
    • La mayoría de los frameworks no requieren 100 KB de JS
      En el caso de Mithril, por ejemplo, toda la funcionalidad cabe en 10 KB gzipped
    • El problema de los ejemplos vanilla es que las páginas suelen ser demasiado simples y el UX apenas trae lo básico
      Si piensas en implementar tú mismo una tabla reactiva con búsqueda, o formularios con etiquetas, validación y errores bien hechos, ¿por qué hacerlo a mano si puedes usar una librería de UI para Svelte y 25 KB de overhead para tener algo bien construido y probado?
    • La imagen principal pesa más de 200 KB, así que la discusión sobre 100 KB no tiene mucho sentido
      Y WordPress también es un framework
      Usar frameworks no vuelve lento un sitio. Ni WordPress ni lo que sea
    • Este es un buen ejemplo de lo inflada que está la web moderna
      Es demasiado rápido
    • ¡De verdad es rápido!
    • Me gusta muchísimo Rest of World
    • “¿Por qué agregar 100 KB de JS?”
      Por productividad del desarrollador (en teoría).
      En la práctica, muchas veces no ayuda tanto
    • El sitio es realmente rápido. Ya había visto antes periodismo así
      Me pregunto si este enfoque tuvo desventajas importantes
    • ¿Qué? Eso es imposible
    • A nadie le importan 100 KB

  • Estoy desarrollando un sistema para unos 2 mil usuarios, y a ellos no les importa en absoluto una UI reactiva
    Lo mejor es hacer un monolito, no preocuparse por el refresh de página y concentrarse simplemente en hacer el trabajo

    • Como contraargumento, muchas apps de escritorio tradicionales terminaron migrando a la web
      Y la motivación no fue tanto técnica, sino que distribuir apps nativas cuesta demasiado
      La web ofrece barato un estándar para distribuir apps, pero la tecnología de UI sigue siendo floja
      Antes hubo varios intentos a medio camino como X11, Java y Flash, y ojalá algún día aparezca una forma más cómoda de desarrollar webapps
    • Solo con CSS @view-transition ya puedes lograr transiciones suaves
      https://developer.mozilla.org/en-US/docs/Web/CSS/@view-transition
    • Para esta época, es una opinión demaaaasiado insensible
      La mayor parte del software es mucho más lento y menos responsivo que dispositivos mecánicos de hace 120 años
    • Solo con CSS y JS también puedes crear dinámicas de recarga ultrabásicas con facilidad
      No hace falta traer paquetes de npm
    • La separación entre React y el servidor también es un desastre
      El backend está en express/node, todo el código está junto, pero en desarrollo el servidor corre con el servidor por defecto de React y en producción corre distinto, así que al final necesitas una forma rara de build y operación que hace perder sentido a la comodidad del dev server, como el hot reload
    • He visto muchas más SPA rotas que MPA
      Incluso las SPA de grandes empresas como Reddit o X (Twitter) eran demasiado inestables en móvil
      Si no eres del tamaño de Twitter, o no eres una plataforma centrada en APIs, no creo que tenga sentido insistir con SPA
      Si ni siquiera empresas de miles de millones lo han construido bien, es peligroso creer que yo sí podría hacerlo mejor
    • La ventaja del enfoque vanilla es que también puedes ampliar sitios SSR ya existentes
      No hace falta rehacer todo en React
      Las funciones avanzadas tipo SPA que menciona el autor original son opcionales
    • A los usuarios pragmáticos no les importa, pero los que simplemente hacen clics sin pensar tienden a apretar el botón de atrás en lugar de esperar para volver al feed principal, y ese tiempo suele ser menor que el de bajar el framework más reciente desde el CDN
    • Si el refresh de página es realmente muy rápido, entonces sí estoy de acuerdo con esa opinión
    • Me gustaría preguntar cómo sabes que a los usuarios realmente no les importa en absoluto el refresh de página
      Me pregunto si también investigaste a quienes abandonaron

  • Quiero vivir en un mundo así
    Vengo de la época anterior a los frameworks, y ese tiempo todavía era inmaduro, además era común encontrar gente que solo sabía jQuery
    Ahora siento que, después de los query selectors, el costo-beneficio de los frameworks ya no es tan grande (los frameworks de testing son aparte y sí son muy buenos)
    Estamos atrapados en una prisión de frameworks llamada React, y todos los fracasos son resultado de una complejidad spaghetti
    Las state machines quedan enredadas a mano, y los resultados traducidos, comprimidos y transpilados son difíciles de reconocer
    Los source maps son otra capa más de complejidad para mantenimiento
    Entiendo por qué se crearon los frameworks, pero me cuesta imaginar que para un ingeniero nuevo sea más fácil seguir aprendiendo frameworks que vanilla JS

    • Yo también viví esa época, y el problema más grande fue que decidimos construir un ecosistema de apps encima de un formato de documentos
      HTML no era más que markup hecho para facilitar un poco el render de texto, y lo mismo con HTTP
      Antes la proporción texto/markup tenía que ser alta, pero ahora está completamente invertida
      Aun así, creímos que el futuro era montar todo el desarrollo de apps encima de eso, y si ves por dentro React, son décadas de trucos y parches
      Antes era como intentar hacer apps con Excel+VB o con PDF+PostScript, algo absurdo
      Como hemos trabajado así, varios MB de JS o consumir megabytes de JS se siente excesivo
    • Para mí, la killer app hoy en día es la reactividad
      La parte en la que la UI responde de inmediato a cambios en los datos; si tengo que armar listeners manuales, hacer actualizaciones por diff y además liberar eventos, eso ya se siente casi como manejo manual de memoria
      Así era en la era de jQuery, y había muchos errores
      Cuando se pueda modularizar la vista de forma declarativa y basada en componentes con vanilla JS, entonces volveré; pero por ahora me parece totalmente inviable
      Falta una pieza decisiva
    • A mí también a veces me confunde si esto es nostalgia empapada del principio KISS y similares
      React y Angular definitivamente tenían sentido antes de ES2015
      Después de eso me cansé de los cambios en los frameworks frontend
      Incluso dentro de React sigue cambiando la forma de trabajar con componentes y manejo de estado
    • Si das servicio a cientos de millones de vistas, imagino que en la práctica estarás mucho más cerca de una arquitectura de sitio estático

  • Yo todavía no compro Web Components
    Incluso con funciones recientes como @scoped, import {type:css} y demás, me parece mucho más sensato renderizar elementos de forma estática y luego actualizarlos dinámicamente con JS moderno
    Soy escéptico frente a la mayoría de los enfoques con Web Components, y sigo creyendo que hay que innovar fuera de frameworks como React/Svelte
    Nunca he sentido que Web Components sean útiles para varios de los sitios que mantengo

    • Web Components no resuelve mis problemas; más bien agrega otros nuevos
      Con Shadow DOM lo mencionan decenas de veces por página, pero en realidad casi todo eso es resolver problemas que aparecen por haberlo introducido
      Como son componentes exclusivos de mi app, tampoco tengo problemas de Shadow DOM
    • “render estático de elementos + actualización dinámica con JS moderno”
      Me pregunto cómo se maneja eso en backend con Web Components
    • Web Components sí ofrece un límite de abstracción claro
      Puedes agregar métodos extra a tus propias etiquetas y encapsular la lógica de actualización dentro del componente
    • Creo que deberíamos volver a Unobtrusive JS
      Necesitamos prácticas basadas en librerías ligeras o incluso escritas por uno mismo
      HTMX tiene cosas buenas, pero sigue funcionando demasiado como una etiqueta script; bastaría con dejar claros en HTML solo la URL y el método, y cosas como hx-target podrían ir en JS como atributos data-
      No quiero incluir todas las funciones de HTMX que no uso

  • No creo que Web Components sea un reemplazo de lo que otros frameworks llaman componentes
    No puedes meter valores compuestos (Object, Array, etc.) en atributos, hay demasiado boilerplate y no hay reactividad
    Yo programo en un estilo vanilla JS usando signals[1]
    No todos los estándares del W3C son la respuesta, y conviene aprender del fracaso de XHTML
    [1] https://wrnrlr.github.io/prelude/

  • http://youmightnotneedjs.com

  • Este parece un enfoque que le va bien a quienes hacen páginas web como hobby
    Los frameworks existen para estandarización, diseño con buenas prácticas incorporadas y para arrancar el desarrollo rápidamente
    El sitio web en sí no tiene valor intrínseco; lo importante es cómo exponer su contenido de forma eficiente y desarrollarlo bien y a tiempo
    En ese sentido, los frameworks reducen costos presentes y futuros

    • Esa es la “narrativa oficial”, pero en la práctica no siempre es cierta
      En grandes empresas reales, las decisiones suelen estar guiadas por modas, costumbres y una actitud defensiva hacia frameworks populares; no se rastrea la pérdida de productividad causada por más complejidad, y de hecho muchas veces las decisiones equivocadas se alinean con los incentivos personales o del equipo
      Es decir, no se puede justificar la elección de un framework con la lógica de que “seguro fue una decisión racional”
    • También he visto muchos proyectos hechos con React y frameworks relacionados que distan mucho de estar perfectamente gestionados
      Usar un framework no garantiza automáticamente buenas prácticas, y al contrario, puede terminar produciendo sistemas más inflados y lentos

  • Es un recurso realmente excelente
    Creo que, si uno va a construir para la web, debería conocer sí o sí los principios de las tecnologías base y aprovechar al máximo la plataforma web
    Encima de eso, usar o no un build system/framework debería ser una elección libre, siempre que se entiendan los trade-offs
    En lo personal me gusta Remix (/React-router v7+) porque está alineado con una filosofía de estándares web
    Es decir, te permite lograr más con menos desarrollo, por ejemplo modificar datos del servidor incluso solo con formularios HTML
    Y también recomiendo https://every-layout.dev, donde se pueden aprender varias técnicas de layout de alto rendimiento, accesibilidad y flexibilidad usando solo CSS nativo del navegador
    Yo mismo trabajo profesionalmente en desarrollo web desde 1998

  • La semana pasada hice un proyecto pequeño completamente vanilla y está funcionando muy bien
    Es una herramienta web para escribir hilos largos en Mastodon
    Mientras la hacía, pensaba todo el tiempo: “¿estaré haciendo algo mal por no usar un framework?”
    Da la impresión de que los demás ya esperan framework por defecto
    Splinter, splinter.almonit.club, por si a alguien le sirve de referencia