¿Estático o no?

Un breve artículo de opinión de Kev Quirk: Por qué no uso un generador de sitios estáticos . Kev usa WordPress:

¿Quieres escribir un blog en mi iPad ? Puedo. ¿Quieres hacerlo en mi teléfono? Ningún problema. ¿En una máquina que normalmente no uso? No hay problema, siempre que tenga un navegador.

En primer lugar, vale la pena entender que al usar WordPress no se excluye el uso de un generador de sitios estáticos. WordPress tiene una API , y eso abre la puerta para acceder a esa API durante un proceso de construcción y construir su sitio de esa manera. Eso es lo que hace Gatsby , hay un complemento que exporta un sitio estático y proyectos como Frontity realmente desdibujan las líneas.

Pero estoy de acuerdo con Kev en su razonamiento. Por todas sus razones, y 1000 más, ejecutar un sitio de WordPress es una opción perfectamente aceptable y, a menudo, inteligente. Lo pienso en términos de solidez y disponibilidad de funciones. ¿Necesitas comercio electrónico? Está allá. ¿Necesita formularios? Hay complementos geniales. ¿Necesita mejorar el funcionamiento del CMS? Tienes control sobre los tipos de contenido y lo que contienen. ¿Necesita autenticación? Esa es una característica fundamental. ¿Desearías haber tenido una gran experiencia de edición? Gutenberg es glorioso.

Una y otra vez, construyo lo que quiero con WordPress de forma rápida y eficiente y me hace sentir productivo y poderoso. Pero no quiero hacer esto específicamente sobre WordPress; Esto puede ser cierto para cualquier CMS “clásico”. Craft CMS tiene una API GraphQL lista para usar . Acabamos de publicar sobre un seminario web de Drupal + Jamstack .

En el mundo relativamente nuevo de los sitios estáticos, una pequeña cosa puede terminar en un viaje de investigación e implementación, como si fueras la única tercera persona en la Tierra en hacerlo.

Ahora todo lo dicho…

¿Qué pienso de los generadores de sitios estáticos y del mundo Jamstack ? Son increíbles.

Creo que hay mucho que decir sobre la construcción de sitios de esta manera. El desacoplamiento de datos y front-end es inteligente. La seguridad es genial. El DX, con las vistas previas de implementación y todo basado en git, es genial. La velocidad que obtienes desde el principio es asombrosa (servir HTML desde una CDN es toda una hazaña).

Al igual que un CMS del lado del servidor clásico no le impide crear un sitio estático, crear con un sitio estático no le impide hacer cosas dinámicas, incluso cosas dinámicas súper sofisticadas. Josh Comeau tiene una nueva publicación excelente sobre esto. Creó una pequeña y elegante aplicación que funciona muchísimo en el navegador con React, pero eso no significa que todavía no pueda entregar una buena cantidad de forma estática. Lo llama un “cambio de mentalidad”, refiriéndose a la idea de que uno podría pensar que necesita una llamada a la base de datos, pero ¿realmente la necesita? ¿Es posible que esa llamada a la base de datos ya haya ocurrido y haya generado un archivo estático? Y si no, aún así, parte podría haberse generado con los últimos bits llegando dinámicamente.

No puedo esperar a que llegue un mundo en el que empecemos a ver realmente lo mejor de ambos mundos. Hacemos todo lo que podemos de forma estática, obtenemos todo lo que no podemos hacer de esa manera con las API y no comprometemos las mejores herramientas en el camino.

Cuándo optar por un sitio estático…

• Si puedes, deberías considerarlo, ya que la velocidad y la seguridad son inmejorables.
• Si está trabajando con un proyecto Greenfield.
• Si su proyecto se basa en API accesibles y las utiliza, puede acceder a esa API durante el proceso de compilación y utilizarla después de la carga inicial de HTML.
• Si algún generador de sitios estáticos parece perfecto para algo que estás haciendo.
• Si un análisis de costos dice que sería más barato.
• Si la funcionalidad (como las vistas previas de compilación) sería extremadamente útil para un flujo de trabajo.

Cuándo optar por el software del lado del servidor…

• Si necesita las funciones de un CMS clásico (por ejemplo, WordPress) y la deuda técnica de pasar a estartico desde allí es demasiado alta.
• Si ya está familiarizado con un proyecto renderizado en un servidor (Ruby on Rails, Python, etc.) y no tiene ningún problema.
• Si ahí es donde tienes más experiencia en equipo.
• Si una analítica de costos dice que sería más barato.
• Si no existen buenas soluciones estáticas para lo que desea crear (por ejemplo, software de foros).
• Si tiene una situación extrema, como millones de URL, y el tiempo de compilación para estática es demasiado alto.

Malas razones para evitar un sitio estático…

• Necesitas hacer cosas con los servidores. (¿Por qué? Aún puede acceder a las API en los servidores, ya sea durante la compilación o durante el tiempo de ejecución).
• Necesitas autenticación. (¿Por qué? Jamstack es perfectamente capaz de realizar autenticación con JWT y demás).
• Ni siquiera has pensado en hacer cosas al estilo Jamstack.

Malas razones para elegir software del lado del servidor…

• Ni siquiera has pensado en hacer cosas al estilo Jamstack.
• Porque cree que el uso de herramientas cómodas/existentes/clásicas/bien establecidas/con buen soporte le impide crear algo de forma estática.
• Algo algo SEO. (En todo caso, el contenido renderizado estáticamente debería funcionar mejor. Pero es comprensible si pasar a estático significa pasar a llamadas del lado del cliente para algo como datos del producto).