Espectro de renderizado

Estas son las grandes categorías de sitios web de renderizado:

• Cliente : envíe un div/divy deje que una plantilla de JavaScript lo represente todo.
• Estático : renderiza previamente el HTML.
• Servidor : permite que un servidor en vivo procese las solicitudes y genere la respuesta HTML.

No son mutuamente exclusivos.

• Un sitio web podría renderizar previamente estáticamente el 75% de sus páginas (por ejemplo, publicaciones de blog), pero el otro 25% tiene un servidor que responde (por ejemplo, foros).
• Un sitio web podría renderizar previamente estáticamente todas las páginas, pero tener un par de divmensajes de correo electrónico vacíos que tienen contenido renderizado del lado del cliente (por ejemplo, un menú generado dinámicamente según el usuario que inició sesión).
• Un sitio web podría renderizarse principalmente en el servidor, pero tiene un almacenamiento en caché delante de modo que se comporta de forma estática.
• Un sitio web podría renderizarse estáticamente, pero luego “hidratarse” hasta convertirse en un sitio completamente renderizado por el cliente.
• Un sitio web podría ser una combinación de servidor y renderizado estático, pero tiene partes dinámicas similares al renderizado del lado del cliente, pero en realidad ocurre en una función perimetral, por lo que termina más como un renderizado del lado del servidor.

Next.js es interesante porque puede hacer las tres cosas. Aquí está Tim Neutkens en una entrevista reciente :

Next.js le permite prerenderizar páginas. Crea HTML en un servidor en el momento de la compilación con generación de sitio estático o utiliza renderizado en tiempo de ejecución en el lado del servidor. Next te permite hacer un híbrido de esos. A diferencia de la mayoría de los otros marcos, no estás sujeto a, oh, voy a crear mi aplicación completamente generada estáticamente. En su lugar, se le permite que algunas páginas se representen en el lado del servidor y otras se generen estáticamente.

En la nueva versión, hacemos posible actualizar estas páginas generadas estáticamente sin tener que ejecutar una nueva compilación, reconstruyendo toda su aplicación.

Fresco. Me encanta ver que eso suceda a nivel de marco. Parece que tener que apostar por un estilo de renderizado no es práctico para muchos sitios.

El renderizado del cliente es el más flexible, pero tiene todas estas desventajas graves, como peor rendimiento, peor confiabilidad, más tensión en los dispositivos, mal SEO, etc. El renderizado previo estático es el más sólido, rápido y seguro, pero es el más limitado. . Las funciones perimetrales además de las estáticas están empezando a abrir puertas, pero el renderizado en servidor es la combinación clásica de flexibilidad y velocidad que ha dominado la web por una buena razón.

La representación del cliente también abre la puerta a esa sensación de “SPA” (aplicación de página única). Todavía me gusta eso, personalmente. Me gusta la sensación de no actualizar la página. Hace que un sitio se sienta ágil y abre la puerta a transiciones de página. Gatsby es famoso por popularizar la hidratación, donde obtienes el bono estático pre-renderizado, pero luego la actualización a SPA a medida que se descarga JavaScript.

Me encantaría ver que la web llegue al punto en el que obtengamos toda esa ventaja de “buena sensación” de un SPA sin tener que construir un SPA. Es notable cuando los marcos brindan sensaciones de SPA sin tener que administrar gran parte de eso usted mismo, pero aún así, algo lo está administrando y ese algo es un montón de JavaScript.

Tom MacWright escribió sobre esto recientemente en su artículo “If not SPAs, What?” correo. Algunas de las alternativas actuales:

Turbolinks … ¿cuál es lo mínimo que debe hacer para obtener la experiencia SPA sin la cooperación de su aplicación?

Turbolinks es como… hacer clic en el enlace, el clic es interceptado, se realiza una solicitud Ajax para una nueva página, JavaScript elimina el contenido de la página con el nuevo contenido. Súper fácil de implementar, pero sigue siendo JavaScript y no es particularmente inteligente en cuanto a enviar menos datos a través del cable.

barba.js e instant.page son enfoques alternativos para el mismo tipo de problema.

Barba se trata de poner en marcha las transiciones de página ( más detalles sobre ese concepto ). instant.page se trata de precargar/renderizar páginas justo antes de hacer clic, por lo que aunque se actualice la página, se siente menos intrusivo (particularmente con pintura retenida ). Ambos son reemplazos interesantes, pero no exactamente uno a uno, para un SPA. (Incluso con retención de pintura, renderizado previo y páginas livianas, todavía no creo que la experiencia sea tan fluida como un SPA. Por ejemplo, todavía aparece el control giratorio de carga de páginas).

Entonces… ¿se está cocinando algo más? Un poco. Hay portal. Posiblemente demasiado simplificado, pero ahí va: los portales son como iframes. Incluso se pueden mostrar visualmente como un iframe. Eso significa que la representación de la URL en el portal ya está hecha. Luego puede “promocionar” el portal para que sea la página activa e incluso animar el portal mientras lo hace.

No lo odio. Me imagino a alguien construyendo una biblioteca tipo turbolinks en portales para que sean “fáciles de usar” y hagan que un sitio se parezca más a un SPA.

Aun así, animar un rectángulo a su posición no suele ser lo que se desea en las transiciones de páginas animadas. Basta con mirar el artículo de Sarah “Animaciones nativas para transiciones de páginas en la Web” . Eso es lo que la gente quiere (al menos la posibilidad de que así sea). Es por eso que Jeremy dijo no portales el otro día cuando dijo descaradamente que “ la mayoría de las aplicaciones de una sola página son simplemente carruseles gigantes. También señala la propuesta de transición de navegación de Jake de hace unos años.

Me encanta esta propuesta . Se centra en las necesidades del usuario. También pregunta por qué la gente recurre a marcos de JavaScript en lugar de utilizar lo que ofrecen los navegadores. La gente recurre a marcos de JavaScript porque los navegadores aún no proporcionan algunas funciones: componentes como pestañas o acordeones; diferencia DOM; control sobre el estilo de elementos de formularios complejos; transiciones de navegación. Los problemas que los marcos de JavaScript están resolviendo hoy deberían verse como los departamentos de I+D para los estándares web del mañana. (Y a la inversa, creo firmemente que el objetivo de cualquier buen marco de JavaScript debería ser volverse redundante ).

Entonces, ¿cuál es el mejor método de renderizado? Lo que funcione mejor para usted, pero quizás una jerarquía como esta tenga algún sentido general:

1. HTML estático tanto como puedas
2. Edge funciona sobre HTML estático para que puedas hacer cualquier cosa dinámica
3. HTML generado por el servidor, lo que tienes que hacer después de eso
4. El lado del cliente renderiza solo lo que es absolutamente necesario