Cómo migrar de jQuery a Next.js

Publicado: 2022-03-10
Resumen rápido ↬ En este artículo, analizamos más de cerca diferentes enfoques y estrategias sobre cómo podemos migrar una aplicación web que usa el marco jQuery y comenzar a usar uno de los marcos React más geniales del mercado: Next.js.

Cuando apareció jQuery en 2006, muchos desarrolladores y organizaciones comenzaron a adoptarlo para sus proyectos. La posibilidad de extender y manipular el DOM que ofrece la biblioteca es excelente, y también tenemos muchos complementos para agregar comportamiento a nuestras páginas en caso de que necesitemos realizar tareas que no son compatibles con la biblioteca principal de jQuery. Simplificó mucho el trabajo de los desarrolladores y, en ese momento, convirtió a JavaScript en un lenguaje poderoso para crear aplicaciones web o aplicaciones de una sola página.

El resultado de la popularidad de jQuery todavía se puede medir hoy en día: casi el 80% de los sitios web más populares del mundo todavía lo usan. Algunas de las razones por las que jQuery es tan popular son:

  • Es compatible con la manipulación DOM.
  • Proporciona manipulación de CSS.
  • Funciona igual en todos los navegadores web.
  • Envuelve métodos de eventos HTML.
  • Fácil de crear llamadas AJAX.
  • Efectos y animaciones fáciles de usar.

A lo largo de los años, JavaScript cambió mucho y agregó varias funciones que no teníamos en el pasado. Con la redefinición y evolución de ECMAScript, algunas de las funcionalidades que proporcionó jQuery se agregaron a las características estándar de JavaScript y fueron compatibles con todos los navegadores web. Con esto sucediendo, parte del comportamiento que ofrece jQuery ya no era necesario , ya que podemos hacer las mismas cosas con JavaScript simple.

Por otro lado, comenzó a surgir una nueva forma de pensar y diseñar interfaces de usuario. Frameworks como React, Angular o Vue permiten a los desarrolladores crear aplicaciones web basadas en componentes funcionales reutilizables. React, es decir, trabaja con el "DOM virtual", que es una representación del DOM en la memoria, mientras que jQuery interactúa directamente con el DOM , de una manera menos eficaz. Además, React ofrece funciones geniales para facilitar el desarrollo de ciertas funciones, como la gestión de estado. Con este nuevo enfoque y la popularidad que comenzaron a ganar las aplicaciones de una sola página, muchos desarrolladores comenzaron a usar React para sus proyectos de aplicaciones web.

Y el desarrollo front-end evolucionó aún más, con marcos creados sobre otros marcos. Es el caso, por ejemplo, de Next.js. Como probablemente sepa, es un marco React de código abierto que ofrece funciones para generar páginas estáticas, crear páginas renderizadas del lado del servidor y combinar ambos tipos en la misma aplicación. También permite crear API sin servidor dentro de la misma aplicación.

Hay un escenario curioso: aunque estos marcos frontend son cada vez más populares a lo largo de los años, jQuery todavía es adoptado por la gran mayoría de las páginas web. Una de las razones por las que esto sucede es que el porcentaje de sitios web que usan WordPress es realmente alto, y jQuery está incluido en el CMS . Otra razón es que algunas bibliotecas, como Bootstrap, dependen de jQuery, y hay algunas plantillas listas para usar que lo usan y sus complementos.

Pero otra razón para esta cantidad de sitios web que usan jQuery es el costo de migrar una aplicación web completa a un nuevo marco. No es fácil, no es barato y requiere mucho tiempo. Pero, al final, trabajar con nuevas herramientas y tecnologías trae muchos beneficios: soporte más amplio, asistencia de la comunidad, mejor experiencia de desarrollador y facilidad para que las personas trabajen en el proyecto.

Hay muchos escenarios en los que no necesitamos (o no queremos) seguir la arquitectura que nos imponen frameworks como React o Next.js, y eso está bien. Sin embargo, jQuery es una biblioteca que contiene mucho código y funciones que ya no se necesitan. Muchas de las características que ofrece jQuery se pueden lograr utilizando funciones nativas modernas de JavaScript , y probablemente de una manera más eficaz.

Discutamos cómo podemos dejar de usar jQuery y migrar nuestro sitio web a una aplicación web React o Next.js.

Definir la estrategia de migración

¿Necesitamos una biblioteca?

Dependiendo de las características de nuestra aplicación web, incluso podríamos tener el caso de que realmente no se necesite un marco. Como se mencionó anteriormente, se incluyeron varias características de jQuery (o al menos una muy similar) a las últimas versiones del estándar web. Entonces, considerando que:

  • El patrón $(selector) de jQuery se puede reemplazar con querySelectorAll() .

En lugar de hacer:

 $("#someId");

Podemos hacer:

 document.querySelectorAll("#someId");
  • Ahora tenemos la propiedad Element.classList si queremos manipular clases CSS.

En lugar de hacer:

 $(selector).addClass(className);

Podemos hacer:

 element.classList.add(className);
  • Muchas animaciones se pueden hacer directamente usando CSS, en lugar de implementar JavaScript.

En lugar de hacer:

 $(selector).fadeIn();

Podemos hacer:

 element.classList.add('show'); element.classList.remove('hide');

Y aplica algo de estilo CSS:

 .show { transition: opacity 400ms; } .hide { opacity: 0; }
  • Ahora tenemos la función addEventListener si queremos manejar eventos.

En lugar de hacer:

 $(selector).on(eventName, eventHandler);

Podemos hacer:

 element.addEventListener(eventName, eventHandler);
  • En lugar de usar jQuery Ajax, podemos usar XMLHttpRequest .

En lugar de hacer:

 $.ajax({ type: 'POST', url: '/the-url', data: data });

Podemos hacer:

 var request = new XMLHttpRequest(); request.open('POST', '/the-url', true); request.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded; charset=UTF-8'); request.send(data);

Para obtener más detalles, puede echar un vistazo a estos fragmentos de código de JavaScript Vanilla.

Identificar componentes

Si usamos jQuery en nuestra aplicación, deberíamos tener algo de contenido HTML que se genera en el servidor web y código JavaScript que agrega interactividad a la página. Probablemente estemos agregando controladores de eventos en la carga de la página que manipularán el DOM cuando ocurran los eventos, probablemente actualizando el CSS o el estilo de los elementos. También podríamos estar llamando a servicios de backend para ejecutar acciones, que pueden afectar el DOM de la página, o incluso recargarlo.

La idea sería refactorizar el código JavaScript que vive en las páginas y crear componentes React. Esto nos ayudará a unir código relacionado y componer elementos que formarán parte de una composición más grande. Al hacer esto también podremos tener un mejor manejo del estado de nuestra aplicación. Analizando el frontend de nuestra aplicación, debemos dividirlo en partes dedicadas a una determinada tarea, de modo que podamos crear componentes basados ​​en eso.

Si tenemos un botón:

 <button>Click</button>

Con la siguiente lógica:

 var $btnAction = $("#btn-action"); $btnAction.on("click", function() { alert("Button was clicked"); });

Podemos migrarlo a un React Component:

 import React from 'react'; function ButtonComponent() { let handleButtonClick = () => { alert('Button clicked!') } return <button onClick={handleButtonClick}>Click</button> }

Pero también debemos evaluar cómo se llevará a cabo el proceso de migración ya que nuestra aplicación está funcionando y siendo utilizada, y no queremos afectarla (o, al menos, afectarla lo menos posible).

buena migración

Una buena migración es aquella en la que todas las partes de la aplicación migran completamente al nuevo marco o tecnología. Este sería el escenario ideal para nuestra aplicación ya que mantendríamos sincronizadas todas las partes y estaríamos usando una herramienta unificada y una única versión referida.

Una buena y completa migración suele incluir una reescritura completa del código de nuestra aplicación, y eso tiene sentido. Si construimos una aplicación desde cero, tenemos la posibilidad de decidir qué dirección queremos tomar con el nuevo código. Podríamos usar un nuevo punto de vista sobre nuestros sistemas y flujos de trabajo existentes, y crear una aplicación completamente nueva con el conocimiento que tenemos en este momento, más completa que la que teníamos cuando creamos nuestra aplicación web por primera vez.

Pero una reescritura completa tiene algunos problemas. En primer lugar, requiere mucho tiempo. Cuanto más grande sea la aplicación, más tiempo necesitaremos para reescribirla. Otro problema es la cantidad de trabajo y la cantidad de desarrolladores que se necesita. Y, si no hacemos una migración progresiva, tenemos que pensar cuánto tiempo no estará disponible nuestra aplicación.

Normalmente, una reescritura completa se puede lograr con proyectos pequeños, proyectos que no cambian con frecuencia o aplicaciones que no son tan críticas para nuestro negocio.

Migración rápida

Otro enfoque es dividir la aplicación en partes o partes. Migramos la aplicación por partes y lanzamos esas partes cuando están listas. Por lo tanto, hemos migrado partes de nuestra aplicación disponibles para los usuarios y que coexisten con nuestra aplicación de producción existente.

Con esta migración gradual, entregamos características separadas de nuestro proyecto de una manera más rápida a los usuarios, ya que no tenemos que esperar a que se reescriba la aplicación completa. También recibimos comentarios más rápidos de los usuarios, lo que nos permite detectar errores o problemas antes.

Pero una migración gradual nos lleva a tener diferentes herramientas, bibliotecas, dependencias y marcos. O incluso podríamos tener que admitir diferentes versiones de la misma herramienta. Este soporte extendido podría traer conflictos a nuestra aplicación.

Incluso podríamos tener problemas si estamos aplicando políticas en el ámbito global ya que cada una de las partes migradas podría funcionar de forma diferente, pero siendo afectado por el código que establece parámetros globales a nuestro sistema. Un ejemplo de esto es el uso de una lógica en cascada para el estilo CSS.

Imagine que trabajamos con diferentes versiones de jQuery en nuestra aplicación web porque agregamos funcionalidades de versiones más nuevas a los módulos que se crearon más tarde. ¿Qué tan complicado sería migrar toda nuestra aplicación a una versión más nueva de jQuery? Ahora, imagine el mismo escenario pero migrando a un marco completamente diferente como Next.js. Eso puede ser complicado.

Migración de Frankenstein

Denys Mishunov escribió un artículo en Smashing Magazine presentando una alternativa a estas dos ideas de migración, tratando de obtener lo mejor de los dos enfoques anteriores: La migración de Frankenstein. Basa el proceso de migración en dos componentes principales: Microservicios y Componentes Web.

El proceso de migración consta de una lista de pasos a seguir:

1. Identificar Microservicios

Según el código de nuestra aplicación, debemos dividirla en partes independientes dedicadas a un trabajo pequeño. Si estamos pensando en usar React o Next.js, podríamos vincular el concepto de microservicios a los diferentes componentes que tenemos.

Pensemos en una aplicación de lista de compras como ejemplo. Tenemos una lista de cosas para comprar y una entrada para agregar más cosas a la lista. Entonces, si queremos dividir nuestra aplicación en partes pequeñas, podríamos pensar en un componente de "lista de elementos" y un "agregar elemento". Al hacer esto, podemos separar la funcionalidad y el marcado relacionado con cada una de esas partes en diferentes componentes de React.

Para corroborar que los componentes son independientes, deberíamos poder eliminar uno de ellos de la aplicación y los otros no deberían verse afectados por eso. Si recibimos un error al eliminar el marcado y la funcionalidad de un servicio, no estamos identificando correctamente los componentes o necesitamos refactorizar la forma en que funciona nuestro código.

2. Permitir el acceso de host a extranjero

"Host" es nuestra aplicación existente. “Alien” es el que comenzaremos a crear, con el nuevo marco. Ambos deberían funcionar de forma independiente, pero deberíamos proporcionar acceso de Host a Alien. Deberíamos poder desplegar cualquiera de las dos aplicaciones sin romper la otra, pero manteniendo la comunicación entre ellas.

3. Escriba un componente alienígena

Vuelva a escribir un servicio de nuestra aplicación Host en nuestra aplicación Alien, utilizando el nuevo marco. El componente debe seguir el mismo principio de independencia que mencionamos antes.

Volvamos al ejemplo de la lista de la compra. Identificamos un componente de "agregar elemento". Con jQuery, el marcado del componente se verá así:

 <input class="new-item" />

Y el código JavaScript/jQuery para agregar los elementos a la lista será algo como esto:

 var ENTER_KEY = 13; $('.new-item').on('keyup', function (e) { var $input = $(e.target); var val = $input.val().trim(); if (e.which !== ENTER_KEY || !val) { return; } // code to add the item to the list $input.val(''); });

En lugar de eso, podemos crear un componente AddItem React:

 import React from 'react' function AddItemInput({ defaultText }) { let [text, setText] = useState(defaultText) let handleSubmit = e => { e.preventDefault() if (e.which === 13) { setText(e.target.value.trim()) } } return <input type="text" value={text} onChange={(e) => setText(e.target.value)} onKeyDown={handleSubmit} /> }

4. Escribir envoltorio de componente web alrededor del servicio alienígena

Cree un componente contenedor que importe nuestro servicio Alien recién creado y lo represente. La idea es crear un puente entre la aplicación Host y la aplicación Alien. Tenga en cuenta que podríamos necesitar un empaquetador de paquetes para generar código JavaScript que funcione en nuestra aplicación actual, ya que necesitaremos copiar nuestros nuevos componentes de React y hacerlos funcionar.

Siguiendo el ejemplo de la lista de compras, podemos crear un archivo AddItem-wrapper.js en el proyecto Host. Este archivo contendrá el código que envuelve nuestro componente AddItem ya creado y crea un elemento personalizado con él:

 import React from "../alien/node_modules/react"; import ReactDOM from "../alien/node_modules/react-dom"; import AddItem from "../alien/src/components/AddItem"; class FrankensteinWrapper extends HTMLElement { connectedCallback() { const appWrapper = document.createElement("div"); appWrapper.classList.add("grocerylistapp"); ... ReactDOM.render( <HeaderApp />, appWrapper ); … } } customElements.define("frankenstein-add-item-wrapper", FrankensteinWrapper);

Deberíamos traer los módulos y componentes de nodo necesarios de las carpetas de la aplicación Alien, ya que necesitamos importarlos para que el componente funcione.

5. Reemplace el servicio de host con un componente web

Este componente contenedor reemplazará al de la aplicación Host y comenzaremos a usarlo. Por lo tanto, la aplicación en producción será una combinación de componentes Host y componentes envueltos en Alien.

En nuestra aplicación Host de ejemplo, debemos reemplazar:

 <input class="new-item" />

Con

 <frankenstein-add-item-wrapper></frankenstein-add-item-wrapper> ... <script type="module" src="js/AddItem-wrapper.js"></script>

6. Enjuague y repita

Siga los pasos 3, 4 y 5 para cada uno de los microservicios identificados.

7. Cambiar a extranjero

El host ahora es una colección de componentes envolventes que incluyen todos los componentes web que creamos en la aplicación Alien. Como convertimos todos los microservicios identificados, podemos decir que la aplicación Alien finalizó y todos los servicios se migraron. Solo tenemos que dirigir a nuestros usuarios a la aplicación Alien ahora.

El método de migración de Frankenstein funciona como una combinación de los enfoques bueno y rápido. Migramos la aplicación completa, pero liberamos los diferentes componentes cuando están listos. Por lo tanto, están disponibles para ser utilizados antes y evaluados por los usuarios en producción.

Sin embargo, debemos considerar que estamos trabajando demasiado con este enfoque. Si queremos usar los componentes que creamos para nuestra aplicación Alien, debemos crear un componente contenedor para incluir en la aplicación Host. Esto hace que dediquemos tiempo a desarrollar el código para estos elementos envolventes. Además, al usarlos en nuestra aplicación Host, duplicamos la inclusión de código y dependencias, y agregamos código que afectará el rendimiento de nuestra aplicación.

Aplicación de estrangulador

Otro enfoque que podemos tomar es el estrangulamiento de aplicaciones heredadas. Identificamos los bordes de nuestra aplicación web existente, y cada vez que necesitamos agregar funcionalidades a nuestra aplicación, lo hacemos utilizando un marco más nuevo hasta que el sistema anterior se "estrangula". Este enfoque nos ayuda a reducir el riesgo potencial que podemos experimentar al migrar una aplicación.

Para seguir este enfoque, necesitamos identificar diferentes componentes, como lo hacemos en la migración de Frankenstein. Una vez que dividimos nuestra aplicación en diferentes piezas de código imperativo relacionado, las envolvemos en nuevos componentes de React. No agregamos ningún comportamiento adicional, solo creamos componentes React que representan nuestro contenido existente.

Veamos un ejemplo para mayor aclaración. Supongamos que tenemos este código HTML en nuestra aplicación:

 <div class="accordion"> <div class="accordion-panel"> <h3 class="accordion-header">Item 1</h3> <div class="accordion-body">Text 1</div> </div> <div class="accordion-panel"> <h3 class="accordion-header">Item 2</h3> <div class="accordion-body">Text 2</div> </div> <div class="accordion-panel"> <h3 class="accordion-header">Item 3</h3> <div class="accordion-body">Text 3</div> </div>> </div>

Y este código JavaScript (ya reemplazamos las funciones de jQuery con nuevas funciones estándar de JavaScript).

 const accordions = document.querySelectorAll(".accordion"); for (const accordion of accordions) { const panels = accordion.querySelectorAll(".accordion-panel"); for (const panel of panels) { const head = panel.querySelector(".accordion-header"); head.addEventListener('click', () => { for (const otherPanel of panels) { if (otherPanel !== panel) { otherPanel.classList.remove('accordion-expanded'); } } panel.classList.toggle('accordion-expanded'); }); } }

Esta es una implementación común de un componente de accordion para JavaScript. Como queremos presentar React aquí, necesitamos envolver nuestro código existente con un nuevo componente React:

 function Accordions() { useEffect(() => { const accordions = document.querySelectorAll(".accordion") for (const accordion of accordions) { const panels = accordion.querySelectorAll(".accordion-panel") for (const panel of panels) { const head = panel.querySelector(".accordion-header") head.addEventListener("click", () => { for (const otherPanel of panels) { if (otherPanel !== panel) { otherPanel.classList.remove("accordion-expanded") } } panel.classList.toggle("accordion-expanded") }); } } }, []) return null } ReactDOM.render(<Accordions />, document.createElement("div"))

El componente no agrega ningún comportamiento o característica nueva. Usamos useEffect porque el componente se ha montado en el documento. Es por eso que la función devuelve nulo porque el gancho no necesita devolver un componente.

Por lo tanto, no agregamos ninguna funcionalidad nueva a nuestra aplicación existente, pero presentamos React sin cambiar su comportamiento. De ahora en adelante, cada vez que agreguemos nuevas funciones o cambios en nuestro código, lo haremos utilizando el marco seleccionado más nuevo.

¿Representación del lado del cliente, representación del lado del servidor o generación estática?

Next.js nos da la posibilidad de elegir cómo queremos renderizar cada página de nuestra aplicación web. Podemos utilizar el renderizado del lado del cliente que ya nos ofrece React para generar el contenido directamente en el navegador del usuario. O bien, podemos representar el contenido de nuestra página en el servidor utilizando la representación del lado del servidor. Finalmente, podemos crear el contenido de nuestra página en tiempo de compilación usando generación estática.

En nuestra aplicación, deberíamos estar cargando y procesando el código en la carga de la página, antes de comenzar a interactuar con cualquier biblioteca o marco de JavaScript. Es posible que estemos utilizando una tecnología o un lenguaje de programación de representación del lado del servidor, como ASP.NET, PHP o Node.js. Podemos aprovechar las funciones de Next.js y reemplazar nuestro método de representación actual con el método de representación del lado del servidor de Next.js. Al hacer esto, mantenemos todo el comportamiento dentro del mismo proyecto, que funciona bajo el paraguas de nuestro marco seleccionado. Además, mantenemos la lógica de nuestra página principal y los componentes de React dentro del mismo código que genera todo el contenido necesario para nuestra página.

Pensemos en una página de tablero como ejemplo. Podemos generar todo el marcado inicial de la página en el momento de la carga, en el servidor, en lugar de tener que generarlo con React en el navegador web del usuario.

 const DashboardPage = ({ user }) => { return ( <div> <h2>{user.name}</h2> // User data </div> ) } export const getServerSideProps = async ({ req, res, params }) => { return { props: { user: getUser(), }, } }, }) export default DashboardPage

Si el marcado que representamos en la carga de la página es predecible y se basa en datos que podemos recuperar en el momento de la compilación, la generación estática sería una buena opción. La generación de activos estáticos en el momento de la compilación hará que nuestra aplicación sea más rápida, segura, escalable y fácil de mantener. Y, en caso de que necesitemos generar contenido dinámico en las páginas de nuestra aplicación, podemos usar la representación del lado del cliente de React para recuperar información de servicios o fuentes de datos.

Imagine que tenemos un sitio de blogs, con muchas publicaciones de blogs. Si usamos generación estática, podemos crear un archivo genérico [blog-slug].js en nuestra aplicación Next.js y, al agregar el siguiente código, generaríamos todas las páginas estáticas para nuestras publicaciones de blog en el momento de la compilación.

 export const getStaticPaths = async () => { const blogPosts = await getBlogPosts() const paths = blogPosts.map(({ slug }) => ({ params: { slug, }, })) return { paths, fallback: false, } } export const getStaticProps = async ({ params }) => { const { slug } = params const blogPost = await getBlogPostBySlug(slug) return { props: { data: JSON.parse(JSON.stringify(blogPost)), }, } }

Crear una API usando rutas de API

Una de las grandes características que ofrece Next.js es la posibilidad de crear rutas API. Con ellos podemos crear nuestras propias funciones serverless usando Node.js. También podemos instalar paquetes NPM para ampliar la funcionalidad. Lo bueno de esto es que nuestra API se irá en el mismo proyecto/aplicación que nuestra interfaz, por lo que no tendremos ningún problema con CORS.

Si mantenemos una API que se llama desde nuestra aplicación web usando la funcionalidad jQuery AJAX, podríamos reemplazarla usando API Routes . Al hacer esto, mantendremos todo el código base de nuestra aplicación en el mismo repositorio y simplificaremos la implementación de nuestra aplicación. Si estamos usando un servicio de terceros, podemos usar API Routes para “enmascarar” las URL externas.

Podríamos tener una ruta API /pages/api/get/[id].js que devuelva los datos que usamos en nuestra página.

 export default async (req, res) => { const { id } = req.query try { const data = getData(id) res.status(200).json(data) } catch (e) { res.status(500).json({ error: e.message }) } }

Y llámalo desde el código de nuestra página.

 const res = await fetch(`/api/get/${id}`, { method: 'GET', }) if (res.status === 200) { // Do something } else { console.error(await res.text()) }

Implementar en Netlify

Netlify es una plataforma completa que se puede utilizar para automatizar, administrar, crear, probar, implementar y alojar aplicaciones web. Tiene muchas características que hacen que el desarrollo de aplicaciones web modernas sea más fácil y rápido. Algunos aspectos destacados de Netlify son:

  • Plataforma global de alojamiento de CDN,
  • Soporte de funciones sin servidor,
  • Implemente vistas previas basadas en Github Pull Requests,
  • webhooks,
  • Reversiones instantáneas,
  • Control de acceso basado en roles.

Netlify es una excelente plataforma para administrar y alojar nuestras aplicaciones Next.js, y es bastante simple implementar una aplicación web con ella.

En primer lugar, debemos hacer un seguimiento del código de nuestra aplicación Next.js en un repositorio de Git. Netlify se conecta a GitHub (o la plataforma Git que prefiramos), y cada vez que se introduce un cambio en una rama (una confirmación o una solicitud de extracción), se activará una tarea automática de "compilación e implementación".

Una vez que tengamos un repositorio Git con el código de nuestra aplicación, debemos crear un "Sitio de Netlify" para él. Para ello, tenemos dos opciones:

  1. Uso de la CLI de Netlify
    Después de instalar la CLI ( npm install -g netlify-cli ) e iniciar sesión en nuestra cuenta de Netlify ( ntl login ), podemos ir al directorio raíz de nuestra aplicación, ejecutar ntl init y seguir los pasos.
  2. Uso de la aplicación web Netlify
    Deberíamos ir a https://app.netlify.com/start. Conéctese a nuestro proveedor de Git, elija el repositorio de nuestra aplicación de la lista, configure algunas opciones de compilación e implemente.

Para ambos métodos, debemos considerar que nuestro comando de compilación será la next build y nuestro directorio para implementar está out .

Finalmente, se instala automáticamente el complemento Essential Next.js, que nos permitirá implementar y usar rutas API, rutas dinámicas y modo de vista previa. Y eso es todo, tenemos nuestra aplicación Next.js funcionando en un servicio de alojamiento de CDN rápido y estable.

Conclusión

En este artículo, evaluamos sitios web que usan la biblioteca jQuery y los comparamos con nuevos marcos frontend como React y Next.js. Definimos cómo podríamos iniciar una migración, en caso de que nos beneficie, a una herramienta más nueva. Evaluamos diferentes estrategias de migración y vimos algunos ejemplos de escenarios que podríamos migrar a proyectos de aplicaciones web Next.js. Finalmente, vimos cómo implementar nuestra aplicación Next.js en Netlify y ponerla en funcionamiento.

Más lecturas y recursos

  • Migración de Frankenstein: enfoque agnóstico del marco
  • Eliminando jQuery de la interfaz de GitHub.com
  • Primeros pasos con Next.js
  • Cómo implementar sitios Next.js en Netlify
  • Artículos de Next.js en Netlify Blog