Cosas que los ingenieros creen sobre el desarrollo web

Artículo original ↗ Discusión en Hacker News ↗

Los ingenieros debaten mitos comunes sobre el desarrollo web moderno, desde si los navegadores son realmente buenos manejando interfaces dinámicas complejas hasta cuándo se justifican los frameworks de aplicaciones de una sola página frente a sitios multipágina más simples renderizados en el servidor. Muchos sostienen que las pilas pesadas de JavaScript, los pasos de build y las arquitecturas SPA se usan en exceso para sitios básicos CRUD y de contenido, creando costes de rendimiento, accesibilidad y mantenimiento que superan los beneficios de UX, mientras que otros responden que las herramientas frontend reactivas son más productivas cuando la interactividad crece. Debajo de todo hay una tensión más amplia entre “la herramienta más simple que funciona” y “la pila más flexible/moderna”, moldeada por la familiaridad del desarrollador, los incentivos de contratación y la división entre las expectativas de aplicaciones de estilo escritorio (p. ej., Figma, Photoshop) y el modelo original del web centrado en documentos.

Rendimiento de renderizado del navegador y alternativas

  • Algunos discrepan de que los navegadores sean “buenos” con árboles DOM complejos y de larga duración; otros sostienen que décadas de optimización los hacen difíciles de superar para árboles dinámicos.
  • Alternativas citadas: WPF (Windows) y Avalonia (multiplataforma), con enlace de datos y plantillas integrados; motores de juego y renderizadores WebGL/canvas que manejan fácilmente miles de objetos animados.
  • Ejemplos: Figma, Google Docs/Sheets y Photoshop en la web eluden gran parte del DOM usando WebGL/canvas/WASM, algo que algunos ven como evidencia de que el DOM es una mala elección para interfaces complejas.

JavaScript, degradación elegante y accesibilidad

  • Una minoría vocal aboga por sitios que funcionen sin JS, especialmente contenido y aplicaciones CRUD simples, por robustez, pruebas y accesibilidad.
  • Otros ven a los usuarios con JS desactivado como algo insignificante y sostienen que la realidad del negocio no justifica diseñar para ellos.
  • Contraargumentos: redes inestables pueden “desactivar” JS en la práctica, los microbrowsers/crawlers no ejecutan JS completo, y las SPA pesadas degradan la UX en dispositivos de gama baja o móviles.

SPA vs MPA, espectro de interactividad y elección de herramientas

  • Gran tema: Figma/Photoshop se usan en exceso como justificación para stacks SPA en aplicaciones mayormente CRUD.
  • Un bando: preferir JS mínimo y MPAs renderizadas en el servidor para aplicaciones más simples; la complejidad debería vivir en el backend; las SPA son un “motte-and-bailey” (claramente correctas para editores ricos, débiles para la mayoría de las apps).
  • Otro bando: las SPA (React/Preact/Vue, etc.) resultan arquitectónicamente más simples para interacciones ricas, acumulan beneficios a medida que crecen las funcionalidades y ofrecen UIs más fluidas (p. ej., filtros facetados, mapas).
  • Muchos señalan patrones intermedios: mejora progresiva, actualizaciones parciales de HTML (estilo Turbolinks/Hotwire), server components, islands/SSR, e incrustar widgets SPA aislados dentro de MPAs.
  • Compromisos de UX: las SPA pueden sentirse más rápidas y fluidas, pero a menudo gestionan mal el historial, fallan con conectividad intermitente y envían bundles de JS grandes; las MPA pueden parpadear y sentirse “bruscas” sin optimización.

Pasos de build, tooling y DX

  • Algunos sostienen que “la web no debería necesitar un paso de build”; los pipelines de build añaden latencia, complejidad y roturas frecuentes al volver a proyectos antiguos.
  • Otros defienden los pasos de build por tree-shaking, bundling, HMR y tipado estático mediante TS/Rust/WASM, al tiempo que señalan que el tooling de build de JS es inusualmente frágil y cambia con rapidez.
  • Alternativas mencionadas: includes simples del lado del servidor, generadores de sitios estáticos, o incrustar UIs de administración directamente en servicios backend en lugar de frontends Node separados.

Apps de escritorio vs web y sandboxing

  • Un lado prefiere las aplicaciones pesadas como software nativo de escritorio, viendo el navegador como un visor de documentos.
  • Otros prefieren firmemente ejecutar esas apps en el navegador por el sandboxing y la facilidad para desmontarlas, citando clientes nativos invasivos (p. ej., procesos en segundo plano que siempre están en ejecución).
  • Un largo subhilo debate si los navegadores son “más seguros” que las apps nativas o móviles, frente a ser simplemente otra capa de sandbox (muy compleja); surgen preocupaciones sobre el monocultivo de Chromium frente a los duopolios de las tiendas de aplicaciones.

Otros temas recurrentes

  • Tensión frecuente entre “la herramienta más simple que funciona ahora” y “la herramienta flexible que podría cubrir necesidades futuras”.
  • Quejas sobre elecciones tecnológicas motivadas por el currículum y por la moda.
  • Observaciones de que las especificaciones del navegador y los equipos de engines a menudo carecen de perspectiva del desarrollo web del día a día; a la inversa, muchos desarrolladores web malinterpretan las limitaciones de los engines.