Componentes: lado del servidor versus lado del cliente

¿Crear un sitio web en 2021? Supongo que adoptará un enfoque basado en componentes. Es toda la charla estos días. React y Vue están en todas partes (¿Angular sigue existiendo?), mientras que otros marcos emergentes continúan intentando destacarse.

Durante la última década, hemos visto una explosión de marcos y herramientas que nos ayudan a construir sitios sistemáticamente utilizando componentes. Los primeros marcos como AngularJS ayudaron a dar forma al concepto genérico de componentes web. Los componentes web también son fragmentos reutilizables de código HTML que están escritos en JavaScript y que el navegador hace funcional. Son componentes del lado del cliente.

Pero los componentes, en un sentido más genérico, en realidad existen desde hace mucho más tiempo. De hecho, se remontan a los primeros días de la web. Normalmente no se les ha llamado componentes, aunque todavía funcionan como tales. Los componentes del servidor también son fragmentos de código reutilizables, pero se compilan en HTML antes de que el navegador los vea. Son componentes del lado del servidor y todavía existen hoy en día.

Incluso en un mundo en el que todo lo que parece escuchar es “Reaccionar, Reaccionar, Reaccionar”, ambos tipos de componentes siguen siendo relevantes y pueden ayudarnos a crear sitios web increíbles. Exploremos en qué se diferencian los componentes del cliente y del servidor entre sí. Eso nos dará una idea más clara de dónde venimos. Y entonces tendremos la información que necesitamos para soñar con el futuro.

Representación

Quizás la mayor diferencia entre los componentes del lado del cliente y del lado del servidor es lo que los hace lo que son. Eso es lo que se encarga de renderizarlos.

Los componentes del servidor se representan mediante… ¡lo has adivinado! – el servidor. Por lo general, no se les conoce como componentes. A menudo se denominan parciales, inclusiones, fragmentos o plantillas, según el marco en el que se utilizan.

Los componentes del servidor pueden tomar dos tipos. El primero es el enfoque clásico, que consiste en renderizar componentes en tiempo real según una solicitud del cliente. Mira aquí:

La segunda opción es el enfoque Jamstack. En este caso, todo el sitio se compila durante un proceso de construcción y el HTML estático ya está disponible cuando lo solicita el cliente. Mira aquí:

En ambos casos, el cliente (es decir, su navegador) nunca ve la distinción entre sus componentes. Simplemente recibe un montón de HTML del servidor.

Los componentes del cliente, por otro lado, son renderizados por: ¡usted es dos por dos y está en ROLLO! – el cliente. Están escritos en JavaScript y renderizados por el cliente (su navegador). Debido a que el servidor es el servidor y lo sabe todo, puede conocer los componentes de su cliente, pero si le importa lo suficiente como para hacer algo con ellos depende del marco que esté utilizando.

Al igual que los componentes del servidor, también hay dos tipos de componentes del cliente. El primero es el componente web más oficial, que utiliza el DOM oculto. El DOM oculto ayuda a encapsular estilos y otras funciones (hablaremos más sobre esto más adelante). Los marcos como Polymer y Stencil hacen uso del DOM de sombra.

Los marcos más populares, como React y Vue, representan el segundo tipo de componente, que maneja la manipulación y el alcance del DOM por sí solos.

interactividad

Debido a que los componentes del servidor son solo HTML cuando se envían al cliente, si van a ser interactivos en el front-end, la aplicación debe cargar el código JavaScript por separado.

Considere un temporizador de cuenta regresiva. Su presentación está determinada por HTML y CSS (volveremos a la parte de CSS). Pero si va a hacer lo suyo (count), también necesita algo de JavaScript. Eso significa no solo incorporar ese JavaScript, sino también tener un medio por el cual JavaScript pueda adjuntarse a los elementos HTML de la cuenta regresiva, lo que debe hacerse manualmente o con (aún) otro marco.

Aunque esto puede parecer innecesariamente tedioso (especialmente si ha estado en esto el tiempo suficiente como para verse obligado a adoptar este enfoque), tiene sus beneficios. Es una clara separación de preocupaciones, donde el código del lado del servidor reside en un lugar, mientras que la funcionalidad reside en otro. Y trae sólo el código que necesita para la interactividad (teóricamente), lo que puede aliviar la carga del navegador.

Con los componentes del cliente, el marcado y la interactividad tienden a estar estrechamente vinculados, a menudo en el mismo archivo o directorio. Si bien esto puede convertirse rápidamente en un desastre si no eres diligente en mantenerte organizado, un beneficio importante para los componentes del cliente es que ya tienen acceso al cliente. Y debido a que están escritos en JavaScript, su funcionalidad puede incluirse junto con su marcado (y estilos).

Actuación

En una comparación uno a uno, los componentes del lado del servidor tienden a funcionar mejor. Cuando la página que recibe un navegador contiene todo lo que necesita para la presentación, podrá entregar esa presentación al usuario mucho más rápido.

Debido a que los componentes del lado del cliente requieren JavaScript, el navegador debe descargar o procesar información adicional (a menudo en archivos separados) para poder representar el componente.

Dicho esto, los componentes del lado del cliente se utilizan a menudo en el contexto de un marco más amplio. React tiene Gatsby y Next, mientras que Vue tiene Nuxt. Estos marcos tienen mecanismos para crear una experiencia superior en la aplicación. Lo que quiero decir es que, si bien pueden ser más lentos a la hora de cargar la primera página que visitas en un sitio, luego pueden concentrar su energía en ofrecer vistas posteriores extremadamente rápido, a menudo más rápido de lo que un sitio renderizado del lado del servidor puede entregar su contenido.

Si estás pensando, sí, pero ¿qué pasa con el renderizado previo y...?

Sí tienes razón. Vamos a llegar. Además, no más spoilers, por favor. El resto de nosotros estamos de acuerdo.

Idiomas

Los componentes del servidor se pueden escribir en (casi) cualquier lenguaje del lado del servidor. Esto le permite escribir sus plantillas en el mismo idioma que la lógica de su aplicación. Por ejemplo, las aplicaciones escritas con Ruby on Rails utilizan plantillas ERB de forma predeterminada, que es una forma de Ruby. Por lo tanto, las aplicaciones Rails utilizan el mismo lenguaje para la aplicación en sí que para sus componentes.

La razón por la que los componentes del cliente están escritos en JavaScript es porque ese es el idioma que los navegadores analizan para lograr interactividad en un sitio web. Sin embargo, JavaScript también tiene tiempos de ejecución basados ​​en servidor, el más popular de los cuales es Node.js. Eso significa que el código para los componentes del cliente podría escribirse en el mismo lenguaje que la aplicación, siempre que la aplicación esté escrita con Node (o similar).

Estilo (CSS)

Cuando se trata de diseñar componentes, los componentes del lado del servidor se encuentran con los mismos problemas que enfrentan con JavaScript. Los estilos normalmente están separados de los componentes y requieren un poco de esfuerzo adicional para vincular los estilos a los elementos de la página.

Sin embargo, existen marcos como Tailwind CSS que están trabajando para hacer que este proceso sea menos doloroso.

Muchas bibliotecas de componentes del lado del cliente vienen con soporte CSS (o al menos un patrón para diseñar) desde el primer momento. Esto a menudo significa incluir los estilos en el mismo archivo que el marcado y la lógica, lo que puede resultar complicado. Pero normalmente, con un poco de esfuerzo, puedes ajustar ese enfoque a tu gusto.

Bienvenidos al futuro (híbrido)

Ningún tipo de componente es la respuesta por sí solo. Los componentes del lado del servidor requieren un esfuerzo adicional en estilo e interactividad que parece innecesario cuando miramos las ofertas de componentes del cliente. Pero los componentes del cliente tienden a restarle rendimiento al front-end. Y debido a que el éxito de un sitio web a menudo depende de la participación del usuario, la falta de rendimiento puede perjudicar el resultado final y ser suficiente para no querer utilizar los componentes del cliente.

¿Qué significa eso para un futuro que exige tanto rendimiento como una buena experiencia de desarrollador? Lo más probable es que se trate de un enfoque híbrido.

Los componentes deberán renderizarse en el lado del servidor. Simplemente lo son. Así es como optimizamos el rendimiento, y un buen rendimiento seguirá siendo un atributo de los sitios web exitosos. Pero, ahora que hemos visto la facilidad de la lógica front-end y la interactividad usando marcos, nuevamente, como React y Vue, esos marcos llegaron para quedarse (al menos por un tiempo).

Entonces adónde vamos?

Creo que veremos estos componentes unirse de tres maneras en un futuro muy cercano.

1. Avance de los marcos de trabajo de JavaScript

¿Recuerdas cuando se te ocurrió ese spoiler sobre el renderizado previo? Bueno, hablemos de ello ahora.

Marcos como Gatsby, Next y Nuxt actúan como motores de interfaz de usuario creados sobre marcos de componentes, como React y Vue. Reúnen herramientas para crear una experiencia front-end integral utilizando su marco preferido. Una de esas características es la renderización previa, lo que significa que estos motores realizarán una introspección de los componentes y luego escribirán HTML estático en la página mientras se construye el sitio. Luego, cuando los usuarios ven esa página, en realidad ya está allí. No necesitan JavaScript para verlo.

Sin embargo, JavaScript entra en juego mediante un proceso llamado hidratación. Después de que se carga la página y su usuario ve todo el contenido (estático), es cuando JavaScript comienza a funcionar. Se hace cargo de los componentes para hacerlos interactivos. Esto brinda la oportunidad de crear un sitio web basado en componentes del lado del cliente con algunos de los beneficios del servidor, a saber, rendimiento y SEO.

Estas herramientas se han vuelto muy populares gracias a este enfoque y sospecho que las veremos seguir avanzando.

2. Representación previa integrada del lado del cliente

Son muchas palabras compuestas.

En lo que he estado pensando mucho en los últimos años es: ¿Por qué React (o Vue) no asume el renderizado del lado del servidor? Lo hacen, simplemente no es muy fácil de entender o implementar sin otro marco que ayude.

Por un lado, entiendo el principio de responsabilidad única y que estos marcos de componentes son solo formas de crear componentes del lado del cliente. Pero me pareció un gran error delegar la renderización del lado del servidor a herramientas más grandes y complejas como Gatsby y Next (entre otras).

Bueno, React ha comenzado a moverse en esa dirección. Vue ya está allí. Y Svelte ha hecho de este enfoque una prioridad desde el principio.

Creo que veremos mucho más desarrollo mientras estas herramientas tradicionalmente centradas en el lado del cliente solucionan el renderizado del lado del servidor. Sospecho que eso también significa que escucharemos un poco más de Svelte en el futuro, que parece estar a la vanguardia en este sentido.

Eso también puede conducir al desarrollo de más competidores para herramientas más voluminosas como Gatsby y Next. Por ejemplo, mire lo que está haciendo Netlify con su sitio web. Es un proyecto de Eleventy que extrae componentes de Vue y los renderiza para su uso en el servidor. Lo que le falta es la pieza de hidratación e interactividad. Espero que eso suceda en un futuro muy cercano.

3. Interactividad de los componentes del lado del servidor

Y aún así, no podemos descartar el uso continuo de componentes del lado del servidor. El único efecto secundario de los otros dos avances es que todavía utilizan marcos de JavaScript que pueden parecer innecesarios cuando solo se necesita un poco de interactividad.

Debe haber una forma más sencilla de agregar solo un poco de JavaScript para hacer que un componente del lado del servidor escrito en un lenguaje del lado del servidor sea más interactivo.

Resolver ese problema parece ser el enfoque de la gente de Basecamp, que acaba de lanzar Hotwire, que es un medio para llevar algunas de las ventajas de los componentes del cliente al servidor, utilizando (casi) cualquier lenguaje del lado del servidor.

No sé si eso significa que veremos surgir competencia con Hotwire de inmediato. Pero sí creo que Hotwire recibirá algo de atención. Y eso podría hacer que la gente vuelva a trabajar con marcos monolíticos de pila completa como Rails. (Personalmente, me encanta que Rails no se haya quedado obsoleto en este mundo centrado en JavaScript. Cuanta más competencia tengamos, mejor será la web).

¿A dónde crees que va todo este negocio de componentes? Hablemos de eso.