Quando inizi a programmare, prima o poi arriva la domanda:

“Quale framework dovrei imparare?”

React? Angular? Vue? Svelte?

E se lavori nel backend, magari NestJS, Django, Spring, Laravel.

Il problema è che questa domanda arriva spesso troppo presto. Prima di chiederti quale framework imparare, dovresti chiederti qualcosa di più importante:

Quanto sono solide le tue fondamenta?

Perché un framework può insegnarti come fare qualcosa, le fondamenta ti permettono di capire perché lo stai facendo.

Il framework è un’astrazione

I framework esistono per un motivo: risolvere problemi ricorrenti senza costringerci a reinventare ogni volta le stesse soluzioni.

Ti danno una struttura.

Ti forniscono convenzioni.

Gestiscono una parte della complessità.

Ti permettono di essere produttivo molto più velocemente.

Ed è proprio questo il loro punto di forza, ma c’è un rovescio della medaglia.

Più un framework nasconde la complessità, più è facile utilizzarlo senza comprenderla.

Puoi creare un componente senza sapere esattamente cosa succede nel browser.

Puoi fare una chiamata API senza conoscere davvero HTTP.

Puoi utilizzare un ORM senza capire come funziona una query SQL.

Puoi utilizzare un sistema di autenticazione senza comprendere fino in fondo cosa succede tra client, server, sessione e token.

Finché tutto funziona, non sembra esserci alcun problema. Il problema arriva quando smette di funzionare.

Quando il framework non basta

Immagina di avere un’applicazione Angular. Un componente non si aggiorna come dovrebbe. Il framework ti mette a disposizione tutti gli strumenti per costruire l’interfaccia, ma non può sostituire la tua capacità di ragionare sul problema.

Devi chiederti:

Cosa è cambiato?

Da dove arriva quel dato?

Quando viene eseguito questo codice?

Il browser cosa sta facendo?

Il problema è nel componente, nello stato, nella richiesta HTTP o nei dati?

Sono domande che vanno oltre il framework. E per rispondere devi conoscere ciò che il framework sta cercando di semplificarti. Questa è una delle differenze tra saper utilizzare uno strumento e saperlo utilizzare consapevolmente.

Le fondamenta sono ciò che rimane

I framework cambiano. Le fondamenta molto meno.

Oggi puoi lavorare con un framework JavaScript e tra qualche anno con un altro.

Puoi cambiare ORM.

Puoi cambiare database.

Puoi cambiare architettura.

Puoi persino cambiare linguaggio.

Ma alcuni concetti continueranno a seguirti:

• Variabili e strutture dati
• Funzioni
• Asincronicità
• HTTP
• Database
  • Networking
• Gestione degli errori
• Debugging
• Algoritmi
• Architettura del software
• Git
• Testing

Non sono necessariamente le cose più “sexy” da imparare, ma sono quelle che ti permettono di trasferire le tue conoscenze da una tecnologia all’altra ed è proprio questa capacità che rende un developer più autonomo.

Conoscere un framework non significa saper programmare

Questa è una distinzione importante.

Puoi essere molto bravo a utilizzare un framework e avere comunque delle lacune nella programmazione. Per esempio, potresti sapere perfettamente come creare un componente, collegarlo a un servizio e visualizzare dei dati, ma se ti chiedessi di spiegare cosa succede realmente quando quel componente viene aggiornato, sapresti farlo? Non perché dovresti necessariamente conoscere ogni dettaglio interno del framework, ma perché dovresti avere abbastanza basi da costruire un modello mentale di ciò che sta succedendo.

Un developer che conosce soltanto la procedura rischia di essere efficace finché il problema rientra nei casi già conosciuti. Un developer che conosce il concetto può invece adattarsi.

Il problema non è il framework. È la dipendenza dal framework.

Un framework non è qualcosa da evitare. Anzi, sarebbe assurdo rinunciare a strumenti che ci permettono di lavorare meglio e più velocemente. Il problema nasce quando non riusciamo più a ragionare al di fuori dello strumento.

“Con React so fare questo.”

“Con Angular devo fare quest’altro.”

“Con questa libreria basta chiamare questa funzione.”

Il rischio è iniziare a vedere il problema attraverso il framework invece di vedere il framework come uno strumento per risolvere il problema.

La direzione dovrebbe essere l’opposto:

Prima capisco il problema, poi utilizzo lo strumento più adatto per risolverlo.

Le fondamenta rendono più facile imparare il prossimo framework

C’è un’altra conseguenza interessante.

Più solide sono le tue fondamenta, meno traumatico diventa cambiare tecnologia. Quando passi da un framework all’altro, infatti, molti concetti non sono completamente nuovi.

Cambiano i nomi.

Cambiano le API.

Cambiano le convenzioni.

Cambiano i dettagli implementativi, ma i problemi che stai cercando di risolvere spesso rimangono gli stessi.

Componenti, routing, stato, richieste HTTP, dependency injection, gestione degli errori, persistenza dei dati, testing ecc….

Una volta che hai compreso il concetto, devi solo capire come quel framework lo implementa. Ed è molto più semplice che imparare tutto da zero.

Il developer non è il suo stack

C’è un’altra trappola in cui è facile cadere, ovvero identificarsi completamente con il proprio stack.

“Sono un developer Angular.”

“Sono un developer React.”

“Sono un developer Node.js.”

Lo stack è importante, ma non dovrebbe diventare la definizione della tua professionalità. Se domani Angular sparisse, le tue competenze dovrebbero avere ancora valore. Se una libreria venisse abbandonata, dovresti poter imparare la sua alternativa. Se un’azienda cambiasse stack, non dovresti sentirti costretto a ricominciare da zero perché il tuo valore non dovrebbe essere legato esclusivamente allo strumento che utilizzi. Dovrebbe essere legato alla tua capacità di capire problemi, progettare soluzioni e imparare nuovi strumenti.

Quindi cosa dovresti studiare?

La risposta dipende dal tuo livello.

Se sei agli inizi, dedica molto tempo alle fondamenta.

Impara bene il linguaggio, capisci come funziona il browser, studia HTTP e le API RESTful, impara a utilizzare Git, fai pratica con il debugging, capisci come funzionano i database.

Poi scegli un framework e costruisci qualcosa di reale.

Non devi aspettare di conoscere tutto prima di iniziare (vedi Come imparare una nuova tecnologia in pochi giorni). Il framework ti servirà proprio per mettere in pratica quello che hai imparato. E quando incontri qualcosa che non capisci, fai un passo indietro. Non limitarti a cercare come risolverlo.

Chiediti:

“Cosa sta succedendo realmente?”

La vera differenza

Un developer che conosce un framework sa utilizzare uno strumento.

Un developer con solide fondamenta sa adattarsi agli strumenti.

Il primo può essere molto produttivo, il secondo può continuare a esserlo anche quando lo strumento cambia. Ed è probabilmente questa la competenza più importante da costruire nel lungo periodo.

Perché i framework continueranno a nascere. Alcuni diventeranno popolari, altri scompariranno. Le mode cambieranno, ma HTTP continuerà a essere HTTP. Un database continuerà ad avere determinati problemi. Il codice continuerà ad avere bug. E qualcuno dovrà continuare a capire perché le cose non funzionano.

Quindi, quando ti trovi davanti alla scelta tra imparare l’ennesimo framework o rafforzare una tua lacuna fondamentale, ricordati:

Il framework ti permette di costruire più velocemente.

Le fondamenta ti permettono di capire cosa stai costruendo.

E un buon developer ha bisogno di entrambe.