Share
Molti di noi hanno familiarità con la libreria JavaScript di jQuery e probabilmente lo usano in almeno alcuni dei nostri progetti. Ma quanto sappiamo delle persone che hanno instancabilmente dedicato il loro tempo a mantenere la libreria JavaScript più popolare del web? Recentemente ho avuto l'opportunità di intervistare il leader del team JQuery Core, Dave Methvin, e discutere di come è stato coinvolto nel progetto e dove ha visto lo sviluppo del front-end. È stato un collaboratore di jQuery dal 2006 ed è anche il presidente della jQuery Foundation.
Il successo di jQuery ci ha reso difficile cambiare qualcosa.
Ho iniziato la mia carriera come programmatore C a tempo pieno con sistemi embedded come navigazione navale, robotica, automazione industriale e telecomunicazioni. Successivamente, mi sono trasferito al giornalismo di computer e ho scritto una colonna JavaScript mentre ero su Windows Magazine. Quando WinMag ha chiuso i battenti, ho co-fondato una startup che ha creato un'utilità di sistema basata su JavaScript e HTML per Windows che ha automatizzato in modo automatico molti dei consigli che avevamo fornito nella rivista.
Quando ero alla partenza, stavo cercando un modo migliore per organizzare il codice JavaScript e HTML che stavamo scrivendo. Ho visto il post del blog di John Resig del 2005 che descrive cosa sarebbe diventato jQuery. Gli ho mandato una mail e lui ha risposto dicendo che stava preparando una mailing list per le persone interessate.
Così all'improvviso, c'è questo gruppo di persone di grande talento che parlano della biblioteca.
Molti di loro sono ancora con il progetto fino ad oggi. Questo è uno dei talenti poco conosciuti di John e una grande ragione per il successo iniziale di jQuery; è molto inclusivo e aperto ai suggerimenti di tutti.
Ho preso ufficialmente le redini di jQuery Core a luglio del 2011, anche se avevo lavorato un po 'su di esso prima di allora. Per quanto riguarda il perché? Penso che John stava cercando la sua prossima grande sfida, quella che sembra aver trovato alla Khan Academy.
Il successo di jQuery ci ha reso difficile modificare qualsiasi cosa, anche se è un cambiamento in meglio, come una correzione di bug o il miglioramento della coerenza dell'API. Poiché circa la metà di tutti i siti Internet utilizza jQuery, possiamo esserne certi qualunque il cambiamento che apportiamo alla biblioteca sarà un cambiamento decisivo per qualcuno. Anche se facciamo betas, la stragrande maggioranza degli utenti preferisce aspettare fino a che non sia definitiva prima di provare il nuovo codice, il che significa che spesso siamo ciechi quando si tratta di conoscere l'impatto di un cambiamento.
jQuery Core è una libreria per semplificare l'attraversamento, la manipolazione e il recupero di documenti HTML.
Quando jQuery arrivò nel 2006, gli sviluppatori web conoscevano le stranezze dei browser e erano felici di avere jQuery portarli al 90 percento per compatibilità cross-browser. Molti degli sviluppatori di oggi non hanno mai vissuto in quel mondo e sono sorpresi che jQuery non possa far sparire ogni piccola differenza tra i vari browser. Ma ci sono dei limiti su come possiamo risolvere i problemi del browser; gli sviluppatori devono capirlo. Molte volte, la soluzione utilizza una semplice correzione a livello di applicazione o per utilizzare un plug-in che affronta alcuni casi rari specifici.
I bug hanno la priorità se si tratta di una regressione, del loro impatto complessivo sulla comunità, della loro gravità e della complessità di una correzione. La maggior parte dei problemi di non regressione sono casi limite o bug del browser che sfuggono all'API jQuery. La nostra sfida è quella di risolvere questi problemi senza creare una massa di soluzioni alternative complesse che la maggior parte delle persone non ha bisogno e introducendo ulteriori bug nel processo.
Dal momento che jQuery rende facile mettere insieme alcuni effetti fantastici usando solo poche righe di codice e alcuni plugin jQuery di terze parti, è inevitabile che i non professionisti proveranno a utilizzarlo. A volte riescono e altre volte fanno un gran casino che qualcuno deve entrare e ripulire. Non vedo alcuna soluzione a quel "problema" oltre a rendere jQuery più ottuso, quindi solo i programmatori professionisti possono capirlo. Non succederà.
Anche se si estrapola IE 6/7/8, c'è molto codice in jQuery per appianare bug e incongruenze del browser. Ero un po 'depresso per vedere quante di quelle linee dovevano rimanere per jQuery 2.0. Sembra che tutti i produttori di browser siano troppo occupati a implementare nuove e brillanti funzionalità come il CSS3 per tornare indietro e correggere le funzionalità di base. E perché dovrebbero preoccuparsi di risolverlo, dal momento che jQuery lo risolve e quindi nessuno si lamenta loro?
I framework MV * sono dove le librerie DOM erano sei o sette anni fa quando jQuery arrivò sulla scena. C'è molta diversità nel loro approccio al design, che è una buona cosa. La maggior parte di questi framework è felice di consentire a jQuery di affrontare i problemi del DOM cross-browser in modo che possano concentrarsi su problemi di progettazione di applicazioni di livello superiore. Siamo decisamente complementari ai loro sforzi.
Mi piace scherzare sul fatto che "il core non viene eseguito finché l'interfaccia utente non verrà eseguita".
jQuery Core è una libreria per semplificare l'attraversamento, la manipolazione e il recupero di documenti HTML. A volte le persone vogliono spingere i limiti e chiedere perché non supportiamo SVG, VML o altre tecnologie webbish, ma è a questo che servono i plugin. Vogliamo mantenere l'API di jQuery focalizzata sulle operazioni DOM. Andando oltre a ciò nella libreria principale si aggiungerebbe un sacco di bloat di cui poche persone hanno bisogno.
jQuery Core ha la capacità di essere usato come un modulo con nome AMD e caricato dinamicamente. In generale, i moduli con nome sono disapprovati, ma così tanti plugin jQuery prevedono di condividere un oggetto jQuery globale. Non sono soddisfatto dello stato attuale del caricamento del modulo JavaScript e preferisco un semplice processo di combinazione e riduzione per la maggior parte del lavoro che svolgo. Tuttavia, AMD è abbastanza popolare che volevamo che jQuery Core lo supportasse in modo che gli utenti AMD possano caricare jQuery da un CDN, ad esempio.
Le soluzioni alternative per IE 6/7/8 rappresentano oltre il dieci percento delle dimensioni totali della libreria jQuery 1.9 e tali soluzioni hanno un impatto sulle prestazioni. Esistono molti luoghi in cui queste soluzioni alternative non sono necessarie, come app di Windows 8, plug-in di Chrome e Firefox, app PhoneGap / Cordova su una piattaforma mobile specifica o programmi node.js in cui una libreria come Cheerio viene utilizzata per caricare jQuery.
Questo è il pubblico principale per jQuery 2.0 al momento; la maggior parte dei siti Internet dovrebbe continuare a supportare le versioni precedenti di IE usando jQuery 1.9.
Ad esempio, non riesco a vedere i siti Web Target o Wal-Mart che utilizzano jQuery 2.0 per almeno alcuni anni; Anche gli utenti di IE8 hanno soldi! Poiché le due API sono sincronizzate, è possibile utilizzare i commenti condizionali per includere l'uno o l'altro per un browser specifico, ma per essere onesti, non penso che valga la pena.
Dal momento che l'interfaccia utente e l'interfaccia di jQuery dipendono da Core, li consultiamo sui problemi della roadmap dove necessario. Questi progetti eseguono anche i loro test unitari contro la nostra build più recente direttamente da Github in modo da sapere immediatamente se abbiamo rotto qualcosa. Tuttavia, mi piace scherzare sul fatto che "il core non è fatto fino a quando l'interfaccia utente non verrà eseguita" e di solito ci sono alcune anomalie che troviamo dopo ogni release. QUnit è un po 'diverso; noi siamo loro cliente. A volte chiediamo loro delle funzionalità e, occasionalmente, i loro aggiornamenti interrompono i nostri test unitari. Quindi abbiamo un assaggio della nostra stessa medicina.
Vediamo la conferenza jQuery come una raccolta per gli sviluppatori che creano siti web e applicazioni web. Alcuni di ciò che vogliono sapere riguarda jQuery, ma non vogliamo fermarci qui. Qualsiasi buon sviluppatore dovrebbe ampliare i propri orizzonti e continuare a imparare strumenti e tecniche che possono aiutarli a migliorare.
Le innovazioni provengono da tutte le direzioni. Le guerre del framework MV * probabilmente produrranno approcci molto migliori e più veloci per sviluppare app e siti web; senza dubbio vedremo qualche consolidamento lì, simile a quello che è successo con jQuery.
Il responsive design è un altro grande argomento, e spero che i miglioramenti nei CSS e nelle immagini reattive renderanno più semplice l'implementazione nel prossimo anno.
Sull'ultimo punto, jQuery sta lavorando con i gruppi di standard di W3C ed ECMA per garantire che gli sviluppatori web nelle trincee siano rappresentati quando prendono decisioni.
Accentsconagua