Frontend e React: lo sviluppo è hype driven
Forse la dobbiamo smettere di saltare su tutti i treni
Negli ultimi anni, il mondo frontend — e in particolare mi riferisco all’ecosistema React — è stato travolto da un’ondata continua di metaframework. Spinti dall’entusiasmo di tech influencer e community, questi strumenti conquistano rapidamente visibilità e proseliti. Ma dietro questo fermento si nasconde un problema culturale e tecnico che merita attenzione.
Solo un anno fa, mi trovavo a comparare due metaframework: Next.js e Remix. Ricordo ancora con che faccia avrei dovuto dire che no, non avrei scelto né l’uno né l’altro: troppo immaturi.
Ero bombardato da informazioni: tutte le fonti e qualsiasi nuovo spunto, invece di chiarirmi le idee e aiutarmi a vedere le cose da prospettive diverse mi confondeva terribilmente.
Ero davanti a due software che facevano più o meno le stesse cose ma la maggior parte delle funzionalità accessorie seppur interessanti… non mi servivano ad una ceppa. Ero tentato da Remix (oggi sostanzialmente React Router 7 per motivi più squisitamente commerciali), ma temevo di fare una scelta incauta, vista la giovane età del framework. Così sono rimasto attendista affinché la situazione "maturasse un po'".
Nel frattempo, in attesa di questa maturazione (che tutto sommato è avvenuta*), nel mondo React ci sono ora quattro metaframework (sì, sì memate pure voi del backend):
Next.js → è il primo (con l’accezione negativa del termine, tipo quando mia sorella più piccola lo usa con mia madre per riferirsi a me quando faccio una stupidaggine: - poverino, è il primo... -). Amicissimi del core team di React, sono stati i primi ad integrare i RSC (React Server Components) e li spacciano come la panacea di tutti i mali. Da quando sono usciti nessuno è ancora stato capace di dargli una definizione chiara: non c'è riuscito il core team di React, ci ha provato Ben Holmes, ci sta provando Dan Abramov, non l'ha ancora capito Mark Erikson 😅.
Remix/React router 7 → progressive enhancement e pragmatismo. Fanno SSR, senza RSC.
TanStack Start → “sentite, sticazzi dei RSC, io voglio fare applicazioni altamente dinamiche CSR first e me ne frega zero del progressive enhancement”.
Waku → “abbiamo i RSC!”.
Gatsby → “Sono morto! 💀”
Hype, FOMO e drama
Il frontend, a differenza di altri stack, viaggia a una velocità di aggiornamento molto diversa. È fisiologico: se devi migliorare l’esperienza utente, il primo impatto è il frontend e devi stare al passo se vuoi restare competitivo e offrire il massimo.
Ma non credo sia solo questo.
Come detto all'inizio, esiste una cerchia di tech influencer abbastanza popolari che alimenta hype e video dopo video ti convincono che quel framework è interessante, utile, indispensabile. Si instilla quell’urgenza di doverlo imparare e successivamente ti convinci che devi assolutamente usarlo in produzione. Sarà poi quella FOMO a spingere sviluppatori e team a saltare da una tecnologia all’altra.
Ad amplificare il tutto ci sono conferenze, talk, infinite e faziose discussioni su Twitter e drammi perfino.
Componenti molto umane e alle volte irrazionali che portano a quell’attaccamento quasi affettivo (ma anche alla disaffezione, per contro) verso un determinato brand o un framework.
Tutto molto bello, ma anche pericoloso.
Le scelte dettate da un marketing ossessivo o da simpatie personali verso figure di settore rischiano di diventare debito tecnico il giorno dopo.
Addio standardizzazione
La proliferazione di tutti questi (meta)framework ha portato anche a un altro effetto collaterale: l’assenza di standard condivisi.
E questo genera due problemi:
Per il developer: oggi sviluppi in Remix, domani ti chiedono TanStack Start e ti accorgi che fare SSR è completamente diverso. E quei 3 anni di esperienza Next.js non valgono quasi nulla su un progetto con un altro framework.
Per i progetti: scegli un framework sperando sia il coltellino svizzero che risolva tutto, ma poi non risolve quel problema specifico che hai tu. E ti ritrovi con una struttura complicata per niente.
Dovremmo smetterla di saltare su ogni treno
Se vogliamo salvaguardare il nostro lavoro, dovremmo scegliere con più cautela, innovare certo, ma senza perdere il controllo.
Quando valuto un framework, mi chiedo sempre:
Quanto mi allontano dagli standard?
Quanto capisco davvero di cosa sta succedendo sotto il cofano?
Quanto mi costa staccarmici domani e portarmi dietro il lavoro fatto?
Forse dovremmo cominciare a ragionarci tutti un po’ di più prima di inseguire il prossimo hype, no?
