Next.JS: lo bueno, lo malo y todo lo que debes saber

NextJS es una tecnología que se utiliza mucho hoy en día para desarrollo web. A mí personalmente me gusta bastante y la he utilizado en múltiples proyectos. Tras varios años utilizando tanto React como NextJS, te quiero contar lo bueno, lo malo, las ventajas y los problemas que me he encontrado creando productos.

Si quieres aprender React y NextJS, estoy planteando una formación en un webinar. Si te interesa apúntate en aquí para que pueda notificarte por e-mail.

Introducción

Lo primero que te quiero contar es por qué empecé a utilizar React: cuando comencé en el mundo laboral, estaba de moda Angular.js con el que desarrollamos algunas aplicaciones webs para clientes (algunas de ellas muy interesantes la verdad), pasando por varias versiones de éste. Luego comencé a trabajar para otros clientes que usaban React, que justo apareció por esta fecha y era la moda, por lo que me tocó aprenderla.

Aquí hay mucho que contar, y me dejo esto para otro post, sobre el funcionamiento interno de React y las diferentes estrategias de renderizado: Client-Side-Rendering (CSR), Server-Side-Rendering (SSR), Static-Site-Generation (SSG) y los nuevos React-Server-Components (RSC).

React por sí sólo es una librería para cliente, por lo que tú tienes que gestionarte toda la implementación para realizar el renderizado en el lado del servidor, así como la compilación del bundle. Obviamente no vamos a reinventar la rueda (a menos que vemos una oportunidad lo suficientemente valiosa), por lo que lo siguiente es buscar alguna herramienta que lo haga por ti.

En este caso para mi el mejor entorno de desarrollo a día de hoy, y desde hace bastante tiempo, es usar NextJS. Por tanto quiero contarte mi experiencia con NextJS, todo lo bueno que me aporta y el por qué la he elegido, pero también todo lo que no te cuentan, los problemas que luego sufres en el día a día.

NextJS: lo bueno y lo malo

NextJS es un framework para crear páginas webs que se basa en la librería React. Es de código libre y es mantenido por la empresa Vercel, que además te ofrece hosting. Este framework te ofrece múltiples ventajas:

Funcionalidad de NextJS

• Server-Side-Rendering (SSR): mejora el SEO y la velocidad de carga inicial.
• Static-site-generation (SSG): te permite generar páginas estáticas en tiempo de construcción, de forma que únicamente tienes que servir ficheros estáticos. Más eficiente y barato e ideal para páginas que no cambian con frecuencia.
• Sistema de routing: la estructura de carpetas te permite crear las rutas de tu página web de forma fácil y flexible. Hasta ahora no me he encontrado ningún problema.
• Pre-fetching de datos: mejora la experiencia del usuario al cargar datos antes de que sean necesarios.
• Soporte para TypeScript. Si quieres tipado, viene por defecto.
• Está basado en Node.js y te permite añadir rutas (/api) muy fácilmente.

Lo bueno de Next.js

• Una de las cosas que me gusta mucho es la comunidad. Al final hay muchas personas trabajando con la misma herramienta, que se encuentran los mismos problemas que tu y, o bien permite que se solucionen antes, o bien alguien ya ha encontrado un workaround.
• Trabajar con ficheros "jsx" / "tsx" es muy cómodo. Poder tener el HTML junto con el código Javascript / Typescript hace que el desarrollo sea más rápido.
• El entorno y la experiencia de desarrollo están muy cuidados, funcionan rápido y no suelen dar problemas.
• Integra muchas optimizaciones sin que tengas que tener los conocimientos sobre cómo optimizar el bundle, cómo hacer prefecth, optimización de imágenes, etc.
• Te evita trabajar con ficheros javascript, conectarlos con el html, y gestionar el sistema de bundling por tu cuenta, que suele requerir mucho conocimiento y lo más importante, el tiempo.
• Hay muchas gente probando y reportando errores, por lo que el desarrollo es muy activo y se corrigen tanto errores como se añaden mejoras continuamente.

React Server Components

Recientemente han salido los React-Server-Components, que te explicaré pronto qué son y por qué son interesantes, y NextJS es el único framework a día de hoy que lo implementa ya que, por así decirlo, React únicamente define la interfaz pero deja la implementación a terceros.

La idea de detrás de los RSC es simple: renderizar en el servidor todo lo que se pueda como server-components, que actúan como una plantilla HTML y no envían código javascript al navegador. De esta forma, puedes utilizar los client-components donde necesites interactividad con el usuario, lo que reduce el tamaño del bundle y el tiempo de carga (e interactividad) de la página.

Vamos, lo que puedes conseguir con tecnologías de hace 20 años como php / python con herramientas para realizar plantillas de html con un toque de javascript. Aunque es cierto que Nextjs te ofrece muchas ventajas para que no tengas que preocuparte de la gestión de la interactividad con el usuario, es decir, toda la parte de javascript viene llista "out-of-the-box".

Todo lo que no te cuentan

Cuando hay tantas personas y empresas utilizando NextJS tras varios años, creo que algo tienen que estar haciendo bien para que tanta gente lo siga utilizando, como yo por ejemplo.

"No todo lo que reluce es oro" y cuando me encuentro problemas me planteo lo fácil que podría ser realizar la mismas cosas con un template de html. De hecho tengo algún proyecto con generación de estáticos o con templates html nativos, y trabajar con js y html es mucho más tedioso que jsx. O quizá simplemente me he acostumbrado a este ecosistema que para mi es más cómodo.

En cualquier caso, te cuento las cosas que no me gustan:

• Utilizar server-side-rendering es costoso computacionalmente hablando. La función renderToString (o la nueva renderToNodeStream) son CPU intensivas y si tienes mucho tráfico, te conviene tener bien configurada una capa de caché.
• Si te sales de los "happy-paths" suele haber problemas. Siempre que he necesitado hacer algo más complejo o que se salga de lo común, me encuentro con diversos problemas.
  • Por ejemplo, no puedes acceder a la URL que estás renderizando en el servidor y necesitar algún workaround para tener el path https://github.com/vercel/next.js/issues/43704
  • El middleware de NextJS está pensado para un runtime edge, por lo que no puedes realizar aquí mucha lógica y tienes que delegarla a alguna API.
  • Si necesitas multi-idioma, añadirás complejidad a tu base de código aunque conseguirás que te funcione como quieres.
• Los problemas se resuelven con workarounds. Por suerte alguien ya se ha encontrado con el mismo problema que tú y suele haber algún hilo en GitHub issues de cómo resolverlo. Aunque en muchas ocasiones, estos workarounds tienen sus desventajas.
• Toda la parte nueva de React-Server-Components está verde y te vas encontrado errores. En mi caso he tenido que rediseñar algunas partes de sistemas que tengo en producción por bugs de la versión actual.
• Muchas veces me pregunto si no hay otra alternativa mejor cuando me encuentro todos estos problemas, pero por ahora, no lo he encontrado.
• Si necesitas añadir una capa de personalización bastante grande, como código personalizado, suele ser bastante complejo o poco posible utilizarlo.

Conclusión: por qué sigo utilizando NextJS

A pesar de todo lo malo, conozco muy bien el funcionamiento de NextJS y de React, me he estudiado los diferentes detalles, los problemas que surgen, cómo solucionarlos... y al final esto, junto con la comodidad de jsx/tsx y la experiencia de desarrollo, me permite ir rápido.

Tiene todo lo que necesito para construir un producto simple, funcional y eficiente que es lo que al final uno busca. Y si con el tiempo me encuentro problemas, siempre puedo rediseñar partes utilizando otras tecnologías.

Al final mi consejo y mi aprendizaje en este sector es que, en general, la tecnología es secundaria. Elige la que más te guste, la que mejor se te de, la que te permita ir más rápido y empieza a construir e iterar tu producto.

Cuando crezca, habrá partes que tendrás que rediseñar y aquí ya puedes plantear usar otras herramientas para problemas concretos que de verdad tengas, evitando añadir soluciones complejas para problemas que a día de hoy no existen ni sabes si los vas a tener.

Y ojo, no digo que no pensemos lo que queremos construir y lo diseñemos bien desde un inicio, sentido común siempre por favor.

Así que elige una herramienta, apréndela bien y empieza a construir, ya que si no se te irá el tiempo aprendiendo herramientas y refactorizando código.