Manteniéndolo Simple

Hola a todos. Soy Matt Bihlmann, CEO y cofundador de Netlify. Hoy voy a hablar sobre la simplicidad y el estado y los peligros de dirigir nuestras comunidades hacia la complejidad.

Entonces, en 2013, React se lanzó como una capa de vista que aportó simplicidad al proceso de construcción de aplicaciones basadas en el navegador. Cualquiera que haya intentado construir una aplicación basada en el navegador antes de React tuvo que lidiar con esta mezcla de estado en todo el DOM. Tenías enlaces escuchando a elementos del DOM. Tenías elementos del DOM que contenían estados. Tenías oyentes AJAX que buscarían, solicitarían y actualizarían elementos del DOM, y a medida que construías aplicaciones más complejas, razonar sobre el estado de tu DOM y el estado de tu aplicación y lo que un usuario experimentaría se volvía cada vez más difícil. React lanzó esta idea de convertir toda la interfaz de usuario en una función de tu estado, y realmente hizo mucho más fácil razonar sobre las experiencias que nuestros usuarios tenían en función de cualquier estado dado. Podías tomar un estado, alimentarlo a un árbol de DOM de componentes de React y sabrías qué vería el usuario para cualquier estado dado. React fundamentalmente facilitó razonar un poco sobre el estado de tu aplicación, y eso fue uno de los superpoderes que hizo a React poderoso y adoptado.

Por supuesto, a medida que queremos que React resuelva problemas cada vez más difíciles para nosotros y resuelva más problemas de construcción de aplicaciones, estamos introduciendo muchos nuevos conceptos como contexto, hooks, los nuevos componentes de servidor propuestos o el streaming. Y a medida que avanzamos en este camino, por supuesto que es importante ser curiosos y emocionarnos y explorar a dónde podemos llegar, pero también es importante que intentemos mantenernos, mantenernos honestos, ¿todavía sabemos cuál es el estado actual de nuestra aplicación? ¿Y sabemos en cualquier momento qué experiencia tendrá un usuario para un estado dado? Esto fue como el superpoder inicial que dio a React una sensación de simplicidad y que hizo que las aplicaciones fueran fáciles de razonar. Entonces, a medida que evolucionamos React como un marco más completo, ¿cómo mantenemos esa calidad? Ahora, hace cinco años en San Francisco, di una charla en la conferencia Smashing donde presenté por primera vez el concepto de JAMstack como una arquitectura.

Y la idea en aquel entonces era muy similar. Había visto cómo, con el tiempo, el desarrollo web había dificultado cada vez más razonar sobre el estado de tu propiedad web. Habíamos pasado de un mundo en el que un navegador recuperaba archivos de un servidor, a un mundo en el que ejecutábamos un programa, a un mundo en el que ese programa siempre se comunicaba con una base de datos para cada solicitud, y a un mundo en el que, para escalar esa arquitectura, comenzamos a introducir diferentes capas de almacenamiento en caché entre servidores y bases de datos a medida que la web se globalizaba y necesitábamos llegar a usuarios de todo el mundo.

Introdujimos CDNs para activos o imágenes o archivos JavaScript, y como desarrolladores, teníamos que ser capaces de razonar sobre todas estas diferentes capas de la pila. El stack GAM fue realmente un enfoque arquitectónico para decir, ¿cómo podemos facilitar el razonamiento sobre el estado de tu propiedad web? ¿Cómo podemos adoptar un enfoque arquitectónico para construir para la web? En lugar de este complejo ciclo de solicitud-respuesta que fluye a través de todas estas diferentes capas de almacenamiento en caché, tomamos código y tomamos tu contenido, tus APIs o tus datos, ejecutamos una compilación e implementamos activos inmutables en una red de borde.

Y al hacer eso, comenzamos a introducir esta idea de implementaciones atómicas, donde siempre sabes que tienes un estado, lo has implementado y está en vivo. Sabes exactamente qué documentos y páginas HTML se han construido como parte de eso. Y cuando cambias a una nueva implementación, es una operación atómica donde todo se implementa al mismo tiempo y siempre sabes qué verá un usuario si visita una URL. Ahora, de manera similar a React, a medida que queremos que la arquitectura GAMSTAG resuelva problemas cada vez más complejos para nosotros y construya más y más aplicaciones en la zona gris de todos esos diferentes casos de uso, también estamos comenzando a ver conceptos más complejos introducidos en la pila, como la rehidratación, el SSR dinámico para algunas páginas, el almacenamiento en caché de CDN escalonado, enfoques como la regeneración estática incremental y las cabeceras HTTP de caducidad mientras se vuelve a validar. Y de la misma manera que con React, a medida que construimos este futuro, realmente tenemos que preguntarnos, ¿sabes qué se ha implementado actualmente en cualquier etapa? ¿Y sabes qué experimentará un usuario si visita una URL determinada? ¿Sabes exactamente qué sucederá si retrocedes a una implementación anterior? ¿Y sabes qué sucederá si implementas una vista previa de implementación número 110 en la rama principal en este momento? Por supuesto, una de las razones por las que estamos explorando muchos de estos nuevos conceptos, como la regeneración estática incremental y la caducidad mientras se vuelve a validar, es porque estamos tratando de construir proyectos cada vez más grandes con un enfoque JAMstack, especialmente proyectos grandes de comercio electrónico con cientos de miles o incluso millones de páginas de catálogo, lo cual ha resultado ser un desafío. Los tiempos de construcción comienzan a ser más largos. Tenemos algunos enfoques existentes dentro de la arquitectura JAMstack actual que a veces funcionan como solución para esto. Dividir tu compilación en muchos sitios diferentes es un enfoque, pero no siempre funciona. A veces, tu contenido simplemente no se presta bien para la división. Las aplicaciones web progresivas o las aplicaciones de una sola página, donde implementamos una estructura de la aplicación en el navegador y luego usamos el paquete JavaScript para comunicarnos con las APIs, a menudo son un concepto muy poderoso y mi recomendación preferida para cualquier experiencia de usuario con inicio de sesión. Pero sabemos que hay un costo de representación desde JavaScript en el navegador en dispositivos de gama baja y el almacenamiento en caché de API en el borde está lejos de ser un problema resuelto. La caducidad mientras se vuelve a validar ha sido otro enfoque, pero personalmente tengo mis dudas al respecto. Sirve contenido caducado a los usuarios y luego, en segundo plano, recupera una nueva versión, la regenera y la coloca en la caché. Pero nuevamente, el problema de servir contenido caducado a los usuarios es que ya no tienes una respuesta clara como desarrollador sobre lo que sucederá cuando un usuario visite cualquier URL determinada. En Netlify hemos estado pensando mucho en cómo podemos abordar estos problemas desde una perspectiva arquitectónica JAMstack, brindar la misma simplicidad fácil de razonar a los desarrolladores, pero resolver estos problemas. Hemos hablado sobre un enfoque llamado Representación Persistente Distribuida, donde tomamos solo las páginas críticas y las ejecutamos en tiempo de compilación. Y luego construimos el resto de las páginas bajo demanda, pero las persistimos y brindamos las mismas garantías en cuanto a implementaciones atómicas y estado predecible que obtendrías de una compilación. Esto es algo en lo que estamos trabajando para convertirlo en una comunidad en RFC. Y nos encantaría contar con la ayuda de esta comunidad para evolucionar y probarlo. Hemos estado trabajando con prototipos de este enfoque en Nox a Eleventy y Next.js. Y puedes obtener mucha más información al respecto en nuestro blog en este momento. Así que por favor participa en la evolución de JAMstack de una manera que se mantenga fiel a las raíces de la simplicidad y garantice que, como desarrolladores, no renunciemos a la capacidad de razonar sobre el estado de nuestra propiedad web. Muchas gracias. ♪