JavaScript vs librerie di terze parti

Il ruolo principale di jQuery è quello di normalizzare l'API DOM, che è l'unica cosa su cui i browser non sono d'accordo da più di un decennio (fino alla pubblicazione di IE9). È meglio pensato come uno strumento di una biblioteca. Fondamentalmente è solo una funzione di fabbrica che restituisce un adattatore unito a un po 'di decoratore che avvolge e normalizza l'API dell'oggetto DOM con molta riduzione di cruft e alcuni extra aggiuntivi come la funzione animate e un sistema di eventi che ti permette di sparare e ascoltare nuovi eventi al volo su qualsiasi oggetto senza nemmeno prima definirli da qualche parte.

Ciò che non fa è aiutarti a scrivere un codice orientato all'app più complesso e manutenibile (beh, la cosa dell'evento è pulita, ma abbastanza facile da fare fai-da-te), usa bene gli oggetti, o usa uno qualsiasi dei core ECMA spec osserva che in realtà costituiscono la base per il linguaggio di base di JavaScript.

Tra gli opportuni sviluppatori JavaScript, ci vuole pochissimo tempo per filtrare gli sviluppatori che saranno utili su un progetto da web designer o sviluppatori di CMS che mirano ad aumentare di stipendio facendo cose terribili con uno strumento che avrebbero piuttosto non capire sotto il cofano se possono evitarlo.

Inoltre, l'API DOM è piuttosto prolissa con nomi di metodi che praticamente scrivono la loro documentazione (avvicinandosi alla lunghezza del paragrafo in fondo), che è una buona cosa, IMO. Vogliamo che le cose core native siano ovvie e spiegate. Ma la noiosa natura della scrittura con esso ci incoraggia ad usare JavaScript per fare qualcosa che è molto bravo. Elimina cruft, normalizza e piega l'API a un paradigma che funziona meglio per noi. Personalmente ritengo che jQuery abbia fatto un lavoro sbalorditivo di questo rispetto alla maggior parte dei suoi contemporanei e che tu possa imparare molto su JavaScript (come come mantenere i tuoi oggetti davvero leggeri per quanto riguarda la memoria) studiando jQuery sotto il cofano.

Ma non lo userei come spazio dei nomi di libreria UI pre-fab. E non scarterei i loop a favore dell'uso di .each su tutto. E spesso passo indietro ai metodi API DOM quando JQuery aggiunge lavoro senza eliminare veramente cruft che fa apparire una delle funzionalità più importanti di jQuery a quelli di noi che sanno davvero cosa stiamo facendo. Non ti disturba quando non lo vuoi lì.

Ma non fare errori. Se non sai come farlo senza jQuery sei nel migliore dei casi uno sviluppatore entry-level di JavaScript / lato client. D'altra parte, se conosci solo JavaScript e hai solo una minima conoscenza dei CSS, è meglio concentrarti su qualcosa di diverso dai problemi dell'interfaccia utente.

Modifica: Mi rendo conto di concentrarmi su JQ un po 'troppo per una domanda che è stata posta più in generale.

La maggior parte degli altri popolari strumenti / librerie / framework JS sono o librerie UI, nessuna delle quali sono una grande fan (troppo rigida in genere) e framework di applicazione rapida che applicano concetti di MVC o modelli simili. Preferirei personalmente l'architettura DIY (e sono un po 'diffidente nei confronti di questo modello vincolante nella tendenza dei modelli) ma questi nuovi framework non sono il genere di cose implementate dagli sviluppatori JS che non possono gestire i problemi di codice che richiedono JS- stessi alfabetizzazione, scommetterei.

La maggior parte degli sviluppatori JavaScript utilizza un framework poiché JavaScript come linguaggio contiene un bel po 'di funzionalità cruft e altrimenti indesiderate. Ha alcune funzionalità davvero potenti ma ci sono anche molti modi per spararti ai piedi.

Ho utilizzato jQuery e YUI e il passato . Quando si utilizza una buona programmazione di JavaScript, la programmazione è un'esperienza decisamente più piacevole. In questi giorni tendo a preferire jQuery perché mi consente di scrivere codice funzionale molto pulito. jQuery si affida molto anche ai selettori CSS per l'interrogazione DOM, quindi è molto più naturale scrivere $('#some_element') che scrivere document.getElementById('some_element') .

Raccomando di leggere JavaScript: The Good Parts di Douglas Crockford per apprendere alcuni suggerimenti molto efficaci (e belli ) Programmazione Javascript. Questo libro non ti insegnerà come scrivere effetti JavaScript o magia AJAXy, ma ti insegnerà la lingua, su cosa fare affidamento e su cosa scappare urlando. È un libro abbastanza breve ma ti consiglio di leggerlo alcune volte.

Quando sviluppavamo in JavaScript dovevamo scrivere tre versioni della stessa funzione per far funzionare la funzione in IE, Safari e Firefox.

JQuery si prende cura di questo problema (non perfetto ma meglio di farlo da zero) e ti consente di concentrarti sulla funzione stessa.

Nel complesso, i framework Javascript risolvono i problemi di interazione del DOM. Il resto JS non ha nulla a che fare con il DOM.

Naturalmente, molti framework forniscono funzioni a JS che si comportano più come un normale linguaggio OO, ad esempio aggiungendo "classi" (uugh, ora la mia bocca ha un sapore sporco). Direi, impara JS per quello che è ed evita quella schifezza. Per me è come provare a programmare C ++ come linguaggio funzionale. Puoi farlo in qualche modo, ma è meglio imparare il C ++ così com'è.

JS ha più in comune con linguaggi come LISP o PROLOG di Java. La sintassi è simile a Java, che è fuorviante e i framework sono progettati per i principianti di PHP non così intelligenti. Quindi cercano di emulare un modello OOP obsoleto e orribile. E il codice che questi principianti producono è semplicemente scadente, brutto e difficile da modificare.

Ovviamente il modello OOP funziona molto bene sul lato server, ma è orribile per l'interfaccia utente lato client. JS ha un modello di programmazione completamente diverso, molto adatto per lo sviluppo dell'interfaccia utente (facile callback, eredità prototipale, incapsulamento super-facile, modello di oggetti molto pulito, ecc.)

jQuery ... è più facile da usare, ma è molto orribile. Con costrutti come parent (). Parent (). Parent () ... è progettato per "proteggerti" dal JS "reale" fornendo un orribile modello OOP simile a PHP. Ecco perché, probabilmente è così largamente adottato. Le persone non hanno tempo per imparare JS, quindi usano solo jQuery e fingono che sia Java o PHP.

instead jump right ahead with a library like JQuery ?

Stammi lontano. Non c'è codice peggiore in JS che codice scritto usando JQuery. Ovviamente se hai già usato Java, sembrerebbe "ok" per te. Ma non è vero. Puoi scrivere molto meglio, codice senza errori e modulare usando puro JS o mootools (perché sta estendendo JS piuttosto che sostituendo il suo modello a oggetti).

Usando quel BS che questi framework forniscono (come "classi") è come tornare da C ++ a C, solo perché non si può pensare oltre le semplici funzioni e le variabili globali. Quindi hai bisogno di qualcosa che "sminuisca" il linguaggio in modo da poter scrivere un codice molto scadente senza imparare nuove cose.

Le persone imparano in modo diverso.

== Approccio top down ==

Alcuni salti nella libreria e imparano come lavorare con la libreria e inevitabilmente imparano alcune delle caratteristiche di javascript o di lingua di base.

== Approccio bottom up ==

Ad altri piace conoscere i pezzi e poi come sono messi insieme per creare la libreria che stanno usando. A volte sentono che per essere più efficaci vorrebbero conoscere gli angoli di ciò che stanno usando e il linguaggio in cui è scritto.

L'approccio che prendi dipende in gran parte da te e dalla facilità con cui la biblioteca deve essere utilizzata. Se la libreria è difficile da utilizzare, gli utenti non la useranno o saranno costretti a fare un approccio bottom up.

Fortunatamente, javascript appare ingannevolmente simile a java e ad altri linguaggi in termini di sintassi che la maggior parte degli utenti ritiene di poter adottare un approccio top-down mentre si affidano alla loro lingua di riferimento per aiutare a determinare come funzionano le cose. Questo accade anche se, come affermato nei commenti, Javascript è molto diverso da Java e trae più ispirazione da LISP / Scheme che da Java.

L'approccio top down funziona piuttosto bene con javascript / jquery, ma l'inevitabile risultato è che l'utente finisce con una soluzione Java simile ai suoi problemi quando una semplice convenzione javascript sarebbe più facile da implementare. Questo è un inconveniente, ma solo fino a quando non si rendono conto che javascript può rendere più facili alcune attività. Fino ad allora, per l'utente, javascript diventa Java solo dal lato client.

Alla fine si imbattono in qualche strano bug o codice che non riescono a capire, come il modo in cui le chiusure funzionano, e devono scavare più in nel javascript di base che devono.

Non so quanta parte del codice lato client sia costruita con librerie di terze parti, ma so che possono rendere la vita molto più facile dal momento che non devi "reinventare la ruota". Gli uomini delle caverne lo hanno fatto un po 'di tempo fa quindi concentrati su altre cose se puoi. Se ti trovi in un ambiente limitato, potresti dover scrivere la tua libreria, ma basarla su una libreria di terze parti NON è una cattiva idea perché hanno pensato, affrontato e risolto più problemi di quelli che una persona potrebbe sperare di coprire nello stesso intervallo di tempo.