Servers: Cool Once Again

Hubo chistes de las vacaciones de que JavaScript decidió ir completamente al lado del servidor. Creo que tuvo sus raíces en:

• La pandilla de Basecamp lanza Hotwire , que parece un estilo de marketing en torno a una combinación de tecnologías. “HTML por cable”, dicen, lo que significa que hace que el servidor genere y entregue HTML, y deja JavaScript del lado del cliente para cosas que sólo JavaScript del lado del cliente puede hacer.
• La pandilla React presenta los componentes del servidor React de tamaño de paquete cero , que creo que es el primer paso del proyecto central hacia cualquier cosa del lado del servidor.

Me refiero a algunas exageraciones de marketing, pero vale la pena señalar que estas son solo nuevas versiones de ideas que ya son sólidas (me atrevo a decir viejas ).

Turbo ( “El corazón de Hotwire” ) es una evolución de Turbolinks , que tiene una idea base tremendamente sencilla: interceptar clics en enlaces internos. En lugar de que el navegador actualice la página completa, fetchel contenido de la nueva página, lo coloca en su lugar y History.pushState()la URL. Ahora tiene la sensación de ser una aplicación de una sola página, pero no tuvo que crear un SPA. Esto es muy conveniente si ya ha creado su aplicación en Rails con plantillas ERB.

¿Pero es eso realmente eficiente? Bueno, hasta ahora no ha sido particularmente popular. La idea ha sido que la red es el cuello de botella, así que enviemos lo menos posible a través de la red. “Lo menos posible” normalmente se traduce en JSON. Si obtiene JSON en el cliente, ahora necesita un sistema de plantillas en el cliente para convertirlo en DOM utilizable. Con esa técnica, estás pagando dos costos: 1) cargar una biblioteca del lado del cliente 2) procesamiento de datos a DOM. Si envió “HTML por cable”, no paga ninguno de esos costos (más rápido), pero en teoría está enviando cargas útiles más potentes a través de la red (más lento), lo que supone que HTML es más pesado que JSON, lo cual es… cuestionable.

Entonces… depende . Depende del tamaño de las cargas útiles y de lo que se espera hacer con ellas.

Es de esperar que la opinión de React sea: definitivamente use el cliente. Pero eso no es cierto con la nueva vista previa de los componentes del lado del servidor . El video es muy claro: “renderizar” los componentes en el servidor es más rápido, particularmente en situaciones de componentes anidados donde muchos de los componentes son responsables de buscar sus propios datos. Entonces, ¿qué aparece en la red? ¿Es HTML listo para DOM? Aqui no. Al echar un vistazo al video, parece que la respuesta de la red es algún formato propietario ¹ que describe un componente de React. Eso parece importante porque significa que el paquete JavaScript del lado del cliente no contiene ese componente en absoluto, y el estado ² se puede pasar de un lado a otro. Lauren Tan también es clara en el video: esto es un poco SSR pero distinto de cómo algo, como Next.js, hace SSR hoy. Y el objetivo es hacer que el Next.js del mañana sea mucho mejor.

Entonces: servidores . Simplemente son buenos para hacer ciertas cosas (dice el tipo que escribe en su blog de WordPress). Parece haber cierto impulso para hacer menos con el cliente, algo que creo que la mayoría de nosotros estaríamos de acuerdo en que últimamente se ha hecho demasiado, cuyos tamaños de activos no hacen más que crecer y crecer.

Llevemos esos servidores al límite mientras estamos en ello.

1. Es un formato propietario. Me dijeron que es como “JSON con agujeros”, es decir, fragmentos de JSON que están separados por espacios en blanco y una nueva línea. Pero, si bien el formato importa un poco porque es posible que te encuentres inspeccionando solicitudes de red por razones de depuración, React habla con React, no es una API abierta donde el formato importaría mucho más.
2. El “estado” principal que se pasa es como la ruta actual. Me han dicho que pases lo menos posible al servidor. El servidor no tiene ningún estado.