Siamo stati a JSDay

Il JSDay è la principale conferenza italiana dedicata al linguaggio Javascript e a tutto il suo ecosistema di tecnologie. È organizzata dal GrUSP, associazione che si occupa di organizzare eventi, conferenze ed incontri informali a tema tecnologico coinvolgendo persone che lavorano nel settore, italiane ed internazionali. La conferenza è un'occasione di scambio e confronto su Javascript e sulle sue diverse applicazioni in vari ambiti.

A parte la parentesi delle restrizioni anti-COVID-19, durante le quali si è potuta svolgere solo in maniera digitale, la conferenza si tiene a Verona presso il San Marco Hotel, dando vita a tre giornate ricche di occasioni per scambiare conoscenze, partecipare a talk e workshop.

Per non restare indietro e continuare ad aggiornarmi con ciò che sono le recenti innovazioni nell’ambito dello sviluppo frontend, ho partecipato alla conferenza per seguire vari talk su questo tema, senza tralasciare gli altri aspetti che girano intorno al mondo della programmazione con Javascript.

Leggi anche: I migliori strumenti per lo sviluppo frontend consigliati dal team Nephila

In questo blog post, voglio raccontarti alcuni dei talk che ho trovato più interessanti della conferenza. Partiamo!

Il primo talk viene presentato da Tejas Kumar che entra subito nel vivo mostrando i più recenti paradigmi e metodi di sviluppo che si stanno diffondendo tra i vari framework:

• la Backend for the Frontend (BFF);
• la Fine Grain Reactivity;
• la Selective Hydration.

La BFF rappresenta un’evoluzione al Server Side Rendering (SSR), già molto diffusa su framework full stack quali NextJS e NuxtJS. In questo caso, viene eseguito sia il rendering visivo, sia quello funzionale ma non di una pagina intera, solo di un componente, il cui peso computazionale potrebbe essere eccessivo per lasciarlo al client.

La Fine Grain Reactivity è un altro ambito di grande interesse e uno dei trend più recenti dello sviluppo frontend. Alcuni tool, come React, quando aggiornano il loro stato, devono fare il rendering di tutta la pagina, ma tramite l’utilizzo dei signal, un espediente introdotto in Solid.JS, è possibile aggiornare solo la parte dell’interfaccia che si basa su quello specifico stato, sfruttando un paradigma molto vicino al concetto degli observable.

La Selective Hydration introdotta da Qwik, invece è una metodologia di sviluppo in cui tramite particolari sistemi di code splitting, non viene creato un bundle (anche pesante diversi MB) contenente tutto il codice ma, utilizzando alcune accortezze, viene caricato solo il minimo indispensabile (1KB). Inoltre, soltanto quando l'utente interagisce con un elemento interattivo viene recuperata dal server la parte di codice che gestisce quella specifica funzionalità.

Si tratta di paradigmi molto recenti ma che stanno prendendo sempre più campo nei vari framework, che in questo modo possono migliorare dal punto di vista sia delle prestazioni che delle funzionalità.

Michele Riva inizia con un'overview sui più utilizzati full-text search engines: Elasticsearch e Algolia. Benché siano ottimi strumenti, ne individua anche delle problematiche soprattutto dal punto di vista dei costi di scalabilità e della difficoltà di interazione con i progetti in cui vogliamo integrarli. Per superare queste problematiche, Michele inizia un percorso per la creazione di un nuovo full-text search engine e condivide tutte le sfide incontrate lungo il cammino nel suo talk. A partire dallo studio della teoria dietro il motore di ricerca, per continuare con la scelta del linguaggio da utilizzare (nel caso specifico è stato scelto Javascript), e ancora lo studio approfondito del linguaggio per ottimizzarne il comportamento in base ai possibili motori di rendering. Al progetto hanno collaborato anche contributor di famosi progetti open source, il cui contributo è stato importante. Tutto questo ha portato alla nascita di Lyra, che a causa di alcune problematiche legate al nome è poi diventato Orama: un full-text search engine scritto in Javascript che funziona con tutti i più famosi motori di rendering e contenente una quantità di plugin, hook e customizzazioni che lo rendono flessibile ed estendibile liberamente.

In questo talk, Phil Nash mostra alcune problematiche comuni nelle codebase di diversi progetti JavaScript:

• Utilizzare const e let al posto di var. Oltre al vantaggio di sviluppo derivato dall’utilizzo di queste nuove keyword nel codice, il loro utilizzo ci aiuta a comunicare meglio l'intenzione di ciò che vogliamo fare con il codice che stiamo scrivendo.
• La complessità cognitiva (la facilità di poter leggere e capire una funzione) delle funzioni non dovrebbe essere troppo alta. Questo aiuta a creare codice più leggibile e funzioni meno difficili da gestire.
• Grandi sezioni di codice non dovrebbero essere commentate. Questo per evitare confusione su chi leggerà il codice e avere un sorgente più pulito. Eventualmente, possiamo sfruttare il vantaggio fornito dall'utilizzo di un sistema di source control.
• Utilizzare i controlli di comparazione più restrittivi (===, !==) invece di quelli meno stringenti. Questo per avere una prevedibilità del codice che verrà scritto senza dover incappare in effetti collaterali non voluti.
• Assegnazioni di variabili non utilizzate dovrebbero essere rimosse. Come per la regola del codice commentato, queste variabili andrebbero eliminate per evitare di creare confusione.

La prima giornata si conclude con Tamas Piros che inizia con un po’ di ginnastica proposta a un pubblico provato da tutti i talk che si sono susseguiti. Il suo talk si focalizza sulle immagini e come gestirle al meglio per fornire la migliore esperienza utente possibile. Dopo un iniziale elenco di tool per l’ottimizzazione delle immagini, si concentra sui concetti chiave inerenti le immagini nel web:

• i formati dell’immagine, per cui si consiglia sempre di non utilizzare le gif all'interno dei siti web, ma di usare al loro posto video mpeg silenziati, in loop e senza controllo. In merito agli altri formati, ognuno ha i suoi vantaggi e svantaggi in base all'equilibrio che deve sempre stabilirsi tra dimensione del file e qualità dell'immagine;
• il dispositivo dell’utente;
• i Core Web Vitals, i parametri utilizzati da Google per misurare la qualità dell'esperienza di navigazione dell'utente, che influiscono anche sull'indicizzazione dei contenuti e determinano penalizzazioni per i siti che hanno valori superiori a certi standard. Il talk approfondisce il Largest Contentful Paint (LCP), l'indice che indica i tempi di caricamento dell'elemento visivo più pesante e consiglia diverse tecniche per tenere il suddetto punteggio/indice il più basso possibile. Uno strumento utilizzabile è Lighthouse (presente all’interno dei DevTools dei browser derivati da Chromium) che crea un report contenente analisi e suggerimenti per la corretta impostazione del parametro LCP;
• la responsività;
• tecniche di segnaposto e caricamento.

Un aiuto nel migliorare la situazione viene da Cloudflare che ha creato i Durable Objects: entità univoche a cui si possono collegare più utenti in maniera scalabile. Da questa idea è nata PartyKit, una piattaforma open source per la creazione di applicazioni collaborative in tempo reale. Permette di sviluppare la parte inerente la comunicazione tra applicazioni diverse con poche righe di codice. È ricca di tool di sviluppo, librerie, piattaforme di deploy ed è totalmente integrabile in buona parte dei progetti.
La presentazione termina con un paio di demo collaborative: un’app di disegno e una di produzione musicale create in collaborazione con chi ha partecipato alla conferenza e seguito il talk.

Come vediamo, sono presenti tre cartelle principali:

• pages, che contiene dei file che rappresentano ognuno una route del sito, possono essere file .astro, .html o .mdx;
• layouts, che contiene un layout specifico di visualizzazione;
• components, che contiene i vari componenti.

Nella gestione dell’hydration vengono utilizzate le direttive client per indicare con quale priorità si debba procedere all’attivazione dell'interattività dei vari componenti.

Il talk non si è concentrato solo sui vantaggi ma ha mostrato anche le principali limitazioni di Astro:

• non supporta tutti i framework (uno tra tutti Angular, ma sembrano esserci alcuni progetti atti a ovviare a questa mancanza);
• non il migliore per i Micro Front-End;
• non è la migliore soluzione per app interattive.

Una grande scorpacciata di tool e trucchi per poter migliorare l’esperienza di debugging/controllo grazie all’uso dei DevTools.

***

Finisce qui il racconto dedicato a JSDay. È stata una conferenza super interessante da cui portare a casa tanti spunti, consigli e best practice. Hai partecipato anche tu a JSDay? Facci sapere che ne pensi e quali sono i talk che hai trovato più interessanti. Ti aspettiamo nei commenti. Puoi trovarci anche su Facebook, Linkedin e Twitter.

Alla prossima!

Autore: Glenn Mendoza


*Gli screenshot di Chrome DevTools sono tratti dalla documentazione ufficiale