 Muy buenas WordPressers, seguimos con la siguiente charla corta y vamos a dar la bienvenida a Daniel Cebane. Daniel es un diseñador y desarrollador full stack, es un profesional al que le gusta que sus proyectos sean accesibles, sencillos, bonitos, rápidos y viene a contarnos una alternativa a la creación tradicional de páginas web con WordPress. Jamstack, no sé si lo conocéis, si os suena, si sois unos valientes, pero sea lo que sea, adelante con ello Daniel. Muy buenas a todos, es un placer estar aquí, como supongo que ya os habrán dicho, mi nombre es Daniel Cebane, soy un diseñador y desarrollador full stack, ya apoyado unos cuantos años desarrollando aplicaciones y páginas web, sobre todo con JavaScript y con React y últimamente me he interesado por Jamstack, ya que nos permite crear páginas web rapidísimas y usando JavaScript, podéis encontrarme en desebane.com o en academiajamstack.com. El último proyecto donde escribo sobre este tema, así que si os interesa podéis echarle un vistazo. Hoy vamos a ver una pequeña introducción a Jamstack, ya que hay mucha gente que no sabe lo que es. Primero y todo y más importante es que Jam, aunque significa mermelada, no tiene nada que ver con Jamstack. Jam viene de JavaScript, API y markup, pero Jamstack no es como otros stacks, como por ejemplo LAMP que viene de Linux Apache MySQL y PHP. Jamstack no tiene un set de herramientas concreto, es más bien una arquitectura, una forma de crear páginas web. Estas páginas web van a ser siempre estáticas, formadas por archivos HTML re-rendrizado, de ahí lo de markup, pero que sea estático no significa que no pueda tener partes dinámicas, ahí es donde entra JavaScript y API. Por ejemplo, podemos tener un blog con unos posts que son páginas estáticas, pero la parte de comentarios puede ser dinámica, utilizando JavaScript y una API. En las web tradicionales, como puede ser una creada con WordPress, cuando vamos a una página ésta se rendirá dinámicamente, o sea que se va a la base de datos, crea la página y la envía. Esto pasa siempre que navegamos, las páginas se están creando en tiempo real, digamos. Esto en Jamstack no ocurre, como ya hemos dicho, son páginas estáticas. En Jamstack tenemos nuestro datos de origen en algún sitio, da igual que sea, puede ser un CMS, Mardown, JSON, da igual. Con esos datos y cada vez que cambien se va a generar la página estática, utilizando estátics a generators o a mano. Y una vez esté generado la página, ya se puede estudiar directamente en un cdn o un hosting, no tanto cuando se navegue por la página, se van a recibir directamente html perrendirizados. No va a haber una aplicación en el servidor que esté creando las páginas dinámicamente. Las páginas Jamstack o estáticas tienen muchos beneficios. Mejor rendimiento, no tiene que ir cada vez a la base de datos, las páginas están ya están perrendizadas. Más seguro no tienes que tener un servidor, una aplicación de servidor funcionando, más barato, puede que sea incluso gratis hospedar tus páginas estáticas. Más escalabilidad, no tienes que preocuparte del tráfico que puede tumbar tu servidor. Las ventajas son muchas y bastante importantes, son un factor decisivo para decidir si usar o no la arquitectura de Jamstack. Después tenemos una desventaja y es que cada vez que el contenido de origen cambia hay que regenerar las páginas para que se mantengan actualizadas. El problema es que puede tardar 30 segundos, un minuto o dos depende del proyecto. Yo no veo que sea un problema tan grave porque no creo que pase nada, pues para 30 segundos. Eso ya dependerá del proyecto y la página. A menos que nuestra página web sea muy pequeña, deberíamos usar un gel stms como datos de origen. Que es un gel stms, las más con cms sin corpres no son gel stms, todo lo que pudiera ser utilizado como tal a través de su restapi o GraphQL con un plugin. Estos son otros gel stms que puede estar interesantes. Por ejemplo Directus, Strapi, Ghost que está pensado más para blogs, Leafy dms que está basado en Git, o sea, aguala a todos sus datos en un reproductorio de Git. Hay un montón, supongo que aquí el que más interesa es corpres. Por eso están los satisíades y unitos que son los que sacan los datos de origen y general en la página. Lo más importante son Gatsby y Next. A mí el que más me gusta es Gatsby. Amos utilizan React, para que no lo sepa, React es una librería de JavaScript. Creo que me gusta ver utilizas React también. Después está Geithson y Nuxt, que es lo mismo pero con View. Después está Frontidi, que es un proyecto español que hace un par de semanas consiguió un millón de euros, una roda de inversión de automática, así que pensé que sería importante mencionarlo. Pues para el deployment, realmente como son páginas estáticas podríamos hospedarlo en cualquier sitio. Pero claro, cuando haya cambios en los datos de origen habría que volver a autorizar esas páginas estáticas. Por eso existen estas herramientas como una Leafy que te permiten automatizar esto. Y aparte de otros beneficios como por ejemplo te permite hacer testa B con tus páginas, además es gratis hospedar ahí tus páginas. Hay unos cuantos interesantes. Después tenemos unos ejemplos de páginas creadas con Gatsby, por ejemplo Strygma, la herramienta de diseño colaborativa, la documentación de React, Brown, la página de una marca importante. Creo que Nike también tenía una página hecha con Gatsby y habrá muchas más páginas que seguro que desconocemos. Aquí tenemos una página de ejemplo creada con Gatsby. Como podemos ver es rapidísima, el cambio de página es casi instantáneo. De hecho si nos vamos a web.dev y pasamos el test de lighthouse tenemos un resultado casi perfecto. Esto es lo normal en páginas Jastak y en páginas Gatsby. De hecho web.dev también es una página Jastak, aunque no usa Gatsby, usa otro static generator, pero bueno. Esta página de ejemplo está hospedada en el ify.com y saca sus datos de este golpes. Vamos a hacer un cambio, una prueba de cambio en el título de este post para que veamos cómo funciona. Le cambiamos el título, le ponemos lore in ipsum por ejemplo, actualizamos y como tiene este plugin instalado Jastak deployment cada vez que haya un cambio en golpes va a avisar en el ify para que haga una reconstrucción, un rebuild de la página con los nuevos datos. Actualizamos, como podemos ver está haciendo el rebuild y este es una de las desventajas entre comillas y es que no es isantáneo, tardará unos segundos ya que tiene que recrear las páginas con los cambios. No tardará mucho porque no es una página que tenga muchos posts. Tiene los que está haciendo ahí sus cosas, sacando sus datos del WordPress y ya debería estar. Ahí lo tenemos site islib, entonces vamos aquí y actualizamos, aquí no es, aquí lore in ipsum y ahí lo tenemos, lore in ipsum, lore in ipsum y esto es todo. Espero que os haya interesado un poco esto de Jastak y cualquier duda no dudéis en preguntarme. Un saludo.