- Algunos desarrolladores creen que los frameworks SPA (React, AngularJS, etc.) son indispensables para crear aplicaciones de alta calidad
- Sin embargo, incluso antes de las SPA, las aplicaciones basadas en MPA ya ofrecían una excelente experiencia de usuario
- Intenté desarrollar una plataforma de observación basada en MPA y centrada en datos usando HTMX, y con la optimización adecuada, incluso una MPA renderizada en el servidor puede ofrecer un rendimiento sobresaliente y una gran experiencia de usuario
Mitos y realidades sobre las MPA
Mito 1: las MPA son lentas al cambiar de página
- Problema: el navegador vuelve a descargar JavaScript y CSS en cada transición de página de forma predeterminada
- Solución:
- Usar librerías como PJAX, Turbolinks o HTMX Boost para reemplazar solo el
body del HTML
- También se puede usar un service worker para mejorar el caché de páginas y el manejo de solicitudes
- Ejemplo: al aplicar un service worker, el tiempo de
DOMContentLoaded se redujo de 2.9 segundos a 500 ms
Cómo implementar un service worker
- Crear el archivo
sw.js: escribir un script para gestionar el caché y las solicitudes de red
- Definir la lista de archivos en caché: especificar recursos clave como HTML, CSS y JS
- Configurar la estrategia de caché: mantener en caché permanente los recursos estáticos o actualizarlos periódicamente
Mito 2: una MPA no puede funcionar sin conexión ni guardar solicitudes para reintento tras recuperar la red
- Con un service worker, la app puede funcionar incluso en estado offline
- Uso de Workbox:
- Si falla la red, almacena las solicitudes y las reintenta dentro de un máximo de 24 horas
- Se puede configurar un manejador offline para devolver contenido alternativo cuando haya solicitudes
Mito 3: las MPA producen parpadeo de pantalla al cambiar de página
- Solución:
- Retrasar el pintado de la pantalla con un service worker y la API de precarga hasta que los recursos estén listos
- Desde 2019, los navegadores manejan las transiciones dentro del mismo dominio sin parpadeos
Mito 4: las MPA no pueden implementar efectos vistosos de transición entre páginas
- Las SPA son famosas por sus animaciones de transición, pero los navegadores también han empezado a soportarlas
- En Chrome 126 es posible implementar animaciones de transición entre documentos solo con CSS
- Enlace de demo
Mito 5: en HTMX o en una MPA, todas las acciones del usuario se procesan en el servidor
- HTMX está diseñado para que solo algunas tareas se procesen en el servidor
- Si hace falta, se pueden agregar funciones interactivas del lado del cliente con WebComponents o frameworks de JavaScript
- También se puede aplicar el enfoque SPA solo a componentes específicos
Mito 6: manipular el DOM es lento; por eso se necesita React/Virtual DOM
- El Virtual DOM solo muestra diferencias de rendimiento en aplicaciones extremadamente complejas
- En la mayoría de las aplicaciones comunes, manipular el DOM directamente es lo bastante rápido
- Material de referencia: "Virtual DOM is pure Overhead"
Mito 7: incluso para funciones interactivas pequeñas se necesita JavaScript
- Con las tecnologías modernas del navegador, es posible implementar varias funciones sin JavaScript
- Se pueden crear funciones de alternancia con checkboxes HTML y CSS
- Al combinarlo con HTMX, se pueden cargar datos de forma asíncrona al hacer clic
Mito final: sin una SPA, el código del lado del cliente termina convertido en spaghetti code
- Incluso en la era del spaghetti code se desarrolló mucho software productivo
- En la etapa inicial de un MVP, una estructura simple puede ser más conveniente
Conclusión
- En 2024, los navegadores han avanzado mucho al integrar lo aprendido de la revolución SPA
- Solo con las herramientas nativas del navegador (HTML, CSS, JavaScript) ya es posible crear aplicaciones interactivas y capaces de funcionar offline
- Vale la pena volver a confiar en el potencial del navegador y aprovecharlo una vez más
8 comentarios
Si te pones a desarrollar con programadores más o menos del montón, te das cuenta enseguida de lo fantasioso que es esto. Parece que quien escribió esto está rodeado de genios o trabaja solo... (con solo ver que menciona ahora a AngularJS, que ya pasó de época, se nota). Y además, el desarrollo no se hace solo con genios.
Alguien podría menospreciarlo diciendo que "se juntan entre los suyos", pero los cambios siempre los ha hecho la gente común.
Cuando veo cosas así, lo primero que pienso es que htmx jamás debería ser aceptado.
Aunque es un tema que sigue apareciendo una y otra vez últimamente,
hay un video de Rich Harris de hace algunos años en el que da su opinión sobre este tema.
https://www.youtube.com/watch?v=860d8usGC0o&t=635s
Si mal no recuerdo, se podría resumir así: los enfoques que actualizan basándose en HTML parcial pueden generar la posibilidad de inconsistencias entre la interfaz y los datos.
¿Todavía confías en las especificaciones del navegador...?
Si tuviera que decirlo de algún modo, creo que las SPA son una forma de desarrollar aplicaciones que depende un poco menos del comportamiento del navegador.
Es cierto que el navegador ha seguido bastante bien las posibilidades geniales de las SPA y que eso parece encajar mejor con la forma de comunicación para la que HTTP fue diseñado originalmente, pero quizás eso se deba a que Chrome llegó a tener una posición prácticamente monopolística en el mundo de los navegadores y, por eso, hubo margen para hacerlo... No sé si eso vaya a durar mucho, ya sea ese margen o esa cuota de mercado...
Si hablamos de manipular el DOM desde el servidor sobre una base de WebSocket, como en Phoenix LiveView, entonces el paradigma es distinto.
Cuando probé htmx, eso de tener que devolver HTML fragmentado desde el servidor no me resultó muy agradable.
Sobre todo en la parte de CSS: si envías clases definidas desde el servidor, desde el lado del servidor no hay forma de saber qué CSS se está usando en la pantalla, así que en la práctica se siente como si te obligara a usar un CSS común.
Hace unos años intenté crear una UI algo compleja con Phoenix LiveView, pero implementar interacciones simples era demasiado complicado y, como cada LiveView se maneja como un proceso de Elixir, la interacción con el componente de al lado es muy difícil. Al final me rendí y recuerdo que volví a React.
Siento que LiveView es el futuro...
Como LiveView también depende mucho de la red, cuando el servidor está en una ubicación remota y el ping es alto, o en lugares como el tercer mundo donde la infraestructura de internet no es buena, sí tiene una gran desventaja.
Opiniones en Hacker News
Hay curiosidad sobre por qué el artículo no menciona cómo aprovechar el caché del navegador para manejar recursos estáticos de CSS y JS. En el pasado, al construir un sitio de compras con un enfoque MPA, las transiciones entre páginas casi no se notaban
También hay quienes sostienen que el desarrollo web de la época de PHP y jQuery era el más productivo. Hay opiniones que se preguntan si ese paradigma del pasado podría ser más productivo que tecnologías modernas como React. Incluso sitios grandes como Amazon o Steam siguen construyéndose renderizando HTML en el servidor y agregando JS
Hay comentarios que piden explicar en qué es mejor la estrategia de service workers frente a los encabezados de caché HTTP tradicionales. Puede reducir los viajes de ida y vuelta por la red, pero da la impresión de reinventar todo por una optimización menor
El título "You Can't Build Interactive Web Apps Except as Single Page Applications... And Other Myths" da una sensación de clickbait porque se omite parte del significado
Lo más peligroso en programación es el aburrimiento del desarrollador y la ignorancia del pasado
Hay opiniones que dicen no entender por qué existe esa dicotomía entre el lado del servidor y el lado del cliente (SPA) en la era de los servidores web con Node.js. Surge la pregunta de si no se podría inicializar la mayor parte del trabajo en el servidor, serializarlo al cliente y hacer que funcione como una SPA
Existe la tendencia de ver SPA y MPA como equipos opuestos, pero también se pueden distinguir como una forma natural de usar el stack web frente a una forma de "hackearlo". Las SPA serían hoy la forma hacky, pero antes estuvieron CGI, los applets de Java y Flash. Las formas hacky sirven para expandir los límites del enfoque natural
Antes que decidir el stack tecnológico, muchas veces los desarrolladores entienden mal qué están construyendo. Si no se necesita un nivel alto de interactividad, en la mayoría de los casos un framework del lado del servidor puede ser suficiente
Hay una refutación al mito de que "no se pueden construir apps web interactivas si no son single-page apps". Las SPA ofrecen más control y reducen la posibilidad de tener que rehacer partes del código
El titular en HN es más agresivo que el titular real. Se trata de un ensayo presentado por Tony Alaribe en BigSkyDevCon, donde se discuten técnicas para hacer rápidas y fluidas las aplicaciones web que no están basadas en SPA. Presenta nuevas técnicas y hay quien piensa que fue la mejor charla de la conferencia