Durante los últimos dos años, he escuchado el término Aplicaciones Web Isomorfas mencionado de manera positiva cada vez con más frecuencia. También durante este tiempo, he pensado en la técnica. Mi conclusión es que las Aplicaciones Web isomórficas son algo que no agregaría valor para mí o para las organizaciones típicas para las que trabajo. Varias cosas me han llevado a esta conclusión.
Pero, antes de enumerar las razones, permítanme enfatizar primero que creo que las bibliotecas javascript isomórficas (es decir, lodash.js) son increíbles. Además, creo que los componentes isomórficos aislados pueden ser valiosos, por ejemplo, un indicador de mercado de valores actualizado en vivo.
Las razones por las que no creo que las Aplicaciones Web Isomorfas sean valiosas para mí o para las organizaciones para las que trabajo son:
- El servidor web ahora solo se puede escribir en javascript
- Las aplicaciones Web isomórficas nunca pueden ser Mejoras progresivas para aplicaciones no triviales
- Bloqueo vs flujo de datos sin bloqueo
- Tiempo de interacción y el Valle Misterioso
- Los dispositivos móviles se congelan durante el análisis de javascript
- Sus mejores desarrolladores ahora están ocupados sin producir valor
Quiero comenzar con una definición de Aplicaciones Web isomorfas. Una aplicación Web isomorfa es una aplicación web en la que el código de la aplicación no sabe dónde se ejecuta. En su lugar, este conocimiento se mantiene en el código de infraestructura y permite que la aplicación en su conjunto se ejecute tanto en el lado del cliente como en el lado del servidor.
- El servidor web ahora solo se puede escribir en javascript
- Las aplicaciones Web isomorfas nunca pueden ser Mejoras progresivas para aplicaciones no triviales
- Flujo de datos de bloqueo vs flujo de datos sin bloqueo
- Time-to-interaction y the Uncanny Valley
- Los dispositivos móviles se congelan durante el análisis de javascript
- Sus mejores desarrolladores ahora están ocupados sin producir valor
- Resumen
- Agradecimientos
El servidor web ahora solo se puede escribir en javascript
Si el código del cliente y el código del servidor son los mismos (y el cliente hoy solo puede interpretar javascript), entonces estamos limitados a usar javascript solo en el servidor. Me gusta node.js mucho, pero creo que es mejor estar abierto a alternativas en el futuro, en mi perspectiva.
Las aplicaciones Web isomorfas nunca pueden ser Mejoras progresivas para aplicaciones no triviales
javascript del lado del cliente tiene acceso a una máquina de estado en memoria que permite un nivel de interacción fino, con una latencia muy baja (sub milisegundos). Lo mismo no es cierto para la máquina de estado HTTP, que es impulsada por clics en enlaces y envíos de formularios.
Para mí, la mejora progresiva consiste en comenzar con una línea de base accesible para todos los dispositivos/navegadores posibles, desde los antiguos hasta los actuales y los futuros. En la práctica, esto significa una línea de base de renderizado del lado del servidor. El paso de mejora es una decisión empresarial sobre dónde mejorar el sitio / aplicación para aumentar el valor. En otras palabras, la mejora se realiza en el código de aplicación (específico) y *no* en el código de infraestructura (general), excepto para técnicas de optimización como pjax o turbolinks.
La forma en que las Aplicaciones Web Isomorfas obtienen mejoras Progresivas es tomar esta máquina de estado en memoria de grano fino y «traducirla» para usar solo enlaces y formularios. Los únicos casos en los que puedo ver que esto es posible es en los que no necesitó una representación completa del lado del cliente en primer lugar, sino que podía confiar en las técnicas de optimización y los componentes del lado del cliente mencionados anteriormente para mejorar la experiencia (es decir, un componente de calendario para un campo de entrada para una fecha).
Una variante de esta solución es no admitir todos los estados/transiciones del lado del cliente en la máquina de estados del lado del servidor. En este caso, esta debe ser una decisión empresarial que debe reflejarse en el código de la aplicación, lo que hace que el entorno del código de la aplicación sea sensible, lo que va en contra de la idea de Aplicaciones Web isomórficas.
La forma en que las Aplicaciones Web Isomorfas obtienen mejoras progresivas es tomar esta máquina de estado en memoria de grano fino y «traducirla» para que solo use enlaces y formularios.
Flujo de datos de bloqueo vs flujo de datos sin bloqueo
La secuencia de procesamiento para la web del lado del servidor y la web del lado del cliente son diferentes: el lado del servidor bloquea y el lado del cliente no bloquea.
Imagine que necesitamos hacer dos solicitudes a algunos servicios para renderizar una vista. Podemos hacer estas peticiones en paralelo.
En el lado del servidor, si la segunda solicitud regresa primero, puede renderizar esa parte de la respuesta, pero necesita bloquear el envío de esos bytes hasta que la primera haya renderizado y devuelto esa parte de la respuesta al navegador.
En el lado del cliente, esta restricción no existe: las dos respuestas se pueden manejar y representar de forma independiente.
Además, creo que lo anterior representa el ejemplo más simple. Imagine que tiene un árbol de componentes, donde el componente raíz es inteligente (consulte Componentes Presentacionales y Contenedores para obtener una explicación de los componentes inteligentes/tontos), seguido de algunos niveles de componentes tontos, y luego al menos un componente hoja que es inteligente.
La infraestructura necesita una forma de asegurarse de que el contexto de la hoja inteligente no se pierda, de modo que perdamos el control de la ejecución de bloqueo/no bloqueo, dependiendo del modo servidor/cliente. Una forma de resolver este problema podría ser hacer que todo el programa se ejecute en una mónada libre, representando la ejecución como datos para ser interpretados posteriormente. Otra solución podría ser usar algún tipo de patrón de visitante y dejar que los componentes declaren qué datos necesitan (similar a Tutorial: Elaboración manual de una Aplicación Redux isomórfica (Con Amor)). Esto último es probablemente más fácil. Mi punto es que el problema de los diferentes modos de bloqueo es probablemente mucho más complicado de lo que uno imagina inicialmente.
Un diseño alternativo es tener una regla que diga «solo el componente raíz puede ser un componente inteligente», similar a la forma en que podría usar la Mónada IO en Haskell, manteniendo las hojas puras y solo teniendo efectos secundarios en el nivel superior. Creo que este diseño es bueno en el lado del servidor, pero no en el lado del cliente: un componente en el lado del cliente debe ser capaz de cargar sus propios datos en al menos algunos escenarios, por ejemplo, con respecto a los componentes relacionados con las redes sociales. Tener una regla que nunca permita estos escenarios parece muy improductivo.
Time-to-interaction y the Uncanny Valley
Con el enfoque de Aplicaciones Web Isomórficas, habrá una cantidad de tiempo en la que el usuario verá elementos gráficos en la pantalla que parecen ser interactivos pero no lo son. En otras palabras, el tiempo entre el momento en que el navegador ha renderizado la respuesta del servidor y el momento en que se descarga, analiza y ejecuta el javascript. Esto se llama el «Valle Misterioso» o «Pueblo Potemkin».
Consulte este tweet y las respuestas para obtener más detalles.
Los dispositivos móviles se congelan durante el análisis de javascript
En un teléfono móvil «típico», se obtiene un bloqueo de hilo de interfaz de usuario de 1 ms por javascript de 1 KB, según este tweet. Malte Ubl es el líder técnico del proyecto AMP, así que sospecho que sabe de lo que está hablando.
Sus mejores desarrolladores ahora están ocupados sin producir valor
Las aplicaciones Web isomorfas son un enfoque que exige un alto nivel de habilidad de desarrollo. En muchas áreas (al menos en el mundo occidental), es difícil encontrar y reclutar desarrolladores altamente calificados. La elección de desarrollar Aplicaciones Web isomorfas asigna a esos desarrolladores a hacer algo que cuestiono que produzca cualquier valor comercial. Hay mejores maneras de aprovechar su tiempo.
Resumen
Las aplicaciones Web isomorfas limitan la elección de idioma/plataforma de su servidor web para que solo sea javascript. Tiene la ambición de permitir una Mejora Progresiva, pero no puede dar resultados. Introduce un alto nivel de complejidad técnica debido a las diferencias en el flujo de datos de bloqueo y no bloqueo. Introduce una ventana de tiempo donde las cosas parecen ser interactivas, pero no lo son (el Valle Misterioso). Una gran cantidad de javascript también congela los navegadores móviles, con la regla general de que 1 KB de javascript significa 1 ms de hilo de interfaz de usuario estancado. Y, dado que requiere un diseño de software complicado, sus mejores desarrolladores necesitan tiempo y esfuerzo valiosos: hay una mejor manera de aprovechar su tiempo.
Finalmente, quiero enfatizar que sus experiencias pueden ser diferentes a las mías. Tal vez haya escenarios en los que las aplicaciones Web isomorfas sean buenas. Pero no son una solución mágica para cerrar cada brecha entre los beneficios de la web del lado del servidor y los beneficios de la web del lado del cliente, al tiempo que no obtienen ninguno de los inconvenientes de ambos enfoques.
¿Qué opinas? ¿Has considerado «ir isomórfico»? ¿Tiene alguna idea sobre los desafíos y los costos? ¿Cómo lidias con ellos?
Agradecimientos
Gracias a Oskar Wickström y Per Ökvist por sus valiosas discusiones sobre este tema. Oskar también revisó este post-gracias Oskar.
