Grazie alla qualità proposta dai framework/librerie Javascript di prima e seconda generazione ed alla loro capacità di semplificare la vita allo sviluppatore, moltissimi sviluppatori si avvicinano al linguaggio di scripting in maniera inversa, avvicinandosi prima ai framework e successivamente alle basi del linguaggio. E' un approccio corretto oppure è meglio partire dal cosiddetto "VanillaJS"?
Personalmente vedo questa realtà diffondersi ogni giorno di più. Studenti delle superiori, universitari e neo-sviluppatori, vivendo in un ambiente che offre sempre più comodità in ogni ambito, sono sempre più vicini all'utilizzo di framework e librerie (non solo relativamente a Javascript) rispetto allo studio completo del linguaggio core.
In una scuola superiore della mia provincia, ad esempio, Bootstrap è argomento di studio del programma annuale di informatica, ma l'HTML, i CSS e lo stesso Javascript vengono relegati ad argomenti "minori".
Essendo amante del core, e dell'apprendimento in parabola ascendente, sono sicuramente a favore della comprensione totale di un linguaggio, prima di passare a componenti sviluppati a partire dal linguaggio stesso, che sono certamente essenziali, ma non devono a mio avviso bypassare le radici della programmazione. In questo contesto, vengono identificate con il termine "VanillaJS".
Per chiarezza, VanillaJS è un nome che si riferisce all'uso del Javascript senza l'ausilio di librerie addizionali. E' come una sorta di "sfottò" ironico per ricordare agli sviluppatori che parecchie delle cose che si ottengono via libreria, sono ottenibili perfettamente tramite il Javascript nativo. Eppure "dove si trova il framwork VanillaJs?" è una domanda che ha tenuto (e che ancora tiene) banco.
In passato gli sviluppatori necessitavano di bypassare il Javascript plain per realizzare diverse feature, prima tra tutte, la compatibilità cross-browser (Internet Explorer ha dato una spinta essenziale) o semplicemente controlli che andavano oltre quello che era nativamente offerto dal linguaggio: i giorni di IE 6 (e 7) insomma. Tuttavia, anche a quel tempo, i framework che l'hanno fatta da padrone, sono stati realizzati con il Javascript plain, che dunque, almeno in potenza, offriva già gli strumenti ideali per andare ben oltre quello che si poteva pensare.
Tuttavia questo era possibile unicamente tramite una conoscenza davvero profonda del Javascript stesso, oltre che attraverso un talento nello scripting ed allo studio di pattern e metodologie vincenti.
Ora invece, le cose sono cambiate, in meglio. Con l'evoluzione delle specifiche ECMAScript, e con la standardizzazione sempre maggiore dei principali browser, ciò che prima diventava un compito tedioso senza avvalersi di un framework professionale, diventa ora non solo possibile, ma anche piuttosto facile.
Scegliere l'opzione VanillaJs al posto di nomi quali jQuery, diventa oggi in molti casi una scelta ottimale, non solo perché gli script non diventano più completamente dipendenti da fonti esterne, ma anche perché il "muscolo mentale dello scripting" viene stimolato più proficuamente e più piacevolmente. Vediamo un semplicissimo esempio che confronta i 2 approcci.
Usando jQuery:
$('.my #awesome selector');Usando Javascript nativo:
document.querySelectorAll('.my #awesome selector');Senza contare che è possibile crearsi la propria libreria minimale, per massimizzare performance e velocità di scrittura di codice.
Studiare il Javascript nativo con tutte le nuove specifiche ECMA è a mio avviso la scelta migliore se ci si vuole avvicinare al mondo dello scripting front-end utilizzando questo linguaggio, perché è il processo naturale attraverso il quale nascono i framework stessi. Ma anche nel caso di sviluppatori esperti ed affermati, che hanno fatto largo uso delle librerie, iniziare a dare il giusto peso anche al "Vanilla" è una scelta a dir poco vincente, sia per i motivi elencati in precedenza, sia per rendere onore alle specifiche ECMA ed agli standard annessi, sfruttando la loro massima potenza.