La única forma de comer un elefante: Code Splitting con Server Side Rendering

Todo comenzó en un momento en el que no existía React. Algunos recuerdan esos tiempos y otros ni siquiera pueden creer que hubo un tiempo en el que no existía React. Pero en ese momento, todas las páginas HTML se servían como cadenas de texto. No lo creerías. Pero todo el contenido era una cadena servida desde los servidores, y se veía algo así. Uno escribía todo el contenido HTML y había muchos, tantos como filas tenías, y en realidad todos estaban contentos en ese momento. Era bastante sencillo en realidad, hasta que, ya no lo era. Y probablemente puedas adivinar la razón. Era por culpa de JavaScript.

Se volvió demasiado tedioso manejar todo el JavaScript, toda la manipulación del DOM con jQuery, ya sabes, con herramientas de renderizado como EGS, handlebars y muchas más en todos los lenguajes de servidor, y también las solicitudes al servidor hicieron sufrir a las personas, y apenas puedo decirte quién sufrió más, si los usuarios o los desarrolladores, con todo su JavaScript, jQuery y handlebars. Entonces, llegaron los héroes de JavaScript y decidieron tener SPAs, aplicaciones de una sola página, y y se imaginaban renderizando todo el contenido en el lado del cliente y decidieron que el navegador podía manejar la navegación sin volver al servidor y pensaron, pensaron que era genial, y también decidieron que podían hacer enrutamiento en el lado del cliente, no porque fuera fácil, sino porque era difícil. Pero pudieron hacerlo. Y el HTML se volvió muy pequeño y superficial y ya no se renderizaba nada en el servidor. Todo se renderizaba en el lado del cliente con uno de los frameworks de JavaScript. Y ahí había más JavaScript, más herramientas para construirlo en un solo paquete y más problemas de JavaScript para resolver, más conferencias de JavaScript para hablar sobre estos problemas y nacieron nuevos monstruos. En realidad, más JavaScript resultó en paquetes más grandes, lo que resultó en un peor rendimiento, en la primera renderización, y en todo lo demás, y los usuarios comenzaron a sufrir y también los negocios comenzaron a sufrir porque el SEO era un problema. Los rastreadores no pueden leer JavaScript, necesitan cadenas de texto. Así que los héroes de JavaScript volvieron de nuevo y decidieron recuperar el SSR, pero esta vez conservaron el mismo JavaScript que habían escrito, porque era tan hermoso como para desecharlo y decidieron que la solución era renderizar este JavaScript que tenían como una cadena en el servidor y tener una función de JavaScript que devolviera una cadena. Así que esa fue una buena solución para el SSR y resolvió el problema de SEO. Pero no resolvió el problema del tamaño del paquete, ¿verdad? Así que estaban usando el mismo JavaScript tanto en el lado del cliente como en el lado del servidor. Entonces, los héroes de JavaScript decidieron que necesitaban idear una solución para la división de código. Y lo hicieron. Implementaron estas importaciones dinámicas. Aquí puedes ver que hay un problema con este código. No porque no esté en React, sino porque es asíncrono. Y sí resuelve el problema de un paquete grande de JavaScript. Puedes ver que ahora el contenido no está en un solo paquete, sino que se carga de forma dinámica. Pero las importaciones dinámicas son para el lado del cliente y no se pueden renderizar en el lado del servidor porque el servidor necesita hacerlo de forma sincrónica. Así que cuando tu contenido depende de la ruta, es decir, cuando necesitas este contenido de inmediato para que el cliente lo vea, puedes tener división de código tanto en el lado del servidor como en el lado del cliente. El único problema que necesitas resolver es decidir en qué entorno te encuentras y cargarlo de forma sincrónica cuando no estás en el entorno del lado del cliente y cargarlo de forma sincrónica cuando sí lo estás. Así que esta es la solución vanilla.js para este problema y aunque me gusta mucho vanilla.js, todos sabemos que no es escalable. Resuelve el problema, pero no es escalable. Pero afortunadamente tenemos React y una solución de biblioteca para ello, y tenemos componentes cargables y es tan fácil con los componentes cargables como lo escribí en vanilla.js Todo lo que necesitas hacer es proporcionarle a esta biblioteca información sobre todos los fragmentos que tienes y pedirle que renderice tu contenido como una cadena en el lado del servidor y luego Loadable decidirá como por arte de magia en qué entorno te encuentras y renderizará tu contenido tanto en el lado del servidor como en el lado del cliente y con división de código, por lo que no servirás paquetes grandes a tus clientes y vivieron felices para siempre SSR codes se casó con SSR y la división de código se casó con React y los componentes cargables y nuestros usuarios están felices y nuestros héroes de GS están listos para conquistar nuevos monstruos. Gracias