Vantaggi dell'utilizzo di JavaScript puro rispetto a JQuery

Quali sono i vantaggi dell'utilizzo del solo Javascript rispetto all'uso del solo JQuery?

Ho un'esperienza limitata con i codici JavaScript e JQuery. Ho aggiunto bit e frammenti di ciascuno alle pagine HTML ma ho principalmente codificato materiale lato server in altre lingue. Ho notato che mentre in teoria puoi fare le stesse cose usando uno dei due approcci (e ovviamente puoi anche mescolarli nello stesso progetto) sembra esserci una tendenza a iniziare sempre a usare JQuery fin dall'inizio non importa quali siano le esigenze del progetto.

Quindi mi chiedo semplicemente, ci sono dei vantaggi puntuali nel non usare solo JQuery ma invece di usare semplicemente il vecchio JavaScript?

So che sembra una non domanda perché si può dire al riguardo che "non esiste una risposta definita" o "si può discutere per sempre", ma in realtà spero in risposte puntuali come "Puoi farlo in un approccio e non puoi farlo con l'altro ".

Come da commento di scrwtp, non mi riferisco solo alla parte DOM Handling. La mia domanda è piuttosto: JQuery è una libreria. Per Javascript. Ciò che trovo strano su questa libreria rispetto ad altre librerie per altre lingue è che nel caso di JQyery sembra essere progettato per essere in grado di usarlo esclusivamente e non è necessario toccare Javascript direttamente. Questo è al contrario di dire Hibernate e SQL, dove anche se la libreria (o piuttosto il framework in questo caso, ma penso che l'analogia si applichi ancora) prende il controllo su MOLTI aspetti, si può comunque usare SQL quando lo si utilizza , almeno per alcuni casi marginali. Tuttavia, nel caso di JQuery e Javascript, potresti fare qualsiasi cosa tu faccia con Javascript usando solo JQuery (o almeno così mi sembra).

Secondo il commento di Stargazer712: sì, sono d'accordo con te, la domanda qui è, poiché la metti "solo una questione di come utilizzerai JavaScript". Questo è quello che stavo davvero cercando di chiedere, ma ho fatto alcune formulazioni sbagliate. Ecco un'altra analogia: Spring Expression Language. È una libreria Java. Non puoi usarlo senza Java, è basato su Java e in fondo tutto ciò che puoi ancora usare Java. Ma in pratica quello che puoi fare è aggiungere questa libreria a un progetto Java, e quindi scrivere tutto il tuo codice usando il linguaggio di espressione di Spring EL che effettivamente fa sì che il tuo codice non assomigli affatto a Java, e persino il cambio di paradigma (ad esempio non hai più forte applicazione del tipo quando si utilizza questo). Anche se capisco che JQuery è solo una libreria JS, a me sembra che in pratica abbia lo stesso effetto di Spring EL con Java, vale a dire che puoi usare le sue API solo attraverso un progetto ed evitare le API di JavaScript. E mi chiedevo se è una buona cosa da fare, quali potrebbero essere le insidie, ecc.

(e sì, dopo aver letto le risposte di tutti capisco che:

un. la mia domanda è alquanto insensata fino a un certo punto

b. anche se la domanda fosse completamente accurata, la risposta sarebbe praticamente "no, non puoi semplicemente usare JQuery solo per tutto il tempo)

Prima di tutto: è impossibile utilizzare solo jQuery, tutto ciò che jQuery fa è aggiungere un oggetto $ al proprio ambito globale, con un sacco di metodi. Anche le librerie più manipolative come il prototipo non sono un'alternativa al javascript, sono una cintura degli strumenti per risolvere i problemi più comuni.

I principali vantaggi dell'aggiunta di jQuery alla cintura degli strumenti sarebbero:

• compatibilità del browser - fare qualcosa come .attr () è molto più facile delle alternative native e non si spaccherà tra i browser.
• semplificazione di operazioni di solito complicate - se desideri vedere una versione ben scritta per un metodo XHR compatibile con browser diversi, dai un'occhiata alla fonte per $ .ajax - per questo metodo da solo vale quasi il sovraccarico di jQ.
• Selezione DOM - cose semplici come il binding di eventi e la selezione di elementi DOM possono essere complicate e differire per browser. Senza molta conoscenza, possono anche essere facilmente scritti male e rallentare la tua pagina.
• Accesso a funzionalità future: cose come .indexOf e .bind sono javascript nativi, ma non sono ancora supportate da molti browser. Tuttavia, l'utilizzo delle versioni jQuery di questi metodi ti consentirà di supportarli su più browser.

Javascript non è più solo una lingua lato client e poiché jQuery dipende dal DOM, è un candidato terribile per passare al server. Consiglio vivamente di dedicare un po 'di tempo a capire perché stai usando jQuery (porre questa domanda è un ottimo primo passo!) E valutare quando è necessario. jQuery può essere pericoloso, alcuni dei principali pericoli sono:

• qualità del codice - jQuery ha una comunità enorme e una curva di apprendimento bassa. Questa è una tempesta perfetta per molti plugin open source scritti male.
• inefficienza: jQuery è facile da scrivere in modo inefficiente. Ad esempio, l'utilizzo di jQuery ciascuno anziché per i loop non è necessario e in alcuni casi potrebbe avere un impatto sulle prestazioni. Molte buone informazioni su queste cose su JSPerf
• bloat - jQuery è un'enorme libreria. Per la maggior parte del tempo, utilizzerai un piccolo sottoinsieme delle sue funzionalità e acquisirai l'intera libreria. Ci sono alcune ottime alternative che ti daranno sottoinsiemi di funzionalità, come zepto.js e underscore.js - a seconda della situazione, puoi salvare alcuni byte scegliendo la libreria giusta per le tue esigenze.

Alla fine, jQuery è una libreria incredibilmente utile e utile, se usato correttamente. Tuttavia, è non è un'alternativa a JavaScript. È una libreria, proprio come zepto.js , YUI , Dojo , MooTools e Prototype - una delle quali potrebbe essere una scelta molto migliore per il tuo progetto attuale.

Javascript è un linguaggio incompreso, e solo di recente viene considerato come qualcosa di più di un linguaggio di scripting dalla maggior parte delle persone. Consiglio vivamente di leggerlo di più, ecco alcuni buoni posti per iniziare:

Modifica 07/2014 - Ho notato che questo post sta ancora attirando l'attenzione, quindi ho aggiunto un sacco di link. Questi non sono in un ordine particolare, ma dovrebbero essere utili.

• Blog di Ben Alman : molte buone pratiche qui. Non sono d'accordo con tutti loro, ma imparo sempre nuove cose dal suo blog.
• Code Academy : formazione di base su javascript e jQuery. A volte tornare alle origini aiuta.
• Javascript Garden - un post riguardante le funzionalità più complicate o incomprese di JavaScript. Si prega di leggere di volta in volta, fino a quando tutto ha un senso.
• Bocoup - questi sono corsi di formazione. Se sei vicino a uno, vai ad esso. Molti dei migliori oratori e insegnanti di JS insegnano questi.
• Il blog di Paul Irish - non strettamente JS, ma molte buone pratiche sono scritte qui. Lui e i feed di Twitter di Ben sono entrambi fantastici da seguire.
• Javascript: The Good Parts - spesso indicato come "The Javascript Bible", questo libro di Douglas Crockford è un posto fantastico per iniziare a capire javascript.
• Blog di Isaac Schlueter - Isaac è il creatore di npm e lavora sul core del nodo. Scrive molto sulla comunità javascript piuttosto che sulle convenzioni di codice, ma se stai davvero entrando in js è un'ottima lettura.
• Javascript di Douglas Crockford - Se Brendan Eich è il padre di javascript, Douglas è lo zio schietto di javascript. È l'autore delle specifiche JSON, della bibbia javascript e di molti post sorprendenti sulle stranezze e l'ascesa meteorica di javascript.
• Brendan Eich's Blog - Brendan è il creatore di javascript - scrive di ogni sorta di cose stupide sul suo blog, e mentre ha i suoi difetti come persona, i suoi post javascript sono preziosi.
• Blog di James Halliday (@substack) - Substack è senza dubbio lo sviluppatore node.js più importante della comunità - con circa 400 (e in crescita ogni giorno) moduli npm e una filosofia guida di piccoli moduli simili a unix, vale tutto ciò che scrive lettura.
• Blog di Max Ogden Max Ogden è un altro autore prolifico di node.js ed è eccellente nello scrivere post di blog che ti insegnano qualcosa. È anche l'autore (con altri credo) di JavaScript per i gatti.
• Javascript per gatti - Questo è un breve tutorial che ti guida attraverso le basi di javascript dalla prospettiva di un gatto. Se sei un principiante, leggi questo. È divertente e insegna in un'ora quali libri richiedono settimane per comunicare.
• Blog di Nicholas Zakas Nicholas è l'autore di alcuni fantastici libri javascript: programmazione orientata agli oggetti in Javascript , Javascript gestibile , Javascript professionale per sviluppatori Web e Javascript ad alte prestazioni . Si concentra principalmente sul cliente, ma ha un sacco di buone pratiche e consigli sulle prestazioni.
• Blog di Guillermo Rauch - Guillermo è un altro sviluppatore node.js prolifico, famoso soprattutto per Socket.io e Mongoose. Il suo blog (e il suo nuovo libro, Smashing Node.js sono entrambe ottime risorse.

Sono sicuro che ci sono molte altre grandi risorse a cui non sto pensando o di cui non sono a conoscenza, che altri risponditori dovrebbero sentirsi liberi di aggiungere a tale elenco.

Ci sono vantaggi, ma è discutibile se superino davvero gli svantaggi.

Il principale è che risparmi la larghezza di banda e ottieni risposte più veloci. jQuery aggiunge un altro ~ 30kb alla tua risposta. Su alcune reti (e in alcuni paesi), ciò potrebbe significare qualche millisecondo in più. D'altra parte, però, puoi impostare la memorizzazione nella cache piuttosto facilmente usando il tuo server web (o come ha detto Xion, usalo dal sito di Google in modo che non abbia alcun impatto sul tuo, e sia comunque memorizzato nella cache).

La seconda cosa è che potresti aver bisogno solo di alcune funzionalità molto semplici, e solo il download e l'impostazione di jQuery potrebbero richiedere più tempo della semplice implementazione di ciò che ti serve.

E infine, potresti voler creare il tuo framework, che è principalmente una cattiva idea, ma alcune persone hanno le loro ragioni.

Se tuttavia scarti jQuery semplicemente perché sei intimidito dalla curva di apprendimento, allora dovresti riconsiderare. Soprattutto in quanto piuttosto delicato.

Per quanto ne so, ci sono solo due vantaggi nell'uso di javascript alla vaniglia rispetto a una libreria come JQuery , MooTools , ecc.

• Le librerie hanno un payload che consuma larghezza di banda. Ma come le persone hanno già indicato nelle altre risposte, puoi limitarlo con gzip e cache. Se vuoi solo un sottoinsieme di jQuery che puoi fare con SizzleJS e con MooTools hai la possibilità di selezionare i set di funzionalità che desideri allo stesso modo di Modernizr .
• Le biblioteche sono grandi e richiede un po 'di tempo per imparare. Poi di nuovo, questo è un investimento una tantum per gli sviluppatori ... ed è bello sul tuo curriculum conoscere le librerie javascript.
• (BONUS) Le biblioteche non sono un proiettile d'argento, quindi se ti piace reinventare la ruota, questa è sicuramente la strada da percorrere.

Vale la pena sottolineare perché vuoi usare una libreria javascript, per la quale ce ne sono molti:

• Non è necessario scrivere il proprio framework per supportare il proprio sviluppo. Se sei curioso di sapere come funzionano le cose, puoi controllare il codice poiché è open source.
• Le librerie risolvono la compatibilità del browser. Sia DOM che javascript presentano alcune differenze tra i browser. Fidati di me, questo è un enorme spreco di tempo se devi hackerare le correzioni da solo.
• È di fatto uno standard Internet per utilizzare le librerie javascript, la maggior parte di esse è ormai ben documentata e la maggior parte degli sviluppatori web (che conoscono javascript) sanno come usarle.
• Non rinunciare davvero a javascript quando si utilizza una libreria. Devi ancora conoscere Javascript con i suoi tipi, oggetti, come funzionano le chiusure , ecc.
• La maggior parte delle librerie sono modularizzate e non ci vuole molto tempo per scrivere plug-in o usare il modello di richiesta e AMD .
• La selezione di elementi CSS dal DOM è di grande aiuto.
• (BONUS) Puoi usarli anche con CoffeeScript .

Lavoravo in un negozio online che era irremovibile nell'uso di javascript alla vaniglia perché jQuery era grande e spaventoso. Questa decisione, influenzata principalmente da uno "sviluppatore javascript" solitario, è stata la fonte di molti bug del browser e lo sviluppo lento e cercare di entrare nella sua base di codice è stata un'esperienza strabiliante. Scrivere il proprio framework potrebbe sembrare una buona idea, ma se si desidera assumere nuovi sviluppatori, non possono rapidamente entrare e dare una mano. Quindi c'è anche il problema del fattore bus da considerare.

Come dicevo, lavoravo lì ... c'erano pascoli più verdi altrove. : ^)

Mi capita di mescolare un po 'l'uso di entrambi. Il motivo principale di ciò è che per alcune applicazioni (pensa alle estensioni di Chrome) non è necessario il supporto di più browser. Ciò significa che posso trarre vantaggio da nuovi progressi come css3 che con cose come le transizioni possono semplificare il tuo codice un sacco sull'uso di jquery.

Inoltre faccio spesso qualcosa di personalizzato. Certamente come gli altri hanno detto che non dovresti reinventare la ruota. Ma quando mi viene chiesto di fare alcune funzionalità folli, trovo spesso molto più facile scriverlo da solo, quindi provare a hackerare alcuni plugin jquery vicini ma non perfetti.

Ho anche lavorato con sviluppatori che lavorano solo con jquery. E devo dire che hanno compromesso la funzionalità molto più spesso, quindi non se non sono riusciti a trovare un plugin jquery che ha fatto quello che volevano.

Ad un certo punto nello sviluppo web ti verrà chiesto di fare qualcosa di non preconfezionato in una libreria. Quindi a quel punto è meglio assicurarsi di capire come funziona davvero la lingua di base.

Quindi TLDC : usa entrambi, sei in svantaggio usando solo la vaniglia e sei in svantaggio se non conosci la vaniglia dentro e fuori e insisti nell'usare sempre jquery.

L'unica cosa a cui riesco a pensare che non puoi fare a meno di JQuery sarebbe usare i plugin JQuery; anche allora, potresti scrivere la tua libreria JS che fornirà esattamente ciò di cui ha bisogno il plugin.

Pensaci in questo modo: JQuery è una libreria Javascript open source scritta in Javascript; puoi guardare la fonte e quindi imparare a fare tutto ciò che fa.

Non puoi usare JQuery senza usare il semplice Javascript vecchio. Probabilmente non userai document.getElementById, ma definirai comunque funzioni e variabili nei modi Javascript standard; potresti persino scrivere un forciclo standard .

Il vantaggio principale dell'uso di JQuery è praticamente lo stesso di qualsiasi altra libreria di terze parti in qualsiasi lingua: non dovrai scrivere più codice per implementare la logica specifica per la tua applicazione.

Non lasciarti spaventare dalle dimensioni. La versione CDN è un download di ~ 33k che verrà memorizzato nella cache dal browser dell'utente dopo l'hit della prima pagina.

Se sei preoccupato per le prestazioni, dovresti provare a usare vanilla js quando possibile. i framework non solo aggiungono un sovraccarico di larghezza di banda, ma anche un sovraccarico di elaborazione. E jQuery viene fornito con la compatibilità del browser anche per browser piuttosto vecchi.

se stai lavorando su app o giochi per dispositivi mobili (o entrambi combinati) devi prima avere prestazioni e risorse efficienti.

jQuery e plugin potrebbero accelerare il tuo sviluppo, ma soprattutto se fai affidamento su plugin jquery di terze parti dovresti sapere cosa stanno facendo all'interno. Molti di questi sono cattivi esempi di qualità ed efficienza del codice.

jQuery può essere da 2 a 10 volte più lento di JavaScript nativo. E può facilmente incoraggiare gli sviluppatori a non progettare correttamente la propria interfaccia e fare troppo affidamento sui selettori jQuery che sono molto più lenti di quelli nativi.