Proseguono le riflessioni sulle competenze ed il ruolo dello sviluppatore Frontend

Javascript Development

Dalla presentazione di Angular nel 2016 c’è stato un cambiamento fondamentale nell’approccio allo sviluppo Javascript nel frontend, a cui va aggiunto il sempre più rapido supporto dei browser alle direttive EcmaScript più recente ed alle sempre più ampia implementazione della varie web API nei browser stessi (Cache, Push, Indexed DB … ), fino ad avvicinare le funzionalità dei siti web a quelle delle applicazioni native (PWA).
Fino a qualche anno fa le interazioni asincrone (AJAX) dei siti erano spesso complesse da implementare in quanto aggiornare la pagina significava accedere ai singoli nodi del DOM per manipolarli, fino a diventare praticamente impossibili quando si trattava di inserire grosse quantità di dati in pagine dalla struttura molto complessa.
I framework/librerie JS più recenti (Angular, React, Vue …) hanno introdotto l’uso del 'Virtual' DOM ( Incremental DOM nel caso di Angular), permettendo allo sviluppatore di ignorare la presentazione del dato nel DOM, potendosi invece concentrare unicamente sulla gestione del dato stesso, da qui il concetto di frontend reattivo.
Un’altra concenzione completamente nuova è quella delle interfaccie basate su componenti, derivata dalla specifica dei Web Components (mai efficacemente implementata lato browser); tramite questo modello implementativo è possibile creare singoli componenti configurabili che possono essere utilizzati non solo più volte nello stesso progetto, ma anche in progetti diversi, e che alla fine non fanno altro che riprendere i pattern della programmazione Object Oriented.
Attorno a questa nuova modalità di fare Javascript è nato anche un nuovo modo di fare CSS, ovvero il CSS-in-JS, che consente di legare lo stile non al sito/applicazione ma al singolo componente, consentendo quindi la portabilità completa, ma perdendo il concetto di Cascading (Cascata). Molti framework css e paradigmi sono nati da questo concetto (Emotion, Css Modules …)
L’insieme di queste novità:

• Possibilità di concentrarsi sul dato e non sulla presentazione
• Introduzione dei paradigmi della programmazione ad oggetti
• Disponibilità di framework CSS minimali e facili da configurare

ha trasformato la concezione di frontend developer in quella di programmatore javascript, sempre meno legato ai principi dell’usabilità e del graphic design, ma sempre di più esperto di coding conventions, paradigmi e architettura del codice. A tutto ciò va aggiunto che la sempre crescente presenza di servizi e strumenti basati Node Js consente, tramite lo stesso linguaggio, di fare programmazione anche lato backend.

Performance Management

Sebbene la questione delle performance sia spesso circoscritto alla fase di ottimizzazione post-sviluppo, una efficiente gestione delle prestazioni non può prescindere da un coinvolgimento in fase di progettazione.
Tra i requisiti del progetto dovrebbe esserci uno studio relativo al budget delle performance: ogni funzionalità del frontend ha un suo costo in tempi di esecuzione e va trovato un equilibrio tra il numero di esse ed il tempo di caricamento della pagina.
L’analisi del performance budget prevede una conoscenza approfondità delle funzionalità e del loro tempo di esecuzione sul browser.
Sempre in fase di analisi vanno anche previste tutte le best practice che possano migliorare i tempi, come ad esempio: lazy loading delle immagini, uso di formati grafici ottimizzati (WebP, Jpeg 2000), integrazione di CDN, implementazione di ottimizzazioni lato server (Gzip, Brotli …), caching lato server, caching lato browser, display mode per i web font, e molti altri. Molte di queste best practice hanno dei costi di implementazione decisamente inferiori se fatte in fase di setup del progetto invece che post rilascio come correzioni.
Molti servizi online come Google Page Speed o WebPageTest consentono di analizzare le pagine in maniera automatica dando dei punteggi che però hanno sempre una valenza generale: una landing page statica avrà più facilmente un punteggio alto rispetto ad una applicazione complessa che deve prevedere diverse interazioni, spetta quindi allo sviluppatore sapere quali sono i valori da usare come benchmark per il proprio progetto e valutare le singole segnalazione per estrarne quelle strettamente coerenti e sulle quali si può intervenire.
Un’altra competenza fondamentale riguarda l’utilizzo dei developer tools dei vari browser per controllare ed analizzare i tempi di caricamento delle singole pagine ed evidenziare tutti gli eventuali colli di bottiglia che si possano presentare, proponendo delle soluzioni pratiche.

Altre risorse

https://medium.com/@nairihar/reactive-programming-e4698b6ee3f
https://it.wikipedia.org/wiki/ECMAScript
http://es6-features.org/
https://developer.mozilla.org/it/docs/Web/Web_Components
https://addyosmani.com/blog/performance-budgets/
https://developers.google.com/web/tools/lighthouse

La parte 1 la trovi qui
La parte 2 la trovi qui
La parte 4 la trovi qui