John Resig y jQuery: la librería que dio forma al front-end

Por qué jQuery importó tanto

Cómo se sentía construir sitios web a mediados de los 2000

Si construías un sitio web entre 2005 y 2008, no solo “escribías JavaScript”. Tenías que negociar con los navegadores.

Una función simple—resaltar un elemento de menú, mostrar un modal, validar un formulario, cargar un fragmento de HTML sin refrescar toda la página—podía convertirse en un pequeño proyecto de investigación. Buscabas qué método existía en qué navegador, qué evento se comportaba diferente y por qué esa llamada al DOM funcionaba en tu máquina pero fallaba para la mitad de tus usuarios.

El problema de “escribe una vez, ejecuta en todas partes”

Los desarrolladores querían “escribe una vez, ejecuta en todas partes”, pero las diferencias entre navegadores hacían que se sintiera como “escribe tres veces, prueba en todas partes”. Internet Explorer tenía sus rarezas, versiones antiguas de Firefox y Safari discrepaban en casos límite, e incluso cosas básicas como el manejo de eventos y la manipulación del DOM podían ser inconsistentes.

Esa descoincidencia no solo consumía tiempo: cambiaba lo que los equipos se atrevían a construir. La UI interactiva era posible, pero cara en esfuerzo y frágil en mantenimiento. Muchos sitios se quedaron más simples de lo necesario porque el coste de hacerlo bien en todos los navegadores era demasiado alto.

La promesa de jQuery: simplificar el trabajo diario de UI

jQuery, creado por John Resig, importó porque se centró en las tareas diarias: seleccionar elementos, reaccionar a acciones del usuario, cambiar la página, animar pequeñas transiciones y hacer peticiones AJAX. Ofrecía una API pequeña y legible que suavizaba las diferencias entre navegadores para que pudieras invertir más tiempo en construir la funcionalidad y menos en pelear con la plataforma.

En la práctica, hizo que las interacciones comunes se sintieran sencillas y repetibles—algo que podías enseñar, compartir y reutilizar.

En qué se centrará este artículo

La historia no es solo que jQuery ahorró tiempo. Influyó en cómo pensaban los desarrolladores: el encadenamiento de operaciones, confiar en selectores concisos, organizar el código de UI en torno a eventos y esperar que las bibliotecas proporcionaran una experiencia de desarrollo consistente. Esos hábitos moldearon las herramientas que vinieron después, incluso después de que los estándares web alcanzaran a la plataforma y surgieran frameworks más nuevos.

Esa mentalidad de “hacer que el camino más común sea fácil” también se ve hoy en las herramientas modernas. Plataformas contemporáneas como Koder.ai aplican el mismo principio de experiencia de desarrollador en otra capa—permitiendo a los equipos crear apps web, backend y móviles vía un flujo de trabajo basado en chat—donde jQuery en su momento hizo que el código orientado al navegador fuera más accesible.

John Resig: la persona detrás del proyecto

John Resig no intentaba iniciar un movimiento cuando empezó a juguetear con una pequeña librería JavaScript a mediados de los 2000. Era un desarrollador en activo que sentía la misma fricción que todos: las cosas simples en la web llevaban demasiadas líneas de código, se rompían en navegadores sorprendentes y eran difíciles de explicar a los compañeros.

Un objetivo práctico: que las tareas comunes sean obvias

La motivación principal de Resig fue la claridad. En lugar de pedir a los desarrolladores memorizar docenas de rarezas de navegadores, quería un conjunto pequeño de comandos que coincidieran con cómo la gente pensaba en construir páginas: “encuentra este elemento”, “cámbialo”, “cuando el usuario haga clic, haz esto”. jQuery no se construyó para presumir de ingenio—se hizo para reducir la frustración diaria y ayudar a que proyectos comunes salieran adelante.

Igualmente importante fue la empatía hacia el desarrollador web típico. La mayoría no estaba haciendo demos experimentales; mantenían sitios de marketing, paneles de administración y páginas de producto con plazos. El enfoque de jQuery en una API compacta y legible reflejaba esa realidad.

Compartir pronto, escuchar con frecuencia

jQuery se difundió porque era fácil de aprender y de compartir. Resig dio charlas y demos que mostraban ganancias inmediatas, y el proyecto rápidamente desarrolló reputación por su buena documentación y ejemplos accesibles. Eso importó: cuando una herramienta te ayuda a solucionar un problema real en minutos, se lo cuentas a otros desarrolladores.

La comunidad temprana reforzó ese ciclo. La gente compartía fragmentos, escribía plugins e informaba casos límite de navegadores y dispositivos que Resig no podía probar solo. jQuery creció en público, con feedback que determinó qué se mantenía simple y qué se pulía.

No es culto a la personalidad, sino buenas decisiones de producto

Es tentador reducir jQuery a un único “momento de genialidad”, pero la historia más honesta es de persistencia y buen juicio: notar un dolor generalizado, diseñar para flujos de trabajo cotidianos y construir confianza mediante la consistencia. Resig no solo escribió código—creó una herramienta que se sentía como un atajo amistoso para cómo funcionaba la web en la práctica.

La web antes de jQuery: puntos de dolor reales

Antes de jQuery, escribir un comportamiento interactivo “simple” a menudo significaba coser un montón de trucos específicos por navegador. Podías construir interfaces ricas, pero el coste eran tiempo, paciencia y muchas pruebas.

Encontrar elementos era más difícil de lo que parece

Hoy, obtener un botón y cambiar su texto parece una línea. Antes, la selección del DOM era inconsistente y torpe. Algunos navegadores soportaban métodos útiles, otros no, y acababas mezclando enfoques como getElementById, getElementsByTagName, bucles manuales y comprobaciones de cadenas solo para apuntar a los elementos correctos.

Incluso cuando seleccionabas lo que necesitabas, a menudo había que escribir código extra para manejar colecciones, convertirlas en arrays o sortear casos límite raros.

Los eventos eran una pesadilla cross-browser

Manejadores de clic, pulsaciones de tecla y efectos hover eran requisitos comunes—pero los navegadores discrepaban en cómo enlazar eventos y cómo era el objeto evento. Código que funcionaba perfectamente en un navegador podía fallar silenciosamente en otro.

Los desarrolladores escribían wrappers para normalizar el manejo de eventos: “si existe esta API úsala; si no, usa la otra”. Eso significaba más código, más depuración y más formas en que los bugs podían colarse.

AJAX parecía territorio de expertos

Las peticiones asíncronas eran posibles, pero poco amigables. Configurar un XMLHttpRequest normalmente implicaba varios pasos, lógica ramificada para distintos navegadores y manejo cuidadoso de estados de respuesta.

Una pequeña funcionalidad—como enviar un formulario sin recargar la página—podía inflarse a docenas de líneas más reintentos, manejo de errores y pruebas en navegadores.

El coste real: fiabilidad y velocidad de equipo

El mayor problema no era escribir el código una vez; era mantenerlo funcionando en todas partes. Los equipos necesitaban algo fiable, fácil de aprender y lo bastante consistente como para que nuevos desarrolladores pudieran contribuir sin memorizar una lista de compatibilidad entre navegadores. jQuery llegó como respuesta a esa fricción diaria.

La gran idea: una API pequeña para tareas comunes de UI

El avance de jQuery no fue una nueva capacidad del navegador, sino una nueva manera de pensar el trabajo diario de UI. En lugar de escribir mucho JavaScript específico del navegador solo para encontrar un elemento, actualizarlo y conectar un evento, jQuery redujo la rutina a un patrón sencillo: selecciona algo, luego haz algo con ello.

“Encuentra, luego actúa”

En el centro está la función $(). Le pasas un selector tipo CSS (o un elemento) y obtienes un objeto jQuery—un wrapper fácil de usar sobre los elementos coincidentes.

A partir de ahí llamas métodos que se leen como tareas: añadir una clase, ocultar un elemento, cambiar texto, adjuntar un manejador de clic. La idea no era exponer cada detalle de bajo nivel; era cubrir el 80% de las tareas de UI que casi todos los sitios necesitaban.

Encadenamiento: menos variables, intención más clara

jQuery fomentó un estilo fluido donde cada paso devuelve el mismo objeto jQuery, de modo que puedes “encadenar” acciones en una línea legible:

$(".notice")
  .addClass("active")
  .text("Saved!")
  .fadeIn();

Aunque no entendieras los entresijos, podías comprender la historia: encontrar avisos, marcarlos como activos, poner el mensaje y mostrarlos.

Por qué una API pequeña y consistente importaba

Antes de jQuery, los desarrolladores preguntaban constantemente: “¿qué método funciona en este navegador?” o “¿esta propiedad se llama diferente en versiones antiguas?” jQuery respondió con un conjunto coherente de métodos y comportamiento predecible. Los principiantes tuvieron una rampa suave hacia JavaScript sin verse aplastados por casos límite. Los profesionales ganaron velocidad: menos funciones auxiliares personalizadas, menos hacks de compatibilidad y menos código que revisar.

Los scripts centrados en tareas se convirtieron en la norma

Porque la API era compacta y los nombres de los métodos se mapeaban a intenciones de UI, jQuery empujó a los equipos hacia scripts más fáciles de leer. En lugar de llamadas DOM dispersas y variables temporales, podías leer el código como una secuencia de acciones de UI—haciendo que el trabajo front-end se sintiera más como ensamblar pasos claros que pelear con el navegador.

Selectores y Sizzle: “encontrarlo” se volvió fácil

Uno de los trucos más persuasivos de jQuery fue hacer trivial el primer paso de cualquier tarea de UI: seleccionar los elementos correctos. En lugar de recordar métodos DOM específicos del navegador y sus rarezas, podías escribir algo que parecía CSS y que tenía sentido inmediato.

Selectores CSS como modelo mental familiar

Diseñadores y desarrolladores front-end ya pensaban en selectores: “coge todos los .button dentro del header”, “apunta al primer ítem”, “encuentra inputs de cierto tipo”. jQuery convirtió ese modelo mental en una herramienta JavaScript:

• $(".nav a") para trabajar con enlaces de navegación
• $("#signup-form input[type=email]") para encontrar un campo específico
• $("ul li:first") para lógica rápida del “primer ítem”

Esa legibilidad importó. Redujo el esfuerzo de traducir entre “lo que quiero” y “cómo el DOM espera que lo pida”.

Qué hizo Sizzle (y por qué importó)

Detrás de $(selector) estaba Sizzle, el motor de selectores de jQuery. Los primeros navegadores no coincidían en cómo ciertos selectores debían comportarse, y algunos no soportaban el conjunto completo. Sizzle proporcionó una interpretación consistente y comportamientos de fallback, así que $(".card > .title") no se convertía en una lotería entre navegadores.

El resultado fue productividad real: menos ramas condicionales, menos “si es IE entonces…” y menos tiempo depurando por qué un selector coincidía en un navegador pero no en otro.

Los compromisos: conveniencia vs. complejidad oculta

El poder de los selectores también ocultó costes:

• Selectores costosos podían afectar el rendimiento, especialmente si se ejecutaban repetidamente (por ejemplo en manejadores de scroll o resize).
• Era fácil sobre-seleccionar y luego “arreglarlo después” con encadenamiento—código de aspecto limpio que hacía más trabajo del que creías.
• Confiar en selectores complejos a veces fomentaba acoplar demasiado el comportamiento JavaScript a una estructura DOM frágil.

Aun así, para el trabajo diario de interfaces, que “encontrarlo” fuera fácil fue un cambio enorme—y una gran razón por la que jQuery se sintió como un superpoder.

Eventos, cambios en el DOM y efectos: la caja de herramientas diaria

Para muchos desarrolladores, jQuery no era “una librería”—era el conjunto de herramientas habituales a las que recurrías para construir interacciones. Convertía el trabajo común de UI en unas pocas llamadas previsibles, incluso cuando los navegadores discrepaban en los detalles.

Eventos sin sorpresas del navegador

Antes de jQuery, enlazar un manejador de clic podía significar lidiar con distintos modelos de eventos y casos raros. .on() de jQuery (y antes .bind()/.click()) dio una forma consistente de escuchar acciones de usuario como click, submit y entrada del teclado.

También hizo obvio “ejecuta esto cuando la página esté lista”:

$(function () {
  // seguro para tocar el DOM
});

Ese hábito único redujo errores de sincronización en páginas típicas—no más preguntarse si los elementos ya existían.

Manipulación del DOM que podías memorizar

La API del DOM de jQuery era intencionalmente pequeña y práctica. ¿Necesitas actualizar contenido? .text() o .html(). ¿Necesitas construir piezas de UI? ('<div>...</div>') y .append(). ¿Necesitas estados visuales? .addClass(), .removeClass() y .toggleClass().

En lugar de manejar diferencias entre className, rarezas de atributos y métodos de nodos inconsistentes, los desarrolladores podían concentrarse en lo que querían cambiar.

Efectos que vendían la interacción (a veces en exceso)

Animaciones integradas como .hide(), .show(), .fadeIn() y .slideToggle() hicieron que las páginas se sintieran vivas con un esfuerzo mínimo. A los diseñadores les encantaban, los stakeholders las notaban y los tutoriales las usaban.

El lado negativo: los efectos eran fáciles de sobreusar—demasiados fades y slides podían hacer que las interfaces se sintieran lentas o cursis. Aun así, para interacciones típicas (menús, acordeones, notificaciones), jQuery bajó la barrera para “hacer que se vea pulido”.

A través de eventos, cambios del DOM y efectos, la verdadera victoria fue la simplicidad: menos casos límite en el trabajo diario y un conjunto compartido de patrones que los equipos podían aprender rápido.

AJAX se volvió accesible

Antes de jQuery, “AJAX” sonaba a truco: actualizar parte de una página sin recargarla. En términos simples, es el navegador enviando una petición en segundo plano, recibiendo datos (HTML o JSON) y actualizando la página para que el usuario continúe.

De XMLHttpRequest a una línea

La característica subyacente era XMLHttpRequest, pero usarla directamente implicaba mucho código repetitivo: crear la petición, vigilar su estado, parsear respuestas, tratar rarezas de navegadores y recordar casos límite.

jQuery envolvió esa complejidad en métodos auxiliares que parecían herramientas cotidianas:

• $.ajax() para control total
• $.get() / $.post() para peticiones simples
• .load() para obtener HTML e inyectarlo en un elemento

En lugar de cablear manejadores, construir cadenas de consulta y parsear la respuesta tú mismo, podías concentrarte en qué debía ver el usuario a continuación.

Usos cotidianos que se sentían “modernos”

Estos patrones se normalizaron rápidamente:

• Sugerencias de búsqueda mientras escribes (traer una lista pequeña y renderizarla bajo el input)
• Envíos de formularios sin navegar (enviar campos, mostrar éxito o errores en línea)
• Dashboards que refrescan partes de la UI (polling, reemplazar una tabla, actualizar contadores)

Incluso con servidores clásicos, jQuery permitía que la interfaz se sintiera ágil.

Dónde tropezaban las personas

jQuery hacía fáciles las peticiones para empezar—pero no siempre fáciles de finalizar correctamente. Errores comunes incluían:

• Manejo de errores débil: asumir éxito e ignorar timeouts, errores del servidor o JSON mal formado
• Condiciones de carrera: varias peticiones devolviendo en distinto orden y sobreescribiendo la UI
• Fallos silenciosos: sin retroalimentación al usuario cuando la red falla

La API bajó la barrera, pero también dejó la lección que aún vale: el “camino feliz” es solo la mitad de construir una interfaz fiable.

Plugins: el ecosistema que multiplicó el poder de jQuery

jQuery no era solo una librería que descargabas—era una plataforma sobre la que la gente construía. Los “plugins” eran añadidos pequeños que extendían jQuery con nuevos métodos, normalmente atados a $.fn. Para los desarrolladores, eso significaba que podías soltar una funcionalidad y llamarla con el mismo estilo que ya usabas para todo lo demás.

Por qué los plugins se difundieron tan rápido

La barrera de entrada era baja. Si conocías jQuery, ya entendías el patrón de plugin: selecciona elementos, llama a un método, pasa opciones.

Igualmente importante, las convenciones de jQuery hicieron que los plugins se sintieran sorprendentemente coherentes, incluso cuando los escribían autores diferentes:

• Nombres: $('.menu').dropdown() leías como jQuery nativo.
• Encadenamiento: los buenos plugins devolvían la selección original, para que pudieras seguir encadenando: $('.btn').addClass('x').plugin().fadeIn().
• Objetos de opciones: la configuración solía verse como { speed: 200, theme: 'dark' }, fácil de copiar y ajustar.

Para qué se usaban

Los plugins cubrían la “media distancia” entre el trabajo DOM crudo y frameworks completos. Categorías comunes: sliders y carruseles, validación de formularios, modales y lightboxes, selectores de fecha, autocompletar, tooltips y helpers de tablas.

Para muchos equipos, especialmente los que trabajaban en sitios de marketing o dashboards internos, los plugins convirtieron semanas de trabajo en UI en un día de ensamblaje.

Los contras

El boom de plugins tuvo un coste. La calidad variaba mucho, la documentación podía ser escasa y combinar varios plugins a veces llevaba a conflictos de CSS o manejadores de eventos. La proliferación de dependencias también se volvió real: una característica podía depender de dos plugins más, cada uno con su propio historial de actualizaciones. Cuando los autores dejaban de mantenerlos, los plugins desactualizados podían bloquear un proyecto a versiones antiguas de jQuery—o convertirse en riesgo de seguridad y estabilidad.

jQuery UI y jQuery Mobile: componentes para las masas

El núcleo de jQuery hizo predecible el trabajo con el DOM, pero los equipos aún tenían que construir piezas de interfaz desde cero. jQuery UI llenó ese hueco con un conjunto de componentes listos—selectores de fecha, diálogos, pestañas, sliders, acordeones, comportamiento draggable/sortable—empaquetados para funcionar en múltiples navegadores con poca complicación. Para equipos pequeños y agencias que lanzaban muchos sitios de marketing o herramientas internas, ese valor de “suficientemente bueno, ahora” era difícil de superar.

Por qué jQuery UI era un atajo de productividad

La gran ventaja no eran solo los widgets—era la combinación de widgets más una API consistente y theming. Podías prototipar rápido insertando un diálogo o autocompletar, y luego ajustarlo a la marca con ThemeRoller en lugar de reescribir marcado y patrones CSS en cada proyecto. Esa repetibilidad hizo que jQuery UI se sintiera más como un kit práctico que como un sistema de diseño.

La apuesta de jQuery Mobile en un móvil temprano y desordenado

jQuery Mobile intentó resolver otro problema: los primeros smartphones tenían capacidades y soporte CSS inconsistentes, y las convenciones de diseño responsive aún no estaban asentadas. Ofrecía componentes táctiles y un modelo de navegación “single-page” con transiciones AJAX entre páginas, buscando que una misma base de código se comportara como una app casi nativa.

Por qué parte de esto envejeció mal

A medida que los estándares mejoraron—CSS3, navegadores móviles más capaces y controles nativos mejorados—algunas de estas abstracciones se volvieron más coste que beneficio. Los widgets de jQuery UI podían ser pesados, difíciles de hacer accesibles y complicados de alinear con expectativas de diseño más modernas. El reescrito del DOM y el modelo de navegación de jQuery Mobile también chocaron con enfoques posteriores como layouts responsive primero y el routing impulsado por frameworks.

A pesar de eso, ambos proyectos probaron una idea clave: componentes compartidos y reutilizables pueden acelerar enormemente el envío de producto real.

Cómo cambió jQuery los hábitos de codificar front-end

jQuery no solo hizo que los navegadores se comportaran; cambió cómo lucía el código front-end “normal”. Los equipos comenzaron a escribir JavaScript a diario, no solo en páginas especiales, porque las tareas comunes de UI de repente se volvieron predecibles.

APIs fluidas y el hábito del encadenamiento

Uno de los mayores cambios culturales de jQuery fue popularizar el encadenamiento: selecciona algo y sigue operando sobre ello en un flujo legible.

$(".card")
  .addClass("active")
  .find(".title")
  .text("Updated")
  .end()
  .fadeIn(200);

Ese estilo influyó en librerías posteriores e incluso en APIs nativas modernas. También empujó a los desarrolladores a operaciones pequeñas y componibles en lugar de funciones monolíticas gigantes.

“Más con menos código” (y sus desventajas)

Los helpers de jQuery—$.each, $.map, $.extend, atajos de AJAX—hacían tentador comprimir la lógica en menos líneas. Eso mejoró la velocidad, pero también animó one-liners “ingeniosos” y comportamientos implícitos difíciles de revisar meses después.

Muchos codebases acabaron con lógica de negocio mezclada directamente en manejadores de clic, porque era tan fácil “hacerlo aquí mismo”. Esa conveniencia aceleró el envío, pero a menudo incrementó la complejidad a largo plazo.

Pruebas y depuración en la era del DOM directo

Antes de que los componentes y modelos de estado predecibles se volvieran comunes, las aplicaciones jQuery con frecuencia almacenaban estado en el DOM: clases, inputs ocultos y atributos data. Depurar significaba inspeccionar HTML en vivo y seguir callbacks de eventos que podían dispararse en órdenes sorprendentes.

Las pruebas unitarias eran posibles, pero los equipos solían confiar más en QA manual y en las devtools del navegador. Los problemas eran frecuentemente relativos al tiempo (animaciones, AJAX, bubbling de eventos), lo que hacía que los bugs parecieran intermitentes.

Cuando jQuery se mantenía limpio vs. se enmarañaba

El código jQuery tendía a permanecer mantenible cuando los equipos:

• mantenían las consultas DOM cerca de los elementos que afectaban
• usaban funciones pequeñas y delegación de eventos
• trataban los plugins como bloques reutilizables

Se enredaba cuando las páginas acumulaban capas de manejadores, repetían selectores por todas partes y añadían “solo un ajuste más” dentro de un callback de animación. La librería hacía la iteración rápida fácil; la disciplina determinaba si el resultado envejecía bien.

Por qué jQuery fue perdiendo protagonismo: los estándares maduraron

jQuery no desapareció de la noche a la mañana, ni “perdió” porque empeorara. Fue perdiendo protagonismo porque la plataforma del navegador dejó de necesitar un traductor. Los problemas que jQuery solucionaba—APIs faltantes, comportamientos inconsistentes y flujos torpes—se volvieron menos comunes a medida que los estándares maduraron y los navegadores convergieron.

El navegador empezó a copiar las mejores partes

A medida que el DOM y las APIs de JavaScript se estandarizaron, muchas llamadas cotidianas de jQuery ganaron equivalentes directos:

• Selección de elementos: document.querySelector() y document.querySelectorAll() cubrieron la mayoría de los casos que antes requerían $(...).
• Eventos: addEventListener() se volvió universalmente fiable, eliminando buena parte del trabajo de compatibilidad.
• Peticiones de red: fetch() (y luego async/await) hicieron que las llamadas tipo AJAX se sintieran nativas y legibles.

Cuando la forma “nativa” es consistente entre navegadores, la razón para depender de un helper disminuye.

El rendimiento y el tamaño del bundle importaron más

A medida que las apps web pasaron de unos pocos widgets interactivos a productos completos, los equipos empezaron a vigilar el tiempo de carga y el coste del JavaScript. Incluir jQuery (más plugins) por un puñado de comodidades era cada vez más difícil de justificar—especialmente en redes móviles.

No es que jQuery fuera lento; es que “una dependencia más” se volvió un trade-off real. Los desarrolladores prefirieron utilidades más pequeñas y enfocadas—o no usar librería alguna cuando la plataforma ya hacía el trabajo.

Las SPAs cambiaron lo que significaba el trabajo front-end

Los frameworks de aplicaciones de una sola página desplazaron la atención desde manipular el DOM manualmente hacia gestionar estado y componer UI desde componentes. En pensamiento estilo React/Vue/Angular, normalmente no preguntas “encuentra este elemento y cámbialo”. Actualizas datos y la UI se re-renderiza.

En ese modelo, las fortalezas de jQuery—manipulación imperativa del DOM, efectos y wiring puntual de eventos—son menos centrales y a veces incluso desaconsejadas.

Un punto justo: jQuery tuvo éxito hasta volverse prescindible

La misión de jQuery fue hacer la web usable y consistente. Cuando los navegadores alcanzaron ese objetivo, jQuery se volvió menos necesario—no menos importante. Muchas webs de producción siguen usándolo, y muchas APIs modernas (y expectativas de desarrollador) reflejan lecciones que jQuery enseñó al ecosistema.

El legado: lo que jQuery dejó atrás

jQuery ya no es la opción predeterminada para nuevo trabajo front-end, pero todavía alimenta silenciosamente una parte sorprendente de la web—y su influencia está integrada en cómo muchos desarrolladores piensan sobre JavaScript.

Dónde todavía aparece jQuery

Lo encontrarás sobre todo en lugares que priorizan estabilidad sobre reescrituras:

• Aplicaciones empresariales legadas construidas en la era de jQuery que siguen funcionando bien
• Temas y plugins de CMS (especialmente en instalaciones antiguas de WordPress)
• Scripts de “arreglos rápidos” en páginas de marketing: un slider por aquí, un modal por allá

Si mantienes uno de estos proyectos, la ganancia es previsibilidad: el código es entendible, bien documentado y, por lo general, fácil de parchear.

Ideas que sobrevivieron a la librería

Las herramientas modernas no copiaron jQuery línea por línea, pero absorbieron sus mejores instintos:

• APIs ergonómicas: hacer tareas comunes con unas pocas llamadas legibles
• Selectores como concepto central: “encuentra elementos, luego actúa sobre ellos” se volvió estándar
• Extensibilidad: la mentalidad de plugin vive hoy en ecosistemas de paquetes y patrones de componentes

Incluso la evolución de JavaScript puro (como querySelectorAll, classList, fetch y mejor manejo de eventos) refleja los problemas que jQuery resolvió para desarrolladores cotidianos.

Qué aprender de jQuery hoy

La lección más grande es de pensamiento de producto: una API pequeña y consistente junto con buena documentación puede cambiar cómo una industria entera escribe código.

También recuerda que la experiencia de desarrollador se acumula. En la era de jQuery, la DX consistía en ocultar las rarezas del navegador tras una API limpia; hoy puede significar también comprimir el camino desde la idea hasta el software en ejecución. Por eso plataformas de vibe-coding como Koder.ai conectan con muchos equipos: en lugar de montar boilerplate a mano, puedes iterar desde un chat, generar un front-end React con un backend en Go + PostgreSQL (o una app móvil Flutter) y seguir avanzando—con la opción de exportar el código fuente cuando necesites control total.

Elegir la herramienta correcta ahora

• Para trabajo nuevo, prefiere APIs modernas del DOM y patrones nativos del framework.
• Para código jQuery existente, no reescribas por principio—refactoriza cuando reduzca riesgo o coste.
• Para pequeños comportamientos puntuales, JavaScript puro suele ser suficiente; jQuery sigue siendo un atajo pragmático si ya está cargado.