Tags: JAMstack, Sitios estáticos, Front end
Los sitios estáticos son una de las posibilidades que ofrece la filosofía JAMstack, que consiste en esencia en prescindir absolutamente de los servicios de alojamiento tradicionales y de las (a menudo problemáticas) bases de datos, desarrollando todo el proyecto (en general páginas web y apps) en base a JavaScript
, APIs
y lenguaje de marcado
.
Si tuviera que poner un eslogan para sintetizar el significado de JAMstack sería el siguiente:
Todo empieza y acaba en la nube
Por su propia construcción este sistema aporta de serie, entre otras cosas:
Como comentaba en la entrada de prueba, mi combinación ha sido la siguiente:
R
>
RStudio>
[
RMarkdown+
Blogdown]
>
GitHub>
Hugo>
Netlify
Muy esquemáticamente:
IDE
que hace más accesible el uso y la gestión de R
.R
es su inmensa biblioteca de librerías (packages
) para hacer casi cualquier cosa. En el caso que nos ocupa, para crear un blog o una web en este entorno, las librerías que he utilizado son Rmarkdown, knitr y blogdown.git
. Hoy es más que eso, y permite por ejemplo coordinarse con otras tecnologías para crear y mantener sitios estáticos
y aplicaciones web, que pueden de hecho ser alojadas en su propia infraestructura.go
, y se encarga entre bambalinas de transformar tu sitio web en una página web operativa.Si alguien se decide a investigar esta tecnología, tiene que tener en mente que se da por sentado un conocimiento aceptable de:
html
deberían ser parte de la cultura general de todo usuario. En una tarde puedes aprender lo básico por ejemplo en W3Schools, aunque si realmente se quiere profundizar recomiendo tener siempre a mano MDN.html
, lo básico del CSS se puede aprender en otra tarde en W3Schools, o profundizar en MDN. Una vez conocido lo básico, no viene nada mal ampliar su funcionalidad con Sass
(syntactically awesome style sheets) que resulta más fácil, más compatible y más poderoso que cualquiera de las versiones de CSS
.CLI
. Puedes fácilmente conseguir minimizar su uso, pero es práctica y afortunadamente imposible que te escapes totalmente de ella. Yo utilizo Windows
y Linux
así que estoy encantado con que Windows haya incluído en Windows 10
, aparte de su poderosa PowerShell, un subsistema Linux
que corre nativamente la Bash
de Ubuntu
(WSL), lo cual elimina la necesidad de máquinas virtuales en tu sistema.código
. Desde primeros de los ochenta he pasado por muchas variedades de editor, casi siempre encadenado al ofrecido por el propio lenguaje de programación. Pero la tecnología actual es sencillamente flipante, una maravilla. Hay muchos, es toda una industría, todos funcionan de miedo y yo he usado alegremente los principales, algunos de ellos desde casi sus principios (Atom, Sublime, Bracket), hasta hace un par de años que me pasé a la opción de código abierto de Microsoft, Visual Studio Code, que funciona a las mil maravillas, y tiene poco que envidiar a opciones comerciales como Sublime
.Ok, entiendo que todo esto puede resultar intimidante para mucha gente, es normal, pero en realidad no necesitas aprender todo, ni hacerte un experto en todo, aunque sí debes adoptar una actitud proactiva, entender que probablemente nunca vas a necesitar profundizar en una tecnología concreta, y asumir sin rubor que ahí está Google (y stack overflow
) para ayudar.
Lighthouse es una herramienta de Google para analizar sitios web, cualquiera puede auditar cualquier página web pública. Por ejemplo si miras europa press (que no es ni de lejos de los peores sitios) obtienes esto:
Estos valores hay que tomarlos con una pizca de sal, Google utiliza sus métricas, que no son ni únicas ni perfectas (aunque indudablemente importantes e influyentes), pero puede haber otras prioridades por parte del propietario del proyecto, que naturalmente tienen preferencia a la hora de diseñar un sitio incluso por encima de los estándares de Google, o de W3 para el caso . El ejemplo de europa press muestra que están claramente inclinados a la optimización SEO y les importa menos que tengas que esperar incluso minutos para ver el contenido.
Aquí es donde JAMstack muestra su poderío. Estos son los resultados para este sitio:
El mensaje de que el sitio está bloqueado para los buscadores aparece porque cuando escribo esto estoy en fase de pruebas, y tengo configurado mi fichero robots.txt para que instruya (en realidad sugiera) a los bots que el sitio no sea indexado.
# robots.txt versión staging
User-agent: *
Disallow: /
Para dejarles escarbar en todo el sitio no hace falta más que quitar la barra /
.
Y para evitar (sugiriéndoles) que no indexen un determinado directorio, hay que especificar cuál:
# robots.txt versión producción
User-agent: *
Disallow: /esto/es/privado/please
No se me ocurren muchas, estas tres son importantes:
front end
, que necesitarán del trabajo de un desarrollador para conseguir un sitio estable y eventualmente actualizarlo.La primera consideración ha de ser advertir que estamos ante tecnologías modernas, en plena ebullición, y que por tanto de momento escasean herramientas que faciliten el proceso a usuarios no especializados, o que no estén al menos familiarizados con los fundamentos básicos del funcionamiento de Internet hoy, o que no se sientan confortables con toda una variedad de aplicaciones, lenguajes y técnicas, que incluyen pero no se limitan a todas las citadas arriba.
Pero la tendencia será a superar este problema. Veamos un ejemplo ilustrativo.
Un freelance le hace una web o un blog a un cliente, y le entrega una carpeta que contiene la página terminada, así como todos los ficheros que sirven para compilarla con su generador estático favorito. Cualquier modificación, mejora, eliminación de errores, actualización, parche de seguridad, o simplemente la publicación de un artículo en el blog, requiere de ciertos conocimientos más o menos oscuros. El cliente necesitará de los servicios del mismo freelance, o de otro desarrollador que conozca el tema, o de lo contrario correrá el riesgo de pulverizar toda la página web, quizá no una debacle, pero desde luego un escenario no deseable para un sitio en producción.
Un profesional equivalente hace unos años le hacía la página al cliente en WordPress, creaba uno o varios usuarios con acceso de colaborador para que pudiera editar y publicar entradas (o páginas, textos, enlaces, fotos…) y todos tan amigos. Además como es una tecnología hegemónica (y también Open Source, por cierto), hay herramientas y especialistas por todo el mundo a tiro de clic.
Lo que utiliza WordPress (y su competencia -Joomla!, Drupal, Squarespace…) es un sistema de gestión de contenidos (CMS, del inglés) que simplifica el proceso de publicación y edición del sitio web, y que permite que usuarios sin conocimientos de programación puedan manejarse sin problemas en el entorno.
Bien, pues la industria JAMstack se está moviendo en ese sentido, y el año pasado Netlify sacaba su propio CMS
, y aunque desde mi punto de vista se queda muy chico todavía, la competencia y el mercado también se mueven, y tenemos ya algunas alternativas.
Comentados los pros y contras mi impresión es que estamos ante una tecnología, o más bien ante una simbiosis de tecnologías, que van a dar mucho juego durante los próximos años. Será muy interesante ver su evolución.
Sin embargo no creo que sea de momento una solución viable para el usuario medio, pero si una solución perfecta a día de hoy para determinados casos de uso:
CMS
ya disponibles como Netlify CMS o Forestry, de manera que puedan prescindir de los aspectos más técnicos.APIs
.¿Mi apuesta? Las ventajas son poderosas y las limitaciones son las normales en una tecnología emergente. Por eso creo que puede ser la arquitectura del futuro para un número creciente de áreas, y podría ser que en pocos años pudieran competir por la hegemonía de los CMS
tradicionales. Veremos.