HTML First
(html-first.com)- Si primero usamos las funciones nativas que el navegador ofrece por defecto, al crear apps web podemos reducir cuánto dependemos de lenguajes y toolchains adicionales
- React aumentó la confiabilidad del desarrollo de UI con patrones como
props,statey componentes, pero trasladó el centro de la forma de desarrollo desde HTML hacia JavaScript - Mientras tanto, W3C, WHATWG, IETF y TC39 agregaron miles de mejoras a los lenguajes base de la web, y al integrarlas los principales navegadores se debilitó parte de las razones por las que React era necesario
- HTML First no busca convencer a desarrolladores satisfechos con React, sino que es una corriente que intenta dar a quienes se interesan por un enfoque centrado en HTML un lenguaje para ordenar sus ideas y discutirlas con sus colegas
- Se parece más a una preocupación práctica: volver a evaluar si es posible crear software rápido y accesible solo con los lenguajes base de la web y las funciones del navegador
El estilo de desarrollo al que apunta HTML First
- HTML First prioriza HTML, CSS, JavaScript y las funciones nativas del navegador al crear software web
- La clave está en reducir las capas de abstracción que se agregan sobre la plataforma web
- Los lenguajes y toolchains adicionales también forman parte de las capas que conviene reducir
- El objetivo es una forma de desarrollo que ponga en el centro las funciones que el navegador ya ofrece y que agregue herramientas encima solo cuando sea necesario
El desarrollo web se volvió más complejo después de React
- Antes de React, lo habitual era escribir interfaces en HTML y complementar con herramientas como jQuery las partes que HTML no soportaba de forma nativa
- Ejemplos representativos son el envío de solicitudes asíncronas y las actualizaciones del DOM
- Librerías como React resolvieron varios problemas del desarrollo web tradicional
- Los patrones
propsystate, que pasan datos explícitamente de elementos padre a elementos hijo, redujeron ciertos tipos de bugs - Agruparon UI, estilos y comportamiento en componentes, lo que permitió instalar fácilmente en la propia base de código piezas creadas por otras personas
- Los patrones
- Para obtener estos beneficios, había que pasar de una forma de trabajo basada principalmente en HTML a otra basada principalmente en JavaScript
- JavaScript se trata como un lenguaje más complejo
- También había que aprender muchos conceptos y herramientas introducidos por React
- La industria aceptó este compromiso pese al aumento de complejidad, y estas librerías se convirtieron en la forma predeterminada de crear apps web
- Antes de React, los nuevos desarrolladores aprendían primero HTML y CSS, y después JavaScript
- Después de React, el flujo cambió a aprender primero JavaScript y React, y luego el resto
El punto de reevaluación que trajeron las mejoras de la plataforma web
- W3C, WHATWG, IETF y TC39 agregaron miles de mejoras a los lenguajes nativos de la web mientras se expandía la forma de trabajar de React
- Estas mejoras se integraron en Chrome, Safari, Firefox y Edge
- Muchas de ellas abordan directamente parte de las razones por las que la gente usaba React
- A medida que suben los costos de desarrollo de software y las mejoras de los navegadores se distribuyen ampliamente, cada vez más personas se preguntan si las capas agregadas siguen siendo necesarias hoy
- La idea de HTML First todavía es minoritaria en la industria
- Este enfoque se centra en ayudar a quienes ya se interesan por el desarrollo centrado en HTML a fortalecer sus ideas y obtener lenguaje y conceptos para comunicarse con sus colegas
- El mensaje central es que usar principalmente los lenguajes y funciones nativas de la web también permite crear software web bello, rápido, fácil de usar y accesible, y que hacerlo es posible, práctico y razonable
1 comentarios
Opiniones en Hacker News
Me gusta la idea, pero, sinceramente, los ejemplos son flojos
El ejemplo de la parte “define estilos y comportamiento como atributos HTML en línea cuando sea posible” en realidad no parece que vaya a funcionar, y si quieres agregar más estilos, la estructura termina siendo una en la que el parámetro de cadena que se le pasa a
ClassList.addno deja de crecerPersonalmente,
button:active { background: green; }me parece mucho más fácil de leer, pero el autor parece verlo como algo complejo por el enfoque de “Locality of Behaviour”Estoy de acuerdo con “si necesitas una librería, usa una que aproveche atributos HTML, no una centrada en JavaScript o en sintaxis personalizada”, pero el ejemplo recomendado “on input put me into #output” se siente más raro que la librería puesta como mal ejemplo, y parece que bastaría con JavaScript sin framework
Como ejemplo de “prefiere HTML ‘crudo’ por encima de capas ocultas que compilan a HTML”, dice que no se usen los helpers de etiquetas ERB de Rails, pero esos helpers se encargan de bastantes cosas que se volverían desordenadas si las escribieras directamente en una plantilla mínima. El ejemplo omite partes realistas como IDs DOM únicos, etiquetas Turbo y manejo de iteraciones
La configuración de estilos y el comportamiento deberían estar separados, y conectarlos solo mediante referencias es lo único que tiene sentido a una escala significativa
Técnicamente puedes meter todas las conexiones a bases de datos SQL y SQL hardcodeado de una app Python en un solo archivo largo, pero así como eso es una mala práctica, este principio me parece similar
Esta parte me confunde: “si necesitas una librería, usa una que aproveche atributos HTML, no una centrada en JavaScript o en sintaxis personalizada”
Pero como ejemplo recomendado muestra _hyperscript [0]. Esa es una librería centrada en sintaxis personalizada, y solo mete dentro de atributos HTML scripts de un lenguaje nuevo que tienes que aprender. No sé si lo dice en serio
[0] https://hyperscript.org
Los ejemplos también son bastante flojos. La solución pura, es decir, solo el primer tip, funciona igual de bien
_se ve realmente raro y confusoPreferiría poner una sentencia JavaScript pura dentro de un
onclickexplícito u otro atributo de evento, para entender de inmediato qué está pasandoEntiendo la intención. Usar las funciones integradas de HTML es limpio y simple
Pero no era práctico hace 10 años y sigue sin serlo ahora. Tampoco siento que algo como htmx sea especialmente mejor que soluciones más pesadas como React
Cada vez que veo este enfoque, la pregunta que hago siempre es la misma. ¿Cómo se ven los dropdowns, la selección múltiple y el selector de fecha? ¿Los navegadores tienen selectores de fecha? Sí. ¿Su apariencia y comportamiento son consistentes entre navegadores? No. ¿Se pueden igualar con estilos? Tampoco
Con la selección múltiple pasa algo parecido. Exigir Shift/Ctrl+clic para seleccionar varios elementos es totalmente inviable desde el punto de vista de la experiencia de usuario. El elemento básico todavía funciona así y no se puede cambiar. No solo la selección múltiple: también los elementos de selección normales se ven mal y por lo general son difíciles de modificar
Hay una razón por la que cada framework nuevo termina teniendo estos componentes de terceros. Los elementos integrados no alcanzan. Es la misma razón por la que, aunque la página de Array en MDN suma funciones integradas cada año, el 90% de mis proyectos todavía depende de lodash. Sí, estamos mejor que hace 10 años, pero todavía falta
Los usuarios pueden usar navegadores distintos, pero es probable que un usuario use el mismo navegador en todos los sitios web que visita
Por eso creo que es más importante que el selector de fecha sea consistente en todos los sitios web dentro de un mismo navegador que consistente entre todos los navegadores dentro de un sitio web. Claro que si necesitas funcionalidad personalizada, la cosa cambia
Cuando quiero seleccionar 10 o 15 elementos consecutivos de una lista, por ahora no conozco una UI mejor que Shift+clic
Sería mucho mejor que los componentes de UI de todos los sitios web siguieran el look and feel nativo del navegador, dejando de lado el diseño propio del sitio, en vez de que cada uno reinvente sus propios estilos tontos. Claro, los navegadores deberían preocuparse por hacer que eso se vea bien
inputes famoso porque sus formas de interacción varían mucho entre navegadores, mientras que la mayoría de los demás elementos HTML tienen un comportamiento representativo bien definidoEstoy de acuerdo con la mayoría de los argumentos, pero este texto se siente un poco contradictorio, porque recomienda Tailwind y al mismo tiempo dice “evita el paso de build”
Distribuir recursos CSS/JS enormes también va en contra del principio de inclusión. Hay mucha gente que no tiene internet rápido ni una computadora suficientemente potente
De hecho, no conozco ningún JavaScript del lado del cliente que Tailwind emita. Mi última experiencia fue con 2.x, así que no estoy seguro de si algo cambió
Con el tamaño del CSS, mi experiencia también fue la contraria: el output de Tailwind normalmente era mucho más pequeño que el CSS escrito a mano
Por supuesto, no estoy en contra de CSS puro, pero también es al menos igual de fácil hacer un desastre con eso
Pero, si mal no recuerdo, no ofrece todas las funciones que da Tailwind completo. En general, me frustró que Fresh en la práctica esté construido en gran medida sobre Preact y Twind, y que no lo deje claro de entrada: primero tienes que aceptar esas bibliotecas
Estoy algo de acuerdo en que es un poco raro recomendarlo en el contexto de este texto, pero el paso de build puede ser extremadamente minimalista y también es bueno que el resultado siga siendo CSS que puedes inspeccionar
Uso Tailwind en mi sitio personal, y todo lo demás es HTML puro. Tener la CLI corriendo en modo watch mientras escribo estilos no me molesta mucho
Ambas son sorprendentemente rápidas y parsean más de 10,000 elementos
Es interesante en teoría o en ejemplos simples, pero me gustaría ver un proyecto grande que lo aplique y qué diferencia hizo realmente
Los objetivos del inicio del texto son excelentes, pero los consejos en sí me decepcionaron un poco. No veo bien cómo funcionaría fuera de situaciones muy básicas, y mucho menos cómo lograría esos objetivos
Estoy a favor de aprovechar al máximo la plataforma web y totalmente a favor de reducir la complejidad tanto como sea posible. Pero soy muy escéptico de que estos principios logren eso; incluso parece que podrían aumentar la complejidad al crear varias formas de hacer lo mismo
Dicho con buena intención, con esta lista no se puede saber si estos principios ya se probaron en la práctica o si solo se asume que funcionarán como se espera
Lo pregunto en serio. La gente saca ese argumento con frecuencia y nunca lo he entendido
Desde mi perspectiva, el 95% de la web son proyectos pequeños a medianos. La mayoría de la tecnología debería enfocarse en eso. Usa soluciones simples para proyectos simples y agrega complejidad después
Una cosa medio objetiva que perdimos fue la accesibilidad. Como reimplementaron ingenuamente los enlaces como divs con event listeners de clic, la mayor parte del sitio no se puede navegar con teclado
Eso es bastante preocupante. Cuando llegue la regulación, estaremos corriendo de urgencia para recuperar lo que tiramos
Aun así, estoy algo de acuerdo en que es difícil encontrar ejemplos famosos de sitios “HTML primero”. Creo en ello, pero no he visto un caso realmente bien desplegado. Aunque la razón podría ser puramente educativa: para cuando HTML se volvió potente, la formación de desarrolladores frontend ya estaba profundamente centrada en frameworks
No parece que el autor haya probado esto en un proyecto con más de dos personas y soporte para el 99% de los navegadores actuales. Además, parece que ni siquiera ejecutó su propio código. Tal vez mi pantalla no es sabrosa, pero
onlickno es un handler de divSi construyes un producto que parece funcionar pero en realidad no funciona, ellos no lo entienden. Entonces terminas encaminado a prometer de más y entregar de menos
Una de las ventajas menos conocidas de las pruebas unitarias es que permiten asegurar más calidad antes de conectar código que la gerencia no puede ver. Reducen ese tramo incómodo entre la primera pantalla visible y el lanzamiento
En 1999 hice mi primer sitio web con HTML puro, CSS y JS puro, y lo alojé en Geocities
Después he construido sitios y apps con PHP/WordPress/Yii/Laravel, Ruby/Rails/Sinatra/Jekyll, React/Typescript y ClojureScript
Hoy React, componentes TSX, CSS-in-TS, Effects y Context se sienten como un hogar cómodo. Por fin se siente como si tuviéramos un lenguaje de programación completo para la web/frontend. Un lenguaje creado explícitamente para el frontend sobre principios modernos como la programación funcional y reactiva
Ahora sí puedo hacer desarrollo de software. Antes de eso, HTML, CSS, JS puro y PHP eran más bien hackeo. Rails era bueno para full stack, pero no brillaba en el frontend
Cuando el stack web también esté listo para apps, me saltaré los frameworks. Por ahora reconozco que quizá baste para sitios
Este año me rendí. Ya se volvió imposible seguir peleando contra los monstruos React, Vue y Angular, con sus bundlers, transpilers y toda la chatarra que viene pegada
Node y npm te tiran que incluso un proyecto creado hace apenas unos segundos tiene “7 vulnerabilidades graves y 8 críticas”. Hay que descargar miles de archivos, y entre ellos puede haber cosas como wrappers de valores booleanos
Creo que para mí se acabaron los días en que un servidor backend en Python también servía el frontend
En realidad, ni tú ni nadie necesita de verdad esa hinchazón pesada de frontends JavaScript. Solo di que no
Puedes servir páginas livianas desde el backend o la caché, y si hace falta, manejar lo vistoso con CSS
Te esperan tiempos de renderizado rápidos y accesibilidad global
Aunque, para ser sincero, los ejemplos de este texto son raros. No entiendo por qué habría que escribir etiquetas puras a mano en vez de usar los helpers de formularios de Phoenix, que generan automáticamente errores y varias comodidades. Entiendo la intención
El argumento central parece ser que el usuario debería poder presionar View Source y entender qué está pasando. Si hablamos de sitios web, estoy de acuerdo
Para webapps, al menos las de más de 50 líneas, probablemente vas a querer usar un lenguaje con tipos. Técnicamente podrías usar
.jscon anotaciones de tipos en comentarios especiales y el compilador de TypeScript, pero no me resultó muy agradableAntes me atraía bastante esta idea, y me entristece que la mayoría de los sitios hoy sean un bloque de HTML ilegible en una sola línea. Hay belleza y elegancia en desplegar todo como un único archivo HTML, sin dependencias. Basta con 1 solicitud de red
Al final sí hice un “sistema de build” para editar con comodidad, pero mi sistema de build es
cat. Termina siendo software autocontenido y portable en un archivo legible por humanosEn esa misma línea, lo más genial del desarrollo web es que puedes crear tu primer programa interactivo solo con Notepad y el navegador predeterminado. Basta con arrastrar el archivo HTML al navegador. Es mágico
Agregado: descubrí una ventaja inesperada del HTML autocontenido. El software se vuelve inmune a la putrefacción de bits. Abrí un proyecto viejo en Web Archive y el archivo JS externo no estaba archivado. Triste. En cambio, este carga bien porque todo el JS está dentro del HTML. Victoria
https://web.archive.org/web/20210508133239id_/https://andai....
Esto es un homenaje al viejo SodaPlay Constructor. No llegué a crear el editor. Puedes ver el código fuente libremente
Está la vista del DOM, la pestaña de red, la vista del heap y la función integrada para embellecer JavaScript
Por supuesto, “ver código fuente” sigue siendo importante, pero dudo que todavía sea tan absolutamente importante como dicen los de HTMX
Ahora con las URL
data:esto se volvió más fácil. También es útil para evitar los problemas de las URLfile://, que ni siquiera requieren un servidor HTTPhttps://github.com/tc39/proposal-type-annotations
La “localidad del comportamiento” es una regla definida de forma demasiado floja. Es solo llamar con un nombre nuevo a algo que va en contra de la separación de responsabilidades.
Decir que CSS es acción espeluznante a distancia también es una exageración. Hay buenos principios, pero la argumentación es bastante débil y se podría haber dicho de forma mucho más simple.
Si para “cambiar un botón rojo y rebotón por uno azul y tembloroso” tienes que seguir un laberinto de 3 a 7 interfaces y clases para averiguar qué clase necesita una nueva implementación y qué se puede reutilizar, algo que sonaba como un cambio de 10 minutos termina siendo media jornada maldiciendo por dentro al compilador o al desarrollador anterior.
Claro que hay que abstraer, pero también tiene que haber una forma de agrupar el comportamiento en un solo lugar para no tener que tocar 6 archivos al modificar un componente.
https://htmx.org/essays/locality-of-behaviour/#conflict-with...
Al usar Tailwind, en la práctica confías en que una biblioteca de terceros abstraiga la especificación de CSS por ti, y en que esa cuasiespecificación abstraída se respete según la configuración de build.
¿Qué hay que separar? ¿Siguiendo qué líneas se divide? ¿Cómo se determinan esas líneas? ¿Cuándo es válido sacar cierta responsabilidad a otra clase, framework, marcado, etc.? ¿Cuándo es mejor dejarla junto a lo demás?
La respuesta es “depende”.
Si no separas nada, obtienes espagueti; si separas al máximo siempre y en todas partes, obtienes código sobreabstraído tan difícil de mantener como el espagueti.
Si los valores predeterminados funcionan bien, la personalización no es obligatoria. Por eso las ganancias de eficiencia de CSS y similares quedan por detrás de la simplicidad.
Si se ve HTML como un lenguaje de documentos/presentación, no se puede negar el estilado. CSS no solo agrega estilado, también agrega animaciones.
En cualquier caso, CSS también puede verse como programación orientada a aspectos.
El verdadero problema descrito aquí es la falta de buenas herramientas que crucen lenguajes y frameworks.
Tiene sentido depender de frameworks más simples cuando sea posible. Pero la idea de eliminar el paso de build es casi una broma total.
Haz que el paso de build sea más eficiente y, si hace falta, no lo incluyas en producción.
Tampoco entiendo por qué habría que priorizar agregar atributos a HTML. ¿Estamos creando documentos y alojándolos como sitios web? ¿En qué otro mundo sería eso preferible? CSS no es difícil de navegar; más bien deberíamos fomentar mejores prácticas de CSS.
Los scripts del frontend pueden enturbiar el estilado, pero si no lo necesitas, no dependas de ese enfoque. Es más fácil ponerlo en un documento de estilos que insertar atributos con JavaScript, así que esto ya es algo obvio.
Algunos consejos del estilo “usa solo lo que necesitas” tienen sentido y son evidentes. Pero el resto es confuso o directamente absurdo. Tampoco entiendo por qué se asume que poder copiar páginas HTML completas sea algo bueno. Sinceramente no me importa, y aunque no pudiera ver el HTML de algunas páginas, ya existen literalmente millones de recursos para aprender HTML.
En general, me deja desconcertado.
Todo este artículo es un antipatrón y un mal consejo. Se lee como si lo hubiera escrito alguien que no ha pasado por los dolores de crecimiento de crear sitios web complejos.
Al principio nosotros también construíamos sitios web así, pero empezaron a romperse por efectos secundarios, nombres de clases en conflicto y mala observabilidad interna, y React vino al rescate.
El patrón deseado es la mejora progresiva, y la salida debería ser HTML limpio y comprimido, con JavaScript reforzándolo. Es decir, se necesita un paso de build. Exactamente lo contrario de lo que aconseja este artículo.
Si no estás usando ya NodeJS en el backend, conviene evitar ReactJS salvo que realmente lo necesites.