div - wrapall javascript




Quali sono alcuni motivi tecnici empirici per non usare jQuery? (7)

Contesto: Sono sbalordito dal numero di sviluppatori front-end che hackerano HTML, Javascript e CSS tutto il giorno e ignorano strumenti come jQuery ( o altri framework helper equivalenti ) e si rifiutano di usarli. Non sto parlando di guru JavaScript, sto parlando in trincea ogni giorno degli sviluppatori di produzione Joe. Ho un sacco di argomenti che sono più come scuse o opinioni personali che non credo abbiano alcun valore tecnico, voglio essere sicuro che non mi manchi qualcosa.

Domanda: quali sono alcuni motivi tecnici empirici per non utilizzare jQuery?

Non sto cercando argomenti religiosi o dogmatici o opinioni soggettive "come qualche altra struttura è meglio", considera jQuery l'uomo di paglia per tutti i quadri comparabili nella domanda.


Aggiornamento 2015:

In questa risposta del 2011 sto parlando di librerie come jQuery, YUI o Prototype. Oggi nel 2015 questo ragionamento è ancora applicabile a strutture come Angular, React o Ember. In quei 4 anni la tecnologia è progredita enormemente e anche se vedo considerevolmente meno pregiudizi nei confronti di React o Angular di quanto ho visto contro jQuery o YUI, lo stesso tipo di pensiero - anche se in misura minore - è ancora presente oggi.

Aggiornamento 2016:

Consiglio vivamente un articolo pubblicato pochi giorni fa:

  • Perché jQuery? di Michael S. Mikowski, autore del libro Applicazioni Web a pagina singola

Quell'articolo è fondamentalmente una risposta molto dettagliata a questa stessa domanda. Se fosse stato disponibile quando stavo scrivendo la risposta qui sotto, l'avrei sicuramente citata.

Risposta originale:

Risponderò a jQuery, ma sono gli stessi argomenti con cui ho sentito di non usare YUI, Prototype, Dojo, Ext e pochi altri. Argomenti principali che ho sentito:

  1. dimensione del file , che in effetti è 84,6 KB in caso di jQuery 3.2.1 - probabilmente più piccolo del logo su un sito web medio e può essere servito dal CDN di Google che probabilmente si trova già nella cache della maggior parte dei visitatori. Siccome usare jQuery significa sempre una dimensione file più piccola dei tuoi file JavaScript, può effettivamente significare un download più piccolo , anche se non già nella cache del browser.

  2. velocità - la scrittura di JavaScript puro può essere più veloce, ma la scrittura di JavaScript portatile sembra impossibile per la maggior parte delle persone. Un sito Web che è più veloce ma non funziona su tutti i browser più diffusi è inutile nel mondo reale. Inoltre jQuery utilizza alcune ottimizzazioni piuttosto pesanti per essere effettivamente dannatamente veloce e continua ad essere ancora più veloce con ogni versione, quindi non è davvero così facile scrivere codice più veloce a mano per scopi diversi da semplici esempi. (*)

  3. "proprietà intellettuale" - un'azienda ha paura di usare il codice di qualcun altro - mentre in realtà jQuery è open source e software libero che viene utilizzato ovunque dal blog di tua nonna ad Amazon, da Twitter a Bank of America, da Google a Microsoft - se possono usalo allora qualsiasi azienda può usarlo.

  4. Non ricordo di aver ascoltato seriamente altre argomentazioni.

(*) Ecco un esempio banale: getElementById ('someid') vs. jQuery ('# someid')

Sta usando getElementById più velocemente? Sì. E ovviamente tutti controllano sempre il parentNode da catturare quando Blackberry 4.6 restituisce nodi che non sono più nel documento, giusto? jQuery fa. E ognuno gestisce il caso in cui IE e Opera restituiscono gli articoli per nome anziché per ID, giusto? jQuery fa. Se non lo fai, il tuo codice non è portatile e introduci bug sottili che possono essere molto difficili da trovare. E getElementById è l'esempio più banale che si possa trovare - non farmi nemmeno iniziare sugli eventi e AJAX e il DOM ...

Aggiornare:

In realtà c'è un quarto risultato nel chiedere perché qualcuno non voglia usare jQuery. Ho dimenticato di inserirlo in questa lista perché non è davvero una risposta, ma piuttosto la mancanza di una risposta. Il comment ho ricevuto ieri mi ha ricordato. Questa non è una "ragione tecnica" da aggiungere alla lista, ma può essere comunque interessante e potrebbe essere la reazione più comune.

Quello che personalmente sospetto sia la ragione principale alla base di tutte queste reazioni, però, è quello che ritengo sia il più grande ostacolo al progresso in informatica: "Non voglio usarlo perché non l'ho mai fatto, quindi deve non essere così importante. "

È stata una volta la reazione all'ottimizzazione di assemblatori, compilatori, programmazione strutturata, linguaggi di livello superiore, garbage collection, programmazione orientata agli oggetti, chiusure o praticamente tutto ciò che ora diamo per scontato - e oggi sono le librerie AJAX. Forse un giorno nessuno ricorderà che una volta usavamo interagire manualmente con l'API DOM grezza a livello di applicazione come ora nessuno ricorda che una volta usavamo scrivere programmi usando numeri esadecimali grezzi, non decritti, imperscrutabili .


Con tutti i mezzi, mi piace jQuery, ma ci sono alcuni motivi per non usare jQuery:

  1. Dimensione download / larghezza di banda: jQuery 1.5 ora è oltre 200K non compressi, poiché alcune delle dimensioni della libreria sono eccessive per giustificare il vantaggio.
  2. Prestazioni: la scrittura di JS nativo sarà sempre più veloce dell'abstract di una libreria.
  3. Complessità aggiunta: molte persone scaricheranno l'intera libreria jQuery quando in realtà hanno solo bisogno di alcune semplici funzionalità.
  4. Dipendenze dell'applicazione: l'introduzione delle dipendenze ha sempre i suoi blocchi. Se c'è un bug in jQuery, puoi eseguire il debug e modificare il file, ma l'aggiornamento successivo introduce problemi. Puoi lasciare il bug, ma ora sei dipendente dall'orario di jQuery per una correzione, non la tua.

Perché spesso non è necessario. se tutto ciò che voglio è convalidare qualche input, o hilight di un campo allora è altrettanto semplice scrivere codice javascript / dom semplice. E jQuery non aiuta molto in casi così semplici, quindi la domanda dovrebbe essere: perché usarla?

Chiaramente ci sono molti casi in cui è molto utile, ma a volte le persone sembrano usarlo senza una vera ragione.


Preferirei usare jquery per dom manipulation o attraversare il dom, che è veramente facile con jquery. Inoltre, allegando un evento o una delega di eventi è così semplice utilizzare jquery o altri framework altrimenti è necessario scrivere allegati di eventi personalizzati per browser IE o non IE, ecc.

Ma ha qualche penalizzazione delle prestazioni quando usi $ .each invece di vanilla JS for e array.push () ... altri problemi come se tu leghi un evento e rimuova quello senza distenderlo avrà perdita di memoria ....

La mia conclusione è solo utilizzare qualsiasi framework per dom manipolazione complessa e il resto usa vanilla JS


filesize - ma in realtà, al di là di questo, è un dio-invio assoluto per le differenze tra javascript e browser multipiattaforma. Dovresti avere dei buoni motivi per non volerlo nel tuo toolkit (o essere un idiota di sviluppatori fondamentalisti).


jQuery esprime tutto in un paradigma DOM-centrico che può essere fuorviante e non richiede alcuna necessità di esprimere le cose in un modello di applicazione.

Molti sviluppatori finiscono per programmare se stessi in un angolo con questo modello DOM-centrico e alla fine si rendono conto che non hanno creato nulla di estensibile o riutilizzabile.

Rebecca Murphey ha una bellissima recensione del suo passaggio a Dojo da jQuery - il post sul blog è più sul perché non jQuery contro perché Dojo.


  • Per codificare effettivamente tutto e saperne di più. (Piuttosto che usare materiale precodificato)
  • jQuery ha tonnellate di funzionalità che potrebbero non essere necessarie, perché l'utente può scaricare così tanti codici se non verrà utilizzato?
  • Mettiti alla prova? Posso battere jQuery, o almeno, posso sopravvivere con un semplice codice di vaniglia?
  • Flessibilità: Altho jQuery è davvero flessibile ... potresti aver bisogno di qualcosa che non fornisce ...






frameworks