¿Por qué elegí Next.js sobre Gatsby, Gridsome o Nuxt?

Cuando elegimos un marco para un nuevo proyecto web, por lo general tendemos a ceñirnos a las herramientas con las que estamos familiarizados, independientemente de lo bien que se ajusten al proyecto. Estoy tratando de hacer exactamente lo contrario. Siempre que tengo la oportunidad, pruebo nuevas tecnologías. ¿Qué aprendí después de estos experimentos? ¿Por qué termino con Next.js como mi herramienta estándar de generador de sitios estáticos (SSG)? En este post hablaré sobre cómo experimenté con diferentes tecnologías web. Se trata de encontrar una herramienta adecuada dentro de Jamstack, cómo elegir exactamente lo que es adecuado para el desarrollador y se integra bien en su proyecto, y por qué elegí Next.js.











Sobre mi experiencia en desarrollo web



Comencé mi viaje en el desarrollo web con PHP y MySQL, y luego, cuando estaba en la universidad, me cambié a la plataforma .NET. Me gustó la seguridad de tipos, el modelo MVC, las capacidades de depuración de código. Así fue, seguí usando .NET en el futuro, haciendo programación y consultoría. Pero fui cambiando gradualmente a JavaScript, y en particular a las primeras versiones de Angular.



Hace unos dos años, me cambié casi por completo a Jamstack. Decidí echar un vistazo más de cerca a Vue.js , ya que parecía la herramienta de JavaScript más amigable que existe. Hice mi sitio web personalutilizando Nuxt.js. Es un generador de sitios estáticos que ahora se denomina marco intuitivo para desarrollar aplicaciones Vue.js. Cuando terminé este proyecto, salió la primera versión de Gatsby , un sistema para construir sitios estáticos basado en React . Usé a Gatsby en mi próximo proyecto para crear el sitio Kentico Advantage , un proyecto simple destinado a apoyar a las agencias web. Esta fue mi primera experiencia con React. Y lo que encontré entonces, realmente no me gustó. Surgieron dificultades muy grandes incluso cuando fue necesario hacer algo.



Mi siguiente desarrollo fue mi propio sitio de bodas. Luego le di a Gatsby y React otra oportunidad, pero al final, solo un par de días después, cambié al marco Gridsome para Vue.js. En ese momento, este generador de sitios estáticos estaba ganando popularidad rápidamente. Me lo encontré literalmente en cada esquina. Gracias a este SSG, pude hacer un sitio web funcional simple en tres horas. Estaba fascinado. Vue.js ha crecido un poco más en mis ojos.



Entonces apareció el proyecto Sourcebit . Es un complemento que se utiliza para combinar varias fuentes de datos y SSG, que se encarga de transformar los datos y hacerlos más fáciles de usar. Dicho esto, el único generador de sitios estáticos basado en JavaScript compatible con Sourcebit fue Next.js... Por lo tanto, después de aprender los conceptos básicos, usé Next.js en otro proyecto.



Elección de herramientas según su propia experiencia o la de otra persona.



Arriba, mencioné las herramientas que más he usado en los últimos años. Pero, si los compara, entonces, como sucede a menudo, entre ellos no será posible elegir el que se puede colocar en primer lugar sin dudarlo.



Digamos que es un desarrollador responsable de elegir las herramientas adecuadas para su próximo proyecto. El momento del inicio del trabajo en el proyecto puede depender de cuál elija, por lo que es poco probable que pueda permitirse una experimentación prolongada con muchas de estas herramientas.



Puede elegir herramientas basadas en su propia experiencia y la experiencia de otras personas. Si ha trabajado con Angular antes, puede decidir mirar primero las herramientas que usan Angular. Si la última vez que trabajó con Angular fue hace mucho tiempo, pregunte a sus colegas qué utilizan. Es cierto que en tal situación no le pregunté a nadie sobre nada, sino que elegí inmediatamente Vue.js. El problema era que todos mis colegas habían trabajado con React antes. Por lo tanto, al final, tuve que usar Google para resolver los problemas emergentes.



Otro factor que influye en la elección de un marco es el tamaño del proyecto. Si crea un sitio personal probando herramientas en él, las preguntas que surjan en su trabajo serán simples. Las respuestas a ellos generalmente se encuentran en la documentación de la herramienta seleccionada. Pero digamos que está desarrollando un proyecto corporativo. Usan compilaciones parciales, algunas partes del proyecto se renderizan en el servidor, usa muchas fuentes de datos. Si en el curso del trabajo tiene alguna dificultad, entonces con la ayuda de la documentación no será posible lidiar con ellas, tendrá que buscar respuestas haciendo preguntas a sus colegas o en algo como Stack Overflow.



Arriba, mencioné tres herramientas de JavaScript. Pero Jamstack no siempre es JavaScript. Quizás PHP o Ruby estén más cerca de ti. Para encontrar el generador de sitios estáticos que más le convenga, consulte la siguiente tabla.



Plataforma Generador de sitio estático
.RED Statiq
Angular Scully
Vamos Hugo
PHP Sculpin
Reaccionar Gatsby, Next.js
Rubí Jekyll
Vue.js Gridsome, Nuxt.js


No puedo decir nada sobre plataformas con las que no he intentado trabajar todavía. Pero puedo compartir mis ideas sobre Vue.js, React y generadores de sitios estáticos relacionados.



Vue.js: comparando Gridsome y Nuxt.js



El framework Vue.js es conocido y reconocido por su excelente documentación. Gridsome sigue el mismo camino. La documentación de este SSG está muy bien escrita. Tiene todo lo que puede esperar cualquiera que comience con Gridsome. Cierto. Cuando leí esta documentación, me pareció que sus autores estaban leyendo mis pensamientos. Gridsome usa GraphQL. Por lo tanto, las fuentes de datos deben estar conectadas al sitio mediante complementos especiales. Gridsome asocia automáticamente modelos de datos con plantillas con los nombres correspondientes y organiza el enrutamiento. Para los principiantes, esta es una gran ventaja. Gridsome permite recursos JavaScript externos. Sé que no parece una "práctica recomendada", pero, por ejemplo, si descarga una plantilla de un sitio como HTML5UP.net, dicha plantilla contendrá cierta cantidad de código JS. Cuando necesitaba algo como esto en Nuxt.js, encontré dificultades. Al final, tuve que reescribir la funcionalidad correspondiente en Vue.



Resumiendo mi experiencia con Gridsome, puedo decir que fue fácil para mí trabajar. El marco me ayudó a lograr lo que necesitaba, no tuve que luchar contra los obstáculos que esta plataforma pondría frente a mí. Gridsome le permite acceder a un sitio web funcional sencillo en tan solo unas horas.



Al trabajar con Nuxt, lo más difícil fue comprender los detalles de trabajar con el almacén de datos de Vuex y crear Vuex.store... Estos repositorios se utilizan en proyectos de Nuxt.js. Si un componente necesita trabajar con datos, entonces debe partir del hecho de que todos los datos están almacenados en un solo lugar. Por supuesto, puede almacenar datos a nivel de componente, pero a menudo sucede que diferentes componentes utilizan los mismos datos. Como resultado, para evitar la duplicación de código, debe utilizar un único almacén de datos. Para implementar dicho almacenamiento, no necesita ningún complemento especial que recopile los datos necesarios de algún lugar. Aunque yo, por ejemplo, usé un complemento diseñado para funcionar con CMS sin la interfaz de usuario de Kentico Kontent . Definitivamente me hizo la vida más fácil, pero también podría haber usado la API Fetch con el SDK de entrega.... Después de que todo funcionó para mí, me di cuenta de que me gusta este patrón. Es confiable y flexible. Yo, para trabajar en grandes proyectos, lo elegiría. Para usarlo, solo necesita, al principio, dedicar un tiempo a conocerlo.



Nuxt.js admite tanto la representación del lado del servidor como el modo de vista previa. Se ha formado una gran comunidad a su alrededor. Todo esto nos permite decir que Nuxt.js es un proyecto más maduro que Gridsome, y que Nuxt.js es más adecuado para sitios serios.



Resumamos la información sobre Gridsome y Nuxt.js enumerando sus fortalezas (marcadas con "+") y debilidades (marcadas con "-") en la siguiente tabla.



Gridsome Nuxt.js
+ excelente documentación + flexibilidad
+ facilidad de uso + más maduro y confiable que Gridsome
+ usando GraphQL + , Gridsome
+ JavaScript- +
+
— «», — , Gridsome


React: Gatsby Next.js



Empecemos por Gatsby. Creo que la característica más interesante de este framework está representada por una herramienta para trabajar con GraphQL llamada GraphiQL . Gatsby usa GraphQL. Y GraphiQL le permite trabajar con los datos que se utilizan en el sitio. No puedo enfatizar lo suficiente la importancia y utilidad de esta herramienta. Le ahorra al desarrollador tener que leer la documentación de la fuente de datos que se está utilizando. GraphiQL le permite ver datos de forma interactiva. A partir de los datos, puede elegir lo que desee. Esto da como resultado consultas GraphQL generadas automáticamente que se copian en componentes.





Trabajar con GraphiQL



Usar GraphQL en Gatsby también significa buscar complementospara las fuentes de datos aplicables. Es cierto que estos complementos están disponibles para todos los principales CMS sin una interfaz de usuario. Otro punto fuerte de Gatsby es que se ha creado una gran cantidad de complementos para este marco. Hay complementos para literalmente todo, desde SEO hasta la carga progresiva de imágenes y la exportación de un esquema GraphQL.



Pero cuando se trabaja con Next.js, faltan herramientas estándar para trabajar con datos. Como resultado, el desarrollador tiene que dedicar tiempo a tratar de averiguar exactamente qué utilizar en cada situación específica. Por ejemplo, al resolver problemas similares, me inspiré en este repositorio y utilicé el patrón "Repositorio". Si puede vivir sin GraphQL, Next.js le dará todo lo que Gatsby puede darle y más.





Enrutamiento en Next.js



Next.js utiliza un modelo de enrutamiento basado en archivos. Esto hace que sea muy fácil encontrar páginas y plantillas incluso en situaciones en las que tiene que trabajar con un proyecto desconocido. Este marco le permite combinar páginas estáticas y páginas generadas dinámicamente. Estos dos mecanismos de creación de páginas incluso se pueden combinar en una sola página. Esto facilita enormemente la implementación de la funcionalidad de vista previa delmaterial. Tanto Gatsby como Next.js saben cómo crear compilaciones incrementales. Pero en el caso de Gatsby, debe alojar el sitio en Gatsby Cloud , y esto solo es posible utilizando complementos preparados con requisitos especiales.



Al comparar Next.js y Gatsby, se puede observar que Next.js genera paquetes de versiones más pequeños. Si hablamos de encontrar materiales de referencia y obtener respuestas a las preguntas de los miembros de la comunidad, entonces, como ha demostrado la práctica, Gatsby y Next.js se ven casi iguales en este sentido.



Resumamos los pros y los contras de Gatsby y Next.js.



Gatsby Next.js
+ usa GraphQL + práctico modelo de enrutamiento basado en nombres de archivos
+ contiene una herramienta para trabajar con GraphQL + modo de vista previa versátil
+ hay muchos complementos para Gatsby + la capacidad de combinar páginas estáticas y dinámicas
- sin sistema de renderizado de servidor real + construcciones más compactas que Gatsby
- compilaciones incrementales y modo de vista previa vinculados a Gatsby Cloud - no existen mecanismos estándar para obtener datos de diversas fuentes, lo que hace necesario que el desarrollador encuentre dichos mecanismos
- el esquema y el almacenamiento en caché de los ensamblados de Gatsby suelen ser la causa de los problemas de almacenamiento en caché


Otras consideraciones a tener en cuenta al elegir una plataforma



A la hora de decidir qué herramienta utilizar para proyectos web, a menudo pensamos así: "La documentación es buena, mucha gente habla de ella en Twitter, a menudo se lanzan versiones, hay muchos complementos". Por lo general, termina con ese razonamiento. Si crees que vas a estar usando una plataforma durante mucho tiempo, si crees que se puede utilizar en varios proyectos o incluso convertirse en una herramienta oficial en toda tu empresa, también debes hacerte las siguientes preguntas:



  • , ?
  • ?
  • ?
  • , , - ?
  • ?
  • - ?




Cuando se trata de elegir frameworks web, tiendo a usar Vue.js siempre que sea posible. Me parece que este marco, sin mucha interferencia con su configuración estándar, le permite crear rápida y fácilmente lo que necesito. Normalmente uso Vue.js siempre que necesito elementos personalizados y componentes de sitios web tradicionales que necesitan una funcionalidad dinámica. Estoy construyendo pequeños sitios en Vue.js. Y, como no uso Vue.js para proyectos grandes, tiendo a usar Gridsome.



Para proyectos más grandes y serios, uso la biblioteca React. En Kentico, casi todo el desarrollo de front-end se basa en React. La empresa planea avanzar en esta dirección en el futuro. Por tanto, es lógico que yo haga lo mismo. Si hablamos de elegir un generador de sitios estáticos, ahora uso tanto Next.js como Gatsby, pero me inclino más por el primero de ellos. Para mí, la característica más importante de este marco es el enrutamiento basado en archivos, que también admite rutas dinámicas. También me gusta la compatibilidad con Sourcebit, que permitirá, si es necesario, cambiar las fuentes de datos o SSG sin reescribir todo desde cero.



¿Qué generadores de sitios estáticos usas?










All Articles