Ciao, e benvenuto nella nona puntata della ventiquattresima stagione. Nella prima puntata avevo detto che Node ha due grandi idee: il modello a non aspettare mai, che abbiamo esplorato a fondo, e JavaScript ovunque, che finora avevo solo accennato. Oggi dedichiamo tutta la puntata a questa seconda idea, perché è una delle ragioni principali della popolarità di Node e tocca da vicino il modo di lavorare di molti sviluppatori. È l'idea di poter usare un solo linguaggio, JavaScript, da un capo all'altro dell'applicazione, sia sul davanti sia sul dietro. Oggi capiamo cosa significa e perché conta, con onestà.
Ripartiamo dalla situazione prima di Node, per misurare il cambiamento. Come abbiamo detto, il mondo del software web era diviso in due mondi linguistici. Il davanti, ciò che gira nel browser e con cui l'utente interagisce, era territorio di JavaScript. Il dietro, il server che fa il lavoro pesante, era territorio di altri linguaggi. Uno sviluppatore che lavorava su entrambi i lati doveva conoscere due linguaggi diversi, con due modi di pensare, due insiemi di regole, e passare continuamente dall'uno all'altro nel corso della giornata. Era come dover parlare due lingue diverse a seconda della stanza in cui ti trovavi, con tutta la fatica del cambio continuo.
Con Node, all'improvviso, questo cambia radicalmente, ed è il cuore di questa idea. Siccome Node porta JavaScript sul server, ora puoi usare lo stesso identico linguaggio, JavaScript, su entrambi i lati: il davanti nel browser e il dietro sul server. Un solo linguaggio, dall'inizio alla fine, per tutta l'applicazione. Non più due mondi linguistici, ma uno solo, coerente, dal browser fino al server. Lo sviluppatore parla la stessa lingua in ogni stanza, senza dover cambiare continuamente. Questa unificazione linguistica, un solo linguaggio da un capo all'altro, è ciò che si intende con JavaScript ovunque, ed è stata una rivoluzione pratica per moltissimi.
Voglio farti apprezzare i vantaggi concreti di questa unificazione, perché sono reali e tangibili. Primo: c'è un solo linguaggio da imparare e padroneggiare, invece di due. Chi conosce bene JavaScript può lavorare su entrambi i lati, senza dover imparare un secondo linguaggio per il server. Questo abbassa la barriera e permette a più persone di lavorare su tutta l'applicazione. Secondo: si passa senza attrito dal davanti al dietro. Non c'è il costo mentale di cambiare linguaggio di continuo: lo sviluppatore resta nello stesso modo di pensare, nella stessa lingua, muovendosi fluidamente tra i due lati. Un solo linguaggio significa una mente più fluida, meno fatica di contesto.
C'è un terzo vantaggio, più sottile: la condivisione. Siccome i due lati parlano la stessa lingua, si possono condividere tra davanti e dietro pezzi di codice, conoscenze, e certe logiche che servono da entrambe le parti e che, con un solo linguaggio, scrivi una volta e usi su entrambi i lati, invece di riscriverle in due linguaggi. Questa condivisione riduce la duplicazione e rende più coerente l'applicazione: davanti e dietro non sono più due isole separate, ma un continuo, unito dalla lingua condivisa.
Questa unificazione favorisce anche il lavoro in team, e riprende un tema dell'Agile. Con un solo linguaggio da un capo all'altro, un gruppo può muoversi liberamente su tutta l'applicazione, senza rigide divisioni tra chi sa solo il davanti e chi sa solo il dietro. La stessa persona contribuisce a entrambi i lati, la conoscenza circola, il team è più coeso. È coerente con l'idea, vista nell'Agile, di team versatili invece che di specialisti rigidamente separati: un valore non solo tecnico ma anche organizzativo.
Ma voglio essere onesto, come sempre: un solo linguaggio ovunque non è automaticamente meglio. Usare lo stesso linguaggio dappertutto ha senso solo se è adatto a entrambi gli usi, e c'è chi sostiene che JavaScript, nato per il browser, non sia sempre la scelta migliore per il server, dove altri linguaggi potrebbero essere più adatti a certi compiti. La coerenza di un solo linguaggio è un vantaggio, ma non l'unico criterio: a volte lo strumento migliore per il dietro non è JavaScript, e insistere per comodità può portare a scelte non ottimali. È un compromesso: guadagni in coerenza, ma potresti perdere in adeguatezza.
Voglio chiudere con una prospettiva equilibrata. JavaScript ovunque è un vantaggio reale per moltissimi casi: la coerenza, la fluidità, la condivisione, la versatilità dei team spiegano gran parte del successo di Node. Ma non è una verità assoluta né sempre ottimale: è un compromesso che privilegia la coerenza, e conviene quando i suoi benefici superano il costo di non usare, magari, lo strumento più adatto per ogni lato. Capirne sia il valore sia i limiti ti permette di apprezzarlo dove conviene, senza trasformarlo in un dogma.
Per oggi ci fermiamo qui. La seconda grande idea di Node è JavaScript ovunque: poter usare un solo linguaggio, dal browser al server, da un capo all'altro dell'applicazione, superando la vecchia divisione in due mondi linguistici. I vantaggi sono reali: un solo linguaggio da imparare, il passaggio fluido tra i due lati, la condivisione di codice e conoscenza, team più versatili, coerente con lo spirito dell'Agile. Ma con onestà: un solo linguaggio ovunque non è automaticamente meglio, perché JavaScript non è sempre l'ideale per il server, ed è un compromesso che privilegia la coerenza. Un grande vantaggio, da usare con giudizio. Nella prossima e ultima puntata tiriamo le somme. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.