El desarrollo excesivamente centrado en JavaScript está arruinando la web
(jonoalderson.com)Resumen general
El desarrollo excesivamente centrado en JavaScript está arruinando la web
- El abuso de frameworks de JS profundiza la complejidad de los sitios web
- La experiencia del desarrollador (DX) aplasta a la experiencia del usuario (UX)
- Incluso las tareas simples exigen una estructura excesiva
- El rendimiento, la accesibilidad y la mantenibilidad se deterioran
- Recuperar la función esencial de la web es la solución
Introducción
Los males de una web centrada en el desarrollo
- La mayoría de los sitios web son demasiado complejos y lentos
- El diseño centrado en JS desplazó la estructura hacia los desarrolladores más que hacia los usuarios
- Se volvió común que incluso cambios sencillos requieran procesos de despliegue complejos
Desarrollo
El deseo de parecer una app es la causa
- Desde la década de 2010, con la popularidad de las apps móviles, aumentó la demanda de una "web como app"
- Con la adopción de frameworks de JS como Angular, la complejidad se disparó
- Incluso el contenido simple se desarrolla como si fuera un sistema
Cultura de priorizar la experiencia del desarrollador (DX)
- Los frameworks más recientes se enfocan en la comodidad del desarrollador
- La abstracción por componentes provoca una desconexión con la UX
- Antes que preguntar "¿por qué usar React para un blog?", se prioriza discutir la compatibilidad con SSR
La realidad donde la complejidad se volvió estándar
- Incluso las tareas simples requieren estructuras de múltiples capas: build, routing, API, caché, etc.
- Debido a stacks complejos, las personas no desarrolladoras no pueden modificar el contenido
- Los cambios tecnológicos son tan rápidos que dificultan el mantenimiento
Los daños del abuso de frameworks
- Se están reimplementando funciones web ya existentes, como SSR, caché y metadatos
- El rendimiento baja y las dependencias aumentan
- Como resultado, surge la contradicción de recrear un CMS con frameworks de JS
Repetición sin sentido y costos
- La adopción y el abandono de frameworks se repiten, sin una estructura estable
- Se dedica más atención a resolver la complejidad interna que a solucionar problemas reales de los usuarios
- El marketing de contenidos, el SEO y la experimentación se retrasan, mientras la experiencia del usuario empeora
El daño a usuarios y marketers por el abuso de JS
- Modificar contenido requiere la intervención de desarrolladores
- El SEO y la calidad de las páginas se deterioran
- Para los usuarios, aumentan las molestias como retrasos de carga y errores de interacción
JS es solo una herramienta, no el objetivo
- JS es una herramienta poderosa, pero resulta excesiva para la mayoría de los sitios web
- Para contenido estático, HTML, CSS y un poco de JS suelen ser suficientes
- Vanilla JS, renderizado del lado del servidor y scripts mínimos son más eficientes
La concentración del control y el problema estructural
- Debido a stacks complejos, todo el trabajo depende de los desarrolladores
- A nivel organizacional, el poder se concentra en torno a los desarrolladores
- Las decisiones tecnológicas se toman con base en la comodidad del desarrollador más que en el usuario
Conclusión
Recuperar la esencia de la web es la solución
- Se necesitan sitios web que carguen rápido, puedan encontrarse en buscadores y sean fáciles de mantener
- La respuesta es volver a lo básico: HTML renderizado en el servidor, marcado semántico y JS mínimo
- Hace falta un enfoque centrado en los resultados más que en la tecnología
- Es necesario preguntarse: “¿por qué estamos usando esta tecnología?”
- Una web simple y centrada en el usuario ofrece rendimiento, reducción de costos y flexibilidad
23 comentarios
Con solo ver WordPress... parece que esa sería la respuesta al problema de arriba. Además, WordPress tiene mucha más cuota de mercado, aunque sea lento...
Creo que si hubiera resultados de benchmarks como evidencia, los desarrolladores podrían empatizar más. Sin duda, si hay un uso excesivo de frameworks el sitio se volverá más lento, pero personalmente he visto más veces que, en cuanto a la transición entre páginas dentro del sitio, un sitio hecho con código vanilla es más lento que un sitio con framework optimizado. Claro, si fuera un sitio compuesto solo de datos estáticos, quizá tener solo HTML + CSS sería más rápido, pero no estoy seguro de qué tan común es hoy en día un sitio hecho únicamente de datos estáticos.
Si no hubiera cosas como React o Vue,
aunque implementes la misma funcionalidad, tendrías que hacerlo con código más complejo, ¿no?
Sobre todo al manejar pop-ups, incluso pasar una sola
propen JavaScript puro hace que el código se vuelva mucho más complejo.Si incluso algo tan simple termina con código complicado, entonces
las funciones realmente complejas se vuelven difíciles de implementar.
Es una complejidad inevitable. Ya no es como antes, cuando era un HTML de plantilla simple.
No hay tantos tipos de navegadores que use la gente, pero sí hay demasiados frameworks. ¿No sería mejor que las empresas que gestionan los navegadores hicieran un framework óptimo y lo mantuvieran junto con ellos? ¿Hasta cuándo vamos a repetir este círculo vicioso?
La filosofía de desarrollo que persiguen varía muchísimo.........
Coincido con el diagnóstico del fenómeno, pero no con la conclusión.
La causa superficial del fenómeno, como también se menciona en el artículo, es que aumentó la demanda de una "web tipo app",
y tanto ahora como antes la web no era realmente adecuada para crear "algo parecido a una app", aunque si uno hace malabares, sí puede "lograr algo similar".
En realidad, la web desde su origen fue una plataforma creada para compartir una especie de "documentos", como los papers.
Eso se puede ver incluso solo observando los componentes básicos de HTML.
Luego aparecieron tecnologías capaces de generar contenido dinámico, como
cgi, y del lado del navegador también se integraron lenguajes de scripting, lo que permitió darle dinamismo al resultado, y así comenzó el alejamiento de la "web como documento".El problema es que, desde ese primer momento de ruptura hasta hoy, la base de la web sigue siendo un sistema fundamentado en "documentos".
Claro, han surgido muchas tecnologías nuevas que se apartan de esa orientación de "documento", como web socket, webrtc y wasm, pero incluso hoy la mayoría de los sitios web siguen desarrollándose sobre la plataforma tradicional basada en "documentos".
Seguimos teniendo que apilar etiquetas
divpara dibujar la pantalla.Hasta ahí llega el análisis del fenómeno, y entonces uno se pregunta cuál sería la respuesta.
Si imaginamos las funciones de una plataforma ideal de próxima generación sin pensar para nada en su viabilidad, sería algo así:
(No digo que todos los sitios deban ser así, sino solo los sitios con carácter de aplicación).
Para empezar, el navegador se convertiría en una especie de lanzador de apps.
Una vez descargada, debería poder ejecutarse también sin conexión.
Y la app se implementaría dejando atrás el actual html/css/js y usando otros lenguajes.
En ese proceso, parece que el navegador podría ofrecer una especie de framework, como Android.
La forma de comunicación con el servidor también podría salir del esquema tradicional de solicitudes web y probar otro paradigma.
En el caso de comunicaciones que requieran tiempo real, se podría incluso usar la comunicación
tcptal cual,y también se podría crear y usar una comunicación
rpcnueva, más simple, que no utilice el protocolohttp.No entiendo muy bien a qué se refiere con lo último que dijo sobre que era una plataforma idealizada.
Al final, estamos hablando de la época en que había que descargar un programa nativo y usar ActiveX ahí.
En esencia, el problema es que se está forzando la creación de una web tipo app dentro del protocolo HTTP, cuya base es el “documento” web.
La idea era que, si para resolver esto se necesitan funciones a nivel de aplicación, entonces quizá habría que crear un nuevo protocolo y framework pensados para apps.
Así como en un smartphone no se ejecutan programas nativos puros sino una especie de apps aisladas en sandbox, sería una estructura que se ejecute a nivel del navegador.
Claro, antes habría que garantizar apertura y estandarización para que no termine convirtiéndose en algo como ActiveX.
Incluso si se trata de una web tipo app, creo que deberíamos aspirar a algo cercano a la conclusión que plantea. Si se usa mucho JavaScript, del lado del cliente se vuelve pesada.
De hecho, no es que no existan frameworks con los que se pueda implementar así. Incluso en Next.js, si minimizas el uso de componentes del cliente y los usas solo cuando hace falta, más o menos se puede lograr. Y, como mencionó otra persona, en el ecosistema de Rails está Hotwire(https://hotwired.dev/), un conjunto de frameworks que soporta webs tipo app para acercarse bastante a la conclusión que menciona el autor (Turbo, Stimulus, etc.).
Estoy de acuerdo con la preocupación de fondo de este artículo, pero también hay partes que me hacen levantar un poco la ceja.
Por ejemplo, el sitio web promocional de cierto servicio que opera nuestra empresa mantiene justamente la misma simplicidad que este artículo elogia. Por suerte, la mayoría de los elementos de ese sitio son bastante estáticos. El código del frontend, como HTML y CSS, está escrito a mano por personas sin ningún framework, y de JS solo tiene jQuery y Google Analytics. Los avisos y el tablero, entre otras cosas, están implementados con AJAX usando jQuery, pero no me parece que eso sea algo irracional ni excesivamente complejo. De hecho, siento que está dentro del nivel que yo mismo podía implementar con jQuery cuando empecé a aprender desarrollo web básico hace mucho tiempo. Hasta donde sé, ese sitio existe desde la época de Internet Explorer, así que no lo hice yo directamente, pero me parece que no está nada mal.
Pero aun así tiene control de versiones con Git y un pipeline de CI/CD, y además están separados el servidor de staging y el servidor de producción. Cuando se fusiona un Pull Request en la rama Main, el pipeline despliega automáticamente en el servidor de staging los artefactos generados por el bundler, y después, cuando la persona responsable revisa el servidor de staging y aprueba finalmente el despliegue, eso se publica otra vez en el servidor de producción. Antes simplemente se sobrescribían directamente los archivos originales en el servidor de producción por FTP, pero después de que ese trabajo pasó a nuestro equipo lo cambiamos a este esquema.
¿De verdad esto es una complejidad irracional? Antes, modificar la etiqueta de título de ese sitio web era tan simple como entrar directamente al archivo HTML del servidor de producción con AcroEdit compatible con conexión por FTP (sí, las personas que originalmente escribieron a mano el HTML de ese sitio seguían usando eso) y cambiar una sola línea, guardar, y con eso terminaba todo el trabajo. Así que probablemente ellas sí podrían sentirlo de esa manera.
Sin embargo, yo creo que agregar este nivel de complejidad era perfectamente razonable. No todas las tareas equivalen a cambiar una sola etiqueta de título. Y me parece que sí son ventajas suficientes cosas como poder borrar sin miedo código viejo que antes quedaba pegado por todos lados solo comentado, porque siempre puede restaurarse; poder rastrear cambios y hacer rollback de forma transparente; o poder agregar, si hace falta, optimizaciones más básicas mediante el bundler. Incluso añadir un servidor de staging para previsualizar antes de desplegar en el entorno real podría verse como otra forma de complejidad, pero yo sí creo que era necesario.
Yo también tengo muchas quejas sobre cómo la estructura interna del código de varios sitios web se ha vuelto excesivamente compleja y pesada. Hoy en día la app de Outlook en Windows está basada en una web app, y últimamente se ha puesto todavía más pesada. Ya llega al punto de trabarse o incluso mostrar "La página no responde" solo por escribir el cuerpo de un correo en pantalla o seleccionar todo el contenido. Me pregunté por qué pasaba eso, abrí las herramientas de desarrollador en Outlook web y me llevé una sorpresa. Una vez borré la caché y recargué, seguían apareciendo solicitudes incluso después de 1 minuto. Al revisarlo en el navegador, vi que solo lo relacionado con el sitio de MS Office tenía almacenados varios gigabytes de datos.
Sin embargo, en este artículo se mezclan varias cosas: con algunas partes coincido, pero con otras no tanto. Según entiendo, en temas como HTML semántico o accesibilidad, el pasado era incluso peor. Además, eso de que mejorar la experiencia del desarrollador empeora la experiencia del usuario no me genera ninguna identificación, aunque quizá sea porque yo no soy desarrollador frontend web. Incluso eso de que todo el poder y el control se concentraron en los desarrolladores me suena absurdo. ¿Acaso el poder en una empresa no lo tiene la dirección? ¿O es que en Occidente la estructura de las empresas es algo distinta de la de Corea?
Como siempre, estoy totalmente de acuerdo en que el equilibrio y la moderación, así como la simplicidad y la practicidad, son valores importantes y deben priorizarse en la toma de decisiones. Pero este artículo sostiene que "tratar todos los sitios web como si fueran productos de software" es casi enteramente responsabilidad de los desarrolladores, y creo que esa parte más bien termina difuminando la preocupación de fondo. Y también pienso que las partes que parecen idealizar aquellos "buenos viejos tiempos" en los que no había procesos establecidos deberían ser objeto de crítica.
¿No es una historia completamente distinta de la que estás contando?
¿En qué parte piensas que se trata de algo completamente distinto?
Al final, creo que lo que este texto critica es la complejidad excesiva y la hinchazón que eso provoca. No considero que mi comentario sea completamente irrelevante solo porque no mencioné JavaScript en él. Si se quiere ver así, es una crítica a un aspecto más bien periférico. Y como mencioné desde el principio en mi comentario, yo también coincido con la conciencia del tema fundamental del texto original.
Creo que entendiste mal la intención del texto original.
Dijiste:
"...Aquí tienen control de versiones con Git y un pipeline de CI/CD, y además separaron el servidor de staging del servidor de producción. Cuando se fusiona un Pull Request en la rama Main, el pipeline genera los artefactos con el bundler y los despliega automáticamente en el servidor de staging; después, cuando la persona responsable revisa el servidor de staging y aprueba finalmente el despliegue, eso vuelve a desplegarse en el servidor de producción. Antes simplemente sobrescribían directamente los archivos originales en el servidor de producción vía FTP, pero después de que ese trabajo pasó a nuestro equipo, lo cambiamos para que funcionara así.
¿Eso de verdad es una complejidad irracional?"
Pero me parece que es un texto que no tiene mucha relación. El trabajo de desplegar y gestionar las cosas de esa manera y lo que este artículo está planteando son cosas bastante distintas.
La intención original del artículo no es simplemente criticar los frameworks de JS que se han vuelto más complejos.
Para mayor comodidad, citaré desde el enlace de la traducción al coreano que aparece arriba.
> Ahora, incluso para cambiar un simple título, se necesitan 4 ingenieros, 3 frameworks y un pipeline de CI/CD. Publicar una página web se ha vuelto absurdamente complejo.
> Así, gradualmente, la web se convirtió en algo que hay que compilar antes de publicar. No porque los usuarios lo necesitaran, sino porque los desarrolladores querían sentirse modernos.
> Todo se ha optimizado para los desarrolladores, y es hostil para todos los demás.
> Ya no solo toleramos la complejidad: la damos por sentada. Asumimos que todos los sitios necesitan una etapa de build, un bundler, una estrategia de hidratación, una capa de routing, una capa de API, un sistema de diseño y una lógica sofisticada de invalidación de caché. Construimos con microservicios, hospedamos en redes edge y desplegamos pipelines para entregar contenido simple.
> Estamos reconstruyendo las funciones de plataformas como WordPress, pero con un resultado 10 veces más pesado y mucho menos usable. Peor aún, cada nueva capa introduce nuevos bugs, nuevos problemas de compatibilidad y una nueva carga cognitiva. Ahora mantenemos lógica de hidratación, estrategias de caché y pipelines de build solo para poner una página de inicio en línea.
> Las campañas de marketing se retrasan porque la librería de componentes no es lo suficientemente flexible. Las pruebas A/B se cancelan porque la capa de analítica no es compatible con la estrategia de hidratación. Las actualizaciones de contenido tienen que esperar días por un build. Los ajustes básicos de SEO terminan enterrados en el backlog.
> Los marketers no pueden actualizar textos ni ejecutar experimentos sin abrir un ticket. No pueden previsualizar contenido, probar layouts ni publicar páginas. Todos los cambios tienen que pasar por desarrolladores, pipelines, aprobaciones y reconstrucciones.
> Marketers, editores de contenido, especialistas en SEO y diseñadores: todos quedan excluidos del proceso. Porque ahora incluso las tareas simples requieren fluidez técnica. Si quieres cambiar una title tag, te dirán que hables con un ingeniero; si quieres lanzar una campaña, que abras un ticket y esperes dos sprints.
> Todo fluye a través del equipo de desarrollo. Es decir, el equipo de desarrollo decide qué es importante, qué se despliega y qué queda indefinidamente relegado en la lista de prioridades. Y mientras más complejidad agregan, más indispensables se vuelven.
A diferencia de Corea, donde la cultura de desarrollo baja desde la dirección ejecutiva -> planificador -> desarrollador, en Occidente no existe ese concepto de planificador como en Corea y sí hay una participación más activa de los desarrolladores en la planificación del producto y similares. Los PM en Occidente, por ejemplo, no coinciden perfectamente con el planificador coreano, del mismo modo que una cover letter y una carta de presentación personal no son conceptos completamente idénticos. Claro, en los juegos, donde el carácter de proyecto creativo es fuerte y la diversión y la jugabilidad son importantes, Occidente también es más horizontal que Asia, aunque igualmente se baja del director al desarrollador.
Ya veo que existe esa diferencia.
Pero no parece ser algo muy relacionado con el contenido de arriba.
Usa Rails, sé feliz
Estoy de acuerdo con la idea principal de este artículo. Últimamente se está abusando demasiado de JS, así que hay muchos casos en los que un sitio se traba incluso usando un i9-9900k. Puede que sea una especificación algo ambigua para gaming o trabajo, pero la realidad es que abundan las computadoras de oficina con especificaciones peores que esa.
Por eso me gustan Astro y Hotwired, frameworks con la filosofía de usar JS solo cuando de verdad hace falta, como en las partes interactivas o en una navegación de página interactiva. También me gusta SSR, es decir, renderizar del lado del servidor. En cambio, detesto mucho CSR (incluyendo cuando solo se renderizan del lado del servidor las meta tags y el resto se maneja con CSR). Porque lo veo como trasladarle al cliente trabajo que debería hacer el servidor. Personalmente, creo que el enfoque tradicional de SPA que usa CSR debería usarse cuando el frontend se ejecuta localmente en una app como Electron. Claro, si el frontend se carga desde el servidor, entonces sí debería usarse SSR.
A continuación se presenta un resumen que clasifica las reacciones en los comentarios sobre la publicación en 5 tipos:
1. Acuerdo y apoyo total
Características principales: Coinciden plenamente con el argumento del texto y reconocen los problemas de una pila de JS compleja.
Ejemplos de opiniones:
2. Preocupación por el abuso de frameworks
Características principales: Critican el uso excesivo de frameworks como React y Angular, y opinan que con tecnologías simples es suficiente.
Ejemplos de opiniones:
3. Acuerdo parcial + consideración de la realidad
Características principales: Empatizan con el argumento, pero también existe una postura realista que ve la complejidad como algo inevitable o necesario.
Ejemplos de opiniones:
4. Crítica a la cultura de desarrollo y a la estructura de la industria
Características principales: Señalan que el exceso de frameworks no es solo un problema técnico, sino el resultado de estructuras de contratación, cultura y marketing.
Ejemplos de opiniones:
5. Crítica o desacuerdo
Características principales: No están de acuerdo con la premisa del texto o lo critican por ser una postura unilateral.
Ejemplos de opiniones:
Oh, al dividirlo por tipos queda cómodo de ver y está bueno.
Coincido con el problema de la “complejidad excesiva de la web” que señala el artículo original. Pero me cuesta estar de acuerdo con el diagnóstico que atribuye esa causa únicamente a la cultura de desarrollo o al abuso de frameworks. La complejidad de la web actual es, en gran medida, la sombra de funciones y seguridad inevitables que exige el “modelo de negocio”. Si se omite ese punto, el diagnóstico inevitablemente queda a medias.
La web ya no es una “sala de exhibición gratuita”. Hoy, salvo los sitios públicos, la mayoría de los servicios web tienen como objetivo generar ingresos. Por eso, la pregunta clave al elegir tecnología no debería ser “¿este código es puro?”, sino “¿esta tecnología ayuda a que nuestro negocio tenga éxito?”.
Visto desde esa perspectiva, la “web ligera de contenido” que el artículo idealiza termina chocando con la pared de las exigencias reales del negocio. Por ejemplo, un negocio que vende contenido no puede operar solo con páginas estáticas simples. Para gestionar suscripciones pagadas y pagos, se necesita lógica basada en estado, como autenticación de usuarios, verificación del estado de la suscripción y gestión de permisos; y para proteger el contenido, también es indispensable una capa de seguridad con validación de tokens en tiempo real para impedir la piratería o el acceso no autorizado. Además, si se busca mejorar la experiencia de usuario y la conversión mediante personalización y pruebas A/B, también se requiere procesamiento dinámico de datos.
Todo eso pertenece al terreno de las “aplicaciones sofisticadas”, y los frameworks son herramientas realistas para implementarlas.
Por supuesto, no toda complejidad puede justificarse. Debemos distinguir entre dos tipos de complejidad.
Complejidad inevitable: es la complejidad con un ROI claro que surge al implementar funciones de negocio (autenticación, pagos, personalización, etc.). Es un costo que hay que asumir.
Complejidad accidental: es la complejidad innecesaria que aparece por conveniencia del desarrollo o por una abstracción tecnológica excesiva. Es deuda técnica y desperdicio que deben medirse y eliminarse de forma continua.
Los servicios exitosos distinguen entre ambas y construyen arquitecturas realistas. Es decir, hacen lo más liviano posible el frente de cara al público, donde el marketing y el SEO son importantes, y aseguran estabilidad con una base de frameworks en las áreas internas donde se necesitan transacciones críticas o funciones de personalización, adoptando una estrategia híbrida que les permite atrapar a la vez dos objetivos: velocidad y funcionalidad.
El artículo original se concentra solo en la cultura de frameworks como causa del deterioro de la experiencia de usuario, dejando fuera las “exigencias inevitables que trae el modelo de ingresos”. Hablar del desarrollo web sin considerar ese punto no es muy distinto de hablar solo de servir “comida rápida y sabrosa” en la mesa del cliente, mientras se hace como si no existieran la cocina compleja donde se prepara ni la caja donde se cobra.
Que la web se haya vuelto pesada no significa que podamos desechar los frameworks sin más. Creo que la discusión debería centrarse en cómo implementar, de la forma más eficiente y con el menor costo posible, las funciones que exige el negocio para entregar valor al usuario.
La traducción al coreano está abajo.
https://junghan92.medium.com/%EB%B2%88%EC%97%AD-%EC%9E%90%EB%B0%94%EC%…