5 mitos sobre Jamstack

Jamstack no es necesariamente nuevo. El término se acuñó oficialmente en 2016, pero las tecnologías y la arquitectura que describe existen mucho antes. Jamstack ha recibido una gran dosis de atención recientemente, con artículos sobre él que aparecen en los principales sitios y publicaciones y nuevos eventos , boletines informativos , podcasts y más centrados en Jamstack. Como alguien que lo sigue de cerca, incluso he visto lo que parece ser un aumento significativo en la discusión al respecto en Twitter, a menudo por parte de personas a las que se les está presentando el concepto por primera vez.

Los rumores también parecieron sacar a relucir las críticas. Algunas de las críticas son justas, y abordaré algunas de ellas en un momento, pero otras parecen estar basadas en mitos comunes sobre Jamstack que persisten, que es lo que quiero abordar primero. Así que veamos cinco mitos comunes que he encontrado sobre Jamstack y desacreditémoslos. Como ocurre con muchos mitos, a menudo se basan en una pizca de verdad pero conducen a conclusiones inválidas.

Mito 1: simplemente son sitios estáticos renombrados

JAMStack es 99,9% de marca y 0,1% de sustancia. https://t.co/nxoEVQ43oE

– Nicole Sullivan – Black Lives Matter (@stubbornella) 9 de febrero de 2020

Sí, como mencioné anteriormente , podría decirse que el término “Jamstack” fue un cambio de marca de lo que anteriormente llamábamos “sitios estáticos”. Este no fue un cambio de marca destinado a engañarlo o venderle algo que no estaba completamente formado, sino todo lo contrario. El término “sitio estático” hacía tiempo que había perdido su capacidad para describir lo que la gente estaba construyendo. Los sitios que se creaban utilizando generadores de sitios estáticos (SSG) frecuentemente estaban llenos de todo tipo de contenido y capacidades dinámicas.

Se consideraba que los sitios estáticos se referían principalmente a blogs y documentación donde la interfaz de usuario se arreglaba principalmente. El alcance de la interacción quizás fueron comentarios integrados y un formulario de contacto. Los sitios Jamstack, por otro lado, tienen cosas como autenticación de usuario, contenido dinámico, comercio electrónico y contenido generado por el usuario.

¿Quieres pruebas? Algunas empresas y sitios conocidos creados con Jamstack incluyen Smashing Magazine , Sphero , Postman , Prima , Impossible Foods y TriNet , solo por nombrar algunos.

Mito 2: los sitios Jamstack son frágiles

Jay Freestone, sobre los problemas con JAMStack: Es posible que necesites un backend

Leer la lista de dependencias de Smashing Magazine parece el servicio equivalente a node_modules, incluidos Algolia , GoCommerce , GoTrue , GoTell y una variedad de servicios de Netlify, por nombrar algunos. Es muy valioso saber qué subcontratar (y cuándo) , pero es divertido notar la complejidad que se ha introducido en un aparente intento de “volver a lo básico”. Esto sin mencionar la posible fragilidad de depender de tantos servicios de terceros dispares.

Sí, para lograr las capacidades dinámicas que diferencian a Jamstack de los sitios estáticos, los proyectos de Jamstack generalmente dependen de una variedad de servicios, tanto propios como de terceros. Algunos han argumentado que esto hace que los sitios Jamstack sean particularmente vulnerables por dos razones. La primera, dicen, es que si alguna pieza falla, toda la funcionalidad del sitio colapsa. La segunda es que su infraestructura se vuelve demasiado dependiente de herramientas y servicios que no le pertenecen.

Abordemos ese primer argumento. La mayor parte de un sitio Jamstack debe estar renderizado previamente. Esto significa que cuando un usuario visita el sitio, la página y la mayor parte de su contenido se entregan como activos estáticos desde la CDN. Esto es lo que le da a Jamstack gran parte de su velocidad y seguridad. La funcionalidad dinámica, como carritos de compras, autenticación, contenido generado por el usuario y quizás búsqueda, depende de una combinación de funciones sin servidor y API para funcionar.

En términos generales, la aplicación llamará a una función sin servidor que sirve como back-end para conectarse a las API. Si, por ejemplo, nuestra funcionalidad de comercio electrónico depende de las API de Stripe para funcionar y Stripe no funciona, entonces sí, nuestra funcionalidad de comercio electrónico no funcionará. Sin embargo, es importante tener en cuenta que el sitio no dejará de funcionar. Puede manejar el problema con elegancia informando al usuario del problema. Una página renderizada por un servidor que se basa en la API de Stripe para el comercio electrónico enfrentaría el mismo problema. Suponiendo que la página renderizada por el servidor todavía llama al código back-end para el pago de forma asincrónica, no sería ni más ni menos frágil que la versión Jamstack. Por otro lado, si la representación del servidor realmente depende de la llamada API, el usuario puede quedarse atascado esperando una respuesta o recibir un error (una situación con la que cualquiera que use la web está muy familiarizado).

En cuanto al segundo argumento, es realmente difícil medir el grado de dependencia de terceros para una aplicación web Jamstack versus una aplicación renderizada por servidor. Muchas de las aplicaciones renderizadas en servidor actuales todavía dependen de las API para una cantidad significativa de funcionalidad porque permiten un desarrollo más rápido, aprovechan el área específica de especialización del proveedor, pueden descargar la responsabilidad de cuestiones legales y de cumplimiento de otro tipo, y más. En estos casos, una vez más, la versión renderizada por el servidor no sería ni más ni menos dependiente que la versión Jamstack. Es cierto que si su aplicación se basa principalmente en soluciones internas o locales, entonces esto puede ser diferente.

Mito 3: editar contenido es difícil

Kev Quirk, sobre por qué no uso un generador de sitios estáticos :

Tener que usar SSH en una máquina de Linux y luego editar una publicación en Vim parece una barrera de entrada ridículamente alta cuando se trata de escribir sobre la marcha. Hoy en día, el mundo es móvil, nos guste o no, por lo que escribir sobre la marcha debería ser fácil.

Este problema parece una reliquia del pasado de los sitios estáticos. Para ser claros, no necesita utilizar SSH en un cuadro de Linux para editar el contenido de su sitio. Existe una amplia gama de opciones de CMS sin cabeza , desde completamente gratuitas y de código abierto hasta ofertas comerciales que potencian el contenido para grandes empresas. Ofrecen una variedad de capacidades de edición que rivalizan con cualquier CMS tradicional (algo de lo que he hablado antes ). El punto es que no hay razón para editar manualmente archivos Markdown, YAML o JSON, incluso en el proyecto paralelo de su blog. ¿No estás seguro de cómo conectar todas estas piezas? ¡Tenemos una solución para eso también!

Una crítica legítima ha sido que el CMS sin cabeza y el proceso de construcción pueden causar una desconexión entre el contenido que se está editando y el cambio en el sitio. Puede resultar difícil obtener una vista previa exacta del impacto de un cambio en el sitio activo hasta que se publique o sin un proceso complejo de vista previa de la compilación. Esto es algo que está siendo abordado por el ecosistema. Empresas como Stackbit (para quien trabajo) están creando herramientas que hacen que este proceso sea fluido.

No somos los únicos que trabajamos para resolver este problema. Otras soluciones incluyen TinaCMS y Gatsby Preview . Creo que estamos cerca de que se convierta en algo común tener la simplicidad de la edición WYSIWYG en una herramienta como Wix ejecutándose sobre Jamstack.

Mito 4: El SEO es difícil para Jamstack

Kym Ellis, sobre lo que significa JAMstack para el marketing :

Deshacerse del concepto de complemento y optar por un sitio JAMstack que sea “solo HTML” no significa en realidad que deba renunciar a la funcionalidad o que de repente necesite saber cómo codificar como un desarrollador front-end para administrar un sitio y sus contenido.

No he visto esto aparecer con tanta frecuencia en los últimos años y creo que es principalmente una crítica heredada de los días de los sitios estáticos, donde la gestión de metadatos relacionados con SEO implicaba editar manualmente el frontmatter basado en YAML. La preocupación era que hacer SEO correctamente se volvía engorroso y difícil de mantener, especialmente si deseaba inyectar diferentes metadatos para cada página única que se generaba o crear datos estructurados como JSON-LD , que pueden ser críticos para mejorar su lista de búsqueda.

Los avances en la gestión de contenidos para Jamstack generalmente han abordado la complejidad de mantener metadatos de SEO. Además, debido a que las páginas están renderizadas previamente, agregar mapas de sitio y JSON-LD es relativamente simple, siempre que existan los metadatos necesarios. Si bien el renderizado previo facilita la creación de los recursos que los motores de búsqueda (léase: Google) necesitan para indexar un sitio, también, combinados con las CDN, facilitan el logro de los puntos de referencia de rendimiento necesarios para mejorar la clasificación de un sitio.

Básicamente, Jamstack sobresale en ” SEO técnico ” y al mismo tiempo proporciona las herramientas necesarias para que los editores de contenido proporcionen las palabras clave y otros metadatos que necesitan. Para obtener una visión más completa de Jamstack y SEO, recomiendo consultar la Guía Jamstack SEO de Bejamas.

Mito 5: Jamstack requiere marcos de JavaScript pesados

Si está tratando de vender sitios web simples a gerentes que están obsesionados con los marcos de trabajo del mes, un sitio web ingenioso que promueva los beneficios de “JAMstack” es algo realmente útil.

– jdietrich, Noticias de hackers

Últimamente, parece como si Jamstack se hubiera convertido en sinónimo de marcos de JavaScript front-end. Es cierto que muchas de las soluciones más conocidas dependen de un marco de front-end, incluidas Gatsby (React), Next.js (React), Nuxt (Vue), VuePress (Vue), Gridsome (Vue) y Scully. (Angular). Esto parece verse agravado por la confusión en torno a la “J” en Jamstack. Si bien significa JavaScript, esto no significa que todas las soluciones Jamstack estén basadas en JavaScript, ni que todas requieran marcos npm o JavaScript.

De hecho, muchas de las herramientas más utilizadas no están construidas en JavaScript, en particular Hugo (Go), Jekyll (Ruby), Pelican (Python) y Bridgetown (Ruby), lanzado recientemente. Mientras tanto, herramientas como Eleventy se crean utilizando JavaScript pero no dependen de un marco de JavaScript. Ninguna de estas herramientas impide el uso de un marco de JavaScript, pero no lo requieren.

El punto aquí no es volcarse en los marcos de JavaScript o las herramientas que los utilizan. Estas son excelentes herramientas, utilizadas con éxito por muchos desarrolladores. Los marcos de JavaScript pueden ser herramientas muy poderosas capaces de simplificar algunas tareas muy complejas. El punto aquí es simplemente que la idea de que se requiere un marco de JavaScript para usar Jamstack es falsa: ¡Jamstack viene en 460 versiones !

Donde podemos mejorar

So that’s it, right? Jamstack is an ideal world of web development where everything isn’t just perfect, but perfectly easy. Unfortunately, no. There are plenty of legitimate criticisms of Jamstack.

Simplicity

Sebastian De Deyne, with Thoughts (and doubts) after messing around with the JAMstack:

In my experience, the JAMstack (JavaScript, APIs, and Markup) is great until is isn’t. When the day comes that I need to add something dynamic–and that day always comes–I start scratching my head.

Let’s be honest: Getting started with the Jamstack isn’t easy. Sure, diving into building a blog or a simple site using a static site generator may not be terribly difficult. But try building a real site with anything dynamic and things start to get complicated fast.

You are generally presented with a myriad of options for completing the task, making it tough to weigh the pros and cons. One of the best things about Jamstack is that it is not prescriptive, but that can make it seem unapproachable, leaving people with the impression that perhaps it isn’t suited for complex tasks.

Tying services together

Agreed. In yesterday’s web you could grab an instrument and begin playing. Today’s web development feels like a conductor trying to pull together a massive orchestra into a cohesive song – you have to understand each individual musician’s part to have any chance of success.

— Brian Rinaldi (@remotesynth) May 1, 2020

When you actually get to the point of building those dynamic features, your site can wind up being dependent on an array of services and APIs. You may be calling a headless CMS for content, a serverless function that calls an API for payment transactions, a service like Algolia for search, and so on. Bringing all those pieces together can be a very complex task. Add to that the fact that each often comes with its own dashboard and API/SDK updates, things get even more complex.

This is why I think services like Stackbit and tools like RedwoodJS are important, as they bring together disparate pieces of the infrastructure behind a Jamstack site and make those easier to build and manage.

Overusing frameworks

In my opinion, our dependence on JavaScript frameworks for modern front-end development has been getting a much needed skeptical look lately. There are tradeoffs, as this post by Tim Kadlec recently laid out. As I said earlier, you don’t need a JavaScript framework to work in the Jamstack.

However, the impression was created both because so many Jamstack tools rely on JavaScript frameworks and also because much of the way we teach Jamstack has been centered on using frameworks. I understand the reasoning for this — many Jamstack developers are comfortable in JavaScript frameworks and there’s no way to teach every tool, so you pick the one you like. Still, I personally believe the success of Jamstack in the long run depends on its flexibility, which (despite what I said about the simplicity above) means we need to present the diversity of solutions it offers — both with and without JavaScript frameworks.

Where to go from here

Sheesh, you made it! I know I had a lot to say, perhaps more than I even realized when I started writing, so I won’t bore you with a long conclusion other than to say that, obviously, I have presented these myths from the perspective of someone who believes very deeply in the value of the Jamstack, despite it’s flaws!

If you are looking for a good post about when to and when not to choose Jamstack over server-side rendering, check out Chris Coyier’s recent post Static or Not?.