Incontro. Questa la parola chiave degli organizzatori della dotJS Conference 2024 che si è svolta a Parigi il 27 giugno. La precedente edizione della manifestazione si è tenuta nel 2019, cinque anni fa. Da allora, la frammentazione dell’ecosistema JavaScript è aumentata.
Non solo abbondano i framework lato client, ma esistono anche numerosi metodi per ottenere gli stessi risultati con questo linguaggio ampiamente utilizzato dagli sviluppatori. Un vero labirinto per i principianti e motivo di costi aggiuntivi per le aziende che sviluppano applicazioni Web.
Alcuni siti fanno riferimento a più di cento framework JavaScript. Il report State of JS 2023 evidenzia fenomeni di adozione eterogenei, anche se React, Vue.js e Angular appaiono come gli strumenti più utilizzati e più apprezzati.
Se si tratta di oggetto di fastidio (e quindi di una formidabile cornucopia a meme), questa abbondanza di metodi e strumenti è anche il riflesso di un “ecosistema vivace”, come indicato da Christophe Porteneuve, relatore alla conferenza dotJS e Senior Staff Engineer presso Doctolib.
Tuttavia, JavaScript è un linguaggio standardizzato da ECMA International con il nome ECMAScript (standard ECMA-262). In effetti, sono in corso diversi sforzi per standardizzare il funzionamento delle basi di diversi framework front-end.
Uno di questi ruota attorno ai segnali. Qui si tratta in particolare della gestione degli stati (valori statici) e della reattività di un’applicazione web.
Problemi di reattività, moltiplicazione dei quadri: due grandi sfide per l’ecosistema
Nel contesto di JavaScript, “un segnale rappresenta uno stato reattivo, un valore che può cambiare nel tempo e informare automaticamente i calcoli e gli effetti dipendenti da questi cambiamenti”, spiega Rakesh Purohit, sviluppatore React di DhiWise, in un post sul blog di a framework di sviluppo che consente di convertire progetti di tipo Figma in codice utilizzabile dagli sviluppatori.
Per Rakesh Purohit, “questa è la pietra angolare della programmazione basata sugli eventi, che consente uno stile di codifica più dichiarativo in cui il flusso di dati, piuttosto che una serie di passaggi imperativi, detta la logica”.
Concretamente, a cosa servono i segnali nell’ecosistema JavaScript? “Molte cose”, risponde Ben Lesh, leader del progetto RxJS, principale ingegnere informatico presso Bridgewater Associates (ex Google e Netflix), durante il suo intervento alle Folies Bergères.
“In primo luogo, consente di ritardare il calcolo delle attività costose finché non sono effettivamente necessarie. Se stai aggiornando qualcosa molto rapidamente in modo asincrono, puoi posticipare il calcolo per ottimizzare le prestazioni. Inoltre, questo approccio avanzato consente di definire chiare dipendenze tra calcoli e segnali”, continua.
“Ad esempio, un calcolo può dipendere dai segnali a e b, mentre un effetto può dipendere dai segnali c, che a loro volta dipendono da a e b. Ciò crea una catena di dipendenze gestita in modo efficiente e reattivo”.
Questa catena di dipendenze è formalmente rappresentata da un grafico che associa valori e logiche di notifica, invalidazione, calcolo e memoizzazione (l’ottimizzazione delle operazioni mediante il loro caching).
“I segnali tengono traccia di modifiche di dati specifici in un’interfaccia utente.”
Minko GechevResponsabile relazioni prodotto e sviluppatori per Angular, Google
“I segnali consentono di tenere traccia di modifiche specifiche dei dati in un’interfaccia utente”, riassume Minko Gechev, responsabile delle relazioni con gli sviluppatori e i prodotti per Angular presso Google. Ad esempio, in un sito e-commerce, se un utente modifica la quantità di un articolo nel carrello, verranno aggiornati solo i componenti che visualizzano tale quantità, senza controllare tutti i componenti della pagina. “Ciò rende gli aggiornamenti dell’interfaccia utente più efficienti e veloci”, afferma. Quanto più complessa è l’applicazione web, tanto più importante sembra questo meccanismo.
Il concetto non è specifico per l’ecosistema JavaScript. Un sistema simile esiste nella libreria front-end QT, basata su C++.
Allo stesso modo, nell’ecosistema JavaScript, i segnali “esistono da molto tempo”, afferma Ben Lesh, da circa dieci anni. “Sono anche conosciuti come proprietà calcolate in Emberjs, sono osservabili in Knockoutjs, in MobX, segnali in Angular e Solidjs, rune scritte, riferimenti Vuejs”, elenca.
Una proposta per i progettisti di framework
Presentato il 1È Aprile 2024 (ma in lavorazione da circa un anno), la proposta TC39 relativa ai segnali mira a “definire la precisa semantica di base del grafico dei segnali”. L’API proposta in questo bando di standardizzazione è dedicata ai framework da cui i progettisti possono trarre ispirazione “per garantire l’interoperabilità grazie a un grafico di segnale comune e un meccanismo di tracciamento automatico”.
I principali contributori dei progetti Angular, Bubble, Ember, FAST, MobX, Preact, Qwik, RxJS, Solid, Starbeam, Svelter, Vue e Wiz partecipano a questo sforzo di standardizzazione da circa un anno.
In effetti, i meccanismi per tenere traccia automaticamente delle modifiche ai valori e alla logica che influenzano l’interfaccia utente sono spesso diversi tra i framework JavaScript.
“Ciò rende difficile condividere modelli, componenti e librerie tra diversi framework, che tendono ad essere erroneamente accoppiati al loro motore di visualizzazione (poiché i segnali sono solitamente implementati come parte di framework JS)”, notano gli autori della proposta.
E suggerire un elenco di prerequisiti per rendere la gestione del segnale quanto più uniforme possibile.
Esistono quindi due tipi di segnali. Il segnale di base rappresenta un valore. Il segnale calcolato può essere il risultato dell’applicazione di una formula a due o più segnali. Entrambi sono generalmente “avvolti” dai framework associati.
L’implementazione proposta dovrebbe avere un impatto minimo sulle prestazioni. Pertanto, i segnali calcolati vengono memorizzati nella cache e ricalcolati solo se la dipendenza del grafico del segnale è cambiata. I confronti personalizzati aiutano a determinare quando i segnali calcolati devono essere aggiornati.
A causa delle dipendenze, il cambiamento di stato di un segnale base può portare alla modifica dei segnali calcolati che da esso dipendono. I meccanismi di feedback identificano i cambiamenti e programmano il ricalcolo dei segnali calcolati. Gli effetti (le operazioni risultanti dalla modifica dei dati) vengono eseguiti secondo il piano di lavoro determinato dalle reazioni.
Se possibile, i segnali di base e quelli calcolati potrebbero essere gestiti dal garbage collector “come qualsiasi valore JavaScript”.
Sebbene questo progetto sia ancora nella seconda fase di cinque (Stage 1) di integrazione nel linguaggio, Google lo sta già implementando in AngularJS e Wiz. Wiz è poco conosciuto perché è un framework proprietario utilizzato internamente dal colosso del cloud.
Quando AngularJS viene utilizzato per sviluppare Google Analytics, le interfacce di servizio di GCP, Wiz viene generalmente gestito dai team dietro Gmail, YouTube e Workspace.
“AngularJS viene spesso utilizzato per interfacce altamente interattive mentre Wiz è piuttosto associato ad applicazioni pubbliche in cui la latenza è molto importante”, spiega Minko Gechev. “Ma i team di prodotto cominciavano a desiderare funzionalità di entrambi i framework. Mi è stato assegnato questo progetto di convergenza con altri”.
Quindi i team dietro AngularJS e Wiz si sono assicurati che i segnali Angular possano essere sfruttati con Wiz.
Un’implementazione già in produzione presso YouTube
“Attualmente, tutto il traffico mobile di YouTube utilizza Wiz con segnali Angular”, afferma Minko Gechev. “Il team ha riscontrato miglioramenti significativi nelle prestazioni. Ad esempio, sulle Smart TV, la latenza di input (quando un utente preme un pulsante sul telecomando, N.d.R.) è stata migliorata del 35%. Lo scorrimento di YouTube Shorts è aumentato a 60 fotogrammi al secondo, rispetto ai 25 fotogrammi al secondo tipici del DOM virtuale.
L’ingegnere ritiene quindi che la standardizzazione della gestione dei segnali nel linguaggio JavaScript sia ben avviata.
“La convergenza di quadri diversi è qualcosa che non avevo mai saputo in passato.”
Minko GechevResponsabile relazioni prodotto e sviluppatori per Angular, Google
“L’implementazione di riferimento utilizza segnali Angular perché ha dimostrato che può funzionare con più framework e scale su YouTube, il secondo sito Web più grande al mondo”, afferma. “Inoltre, la convergenza di quadri diversi è qualcosa che non avevo mai saputo in passato. In effetti, i progettisti di framework hanno spesso cercato di andare in direzioni diverse, anche se alcune idee ritornano e sembrano essere buone pratiche.
Questa convergenza non è solo interna. A poco a poco, Google prevede di combinare le funzionalità di Angular e Wiz nel ramo open source di Angular. Minko Gechev prevede che ci vorranno diversi anni.
Infine, il responsabile delle relazioni con gli sviluppatori di Google ritiene che i framework JS stiano diventando dei “meta framework”. Secondo una diapositiva che ha condiviso, Angular, Next.js, Remix, Nuxt, SolidStart e SvelteKit condividono caratteristiche comuni. Gli strumenti sfruttano componenti, forniscono DOM virtuale o incrementale, supportano la generazione di siti statici, il rendering lato server, TypeScript e funzionalità reattive di base e avanzate (come i segnali).
Altre funzionalità dovrebbero essere soggette a qualche forma di riconciliazione. Minko Gechev scommette sull’adozione di approcci identici, se non simili, alla struttura della vista, all’iniezione di dipendenze, alla riproduzione di eventi e all’aggiornamento selettivo dei componenti dell’interfaccia utente (una funzione che potrebbe essere tradotta con l’espressione irrigazione parziale).
“Come scegliere un quadro oggi? Non pensarci troppo”, consiglia. “Sarà sempre la stessa tecnologia con un cappello diverso.”
Tuttavia, l’implementazione degli elementi di segnale potrebbe ancora essere soggetta a interpretazioni diverse a seconda dei progettisti, notano alcuni sviluppatori. Altri lo considerano un “errore”.
Minko Gechev nota che i problemi di stabilità e affidabilità a volte vengono messi da parte dai team di sviluppo. “Vogliamo assicurarci di utilizzare una soluzione stabile che ci supporterà a lungo termine. È anche molto importante disporre di un ecosistema ricco, inclusivo e solidale, nonché di una soluzione che ci piace davvero utilizzare”, conclude.
