Quando se trata de jQuery, muitas pessoas dizem: “Basta usar JavaScript comum. Você não precisa de uma biblioteca jQuery. O que posso dizer? Não preciso de muitas coisas, mas, apesar disso, é bom quando elas são. O mesmo acontece com o jQuery. Eu não preciso desta biblioteca, mas é definitivamente bom tê-la em mãos.
Sites como o
Talvez você não precise do jQuery (YMNJQ) estão promovendo a idéia de que o jQuery é muito fácil de se livrar. Mas o primeiro exemplo neste site demonstra um bom motivo para usar o jQuery. Lá, uma simples linha de código jQuery é substituída por 10 linhas de JS regulares!
A maioria das APIs JavaScript, especialmente aquelas que se concentram no trabalho com o DOM, ofendem meus sentidos estéticos. Esta é, para dizer o mínimo, minha atitude em relação a eles. Falando diretamente, acho que essas APIs são um pesadelo completo. Por exemplo, a construção
el.insertAdjacentElement('afterend', other) certamente funciona. Mas muito melhor parece
$(el).after(other) . Embora eu nunca tenha gostado muito da aparência da função
$() , ela é incomparavelmente melhor do que o que as APIs padrão para trabalhar com o DOM nos fornecem. Eu sei que, em vez de
$() você pode usar algo como
jQuery(sel) ou
window.jq = jQuery . Mas não programo no espaço sem ar. Portanto, eu prefiro usar técnicas padrão. Não sei se isso é bom ou ruim, mas o padrão para usar o jQuery é a construção
$() .
Tente se lembrar rapidamente de como obter um elemento vizinho de outro elemento usando o DOM. O que devo usar para isso -
nextSibling ou
nextElementSibling ? Qual a diferença? E quais navegadores suportam esse ou aquele método? Enquanto você tenta se lembrar disso e examinar o MDN, verificando-se, eu, usando o jQuery, basta escrever
next() ou
prev() .
A realização de muitas operações comuns implementadas na API JavaScript é inconveniente. Eu poderia fornecer aqui uma lista completa dessas operações, mas para mim foi perfeitamente feita na página YMNJQ.
Para resolver vários problemas simples usando ferramentas JS, são necessárias funções auxiliares. E no site YMNJQ, novamente, você pode encontrar muitos exemplos. O uso do jQuery é uma maneira padrão de incluir essas funções auxiliares no código do seu projeto. Ao mesmo tempo, o programador não precisa toda vez que precisar de algo assim para obter trechos de código das primeiras respostas ao Stack Overflow que apareceram em seu braço.
Embora os problemas de compatibilidade do navegador tenham perdido a gravidade atualmente, eles ainda são relevantes. Especialmente - para aqueles que não pertencem ao grupo de desenvolvedores que acreditam que, se algo funciona em 85% dos navegadores, é adequado. A propósito,
aqui está o material sobre o porquê o Hello CSS não usa variáveis CSS.
Devo sempre usar o jQuery? Não, claro que não. Qualquer dependência adicional é um aumento na complexidade do projeto e um aumento no volume do seu código. Mas o jQuery não é uma grande biblioteca. O conjunto padrão, minificado e compactado, leva 30 Kb. A montagem personalizada sem ajax e recursos raramente usados tem 23 Kb. E o assembly, que usa
querySelector vez de
querySelector , ocupa apenas 17 Kb. Para resolver muitos problemas, estou muito satisfeito com o conjunto padrão de 30 Kb e o conjunto otimizado de 17 Kb.
Aqui você pode ver quanto esforço foi feito para remover o jQuery do Bootstrap e mudar para o JS comum.
Os desenvolvedores escreveram suas próprias funções auxiliares. Eles tiveram que abandonar o suporte do IE, pois esse suporte era muito difícil de implementar. Eles tornaram a API incompatível ("quebramos tudo") e passaram um ano e meio nisso tudo. Não posso dizer que o que aconteceu é muito melhor do que o que aconteceu.
Entendo os motivos da tradução do Bootstrap para JS comum. Por exemplo, os desenvolvedores desejam usar o Bootstrap com o Vue.js ou algo semelhante. E o Vue.js e o jQuery em um projeto já são um fracasso. Sou um grande defensor da redução da quantidade de código desnecessário na Web (e
aqui estão alguns materiais sobre isso). Mas aqui proponho olhar a situação de um ponto de vista pragmático e realista. A inclusão do código jQuery de 17 KB no Bootstrap - é tão ruim assim? Quando digo que, para visualizar sites como o Medium ou o New York Times, é necessário baixar mais de um megabyte de código JavaScript, a fim de proteger essa situação, eles me perguntam se estou sentado em uma linha de modem de 56 kilobits. Megabyte JS está bem. O jQuery de 17Kb é realmente pesado?
Existem boas razões para não usar o jQuery. Por exemplo, o jQuery não é necessário se você estiver escrevendo um código que deseja compartilhar com outras pessoas ou se estiver criando alguma função pequena. Mas por que virar de dentro para fora para não usar o jQuery? Por que todo esse esforço se você pode apenas escrever
$() ? Não acho que o jQuery deva ser usado em todos os lugares e sempre, mas não acho que a rejeição fanática do jQuery esteja correta.
Quero observar que não sou casado com o jQuery. Ficarei feliz em usar algo como "jQuery light" - um tipo de biblioteca que cobre as deficiências das APIs padrão, dando ao programador algo mais agradável. O site YMNJQ recomenda, entre outras, as bibliotecas
bonzo e
$ dom , projetadas para resolver vários problemas. Mas muitos deles, ao que parece, não são suportados há muito tempo. Além disso, muitos já conhecem o jQuery. Por que mudar o jQuery por outra coisa sem uma boa razão?
Muitos leitores podem se perguntar o que eu, no contexto deste material, posso dizer sobre o Vue.js, o React e outras estruturas modernas. Mas o objetivo deste artigo é mapear JavaScript e jQuery, em vez de oferecer à comunidade uma "Grandiosa General Frontend Development Theory".
Dado o exposto, acredito que posso encontrar muito poucas razões para usar JS regular, onde você pode usar o jQuery. Isso se deve principalmente ao fato de eu querer criar páginas rápidas e usar as construções de trabalho mais simples. Ao mesmo tempo, esforço-me para garantir que o maior número possível de usuários da Web possa visualizar minhas páginas. A experiência me diz que a maneira mais curta de atingir esse objetivo são os modelos gerados no servidor, que são levemente temperados com JavaScript no estilo de "melhoria progressiva". Se você comparar esses projetos com algo que usa algo mais complexo, acontece que eles geralmente são mais fáceis de desenvolver. Esses projetos geralmente são mais rápidos, geralmente apresentam menos erros e, enquanto trabalham neles, o ventilador do laptop não faz barulho que pode acordar a casa inteira.
Isso significa que estruturas da Web modernas e bibliotecas poderosas são sempre ruins? Não, não é. Muito pouco vale a pena ser sempre chamado de ruim ou bom. Mas usar a estrutura significa fazer alguns compromissos (isso, é claro, é verdade para o jQuery).
Em geral, vejo a web como um ambiente para visualização de documentos, e não como um sistema operacional. E a "abordagem de documentos" é boa não apenas para sites regulares, mas também para muitos "aplicativos da web" (como você quiser).
Caros leitores! Você usa jQuery?
