jQuery v4.0 beta

• Se elimina el soporte para IE 10 y versiones anteriores, y también se deja de dar soporte a Edge Legacy, iOS <11, Firefox <65 y Android Browser
• Se eliminan APIs que habían estado marcadas como obsoletas (deprecation) durante varias versiones: jQuery.cssNumber, jQuery.cssProps, jQuery.isArray, jQuery.parseJSON, jQuery.nodeName, jQuery.isFunction, jQuery.isWindow, jQuery.camelCase, jQuery.type, jQuery.now, jQuery.isNumeric, jQuery.trim, jQuery.fx.interval
• Se eliminan push, sort, splice, métodos internos de Array del prototipo de jQuery, lo que podría afectar a plugins que dependían de esos métodos
• Se elimina el override previo de jQuery en el orden de eventos relacionados con focusout, blur, focusin y focus, y los navegadores, excepto IE, ahora siguen el orden actual del W3C: blur → focusout → focus → focusin
• jQuery.ajax ahora soporta datos binarios y FormData, y cambia el comportamiento anterior que trataba tipos de datos desconocidos como cadenas para convertirlos automáticamente
• Se elimina el comportamiento de jQuery.ajax que promovía automáticamente a solicitudes JSONP cuando se proporcionaban dataType: "json" y un callback al mismo tiempo
• El código fuente de jQuery migró de AMD a ES modules, y la herramienta de empaquetado cambió de RequireJS a Rollup
• Se agrega soporte para Trusted Types, por lo que HTML envuelto en TrustedHTML puede usarse como entrada en métodos de manipulación de jQuery sin violar la directiva CSP require-trusted-types-for
• La mayoría de las solicitudes asíncronas de scripts ahora usan la etiqueta <script>, para evitar errores de CSP causados por el uso de scripts inline
• En la compilación slim se eliminan Deferreds y Callbacks, quedando por debajo de 20k bytes con gzip, y es aproximadamente 8k bytes gzipped más pequeña que la compilación normal
• Si necesitas soporte para IE11, se recomienda usar la compilación main en lugar de la slim, o agregar un polyfill de native Promises
• Antes del lanzamiento oficial se publicará una guía integral de actualización, y el plugin jQuery Migrate estará disponible para ayudar con la migración
• La beta está disponible en el CDN de jQuery y en npm; los CDN de terceros no alojarán la beta y más adelante alojarán la versión final 4.0.0

[GN⁺]

Opiniones de Hacker News

• Si quieres entender qué sigue impulsando a jQuery incluso después de 2024, hay que recordar que WordPress sigue siendo más de 1/3 de la web y que la mayoría de las instalaciones y una enorme cantidad de plugins dependen fuertemente de jQuery
  Está bien que siga avanzando la eliminación de APIs y funciones en desuso, y es muy probable que jQuery siga siendo dominante en la web por varios años más

  • Además, jQuery es excelente
    Durante unos 15 años, la industria estuvo obsesionada con frameworks de JavaScript demasiado complejos y llamativos, pero para el 99% de las páginas web, todo el JavaScript que se necesita es enlazar dinámicamente formularios generados de forma dinámica, manejar estados de error y hacer unas cuantas llamadas Ajax; lo demás muchas veces es excesivo
    Parece que la industria terminará alejándose de la complejidad de React y se moverá hacia la simplicidad de htmx, Phoenix LiveView, Ruby on Rails Turbo, y simplemente jQuery
  • Digan lo que digan, jQuery sigue siendo poderoso, importante e influyente
    Si eliminaras jQuery de todo el software, una parte considerable de los sitios web en internet dejaría de funcionar
  • No es solo un problema de WordPress
    En una empresa donde trabajé antes, operaban un producto SaaS empresarial con decenas de miles de líneas de código en jQuery
    No van a reescribirlo con un framework moderno de JS a menos que se vuelva absolutamente necesario. En su mayoría es código escrito hace más de 10 años para ajustarse a requisitos específicos de ciertos clientes, y tampoco funciona el argumento de que usar un framework moderno ayuda a contratar gente. La empresa solo paga entre 75 mil y 90 mil dólares a los ingenieros frontend, la rotación es baja y la mayoría de los ingenieros actuales llevan más de 5 años allí
    Sobre todo, el stack actual funciona bien y los clientes antiguos están satisfechos. Gran parte de la ingeniería de software ocurre en este tipo de negocios aburridos en ciudades con un costo de vida mucho menor que en hubs big tech como Bay Area o Seattle
  • Los desarrolladores de WordPress son como los plomeros de la industria tecnológica
    No es glamoroso, pero hay tanta demanda que se puede ganar muy bien
    Si algún día me retiro del mundo de startups big tech obsesionadas con seguir la moda del momento, me gustaría ganarme la vida honestamente haciendo sitios de WordPress y terminar mi jornada todos los días a las 3 de la tarde
  • Hace poco pensé en publicar esto en HN, pero al final no lo hice: todavía no he encontrado un gran modelo de manejo/propagación de cadenas de eventos que permita disparar eventos donde los miembros del DOM y las instancias de clases abstractas puedan usarse de forma intercambiable
    He hecho despachadores de eventos manuales por todos lados, pero jQuery resuelve muy bien esta parte. Hoy en día casi solo uso jQuery para manejar eventos, pero es tan útil que lo incluyo en casi todos los proyectos del lado del cliente
    Lo que quería preguntar era si alguien conoce una librería ligera que permita manejar con la misma API incluso la escucha asíncrona entre $(window).trigger('click') y $(myClassInstance).trigger('myCustomEvent',{data})
    Gracias al auge de fetch() y los selectores CSS, parece que ya podría prescindirse del resto de jQuery, pero no sé si tenga sentido reinventar la rueda. Antes de decir que hacer que una instancia de clase despache eventos es un code smell, hay que considerar que es indispensable si quieres crear un framework reactivo desde cero
    Por ejemplo, mi clase base de componentes escucha un evento custom de resize que ocurre en la pantalla que la contiene, y esa pantalla solo envía el evento a los componentes que necesitan reorganizar internamente su contenido sin hacer scroll. La clase de pantalla escucha window.resize, pero solo despacha cuando el layout se complica. No tiene sentido conectar un listener individual de resize del DOM en window para cada componente

• Me sorprende que en HN siga habiendo gente que ve a jQuery como una simple librería para seleccionar el DOM
  En realidad es un conjunto de herramientas ampliamente soportado y muy estable que, además de selección del DOM, ofrece manipulación de atributos, solicitudes Ajax, manejo de eventos, animaciones y funciones utilitarias de propósito general
  Y además, aunque existan funciones nativas que sustituyan a jQuery, sus APIs no son tan elegantes
  Si solo necesitas añadir un poco de funcionalidad encima de HTML generado en el servidor y no hace falta llegar a un framework completo de UI en JS, jQuery es una dependencia estable, confiable y compatible entre navegadores a cambio de un costo pequeño

  • Hace unos años dejé jQuery y me pasé a JavaScript puro, y no he vuelto a mirar atrás ni una vez
    JS nativo tiene todo lo que ofrece jQuery, salvo ese montón de plugins mal mantenidos y a medio hacer. Esos plugins normalmente solo hacen justo lo que buscan hacer y no mucho más
    Los selectores puros sí son más verbosos, pero en cualquier editor de código decente la velocidad de escritura termina siendo la misma. No lo digo por discutir, pero realmente no entiendo por qué tanta gente sigue usando jQuery
    https://youmightnotneedjquery.com/
  • Viendo el tipo de gente que escribe en HN, tampoco es tan sorprendente
    En cuanto necesitan algo más que un poco de selección del DOM, muchos agarran de inmediato el gran framework de JS que esté de moda en ese momento, porque eso es lo que siempre han hecho
  • Dicen “gente que ve a jQuery como una simple librería de selección del DOM”, y enseguida se ponen a enumerar selección y funciones nativas
  • Es mucho más fácil meter jQuery en un proyecto
    No hacen falta herramientas de build ni todos los dolores de cabeza que vienen con ellas. Con React también se puede hacer así, pero lo que ofrece no está en la misma categoría de comparación

• En un mundo donde mucha gente intenta eliminar activamente los últimos rastros de jQuery, de verdad me pregunto quién sigue desarrollando activamente con jQuery hoy en día
  La mayoría de las cosas que antes se hacían con jQuery ahora ya vienen en el navegador, y querySelectorAll me parece el ejemplo más claro

  • Ya estoy mayor y las nuevas tecnologías me interesan menos, así que las promises de JS nativo, await y async me parecen mucho menos simples que $.ajax()
    Para intentar acostumbrarme usé JS puro en algunos proyectitos personales, pero para mí hacerlo con `$.ajax()`` es algo que me sale de memoria muscular
    Además, probablemente solo unas 20 personas usen realmente el código de manipulación del DOM que escribo. Yo no soy de UI sino de backend, y si hago frontend es solo porque no hay nadie más que lo haga
  • Según la encuesta de Stack Overflow del año pasado, jQuery fue la tercera más popular
    https://survey.stackoverflow.co/2023/#section-most-popular-t...
  • Justo hace poco trabajé en una empresa eliminando los últimos rastros de React para cambiarlo por HTMX
    Personalmente, creo que HTMX es en cierto sentido el heredero espiritual de jQuery
  • Yo también estoy intentando activamente quitar jQuery, pero parece que la gente ya se acostumbró a la herramienta y volver a escribirlo cuesta, así que no hay suficiente voluntad ni justificación de negocio para retirarlo
    Empezar proyectos nuevos con jQuery sí me parece cuestionable, pero sin duda hay desarrolladores que se sienten mucho más cómodos resolviendo las cosas al estilo jQuery que con JavaScript puro
  • Lo usan desarrolladores solistas o equipos pequeños que no soportan las toolchains modernas
    Un buen ejemplo es levelsio: https://twitter.com/levelsio/status/1750175827197567165
    Yo también soy de ese lado y sigo usando jQuery
    Mi SaaS actual es https://www.snipcss.com, una extensión que no tiene mucho código de UI, y mi próximo SaaS será una extensión de automatización web basada en ChatGPT con bastante UI. Ambos usan jQuery
    La razón principal por la que no me paso a JS puro con querySelectorAll es que me gusta cómo se enlazan eventos, sobre todo porque puedes ponerlos en el padre y apuntar a elementos hijos agregados dinámicamente; además, el encadenamiento de funciones está muy bien y el código queda más corto que en JS puro

• Excelente. Pero como esperé demasiado por la 4.0, al final terminé haciendo mi propio jQuery con algunas diferencias clave
  Para animaciones, tweens y timelines uso CSS puro en vez del sistema personalizado de jQuery, manejo de forma transparente elementos únicos y listas, y opté por un enfoque inline

  • Siempre pensé que hacía falta una alternativa moderna y ligera a jQuery. Está muy bien hecha y también me gusta la sintaxis
    Yo estaba implementando algo parecido, incluyendo eventos inline y más que solo métodos estándar de arrays [0]
    Me gustaría ver algún texto o screencast que explique cómo se implementa la locality of behavior en surreal y en el proyecto acompañante css-scope-inline
    Quiero entenderlo para poder mantenerlo a largo plazo e incluso meterlo en mis proyectos
    También me gustaría hablar de filosofía web. Creo que en varias cosas pensaríamos parecido
    [0] https://hyperspace.so/All.js.png

• Se siente como volver a mis años de junior, por allá de 2008. Recuerdo haber discutido intensamente con el tech lead para agregar jQuery al proyecto
  Su argumento era que el tamaño minimizado de la librería, 40 KB, era una carga demasiado grande para el tiempo de carga de la página
  Luego pasamos una semana entera escribiendo las llamadas Ajax a mano y probando compatibilidad entre navegadores, pero al final no logramos hacer que funcionara en Internet Explorer 5
  En esa época jQuery de verdad resolvía muchísimos dolores de cabeza, y al final él terminó agregando la librería al proyecto

  • La gente suele olvidarlo, pero los navegadores de antes eran muy distintos entre sí, y jQuery era prácticamente el único pegamento razonable capaz de mantener unido el codebase en ese aspecto
  • Un aplauso para ese tech lead por dar una buena pelea

• Bien por el equipo de jQuery. Creo que siempre voy a querer a jQuery
  Simplemente es una herramienta que saca el trabajo

  • Bootstrap, PHP, JQuery y WP son el stack de la gente que realmente entrega resultados

• Ahora que el soporte del navegador para seleccionar elementos del DOM es muchísimo mejor, me pregunto por qué alguien usaría jQuery en 2024
  No lo digo para menospreciarlo; de hecho me parece genial que todavía siga en desarrollo, pero me cuesta ver cuál es el caso de uso

  • Hay varios selectores bastante prácticos que document.querySelector() no soporta
    Por ejemplo :selected, :checked y algunos más que sí me he topado varias veces
    En general, la API del DOM choca con casi todo mi sentido de lo que debería ser un buen diseño de API. También tengo quejas con la API de jQuery, pero me parece mucho mejor, y el flujo de lectura y escritura se siente mucho más natural
  • ¿No será por proyectos legacy?
    Mantengo una app web de .NET viejísima, de unos 15 años, que gira alrededor de jQuery. Soñar con refactorizarla o reescribirla por completo con algo más moderno como Web Components está bien, pero en la práctica nunca va a pasar
  • Supongo que será por la comodidad de la API y el ecosistema enorme
  • En paneles de administración me encanta jQuery
    Si es una página que solo ven 20 empleados internos, jQuery es lo bastante ligero, se puede cargar directo desde un CDN, no requiere ningún transpile y básicamente resuelve todo lo necesario

• Como referencia, nosotros construimos con jQuery el editor drag-and-drop de toda una plataforma low-code
  Incluye el editor, todos los controles, es decir, los componentes de UI, y por supuesto el código final que se genera también es puro jQuery
  Pero los ejecutivos de grandes empresas suelen preguntarles a los ingenieros de ventas por qué no es React o Angular o algo así
  Así que me alegra muchísimo leer que jQuery sigue siendo tan relevante, y me da gusto que mi cofundador y CTO siga apoyando esta decisión en vez de intentar mover el stack

• Recuerdo cuando salió jQuery por primera vez
  Para convencer a mis colegas, di una presentación interna llamada “Don’t Fear the $” y expliqué las ventajas que ofrecía jQuery

• Recuerdo la época dorada de jQuery, cuando lo usábamos como reemplazo de Mootools
  Como mucha gente se está pasando de React a HTMX, quizá demos toda la vuelta y terminemos viendo una web que simplemente use jQuery puro otra vez

  • Pasamos por una era parecida, pero no extraño ese caos
    Pensar en hacer una app moderna solo con jQuery, con accesibilidad, soporte móvil, actualizaciones en tiempo real, visualización y hasta algunas funciones de PWA, suena realmente desagradable
    El hype de HTMX también está esperando encontrarse con la realidad. Programar apps con pseudoatributos tipo DSL suena a algo que cansa rápido
  • HTMX me recuerda a Mootools
    Es una librería de JS pequeña y muy especializada
  • HTMX se parece a $().load()
  • “Mucha” puede ser una exageración