Benvenuti su Gitbar, il podcast dedicato al mondo dei full stack developer, i mezzo artigiani, i mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.Bene, benvenuti su Gitbar.Sentite la mia voce un po' strana? preoccupatevi è perché mi trovo a registrare in una condizione estrema ma non potevo mancare per la seconda settimana di seguito quindi devo iniziare chiedendovi scusa.Scusa perché non son riuscito a registrare la settimana scorsa e provo a recuperare questa settimana con un microfono poggiato sul trolley pronto per ripartire ma è un po' la mia vita è così ormai state imparando a conoscerla.Comunque, bando alle ciance, questa settimana è una settimana un po' disseminata di campagne elettorali, un po' qua un po' là, e anche io voglio parlarvi di politica e non scherzo, in realtà voglio affrontare un discorso abbastanza controverso di politica dove voglio prendere anche la mia posizione.Naturalmente non parliamo di destra o di sinistra ma parliamo sempre di tecnologia lo faremo subito dopo avervi ricordato come il nostro solito i contatti.Riniziamo ricordandovi che potete iscrivervi a entrare insomma nel nostro gruppo telegram dove ci scambiamo quattro chiacchiere oppure potete scrivermi a @brainrepo su twitter o o a info@gitbar.it.Comunque non perdiamoci in chiacchiere, piccola pausa e poi iniziamo ad affrontare l'argomento della settimana.E' arrivato la rovina! Il web ci dà la carriera e aumenta le nostre vite e per questo io mi batto sempre sul concetto che noi dev abbiamo sulle nostre spalle una importante responsabilità.Infatti quotidianamente quando sviluppiamo applicazioni abbiamo davanti a noi una serie di scelte.Delle scelte che spesso vengono intese come scelte di natura tecnica ma dietro una facciata fatta di bit, fatta di infrastrutture architetture c'è in realtà una scelta di tipo etico, una scelta di tipo etico che dobbiamo affrontare in primis in qualità di uomini, in seconda battuta in qualità di tecnici.Infatti oggi vi voglio parlare di "Gradeful Degradation" e di "Progressive Enhancement".Insomma, parliamo un po' in modo molto modesto di filosofia della progettazione del software.Quando si parla di "Gradeful Degradation" naturalmente il mio inglese lascerà a desiderare ma ormai lo sapete, si parla di quel tipo di approccio alla progettazione che parte da uno studio delle funzionalità basate sui browser più performanti.Quindi io devo sviluppare un sito o un'applicazione mi baso completamente su l'ultima versione di Chrome o di Firefox.Questo approccio però fa sì che i browser più datati o meno capaci vengano presi in considerazione solo nell'ultima parte del ciclo di sviluppo e spesso ci si limita all'implementazione diciamo delle stesse funzionalità almeno nelle ultime versioni dei browser principali quindi non si va indietro nella storia per rendere supportato il sito, l'applicazione che stiamo facendo anche nelle versioni più vecchie e naturalmente quello che ne avremo di conseguenza non è altro che insomma un'esperienza zoppa, più povera ma comunque tutto sommato fruibile questo può voler dire anche meno funzionalità.Questo lo si fa utilizzando delle particolari tecniche tra le quali appunto la tecnica dei polyfill, un modo per appunto far portare le funzionalità più moderne nei browser più datati fatto in modo un po' empirico.Questo approccio viene indicato come un approccio top down quindi parto da un contesto, una situazione ottimale e una volta che ho sviluppato la mia applicazione, il mio sito, il mio artefatto, in quella situazione ottimale inizio a togliere pezzi e a semplificare per farlo funzionare nelle situazioni un po' più semplici, più limitate e infatti spesso viene indicato come il portare dalla complessità alla semplicità.Io, se sapete che ormai provo a raccontarvi le cose un po' come le memorizzo io quindi per immagini e quando si parla di gradeful degradation l'immagine che mi viene in mente è quella di far entrare un castello fatto con le Lego all'interno di una scatola, della stessa scatola del castello.Beh, probabilmente le torri cadranno o comunque l'esperienza zoppata ci sarà.Questa è un'idea che viene dal mondo dell'ingegneria e un'idea che ha trovato molto spazio a partire dagli anni '90.Un'idea, come vi dicevo prima, che dice bene i browser moderni si possono godere tutto il pranzo dall'antipasto fino al dolce mentre i browser vecchi beh si accontenteranno delle briciole ma questa visione non si sposa con la visione democratica ampia di un web universalmente accessibile che è la visione che Tim Berners-Lee promulgava e promulga.Quindi attorno al 2004 si è sviluppato un filone un pelino più consapevole, un filone che provava a sostituire quest'approccio top-down di porting, di resa di diffulibilità degli strumenti che andiamo a realizzare in un approccio bottom-up.In realtà io ho detto 2004 in realtà si iniziano a vedere delle prese di consapevolezza già dal 2003 infatti se andate a cercare dovreste trovare un talk della XXSW se lo cerco e lo metto nelle note dell'episodio dove in realtà si inizia a sventolare questa bandiera a promulgare a proclamare questo cambio di tendenza Il talk si chiama "Inclusive Web Design for the Future" ed è appunto, diciamo, uno sviluppo di consapevolezza che porta a un web più democratico, dove l'approccio in realtà di coinvolgimento e di democratizzazione è by design.Questo perché? Perché in realtà non ci si focalizza su quello che si ha e si vanno a eliminare dei blocchi, ma si parte in fase di costruzione, by design, nello stabilire, nello strutturare un'architettura, quindi un'applicazione, che possa crescere con la crescita delle capacità non solo poi del browser ma anche del contesto.Su questo poi ci scenderemo a fondo nella seconda parte di questo episodio dove andiamo ad affrontare anche un'ulteriore evoluzione che si è sviluppata.Quindi in realtà qual è il principio fondante del progressive enhancement? Si parte da basi solide e sopra queste basi solide si costruisce pezzetto su pezzetto le funzionalità aggiuntive quindi quelle funzionalità che fanno uso dei sistemi magari più evoluti e lì si pensa partendo da un contesto limitato quindi dice ok le mie risorse sono questa manciata e un set limitato di risorse bene cosa posso fare partendo da questo set limitato? e poi via via si tracciano dei cerchi che si vanno a estendere per cui si parte da un sistema semplice a un sistema più complesso ecco perché il progressive enhancement è inteso come un approccio bottom up perché prende in considerazione il fatto che noi stiamo sviluppando il nostro sistema per browser che non conosciamo e quindi non con in mente l'ultima versione di Chrome con l'ultima versione delle web api supportata e questo fa sì che noi possiamo sviluppare partendo da una base solida di fallback.Quali sono gli strumenti che abbiamo bisogno per mettere in piedi questa strategia? Solitamente sono due, sono due tool che ci vengono messi a disposizione.il primo è la possibilità di fare la feature detection quindi capire se il browser supporta una funzionalità o meno la seconda è quella di applicare dei polyfill quindi le strategie che vanno ad aggiungere quelle funzionalità che mancano al browser e le vanno ad aggiungere utilizzando javascript ed ed ecco che qua entra in gioco il javascript un player importante che poi è anche l'elemento che diciamo attiva quella che è la discussione che porta poi a cercare di evolvere la visione del progressive enhancement però non vi anticipo nulla ci prendiamo una piccola pausa e una volta tornati da questa piccola pausa beh inizieremo a parlare della pietra dello scandalo.Dal 2006 in poi ci sono stati due fazioni, due blocchi distinti, due blocchi che avevano visioni diverse, modi diversi di intendere il progressive announcement.C'è stato un blocco, quello un pochino più più conservatore che ha una visione che io reputo stretta per meglio dire tecnica del progressive enhancement che è la visione che si riconduce poi al concetto di ok sviluppiamo partendo dall'html in modo che sia supportato su tutti i browser poi ci attacchiamo il css in modo che buona parte dei browser lo supportano quindi tutto possa essere visualizzato nel modo migliore esteticamente più fruibile.Beh, una volta che ho HTML e CSS io ho la base principale del mio sito o della mia applicazione quindi tutto dovrebbe funzionare a prescindere dal JavaScript.Poi ci attacco il JavaScript e tutto dovrebbe in qualche modo aumentarsi.Questa visione è appunto la visione stretta, tecnica, del progressive enhancement.C'è però un'altra fazione che vede il concetto di progressive enhancement in un modo un po' più ampio direi anche in un modo un pochino più politico e come vi dicevo all'interno di questo episodio c'è la mia posizione infatti io mi colloco a livello di idee un po' più su questa parte della barricata cioè l'idea di vedere la nostra applicazione al di là del set tecnologico che utilizziamo e quindi partire dalla funzionalità non dallo strumento.A questo punto si studia una base di funzionalità che deve essere democraticamente fruita cioè tutti possono accedervi e via via seconda delle capacità del browser questo set di funzionalità può estendersi gradualmente, aumentare la qualità dell'esperienza utilizzando appunto quelle funzionalità che sono supportate in alcuni browser e in altri no.Vedete che questo modo di approcciare esula un po' dagli strumenti, anzi esula completamente dagli strumenti tecnologici utilizzati.Quindi a parer mio la visione stretta, quella visione che diceva HTML, poi CSS, poi JavaScript è una visione limitata, anzi la butto, anche anacronistica.Perché? Perché oggi il nostro web si è evoluto.Non è più quello del 2006-2005 quando la parola "progressive enhancement", la visione del progressive enhancement con una prospettiva tecnica poteva essere anche giustificata ma oggi i nostri siti diventano più app che siti di contenuto e anche i siti di contenuto di per sé richiedono un'interattività e una funzionalità molto più evoluta di quella che era richiesta dai siti di 10 15 anni fa per cui vedo l'approccio stretto alla definizione di progressive enhancement quindi quell'approccio HTML, CSS e JavaScript come un approccio semplicistico infatti chi sostiene questa tesi spesso dice beh disattiva JavaScript e vedi se funziona se il tuo sito funziona beh a quel punto la tua accessibilità è supportato e tu stai rispettando il progressive announcement.Beh, dal mio punto di vista non è così.È troppo facile disattivare javascript e con questo provare che il tuo sito o la tua app è sviluppata in modo etico e democratico.Ed è soprattutto fuori contesto in un mondo dove le nostre app non sono più dei siti web ma si complicano talmente tanto che se vogliamo descriverle dobbiamo rappresentarle con per esempio un grafico che riassume, che descrive il "Documents to Application Continuum" che cos'è il "Documents to Application Continuum"? è un modello mentale che ci aiuta a pensare i nostri progetti e a posizionare i nostri progetti o sul lato del sito web o sul lato dell'applicazione web perché spesso noi tendiamo a dividere sito web o applicazione web come due facce di una medaglia, dimenticando quelle che sono le sfumature graduali nel mezzo.Quindi non è più una questione di bianco o nero ma è tutta una serie di sfumature.In questo contesto è troppo semplice definire il rispetto del concetto del principio del progressive enhancement con il disattiva javascript.A proposito di document to application continue, questa è una piccola parentesi, vi metto il link perché questo concetto è spiegato benissimo nel libro di Michel Geers o Michael Geers non lo so, che si chiama "Micro front-end in action" e c'è proprio un capitolo che affronta questo concetto e vi suggerisco di leggerlo.Comunque questo approccio, questa visione stretta è assolutamente limitante e dal mio punto di vista va superato questo limite e questo paraocchi va aperto quindi va intesa, progressive announcement va inteso in modo più moderato.Uno dei diciamo dei promulgatori, dei sostenitori di questo modo di vedere il il Progressive Enhancement e Jack Archibald o Archibald, se non lo conoscete andatelo a cercare su youtube lui è un developer advocate per Google e troverete sicuramente su Google un suo bellissimo talk che ha scritto per la JSConf Asia 2018 che racconta l'event loop, mi raccomando se non l'avete visto buttateci un occhio perché ne vale la pena, tra l'altro io Sono due anni che mi chiedo come ha fatto quel slide, ma chiudiamo le parentesi.Comunque, dicevo, questa visione ampia di intendere il progressive enhancement ci porta a iniziare a ragionare in termini di contesto.Cioè, se io disattivo il JavaScript, quali sono gli utenti e quanto è larga la fetta di utenti che io mi perdo? Adesso, se noi proviamo a fare questo esperimento, ci rendiamo conto di diverse cose.Ci rendiamo conto, per esempio, che buona parte dei device che tutti i giorni usiamo, quanto siano obsoleti per quanto siano limitati in termini di performance supportano javascript quindi in realtà disabilitando javascript quegli utenti che noi stiamo tagliando fuori tendono allo zero per cui è un falso mito è una falsa unità di misura quella di disabilitare il javascript per vedere se il nostro sito migliora progressivamente e questa non è una solo una mia idea ma anche Paul Lewis creatore di Lighthouse il tool che utilizziamo per misurare quanto i nostri siti o le nostre web application siano progressive web app ma anche creatore di Chrome DevTools supporta questo modo progressista di intendere il progressive enhancement.Per cui il primo lavoro che io suggerisco quando ci si vuole posizionare in un ragionamento di miglioramento progressivo è quello di provare a capire in realtà quanto è alta la fetta e se esiste una fetta di utenti che non supporta javascript.Perché quando si intende progressive enhancement è necessario intendere un principio che esula dal mero concetto tecnologico, esula dalla lotta javascript o non javascript ma è qualcosa in più.In realtà nel web moderno i colli di bottiglia sono ben altri.Uno di questi è per esempio la rete.Un modo moderno di intendere progressive enhancement è per esempio l'offline first.Oggi abbiamo bisogno di pensare le nostre applicazioni perché possano girare a prescindere dalla rete che è il nostro limite.Internet oggi lo offriamo dei dispositivi mobili dispositivi mobili che utilizziamo appunto in mobilità e l'elemento che emerge nell'utilizzo in mobilità dei dispositivi mobili è la non stabilità della rete ed ecco perché per fare dei siti o delle applicazioni che siano miglioranti progressivamente che abbraccino il progressive enhancement abbiamo bisogno di strumenti ampiamente supportati e moderni come il service worker.Abbiamo bisogno di strumenti come index DB tutti questi strumenti che non possono funzionare a prescindere dal javascript e sono strumenti che sono supportati anche dai device android di entry level che supportano il 3g quindi per esempio se noi iniziamo a pensare i nostri siti le nostre applicazioni e li ragioniamo in termini di 3g first beh a questo punto anche l'applicazione che gira su un device 4g, la stessa applicazione che gira su un device 4g, ne avrà del beneficio, sarà sicuramente migliore.Ecco un modo di intendere moderno del progressivo enhancement, del miglioramento progressivo.E per tutti quelli che dicono "sì, vabbè, ma il javascript non è il javascript", abbiamo l'esempio pratico.Un esempio è quello delle applicazioni fatte per i paesi in via di sviluppo.L'applicazione che è stata sviluppata per l'Ebola utilizzava WebWorkers, PunchDB eppure girava in condizioni estreme con device super limitati.Quindi oggi il discorso non è più JavaScript o non JavaScript.È per esempio rete, copertura di rete continua o non copertura diretta.Quindi quello che sta succedendo e quello che dovremmo intendere, ragionare quando appunto pensiamo in termini di progressive enhancement è che stiamo vivendo un cambio di contesto.Se prima avevamo dei browser incapaci ma con connessioni stabili, oggi abbiamo connessioni instabili e browser capaci quindi non possiamo più ragionare in termini di HTML first quindi di HTML prima poi CSS e poi JavaScript.L'unico forse momento in cui questo retaggio del passato può rimanere è solo quando noi ragioniamo in termini di server-side rendering per una mera e dico mera questione di performance.Il cambio questo cambio di contesto rende completamente anacronistico il concetto di HTML first specie perché in realtà non è più applicabile.Oggi lavoriamo in termini di web components dove non c'è più la separazione di "do all'html la struttura al CSS la parte estetica e al JavaScript l'azione.Ma è divido la mia applicazione in components ognuno dei quali ha del CSS, del JavaScript e dell'HTML io non posso prescindere dal fatto che ognuno di questi tre elementi possa debba viaggiare mano nella mano con gli altri.Ed ecco che anche questo nuovo modo di vedere quella che viene indicata come "separation of concerns" quindi la separazione degli ambiti sarebbe non ha non ha più senso a questo punto ragionare in termini di HTML first.Perché vi sto facendo questo pippone? Perché in realtà spesso quando noi sviluppiamo i nostri siti e le nostre applicazioni la buttiamo sull'ambito e sul contesto della tecnologia.Ma la fruibilità delle nostre applicazioni e dei nostri siti web non è più un elemento di tipo tecnologico, ma è un elemento di tipo etico e politico.è la cosa che dobbiamo avere presente e vi voglio lasciare con questa citazione è che l'unica costante è il cambiamento e questo non lo diceva Brain Rap che è l'ultimo pirla del mondo ma lo diceva Eraclito spero che questo episodio vi sia piaciuto io mi sono anche un po' riscaldato, devo dire la verità perché queste cose mi infervorano quando si parla di etica e di politica mi accendo sempre, infatti penso di aver raggiunto 40 gradi centigradi.Comunque spero che questo episodio vi sia piaciuto, noi ci diamo appuntamento alla prossima settimana tenendo presente che dalla prossima settimana ripartirà un interessantissimo ciclo di intervista con una serie di ospiti super super interessanti.Quindi cosa dirvi? sperando che questo episodio vi sia piaciuto, se vi è piaciuto naturalmente aprite la vostra app, naturalmente se non l'avete già fatto, aprite la vostra app di podcast e iscrivetevi se vi è piaciuto davvero tanto, beh, aprite iTunes o l'app podcast di Apple e lasciate una recensione, due righe fanno sempre piacere e soprattutto aiutano a catturare orecchie nuove e non fa mai male.Se avete voglia di rispondermi o se la vedete diversamente da come la vedo io c'è il gruppo telegram alla quale potete lasciare anche un messaggio vocale quindi perché no lo manderò come risposta nei prossimi episodi non siate imbarazzati mi raccomando.Tenete presente che gitbar è un bug degli sviluppatori quindi se volete dire la vostra la porta è sempre aperta.Cosa dirvi? Info@gitbar.it via email o @brainrepo per scrivermi, gruppo telegram ve l'ho già detto, beh noi ci diamo appuntamento alla prossima settimana.Da Olby è tutto, ciao! Gitbar, il circolo dei full stack developer.Una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei Full Stack Dev.
