jQuery v4.0 beta

• O suporte ao IE 10 e anteriores foi removido, e o suporte a Edge Legacy, iOS <11, Firefox <65 e Android Browser também foi descontinuado
• APIs que estavam em estado de descontinuação (deprecation) por várias versões foram removidas: 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
• Os métodos internos de Array do protótipo do jQuery, push, sort, splice, foram removidos, o que pode afetar plugins que dependiam desses métodos
• No encadeamento de eventos relacionados a focusout, blur, focusin e focus, o override anterior do jQuery foi removido, e os navegadores, exceto o IE, agora seguem a ordem W3C atual: blur → focusout → focus → focusin
• jQuery.ajax agora oferece suporte a dados binários e FormData, e o comportamento anterior de tratar tipos de dados desconhecidos como strings foi substituído por processamento automático
• Foi removido o comportamento do jQuery.ajax que promovia automaticamente para requisições JSONP quando dataType: "json" e um callback eram fornecidos juntos
• O código-fonte do jQuery foi migrado de AMD para ES modules, e a ferramenta de empacotamento foi trocada de RequireJS para Rollup
• Foi adicionado suporte a Trusted Types, permitindo usar HTML encapsulado com TrustedHTML como entrada de métodos de manipulação do jQuery sem violar a diretiva CSP require-trusted-types-for
• A maioria das requisições assíncronas de script passou a usar a tag <script>, evitando erros de CSP causados pelo uso de scripts inline
• Na build slim, Deferreds e Callbacks foram removidos, reduzindo o tamanho para menos de 20k bytes em gzip, cerca de 8k bytes gzipped menor que a build normal
• Se você precisa de suporte ao IE11, é recomendado usar a build principal em vez da build slim ou adicionar um polyfill de native Promises
• Um guia completo de upgrade será publicado antes do lançamento oficial, e o jQuery Migrate plugin será preparado para ajudar na migração
• A versão beta está disponível no CDN do jQuery e no npm; CDNs de terceiros não hospedarão a beta e devem hospedar a versão final 4.0.0 posteriormente

[GN⁺]

Comentários do Hacker News

• Se você quer entender o que ainda mantém o jQuery vivo mesmo depois de 2024, precisa lembrar que o WordPress ainda representa mais de 1/3 da web, e a maioria das instalações e inúmeros plugins dependem fortemente de jQuery
  É bom ver avanço na remoção de APIs e funções obsoletas, e há uma boa chance de o jQuery continuar predominante na web por mais alguns anos

  • Além disso, jQuery é excelente
    Nos últimos 15 anos mais ou menos, a indústria ficou obcecada por frameworks JavaScript excessivamente complexos e chamativos, mas para 99% das páginas web tudo o que se precisa de JavaScript é fazer binding dinâmico em formulários gerados dinamicamente, lidar com estados de erro e fazer algumas chamadas Ajax; o resto muitas vezes é exagero
    Parece que a indústria vai se afastar da complexidade do React e migrar para a simplicidade de htmx, Phoenix LiveView, Ruby on Rails Turbo e simplesmente jQuery
  • Diga o que quiser, jQuery ainda é poderoso, importante e influente
    Se você removesse jQuery de todo software, uma parte considerável dos sites espalhados pela internet pararia de funcionar
  • Não é um problema só do WordPress
    Em uma empresa onde trabalhei no passado, um produto SaaS corporativo era operado com dezenas de milhares de linhas de código em jQuery
    Não vai acontecer uma reescrita para um framework JS moderno a menos que isso se torne absolutamente necessário. A maior parte é código escrito há mais de 10 anos para atender exigências específicas de certos clientes, e também não cola esse argumento de que usar um framework moderno ajudaria na contratação. A empresa paga só entre US$ 75 mil e US$ 90 mil para engenheiros de front-end, a rotatividade é baixa e a maioria dos engenheiros atuais está lá há mais de 5 anos
    Acima de tudo, a stack atual funciona bem e os clientes antigos continuam satisfeitos. Uma parte significativa da engenharia de software acontece nesses negócios sem graça em cidades com custo de vida muito mais baixo do que polos de big tech como Bay Area ou Seattle
  • Desenvolvedores de WordPress são como os encanadores da indústria de tecnologia
    Não é glamouroso, mas há tanta demanda que dá para ganhar muito dinheiro
    Se um dia eu me aposentar desse mundo de startups de big tech obcecadas pela última moda, quero ganhar dinheiro honestamente criando sites em WordPress e terminar o trabalho todo dia às 15h
  • Há pouco tempo pensei em postar isso no HN, mas desisti: ainda não encontrei um ótimo modelo de tratamento/propagação em cadeia de eventos que permita disparar eventos em que membros do DOM e instâncias de classes abstratas possam ser usados de forma intercambiável
    Já criei despachantes de eventos manualmente em vários lugares, mas o jQuery faz isso direito. Ainda hoje uso jQuery quase só para tratamento de eventos, mas é tão útil que acabo incluindo em quase todo projeto client-side
    O que eu queria perguntar era se alguém conhece uma biblioteca leve que permita tratar $(window).trigger('click') e $(myClassInstance).trigger('myCustomEvent',{data}) com a mesma API, incluindo escuta assíncrona
    Graças à ascensão de fetch() e dos seletores CSS, parece que hoje já dá para viver sem o restante do jQuery, mas fico pensando se realmente vale a pena reinventar a roda. Antes de dizer que instâncias de classes disparando eventos é code smell, isso é absolutamente necessário se você quiser construir um framework reativo do zero
    Por exemplo, minha classe base de componente escuta certos eventos customizados de resize que acontecem na tela em que ela está, e essa tela só envia eventos aos componentes que precisam reorganizar seu interior sem que a própria tela faça scroll. A classe de tela escuta window.resize, mas só despacha quando o layout fica problemático. Não faz sentido colocar listeners individuais de resize do DOM em window para todos os componentes

• Fico surpreso ao ver que no HN ainda aparece gente tratando jQuery como se fosse apenas uma biblioteca simples de seleção de DOM
  Na prática, é um conjunto de ferramentas amplamente suportado e extremamente estável, oferecendo não só seleção de DOM, mas também manipulação de atributos, requisições Ajax, tratamento de eventos, animações e até funções utilitárias de uso geral
  Além disso, mesmo quando existem recursos nativos para substituir jQuery, a API não é tão elegante quanto
  Se a tarefa só precisa adicionar um pouco de funcionalidade em cima de HTML renderizado no servidor e não exige um framework completo de UI em JS, jQuery é uma dependência estável, confiável e compatível entre navegadores por um custo pequeno

  • Alguns anos atrás abandonei jQuery e migrei para JavaScript puro, e nunca mais olhei para trás
    O JS nativo já tem tudo o que jQuery oferece, só não tem aquele monte de plugins mal mantidos e pela metade. Normalmente esses plugins fazem só aquilo a que se propõem e quase nada além disso
    Seletores puros são mais verbosos, mas em qualquer editor de código decente a velocidade de digitação acaba sendo a mesma. Não quero discutir, mas realmente não entendo por que tanta gente ainda usa jQuery
    https://youmightnotneedjquery.com/
  • Olhando para o perfil de quem escreve no HN, não é tão surpreendente assim
    Muita gente, no momento em que precisa de um pouco mais do que seleção de DOM, já pega imediatamente o grande framework JS da moda, porque sempre fez isso
  • Você diz “pessoas que veem jQuery como apenas uma biblioteca de seleção de DOM”, mas logo em seguida passa a listar seleção e funções nativas
  • É muito mais fácil colocar jQuery em um projeto
    Não precisa de ferramentas de build nem de toda a dor de cabeça que vem junto. Também dá para fazer isso com React, mas os recursos oferecidos nem são comparáveis

• Em um mundo em que muita gente está tentando remover ativamente os últimos vestígios de jQuery, fico sinceramente curioso para saber quem ainda está desenvolvendo ativamente com jQuery hoje
  A maior parte do que antes se fazia com jQuery agora já está no navegador, e acho que querySelectorAll é o exemplo mais forte disso

  • Fiquei mais velho e as novas tecnologias ficaram menos interessantes para mim, então as promises, await e async do JS nativo parecem bem mais complicadas do que $.ajax()
    Tentei me acostumar usando JS puro em alguns pequenos projetos pessoais, mas para mim fazer isso com $.ajax() é algo que sai direto, como memória muscular
    Além disso, provavelmente só umas 20 pessoas usam de fato o código que escrevo para manipulação de DOM. Eu não sou de UI, sou de backend, e só mexo no frontend porque não há quem faça isso
  • Segundo a pesquisa do Stack Overflow do ano passado, jQuery foi a terceira mais popular
    https://survey.stackoverflow.co/2023/#section-most-popular-t...
  • Acabei de passar um bom tempo em uma empresa removendo os últimos vestígios de React e trocando por HTMX
    Pessoalmente, vejo o HTMX como o sucessor espiritual do jQuery em certos aspectos
  • Eu também estou tentando ativamente eliminar jQuery, mas parece que as pessoas já se acostumaram com a ferramenta, e voltar a usá-la tem um custo, então falta disposição ou justificativa de negócio para removê-la
    Começar um projeto novo com jQuery é algo questionável, mas definitivamente existem desenvolvedores muito mais acostumados a fazer as coisas do jeito do jQuery do que do jeito JavaScript puro
  • Desenvolvedores solo ou equipes pequenas que não gostam de toolchains modernas usam
    Um bom exemplo é levelsio: https://twitter.com/levelsio/status/1750175827197567165
    Eu sou desse grupo e ainda uso jQuery
    Meu SaaS atual é a extensão https://www.snipcss.com, que não tem muito código de UI, e o próximo SaaS será uma extensão de automação web baseada em ChatGPT com bastante UI. Ambos usam jQuery
    O principal motivo para eu não ir para JS puro com querySelectorAll é que gosto da forma de anexar eventos, especialmente por poder anexá-los ao pai e mirar elementos filhos adicionados dinamicamente, além de gostar do encadeamento de funções e do fato de exigir menos código que JS puro

• Excelente. Só que, de tanto esperar pelo 4.0, acabei criando meu próprio jQuery com algumas diferenças fundamentais
  Para animações, tweens e timelines, uso CSS puro em vez do sistema customizado do jQuery, lido de forma transparente com elementos únicos e listas, e adoto uma abordagem inline

  • Sempre achei que deveria existir uma alternativa moderna e leve ao jQuery desse tipo. Ficou muito bem feito e gostei da sintaxe
    Eu também estava implementando algo parecido, incluindo eventos inline e mais do que apenas métodos padrão de array [0]
    Seria ótimo ver um texto ou screencast explicando como a localidade do comportamento (locality of behavior) é implementada em surreal e no projeto companheiro css-scope-inline. Quero entender isso para poder manter no longo prazo e talvez colocar nos meus projetos
    Também gostaria de conversar sobre filosofia da web. Acho que em alguns pontos pensamos de forma parecida
    [0] https://hyperspace.so/All.js.png

• Parece que voltei aos meus tempos de júnior por volta de 2008. Tive uma discussão acalorada com o tech lead para adicionar jQuery ao projeto
  O argumento dele era que o tamanho minificado da biblioteca, 40KB, era um peso grande demais para o tempo de carregamento da página
  Depois disso, passamos uma semana inteira escrevendo chamadas Ajax manualmente e testando suporte a vários navegadores, mas no fim não conseguimos fazer funcionar no Internet Explorer 5
  Naquela época, jQuery realmente resolvia muitas dores de cabeça, e no fim ele adicionou a biblioteca ao projeto

  • As pessoas esquecem isso com frequência, mas os navegadores antigos eram muito diferentes entre si, e o jQuery era a única cola realmente razoável para manter a base de código unida nesse aspecto
  • Palmas para o tech lead, que travou uma boa luta

• Bom trabalho da equipe do jQuery. Acho que vou gostar de jQuery para sempre
  É simplesmente uma ferramenta que faz o trabalho acontecer

  • Bootstrap, PHP, JQuery e WP são a stack de quem realmente entrega resultado

• Agora que o suporte do navegador para seleção de DOM está muito melhor, fico curioso por que usar jQuery em 2024
  Não estou tentando diminuir, e acho legal que ainda haja desenvolvimento, mas fico confuso sobre quais seriam os casos de uso

  • Há vários seletores bem convenientes que document.querySelector() não suporta
    Por exemplo, :selected, :checked e alguns outros; já me deparei com isso algumas vezes na prática
    No geral, a API de DOM fere bastante do meu senso de bom design de API. Também tenho reclamações sobre a API do jQuery, mas ela é muito melhor, e o fluxo de leitura e escrita é bem mais natural
  • Talvez por causa de projetos legados
    Faço manutenção em um antigo aplicativo web .NET com uns 15 anos e ele gira em torno de jQuery. Sonhar com um refactor ou reescrita completa usando algo mais moderno, como Web Components, é legal, mas na prática isso nunca vai acontecer
  • Meu palpite é que seja pela API conveniente e pelo enorme ecossistema
  • Gosto de jQuery para páginas administrativas
    Se é uma página vista só por 20 funcionários internos, jQuery é leve o suficiente, pode ser carregado direto de uma CDN, não precisa de transpile nenhum e basicamente resolve tudo que você precisa

• Como referência, nós construímos todo o editor de arrastar e soltar de uma plataforma low-code com jQuery
  Incluindo o editor, todos os controles, ou seja, os componentes de UI, e, claro, o código final gerado também é jQuery puro
  Mas executivos de grandes empresas vivem perguntando aos engenheiros de vendas por que não é React, Angular etc.
  Então fico muito feliz em ler que o jQuery ainda é tão relevante, e feliz por meu cofundador e CTO continuar apoiando essa escolha em vez de tentar mudar a stack

• Lembro de quando o jQuery apareceu pela primeira vez
  Para convencer meus colegas, fiz uma apresentação interna chamada “Don’t Fear the $” e expliquei as vantagens que o jQuery oferecia

• Lembro da era de ouro do jQuery, quando o usávamos como substituto do Mootools
  Como muita gente está migrando de React para HTMX, talvez, depois de dar uma volta completa, a web acabe voltando a usar jQuery puro

  • Passamos por uma época parecida, mas não sinto falta daquela bagunça
    Pensar em criar um app moderno só com jQuery — com acessibilidade, suporte a mobile, atualizações em tempo real, visualizações e até alguns recursos de PWA — soa realmente desagradável
    O hype do HTMX também está só esperando encontrar a realidade. Programar apps com pseudoatributos estilo DSL parece algo de que as pessoas vão cansar rapidamente
  • HTMX me lembra Mootools
    É uma biblioteca JS pequena e bem especializada
  • HTMX é tipo $().load()
  • “Muita” talvez seja um exagero