Vantagens de usar JavaScript puro sobre JQuery

Quais são as vantagens de usar somente Javascript em vez de usar apenas JQuery?

Tenho experiência limitada com JavaScript e codificação JQuery. Adicionei bits e trechos de cada uma às páginas HTML, mas na maioria das vezes codifiquei coisas do lado do servidor em outros idiomas. Percebi que, embora você possa teoricamente fazer as mesmas coisas usando uma das duas abordagens (e é claro que você pode até misturá-las no mesmo projeto), parece haver uma tendência a sempre começar a usar o JQuery desde o início não importa quais sejam as demandas do projeto.

Então, eu estou simplesmente me perguntando, há algum benefício pontual em não usar apenas o JQuery, mas apenas usar o JavaScript antigo e simples?

Sei que isso parece uma não-pergunta, porque pode-se dizer que "não há resposta definitiva" ou "pode ​​ser debatido para sempre", mas na verdade estou esperando respostas pontuais como "Você pode fazer isso em uma abordagem e você não pode fazer isso com a outra ".

Conforme o comentário do scrwtp, não estou me referindo apenas à parte de manipulação do DOM. Minha pergunta é: JQuery é uma biblioteca. Para Javascript. O que acho estranho nessa biblioteca, em oposição a outras bibliotecas para outras línguas, é que, no caso do JQyery, ele parece ter sido projetado para poder usá-lo exclusivamente e não precisa tocar diretamente no Javascript. Isto é o contrário de, digamos, Hibernate e SQL, onde, embora a biblioteca (ou melhor, a estrutura neste caso, mas acho que a analogia ainda se aplique) domine MUITOS aspectos, você ainda poderá usar o SQL ao usá-lo , pelo menos em alguns casos adicionais. No entanto, no caso JQuery e Javascript, você pode fazer qualquer coisa com Javascript usando apenas JQuery (ou pelo menos é assim que me parece).

Conforme o comentário de Stargazer712: sim, eu concordo com você, a pergunta aqui é: como você coloca "apenas uma questão de como você usará o JavaScript". Era isso que eu realmente queria perguntar, mas fiz algumas formulações ruins. Aqui está outra analogia: Spring Expression Language. É uma biblioteca Java. Você não pode usá-lo sem Java, ele é baseado em Java e, ao longo de tudo, você ainda usa Java. Mas, na prática, o que você pode fazer é adicionar essa biblioteca a um projeto Java e, em seguida, escrever todo o seu código usando a linguagem de expressão do Spring EL, que efetivamente faz com que seu código não se pareça com o Java, e é até uma mudança de paradigma (por exemplo, você não tem mais forte aplicação do tipo ao usá-lo). Embora eu entenda que o JQuery é apenas uma biblioteca JS, para mim parece que, na prática, tem o mesmo efeito que o Spring EL com Java, ou seja, você só pode usá-lo por meio de um projeto e evitar as APIs do JavaScript. E eu queria saber se isso é uma boa coisa a fazer, quais podem ser as armadilhas etc.

(e sim, depois de ler as respostas de todos, entendo que:

uma. minha pergunta é um tanto absurda até certo ponto

b. mesmo que a pergunta fosse completamente precisa, a resposta seria praticamente "não, você não pode usar apenas o JQuery apenas o tempo todo)

Primeiro - é impossível usar apenas o jQuery, tudo o que o jQuery faz é adicionar um objeto $ ao seu escopo global, com vários métodos nele. Bibliotecas ainda mais manipuladoras, como prototype, não são uma alternativa ao javascript, são um cinto de ferramentas para resolver problemas comuns.

As principais vantagens de adicionar o jQuery ao seu cinto de ferramentas seriam:

• compatibilidade do navegador - fazer algo como .attr () é muito mais fácil do que as alternativas nativas e não afeta os navegadores.
• simplificação de operações geralmente complicadas - se você gostaria de ver uma versão bem escrita de um método XHR compatível com vários navegadores, dê uma olhada na fonte para $ .ajax - somente para esse método, vale quase a sobrecarga do jQ.
• Seleção DOM - coisas simples, como vincular eventos e selecionar elementos DOM, podem ser complicadas e diferem por navegador. Sem muito conhecimento, eles também podem ser facilmente escritos mal e tornar a página mais lenta.
• Acesso a recursos futuros - coisas como .indexOf e .bind são javascript nativo, mas ainda não são suportados por muitos navegadores. No entanto, o uso das versões jQuery desses métodos permitirá que você os suporte em vários navegadores.

Javascript não é mais apenas uma linguagem do lado do cliente e, como o jQuery depende muito do DOM, é um péssimo candidato para a mudança para o servidor. Eu recomendo dedicar algum tempo para entender por que você está usando o jQuery (fazer essa pergunta é um ótimo primeiro passo!) E avaliar quando é necessário. O jQuery pode ser perigoso, alguns dos principais perigos são:

• qualidade do código - o jQuery tem uma comunidade enorme e uma baixa curva de aprendizado. Esta é uma tempestade perfeita para muitos plugins de código aberto mal escritos.
• ineficiência - o jQuery é fácil de escrever de maneira ineficiente. Por exemplo, o uso de jQuery's em vez de para loops é desnecessário e pode ter um impacto no desempenho em alguns casos. Muitas informações boas sobre esse material no JSPerf
• inchar - jQuery é uma biblioteca enorme. Na maioria das vezes, você usa um pequeno subconjunto de seus recursos e agarra a biblioteca inteira. Existem algumas alternativas excelentes que fornecerão subconjuntos de recursos, como zepto.js e underscore.js - dependendo da sua situação, você poderá salvar alguns bytes escolhendo a biblioteca certa para suas necessidades.

Por fim, o jQuery é uma biblioteca incrivelmente útil e útil, quando usada corretamente. No entanto, é não uma alternativa para javascript. É uma biblioteca, assim como zepto.js , YUI , Dojo , MooTools e Prototype - uma das quais pode ser uma escolha muito melhor para o seu projeto atual.

Javascript é uma linguagem incompreendida e só recentemente é considerada como algo mais que uma linguagem de script para a maioria das pessoas. Eu realmente recomendo ler mais, aqui estão alguns bons lugares para começar:

Edit 07/2014 - Notei que este post ainda está recebendo atenção, então adicionei vários links. Eles não estão em uma ordem específica, mas devem ser úteis.

• Blog de Ben Alman - muitas boas práticas aqui. Não concordo com todos eles, mas aprendo coisas novas em seu blog o tempo todo.
• Code Academy - treinamento básico sobre javascript e jQuery. Às vezes, voltar ao básico ajuda.
• Javascript Garden - um post sobre os recursos mais complicados ou incompreendidos do javascript. Por favor, leia isso de tempos em tempos, até que tudo faça sentido.
• Bocoup - estas são aulas de treinamento. Se você estiver perto de um, vá para ele. Muitos dos melhores palestrantes e professores de JS ensinam isso.
• Blog de Paul Irish - não estritamente JS, mas muitas das melhores práticas estão escritas aqui. Os feeds de twitter dele e de Ben são ótimos para seguir.
• Javascript: The Good Parts - frequentemente referido como 'A Bíblia Javascript', este livro de Douglas Crockford é um lugar incrível para começar a entender o javascript.
• Blog de Isaac Schlueter - Isaac é o criador do npm e trabalha no núcleo do nó. Ele escreve muito sobre a comunidade javascript, e não sobre convenções de código, mas se você realmente está acessando js, ​​é uma ótima leitura.
• Javascript de Douglas Crockford - Se Brendan Eich é o pai de javascript, Douglas é o tio franco de javascript. Ele é o autor da especificação JSON, da bíblia javascript e de muitos posts incríveis sobre as peculiaridades e a ascensão meteórica do javascript.
• Blog de Brendan Eich - Brendan é o criador do javascript - ele escreve sobre todos os tipos de coisas bobas em seu blog e, embora tenha seus defeitos como pessoa, suas postagens em javascript são valiosas.
• Blog do James Halliday (@substack) - Substack é indiscutivelmente o desenvolvedor node.js mais importante da comunidade - com cerca de 400 (e crescendo todos os dias) módulos npm e uma filosofia orientadora de pequenos módulos semelhantes a unix, tudo o que ele escreve vale a pena lendo.
• Blog de Max Ogden Max Ogden é outro autor prolífico do node.js e é excelente ao escrever posts que ensinam alguma coisa. Ele também é o autor (com outros que acredito) de javascript para gatos.
• Javascript para gatos - este é um pequeno tutorial que mostra os conceitos básicos de javascript da perspectiva de um gato. Se você é iniciante, leia isso. É divertido e ensina em uma hora o que muitos livros levam semanas para se comunicar.
• Blog Nicholas Zákas Nicholas é o autor de alguns livros javascript fantásticas: Programação Orientada a Objetos em Javascript , Maintainable Javascript , Javascript profissional para desenvolvedores Web , e High Performance Javascript . Ele se concentra principalmente no cliente, mas possui várias práticas recomendadas e dicas de desempenho.
• Blog de Guillermo Rauch - Guillermo é outro prolífico node.js dev, famoso principalmente por Socket.io e Mongoose. Seu blog (e seu novo livro, Smashing Node.js são ótimos recursos.

Tenho certeza de que há muitos outros ótimos recursos que não estou pensando ou que não conheço, outros respondentes devem ficar à vontade para adicionar a essa lista.

Existem vantagens, mas é discutível se elas realmente superam as desvantagens.

O principal é que você economiza largura de banda e obtém respostas mais rápidas. O jQuery adiciona outros ~ 30kb à sua resposta. Em algumas redes (e em alguns países), isso pode significar mais alguns milissegundos. Por outro lado, no entanto, você pode configurar o cache para ele com bastante facilidade usando seu servidor da Web (ou, como Xion disse, use-o no site do Google para que não cause impacto no seu próprio e ainda seja armazenado em cache).

A segunda coisa é que você pode precisar apenas de algumas funcionalidades muito simples e apenas o download e a configuração do jQuery podem levar mais tempo do que simplesmente implementar o que você precisa.

E, por último, convém rolar sua própria estrutura, que é principalmente uma má idéia, mas algumas pessoas têm seus motivos.

No entanto, se você descartar o jQuery simplesmente por se sentir intimidado pela curva de aprendizado, deve reconsiderar. Especialmente porque é bastante gentil.

Até onde eu sei, existem apenas duas vantagens em usar o javascript vanilla versus uma biblioteca como JQuery , MooTools , etc.

• As bibliotecas têm uma carga útil que consome largura de banda. Mas como as pessoas já apontaram nas outras respostas, você pode limitar isso com gzipping e cache. Se você deseja apenas um subconjunto do jQuery, pode fazer com o SizzleJS e com o MooTools, você tem a opção de selecionar os conjuntos de recursos que deseja da mesma maneira que o Modernizr faz .
• As bibliotecas são grandes e levam algum tempo para aprender. Então, novamente, este é um investimento único para desenvolvedores ... e fica bem no seu currículo conhecer as bibliotecas javascript.
• (BÔNUS) As bibliotecas não são uma bala de prata; portanto, se você gosta de reinventar a roda, esse é definitivamente o caminho.

Vale ressaltar por que você deseja usar uma biblioteca javascript, para a qual há muitas:

• Você não precisa escrever sua própria estrutura para dar suporte ao seu desenvolvimento. Se você estiver curioso para saber como as coisas funcionam, confira o código, pois ele é de código aberto.
• As bibliotecas resolvem a compatibilidade do navegador. O DOM e o javascript têm algumas diferenças entre os navegadores. Confie em mim, este é um enorme sumidouro de tempo se você precisar hackear as correções.
• É de fato padrão da Internet usar bibliotecas javascript, a maioria delas está bem documentada agora e a maioria dos desenvolvedores da Web (que sabem javascript) sabem como usá-las.
• Você realmente não desiste do javascript ao usar uma biblioteca. Você ainda precisa conhecer o Javascript com seus tipos, objetos, como funcionam os fechamentos etc.
• A maioria das bibliotecas é modularizada e não leva muito tempo para escrever plug-ins ou usar require e o padrão AMD .
• A seleção de elementos CSS do DOM é uma grande ajuda.
• (BÔNUS) Você também pode usá-los com o CoffeeScript .

Eu costumava trabalhar em uma loja virtual que era inflexível ao usar javascript de baunilha porque o jQuery era grande e assustador. Essa decisão, principalmente influenciada por um "desenvolvedor de javascript", foi a fonte de muitos bugs do navegador e o desenvolvimento lento, e tentar entrar em sua base de código foi uma experiência impressionante. Escrever sua própria estrutura pode parecer uma boa ideia, mas se você deseja contratar novos desenvolvedores, eles não podem entrar e ajudar rapidamente . Depois, há também a questão do fator de ônibus a considerar.

Como eu disse, costumava trabalhar lá ... havia pastos mais verdes em outros lugares. : ^)

Por acaso, misturo bastante o uso de ambos. A maior razão para isso é que, para alguns aplicativos (pense em extensões do Chrome), você não precisa de suporte entre navegadores. O que significa que eu posso tirar proveito de novos avanços como o css3 que, com coisas como transições, podem simplificar muito o seu código sobre o uso do jquery.

Também costumo fazer algo personalizado. Por todos os meios, como os outros disseram, você não deve reinventar a roda. Mas quando você é solicitado a fazer algumas funcionalidades malucas, geralmente acho muito mais fácil escrevê-las, então, tentar hackear algum plugin jquery que seja próximo, mas não uma combinação perfeita.

Também trabalhei com desenvolvedores que trabalham com nada além de jquery. E tenho que dizer que eles comprometiam a funcionalidade com muito mais frequência do que se não conseguissem encontrar um plugin jquery que fizesse o que queriam.

Em algum momento do desenvolvimento da Web, você será solicitado a fazer algo não pré-empacotado em uma biblioteca. Então, nesse ponto, é melhor você entender como o idioma base realmente funciona.

Portanto, TLDC : use os dois, você está em desvantagem usando apenas baunilha e está em desvantagem se não conhece a baunilha por dentro e por fora e insiste em sempre usar o jquery.

A única coisa em que consigo pensar que você não pode ficar sem o JQuery seria usar os plugins do JQuery; mesmo assim, você poderia escrever sua própria biblioteca JS que forneceria exatamente o que o plug-in precisa.

Pense assim: JQuery é uma biblioteca Javascript de código aberto escrita em Javascript; você pode olhar para a fonte e, assim, aprender como fazer qualquer coisa que ela faça.

Você não pode usar o JQuery sem usar o Javascript antigo simples. Você provavelmente não usará document.getElementById, mas ainda definirá funções e variáveis ​​das formas Javascript padrão; você pode até escrever um forloop padrão .

O principal benefício de usar o JQuery é praticamente o mesmo que qualquer outra biblioteca de terceiros em qualquer idioma: você não precisará escrever tanto código para implementar a lógica específica do seu aplicativo.

Não deixe o tamanho assustar você. A versão CDN é um download de ~ 33k que será armazenado em cache pelo navegador do usuário após a primeira página ser acessada.

Se você está preocupado com o desempenho, tente usar o vanilla js sempre que possível. estruturas não apenas adicionam sobrecarga de largura de banda, mas também sobrecarga de processamento. E o jQuery também oferece compatibilidade com navegadores para navegadores bastante antigos.

se você estiver trabalhando em aplicativos ou jogos para celular (ou ambos combinados), precisará primeiro de desempenho e eficiência de recursos.

O jQuery e os plugins podem acelerar o seu desenvolvimento, mas principalmente se você confiar nos plugins jquery de terceiros, deverá saber o que eles estão fazendo por dentro. Muitos deles são exemplos ruins de qualidade e eficiência do código.

O jQuery pode ser 2 a 10 vezes mais lento que o JavaScript nativo. E isso pode facilmente incentivar os desenvolvedores a não projetar adequadamente sua interface e confiar demais nos seletores jQuery, que são muito mais lentos que os nativos.