jQuery de John Resig simplificó JavaScript, mitigó las inconsistencias entre navegadores y popularizó patrones que influyeron en las herramientas front-end durante años. Así fue su impacto en la web.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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”.
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.
El poder de los selectores también ocultó costes:
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.
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.
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.
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.
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.
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.
XMLHttpRequest a una líneaLa 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 elementoEn 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.
Estos patrones se normalizaron rápidamente:
Incluso con servidores clásicos, jQuery permitía que la interfaz se sintiera ágil.
jQuery hacía fáciles las peticiones para empezar—pero no siempre fáciles de finalizar correctamente. Errores comunes incluían:
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.
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.
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:
$('.menu').dropdown() leías como jQuery nativo.$('.btn').addClass('x').plugin().fadeIn().{ speed: 200, theme: 'dark' }, fácil de copiar y ajustar.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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
El código jQuery tendía a permanecer mantenible cuando los equipos:
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.
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.
A medida que el DOM y las APIs de JavaScript se estandarizaron, muchas llamadas cotidianas de jQuery ganaron equivalentes directos:
document.querySelector() y document.querySelectorAll() cubrieron la mayoría de los casos que antes requerían $(...).addEventListener() se volvió universalmente fiable, eliminando buena parte del trabajo de compatibilidad.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.
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.
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.
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.
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.
Lo encontrarás sobre todo en lugares que priorizan estabilidad sobre reescrituras:
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.
Las herramientas modernas no copiaron jQuery línea por línea, pero absorbieron sus mejores instintos:
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.
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.
jQuery importaba porque convirtió la programación del DOM, llena de inconsistencias dependientes del navegador, en un conjunto de herramientas pequeño y predecible. Hizo que tareas cotidianas —seleccionar elementos, enlazar eventos, modificar el DOM y realizar AJAX— fueran repetibles entre navegadores, lo que aumentó la velocidad y la confianza de los equipos.
Antes de jQuery, los desarrolladores se enfrentaban rutinariamente a diferencias entre navegadores en:
XMLHttpRequest y sus casos límite)El coste real no era tanto escribir código una vez, sino mantenerlo fiable en todas las plataformas.
$() es la función central: se le pasa un selector de estilo CSS (o un elemento) y devuelve un objeto jQuery que envuelve los elementos coincidentes. Ese objeto expone un conjunto coherente de métodos para que puedas “encontrar y luego actuar” sin preocuparte por las rarezas del navegador.
El encadenamiento es relevante porque la mayoría de los métodos de jQuery devuelven el mismo objeto jQuery tras ejecutar una acción. Eso permite expresar una secuencia de operaciones de interfaz en un flujo legible (seleccionar → modificar → animar) con menos variables temporales.
Sizzle es el motor de selectores detrás de $(selector). Proporcionó un comportamiento consistente y soporte para selectores más amplios en una época en la que los navegadores discrepaban sobre qué selectores soportar y cómo interpretarlos.
jQuery normalizó tareas comunes de eventos para que no tuvieras que escribir comprobaciones específicas por navegador. También popularizó patrones como ejecutar código cuando el DOM está listo:
$(function () {
// seguro para manipular el DOM
});
Eso redujo errores relacionados con el tiempo en páginas habituales.
Los ayudantes de AJAX de jQuery envolvían las partes repetitivas de XMLHttpRequest y convirtieron casos comunes en operaciones de una sola línea:
$.ajax() para control completo$.get() / $.post() para peticiones sencillas.load() para cargar HTML dentro de un elementoLos plugins extendían jQuery añadiendo métodos (normalmente en $.fn), de modo que las funcionalidades se usaban con el mismo estilo que el resto de jQuery. Esto permitió “enchufar” capacidades comunes (modales, validación, sliders) usando patrones familiares: selectores + objetos de opciones + encadenamiento.
jQuery dejó de ser tan dominante porque los navegadores estandarizaron muchas de las cosas que antes solucionaba:
querySelector(All) cubrió la mayoría de los casos de selecciónaddEventListener() se volvió fiable en todos los navegadoresfetch() y async/await hicieron el código de red más nativo y legibleAdemás, el peso de los bundles y la preocupación por rendimiento en móviles hicieron que incluir jQuery por unas pocas ventajas fuera más difícil de justificar.
No reescribas solo por eliminarlo. Un enfoque práctico es:
jQuery suele ser defendible en aplicaciones legadas, temas/plugins antiguos de CMS y pequeñas mejoras puntuales donde ya está presente.
Bajó la barrera para interfaces con mejor respuesta, pero seguía siendo necesario un buen manejo de errores y retroalimentación al usuario.