Modernización · jQuery

Migrar una app con mucho jQuery a un framework de componentes

Una aplicación jQuery está hecha de páginas, plugins y scripts que comparten el DOM, sin componentes que convertir. Esta guía explica cómo llevarla a Angular en pasos pequeños mientras sigue funcionando.

Por Carlos Cifuentes · Arquitecto frontend · Actualizado 2026-10-02

Por qué las apps jQuery son un problema distinto

jQuery es una librería para trabajar con el DOM. Todavía se mantiene. La dificultad viene de la forma que toman las aplicaciones construidas sobre ella durante muchos años:

El estado vive en el DOM. El valor actual de algo es lo que diga un campo oculto o una clase CSS.
Los scripts se organizan por página. Cada página renderizada en el servidor incluye sus propios archivos, y se ejecutan en el orden de las etiquetas script.
Los handlers son globales. El código se engancha a document o a selectores amplios, y un script puede afectar otra zona de la página sin que nadie lo note.
Los plugins hacen el trabajo pesado. Grillas, selectores de fecha, modales y validación vienen cada uno de un plugin con sus propias convenciones.
El servidor devuelve HTML. Las llamadas AJAX muchas veces traen fragmentos ya renderizados y los insertan en la página.

No hay un árbol de componentes que traducir. La migración tiene que crear esa estructura.

Define primero el estado final

No toda aplicación jQuery debe convertirse en una single-page application.

Estado final	Descripción	Cuándo encaja
Páginas de servidor con islas de componentes	El servidor sigue renderizando páginas. Las zonas interactivas son componentes Angular	Sitios con mucho contenido y pocas pantallas complejas
SPA para el área de aplicación	La parte compleja e interactiva pasa a ser una app Angular. Las páginas simples se quedan en el servidor	Herramientas de back-office rodeadas de un sitio público
SPA completa	El servidor expone solo un API	Productos muy interactivos

Elegir el estado final más pequeño que resuelva tu problema ahorra mucho trabajo.

Paso 1: Inventario de páginas y plugins

Lista cada página con sus scripts, sus plugins y sus llamadas AJAX. Ordena las páginas por uso y por frecuencia de cambio. Una página que se usa a diario y cambia seguido es la que más gana con componentes. Una página que nadie edita hace años puede esperar o quedarse como está.

Para cada plugin, registra si todavía se mantiene y dónde se usa. El índice de migración de librerías ayuda con los reemplazos comunes.

Paso 2: Convertir endpoints de HTML en endpoints de datos

Los componentes necesitan datos. Para cada área que piensas migrar, agrega endpoints JSON junto a los existentes que devuelven HTML. Conserva los endpoints antiguos hasta que desaparezcan las páginas antiguas. Este trabajo de backend suele ser una partida oculta grande en una migración de jQuery, así que dimensiónalo durante el diagnóstico.

Paso 3: Montar un build y una capa compartida

Un build moderno que produzca bundles que las páginas existentes puedan incluir.
Una hoja de estilos o design tokens compartidos, para que los componentes nuevos se vean igual que las páginas antiguas.
Un solo servicio para la sesión. Con autenticación por cookies en el mismo sitio esto suele funcionar sin cambios, pero maneja la expiración en un solo lugar.

Paso 4: Empezar con islas

Los componentes de Angular se pueden empaquetar como custom elements. La página renderizada en el servidor incluye el bundle y usa una etiqueta como <order-summary> donde estaba el markup antiguo. El resto de la página queda intacto.

Cada isla reemplaza una zona y su código jQuery. Publícala detrás de un interruptor, como se describe en feature flags en una migración incremental.

Paso 5: Pasar de islas a páginas

Cuando la mayor parte de una página está hecha de componentes, reemplaza la página completa por una ruta de Angular. El servidor o el proxy envía esa URL a la aplicación Angular. Este es el punto de corte en el borde del patrón strangler fig. Repite página por página en el área que debe convertirse en SPA.

Paso 6: Quitar jQuery donde ya no hace falta

Cuando a una página no le queda código jQuery, elimina sus inclusiones de scripts. Al final, quita los plugins y, si nada más depende de ella, la librería.

Errores comunes

Handlers globales que tocan los componentes nuevos. Un script antiguo que se engancha a todos los input de la página también se va a enganchar a los inputs dentro de una isla. Acota los selectores antiguos o usa Shadow DOM en la isla.
CSS global. Las hojas de estilo antiguas con reglas amplias se filtran a los componentes nuevos. Encapsula los estilos nuevos y revisa los resets.
Envolver plugins para siempre. Un plugin de jQuery envuelto en un componente es una medida temporal. Ponle a cada wrapper una fecha de reemplazo.
Dos fuentes de verdad. Mientras los scripts antiguos y los componentes nuevos compartan una página, acuerda cuál es dueño de cada dato. Comunícalos con eventos o atributos. Evita que cada uno lea el DOM del otro.

Cuando el servidor es parte del problema

El código jQuery suele estar atado a los templates de servidor que producen su markup. Si las páginas vienen de ASP.NET MVC o de JSP, los pasos para desenredarlas se parecen a los de las guías de AngularJS con ASP.NET MVC y AngularJS con Java y JSP.

Más en esta sección

¿Planeas una migración o una plataforma de microfrontends?

En una llamada de 20 minutos me cuentas tu situación y te digo cómo la abordaría. Si todavía no vale la pena, también te lo digo.

Escríbeme por LinkedIn