Quali sono le ragioni tecniche empiriche per non utilizzare jQuery?

Context: Sono sorpreso dal numero di sviluppatori di front-end che hackeranno HTML, Javascript e CSS tutto il giorno e che ignorano strumenti come jQuery ( o altri frameworks di supporto equivalenti ) e rifiutano di utilizzarli. Non sto parlando di gurus JavaScript, sto parlando nelle trincee each giorno Joe sviluppatori di produzione. Ho molti argomenti che sono più come scuse o opinioni personali che non credo siano dotate di un merito tecnico, voglio assicurarmi che non manchi qualcosa.

Domanda: Quali sono le ragioni tecniche empiriche per non utilizzare jQuery?

Non sto cercando argomenti religiosi o dogmatici o opinioni soggettive "come un altro quadro è migliore", considerate l'uomo paglia per tutti i frameworks comparabili nella domanda.

Aggiornamento 2015:

In questa risposta dal 2011 sto parlando di librerie come jQuery, YUI o Prototype. Oggi nel 2015 questo ragionamento è ancora applicabile a frameworks come Angular, React o Ember. In quei 4 anni la tecnologia ha progredito tremendamente e anche se vedo notevolmente less pregiudizio contro React o Angular rispetto a quanto vedo contro jQuery o YUI, lo stesso tipo di pensiero, anche se in misura minore, è ancora presente.

Aggiornamento 2016:

Raccommand vivamente un articolo pubblicato pochi giorni fa:

  • Perché jQuery? di Michael S. Mikowski, autore del libro delle singole pagine web

Questo articolo è fondamentalmente una risposta molto dettagliata a questa stessa domanda. Se fosse stato disponibile quando stavo scrivendo la risposta qui sotto – avrei sicuramente citato.

Risposta originale:

Risponderò a jQuery ma questi sono gli stessi argomenti che ho sentito contro l'utilizzo di YUI, Prototype, Dojo, Ext e pochi altri. I principali argomenti che ho sentito:

  1. la dimensione del file , che in realtà è di 84,6 KB in caso di jQuery 3.2.1 – probabilmente più piccolo del logo su un sito web medio e può essere servito da CDN di Google che è probabilmente già nella cache della maggior parte dei tuoi visitatori. Come utilizzare jQuery significa sempre size minori di file dei tuoi file JavaScript, può significare un download più piccolo , anche se non già nella cache del browser.

  2. velocità – la scrittura JavaScript pura può essere più veloce, ma la scrittura di JavaScript porttile sembra imansible per la maggior parte delle persone. Un sito web più veloce ma non funziona su each browser popolare è inutile nel mondo reale. Oltre a jQuery utilizza alcune ottimizzazioni piuttosto pesanti per essere davvero dannatamente veloce e continua ad get sempre più veloci con each rilascio, quindi è in realtà non è così facile scrivere codice più veloce a mano per qualsiasi cosa diversa da esempi banali.

  3. "properties; intellettuale" – una società è spaventata usando il codice di qualcun altro – mentre in realtà jQuery è software open source e libero che viene utilizzato ovunque dal tuo blog di nonna a Amazon, da Twitter a Bank of America, da Google a Microsoft – se possono utilizzarlo quindi qualsiasi azienda può utilizzarlo.

  4. Non riesco a ricordare di sentire qualsiasi altra argomentazione essere utilizzata seriamente.

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

Utilizza getElementById più veloce? Sì. E ovviamente tutti controllano sempre il codice di parentNeto da catturare quando Blackberry 4.6 restituisce nodes che non sono più nel documento, giusto? jQuery fa. E ognuno gestisce il caso in cui IE e Opera restituiscono elementi per nome anziché ID, giusto? jQuery fa. Se non lo fai allora il tuo codice non è porttile e introducete sottili bug che possono essere molto difficili da trovare. E getElementById è l'esempio più banale che si potrebbe trovare – non mi fanno nemless iniziare gli events e AJAX e il DOM …

Aggiornare:

Esiste in realtà un quarto risultato di chiedere perché qualcuno non vuole usare jQuery. Ho dimenticato di metterlo in questa list perché non è una risposta, ma piuttosto la mancanza di una risposta. Il commento che ho ricevuto ieri mi ha ricordato. Questo non è un "motivo tecnico" da aggiungere all'elenco, ma può essere interessante e comunque può essere la reazione più comune.

Quello che personalmente sospetto di essere il principale motivo sottostante a tutte queste reazioni, però, è quello che credo di essere il più big ostacolo al progresso nella scienza informatica: "Non voglio usarlo perché non ho mai fatto, pertanto è necessario non essere così importnte. "

Una volta è stata la reazione per ottimizzare gli assemblatori, i compilatori, la programmazione strutturata, i linguaggi di livello superiore, la raccolta di rifiuti, la programmazione orientata agli oggetti, le chiusure o quasi tutto ciò che ora prendiamo per scontato – e oggi sono le librerie AJAX. Forse un giorno nessuno ricorderà che una volta abbiamo usato per interagire manualmente con l'API DOM grezzo sul livello di applicazione come ora nessuno ricorda che una volta abbiamo usato per scrivere i programmi utilizzando numbers esadecimali grezzi, inadeguati e inesplorabili .

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

Molti sviluppatori finiscono per programmare se stessi in un angolo con questo model DOM-centric e finalmente si rendono conto che non hanno creato nulla extensible o riutilizzabile.

Rebecca Murphey ha una grande scrittura del suo proprio interruttore a Dojo da jQuery – il post sul blog è più su perchè non jQuery rispetto a perché Dojo.

Un motivo per non utilizzare un framework – e questo è un caso estremo – è quando scrivi un codice embeddable per un altro sito web, ad esempio un banner. Inserendo arbitrariamente una libreria complicata o un'altra potrebbe inquinare lo spazio dei nomi e potenzialmente rompere il sito di qualcun altro. Non che non avrei dovuto metterlo davanti ad alcuni inserzionisti per provare comunque, lo stormo di tuffo di stagno, ma devo digerire …

Non ho l'approvazione di aggiungere un quadro quando uno è già presente e altrettanto abile. Lo vedo troppo spesso ed è il mio odio per l'animale, lo vedo come gonfio ingiustificato. Questa è un'altra domanda interamente.

A parte questo non posso pensare a una ragione giustificata.

fileize – ma in realtà, al di là di ciò, è un dio-submit assoluto per le diverse piattaforms di javascript e browser. Dovresti avere buone ragioni per non volerlo nel tuo toolkit (o essere idiota dello sviluppatore fondamentalist).

  • Non possono giustificare il file system (anche se è probabilmente less dello script che non utilizza le astrazioni fornite).
  • Non vogliono fare affidamento su strumenti di terze parti.
  • La loro attività non vuole eseguire alcuna biblioteca (per qualunque motivo).
  • La loro attività non vuole eseguire alcun codice JavaScript scritto dai loro dipendenti.
  • Effettivamente codificare tutto e saperne di più. (Piuttosto che utilizzare roba precodita)
  • jQuery ha tonnellate di funzionalità che potrebbero non essere necessarie, perché far sì che l'utente scarica tanti codici se non verrà utilizzato?
  • Mettiti alla prova? Posso battere jQuery, o alless, posso sopravvivere con un semplice codice vanigliato?
  • Flessibilità: Altho jQuery è davvero flessibile … potrebbe essere necessario qualcosa che non fornisce …

In each modo, mi piace jQuery, ma ci sono alcuni motivi per non utilizzare jQuery:

  1. Scarica la dimensione / la width di banda: jQuery 1.5 è ora oltre 200K non compresso, perché alcune delle size della libreria sono troppo per giustificare il beneficio.
  2. Prestazione: la scrittura di JS native sarà sempre più veloce di astrazione dietro una libreria.
  3. Aggiunta complessità: Molte persone scaricheranno l'intera libreria di jQuery quando in realtà hanno solo bisogno di alcune caratteristiche pulite da esso.
  4. Dipendenze delle applicazioni: L'introduzione delle dependencies ha sempre i suoi limiti. Se c'è un errore in jQuery, è ansible eseguire il debug e modificare il file, ma l'aggiornamento in seguito presenta dei problemi. Potresti lasciare il bug, ma ora sei dipendente dalla tabella di tempo di jQuery per una correzione, non il tuo.

Perché spesso è solo inutile. se tutto quello che voglio fare è validationre un po 'di input, o un po' di field, allora è altrettanto facile scrivere semplici codice javascript / dom. E jQuery non aiuta davvero in casi così semplici, quindi la domanda dovrebbe essere perché usarlo?

Chiaramente ci sono molti casi in cui è molto utile, ma a volte la gente sembra usarlo per nessun motivo reale troppo.

Preferirei utilizzare jquery per la manipolazione di dom o attraversare la dom, che è veramente facile con jquery. Inoltre, l'attaccamento di una delegazione di events o events è così facile utilizzando jquery o altri framework altrimenti è necessario scrivere l'allegato di events personalizzati per IE o browser IE, ecc.

Ma ha una penalità di performance quando si utilizza $ .each invece di vanilla JS per e arrays.push () … altre questioni come se si lega un evento e rimuove che senza dissolvenza avrà perdita di memory ….

La mia conclusione è solo utilizzare qualsiasi quadro per la manipolazione complessa dom e il resto utilizzare la vaniglia JS

Perché non utilizzare jQuery?

Non riesco a pensare a una buona scusa per utilizzare JavaScript vanilla su jQuery (a parte il fattore di intimidazione di apprendere qualcosa di nuovo), ma alcune persone preferiscono altri framework JavaScript (come gli eccellenti MooTools ) a causa delle differenze filosofiche tra di loro.

Alcune persone semplicemente non amano la syntax DSL- jQuery, ma riconoscono l'importnza di utilizzare un robusto framework JavaScript.

Personalmente, amo jQuery, ma conosco persone che utilizzano altri frameworks e non sono less produttivi.