El año pasado se produjo un saludable debate en torno al término ‘Jamstack’, ya que la definición se amplía para incluir nuevos casos de uso. Recientemente publiqué mi opinión sobre una definición de Jamstack en “Estático vs. Dinámico vs. Jamstack: ¿Dónde está la línea?” En este artículo, quiero ver la evolución de Jamstack y lo que eso significa para el término.
Los desarrolladores han estado creando sitios estáticos mucho antes de que se acuñara el término Jamstack. El caso de uso más común fue una manera fácil para que los desarrolladores alojen su blog o documentación de código abierto en las páginas de GitHub. Algunos pioneros impulsaron proyectos comerciales más grandes en sitios estáticos, pero ciertamente no era tan común como lo es hoy.
Los sitios estáticos se percibían como limitados: tecnología antigua de los años 90. ¿Por qué las empresas con visión de futuro querrían utilizar esta forma antigua de crear sitios web? Phil Hawksworth presione justo en el botón en su charla IJS acerca de que la estática es un término cargado:
¿Estamos hablando de una experiencia estática o estamos hablando de una arquitectura estática?
El potencial de ambigüedad es increíblemente confuso, especialmente para los que no son desarrolladores. Los sitios web estáticos de los años 90 no son lo mismo que los sitios estáticos modernos. Hay nuevas tecnologías que justifican dar una segunda mirada a los sitios estáticos:
- JavaScript se ha convertido en un poderoso lenguaje para crear aplicaciones en el navegador. Gmail se lanzó en 2004 y fue la primera aplicación principal en hacer un uso intensivo de Ajax.
- Generadores de sitios estáticos (SSG) han aportado muchas ventajas dinámicas a los sitios, como diseños y separación del contenido del código. Jekyll fue el primer SSG muy popular y se lanzó en 2008.
- CDN Solía ser una tecnología que solo las grandes empresas podían permitirse. Cuando se lanzó AWS Cloudfront en 2008, podía configurar una CDN en minutos y, a pequeña escala, solo le costaría unos pocos dólares.
- Git Los flujos de trabajo y las herramientas de CI/CD creadas a su alrededor han hecho que las implementaciones de FTP propensas a errores sean cosa del pasado.
- Ecosistema — hay un número creciente de herramientas independientes que puede colocar en un sitio estático para habilitar funciones adicionales, desde búsqueda y comercio electrónico hasta bases de datos, comentarios y más.
Jamstack ayudó a cambiar la percepción de las personas sobre los sitios web estáticos. Y los vientos cambiantes en la estática fueron los que llevaron matt biilmann para acuñar el término Jamstack en 2016. De repente, teníamos una palabra que capturaba los beneficios de los sitios estáticos modernos sin el equipaje de la estática. cassidy williams hace un trabajo fantástico al capturar la esencia de Jamstack:
Jamstack se trata de crear aplicaciones web con el mismo estilo que las aplicaciones móviles: la interfaz de usuario se compila y luego se extraen los datos según sea necesario.
Jamstack tocó la fibra sensible de muchos desarrolladores de WordPress en particular. Viniendo del mundo de las complejas API de temas y complementos, la simplicidad y el control que obtuvo con un SSG fue refrescante. El movimiento había comenzado y se había formado una comunidad en torno al enfoque desacoplado de Jamstack.
A medida que Jamstack creció en popularidad, también lo hizo el tamaño y la complejidad de los proyectos. Vimos que los principios de Jamstack iban más allá de los sitios web y, a medida que se abrían camino hacia las aplicaciones web, pronto alcanzamos los límites técnicos de lo que un sitio estático era capaz de hacer. Las plataformas agregaron nuevas funciones y flujos de trabajo para expandir los principios de Jamstack, lo que permitió que las aplicaciones más grandes y complejas adoptaran un enfoque de Jamstack.
Estoy emocionado de participar en esta evolución con CloudCannon. Estamos viendo un cambio significativo en la forma en que los desarrolladores crean software para la web. Hay un ecosistema floreciente de herramientas y plataformas especializadas que permiten a los desarrolladores front-end hacer más y que las aplicaciones sofisticadas vivan al límite.
Mi preocupación es que no podemos ponernos de acuerdo sobre lo que realmente significa Jamstack. Tenemos definiciones sucintas que marcan un límite claro de lo que es y no es Jamstack. Muchos de mis favoritos están en este artículo. Estamos viendo que el término Jamstack se usa para un comportamiento cada vez más dinámico. Algunos miembros de la comunidad están de acuerdo con este uso y otros no. La ambigüedad y la percepción fueron las razones originales para acuñar el término, y aquí corremos el riesgo de cerrar el círculo.
Es un problema difícil al que se enfrenta la comunidad de Jamstack porque hay muchos cruces entre el significado original de “Jamstack” y el uso nuevo, evolucionado y más dinámico de la palabra. Yo mismo estoy en conflicto porque me encanta la idea de aplicar los principios de Jamstack a enfoques más dinámicos. Consideré brevemente la idea de usar “Jamstack” para describir el uso estático y “Jamstack++” el uso más dinámico. Pero rápidamente me di cuenta de que probablemente crearía más confusión de la que resuelve.
Matt Biilmann lo logró con el anuncio de Netlify de Distributed Persistent Rendering (DPR):
Para cualquier tecnología, la parte más difícil no es establecer la simplicidad, sino protegerla a lo largo del tiempo.
Esto captura perfectamente mis pensamientos. Es tranquilizador saber que no estoy limitado si construyo un nuevo proyecto con un enfoque Jamstack. Si mi sitio se vuelve enorme o necesito un comportamiento dinámico, tengo opciones. Sin estas opciones, Jamstack se vería como una tecnología limitada para casos de uso pequeños. Por otro lado, cuanto más enfatizamos estas soluciones más dinámicas, más nos alejamos de la elegante simplicidad que creó el movimiento Jamstack en primer lugar.
DPR es una tecnología nueva y emocionante. Es una solución elegante a la dolorosa limitación de preconstruir grandes sitios. Para un sitio de 100.000 páginas, ¿haría el compromiso de crear previamente un subconjunto de esas páginas y hacer que el resto se construya bajo demanda la primera vez que se solicitan, reduciendo así el tiempo de construcción de manera significativa? ¡Diablos, sí, lo haría! Esa es una compensación que tiene sentido.
He estado pensando mucho sobre dónde encaja DPR en la imagen de Jamstack, principalmente porque está justo en el límite. Ya sea que lo incluya o lo excluya del paraguas de Jamstack, tiene ramificaciones ondulantes.
Sean Davis tiene una definición de Jamstack de la que soy fan:
Jamstack es una arquitectura para construir y entregar de forma atómica proyectos front-end web desacoplados y precompilados desde el perímetro.
Esto resuena con lo que creo que es Jamstack. Si vamos a incluir DPR en esta definición, necesita algo de trabajo:
Jamstack es una arquitectura para compilar y entregar de forma atómica (o páginas web generadas bajo demanda, pero solo si es la primera solicitud y luego persiste), proyectos web front-end desacoplados del perímetro.
La definición oficial de Jamstack funciona mejor para DPR:
Jamstack es la nueva arquitectura estándar para la web. Mediante el uso de flujos de trabajo de Git y herramientas de compilación modernas, el contenido prerenderizado se envía a una CDN y se dinamiza a través de API y funciones sin servidor.
DPR entrega contenido utilizando una función sin servidor o como archivo estático a través de un CDN para que se ajuste a la definición.
Es interesante ver cómo la definición ha cambiado con el tiempo. Antes de finales de 2020, la definición oficial de Jamstack, publicada directamente en Jamstack.org en ese momento, era la siguiente:
Sitios y aplicaciones rápidos y seguros entregados mediante la representación previa de archivos y sirviéndolos directamente desde una CDN, eliminando el requisito de administrar o ejecutar servidores web.
La tecnología evoluciona con el tiempo, al igual que el lenguaje, por lo que es genial ver la definición modificada para mantenerse al día. Introducir “sin servidor” en la definición tiene sentido, por un lado, ya que la tecnología se está volviendo más accesible para los desarrolladores front-end, que son la audiencia predominante de Jamstack. Por otro lado, va en contra de los principios básicos de Jamstack de procesamiento previo y desacoplamiento. ¿Necesitamos actualizar estos principios básicos también?
Todavía estoy procesando todos estos pensamientos e ideas yo mismo. Soy un gran admirador de Jamstack, ha servido como un importante catalizador para el crecimiento de los generadores de sitios estáticos y nos ha brindado un lenguaje para hablar sobre el enfoque de prerenderizado y desacoplamiento de sitios web. Mirando hacia el futuro, puedo ver cinco direcciones en las que Jamstack puede ir:
- Jamstack está cimentado en su significado original, representación previa y desacoplamiento. Los enfoques más dinámicos, inspirados en Jamstack, reciben su propio nombre.
- Jamstack evoluciona y se amplían la definición y los principios. Como resultado, el significado probablemente se vuelve más ambiguo.
- Jamstack es el nombre de la comunidad. Es un conjunto de pautas y no hay reglas estrictas y rápidas.
- Jamstack ha levantado el equipaje de lo estático, y podemos hablar de sitios web estáticos, híbridos y dinámicos.
- Jamstack se vuelve lo suficientemente convencional como para que podamos llamarlo simplemente desarrollo web moderno.
Hay personas en todos estos campamentos tirando en diferentes direcciones, lo que genera mucha confusión y discusión en la comunidad. Lo que está claro es que esta comunidad de personas siente una gran pasión por este enfoque para crear sitios web. Francamente, no podría estar más entusiasmado con las innovaciones que suceden en este espacio. Lo que necesitamos es consenso y un camino a seguir. Sin esto, creo que, para bien o para mal, terminaremos con una combinación de opciones 3, 4 y 5.