Bene e benvenuti su Geekbar, nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori.

In realtà, viste le condizioni di salute potrebbe sembrare più tipo Villa della Pace, quella villa per anziani dove sono tutti un po' malattici, perché la mia situazione di salute è veramente precarissima, sono a un passo dal baratro, ma non volevamo missare questo episodio.

Per cui insieme al super ospite che vi annunciamo tra pochissimo, c'è chi si prenderà cura di questa puntata e ci accompagnerà nella scoperta insieme al nostro ospite di una roba molto figa.

Infatti con me qua è Carmine e Luca.

Ciao a tutti! Ma quanto fa anni 80? Ciao raga! O anni 90? Mi sento ambra angiolini a palla! Vabbè, noi tutti, quasi tutti da lì veniamo, dagli anni 80.

Ebbene sì, ebbene sì.

E credo che anche il nostro ospite, forse è più giovane, non mi sbaglio, quindi anche tu sei degli anni 80.

Comunque detto questo, io ringrazio davvero Luca e Carmine per essere qua a darmi una mano, forse anche due, prestarmi anche la voce.

E nulla, vi ricordo rapidamente i nostri contatti.

Info che io ce l'ho a gitbar.it, atbrainrepo su Twitter e il gruppo Telegram.

Potete trovarci vicinando Gitbar nel vostro client Telegram preferito.

Siamo più di 1300 persone e aspettiamo solo voi per discutere di colori pare.

Anzi, in realtà ultimamente siamo molto molto più attivi di prima, quindi ci sono più conversazioni interessanti.

Aspettiamo! E sempre sul gruppo Telegram, anche se è tipo borderline a livello legale, perché la normativa italiana non permette di fare giveaway, abbiamo un giveaway.

Abbiamo due ticket omaggio per We Are Developer, perché come vi dicevo la scorsa volta siamo diventati partner di We Are Developer e quindi ci hanno regalato due ticket omaggio che noi regaleremo a chi lo scoprirete nel gruppo Telegram.

Ci sarà qualcosa da fare e scoprirete come ottenere uno dei due free pass.

Abbiamo anche un codice sconto individuale.

Mettiamo tutto nel nostro gruppo Telegram perché è il nostro punto di riferimento.

Però detto questo io direi che possiamo iniziare.

Benvenuti su Gitbar, il podcast dedicato al mondo dei fullstack 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.

L'ospite di oggi, ancora prima di essere un grande professionista, è un amico.

Un amico con il quale ho fatto tantissime, anzi non tante devo dire, poche chiacchieratte ma intense e piacevoli.

Abbiamo con noi Giorgio Boa.

Ciao Giorgio! Ciao a tutti, grazie di avermi invitato.

Come stai? Molto bene, molto bene.

Beh, mi fa super piacere.

Ho visto che questo periodo stai facendo un pacco di roba.

Sì, sì, sì, sono super impegnato su questo periodo e tra i vari incastri sono riuscito a essere qui con voi quest'oggi e sono molto molto contento.

Dai, guarda, io sono super felice anche perché avevamo pianificato questo episodio per qualche settimana fa.

Quale avevamo pianificato qualche settimana fa, però tu mi hai detto, Mauro, guarda, fai una cosa, aspetta un pochino qualche, posticipiamolo di una settimana perché vedrai che qualcosa succede.

In realtà io ho visto che è successo qualcosa.

Cos'è successo? È successo che il framework QUIC ha raggiunto la versione 1.0 e proprio ieri, quindi l'altro ieri in realtà, scusa, hanno annunciato la versione 1.0.

1.0.

Scusate, stavo tipo morendo davanti al microfono.

Prima di lasciare la parola perché ormai moribondo dovrò sedermi sulla sedia e godermi la chiacchierata, voglio chiederti tu in Italia sei tipo l'ambassador numero uno, in Italia e non solo in Italia, ho la sensazione che tu lo sia anche tipo in buona parte dell'Europa l'ambassador numero uno di QUIC.

Mi sbaglio, prima domanda, seconda cosa, come hai scoperto QUIC? Allora, effettivamente di speaker che parlano di QUIC non siamo tantissimi e devo dire che è stata per me una piacevole sorpresa, nel senso che proprio a We Are Developer, la conferenza dove appunto avete i ticket da regalare in omaggio, ho conosciuto il creatore di Angular.

Io in realtà mi ero avvicinato a lui per fare un selfie perché comunque da utilizzatore di Angular mi faceva piacere comunque scambiare due parole e poi da lì è nata una collaborazione con QUIC, cioè mi ha detto guarda sto facendo questo nuovo framework se ti va di investire un po' del tuo tempo per vedere, darmi del feedback eccetera eccetera sentiamoci e così ho colto l'occasione.

All'inizio era un po' titubante se accettare o meno, nel senso che comunque sapevo che sarebbe stato impegnativo a livello di tempo, però ho detto mal che vada comunque ho modo di parlare con il creatore di QUIC e quindi perché no.

Allora comincio io subito perché io parlo da ignorante, nel senso l'ho visto, ho visto più o meno la Lazio insomma di tutto, ma che cos'è QUIC? Se proprio dovessi descrivere in una frase, però in una bella frase, diciamo non come mi descriveresti tasto tipo, oppure come mi descrivesti? Ok allora QUIC è principalmente un framework front-end che fa server-side rendering, quindi nasce come server-side rendering che però basa il suo modo di renderizzare la pagina, quindi renderizzare le applicazioni su concetti totalmente diversi, quindi dove magari con Remix, SvelteKit, Solid, Next, hai quel modo di fare rendering, quindi più o meno dietro le quinte funzionano uguali, con QUIC è diverso, cioè funziona in maniera diversa.

Diversa come? Ok, allora questa è una bella domanda.

Allora, principalmente con le applicazioni che fanno server-side rendering, attualmente si usa la tecnica dell'hydration, cioè viene generata la pagina lato server, viene servita al client, quindi spedito HTML, CSS, JavaScript, viene servito come uno snapshot, quindi alla fine i primi millisecondi che vediamo nella nostra pagina sono dei millisecondi di snapshot.

Dietro le quinte che cosa fa il browser? Tramite il JavaScript, HTML e CSS riesegue tutta la logica per attaccare ai vari bottoni, alle varie parti interattive, attacca di nuovo la logica per poter poi rispondere all'utente, quindi fa un doppio lavoro, fa un lavoro lato server più fa un lavoro lato client.

Con QUIC invece è totalmente differente, cioè quando viene generato il bundle per la produzione, invece di andare a creare un unico JavaScript, vengono creati dei piccoli chunk, quindi dei piccoli chunkettini, siccome il core team di QUIC segue sia la parte di rendering che la parte di bundling, cioè quello che è la creazione del risultato finale da spedire al sito web, quindi il nostro browser segue anche quella parte lì, è in grado di dividere il JavaScript in piccole parti.

Questo che vantaggio dà? Dà un vantaggio che nel primo rendering noi renderizziamo solo HTML e CSS, senza renderizzare del JavaScript o pochissimo, solamente quel JavaScript, quindi pochissimo, un kilobyte di JavaScript, che è in grado di attendere l'interazione dell'utente, quindi quando poi l'utente clicca sul bottone, eseguiamo solamente il JavaScript che permette di animare la pagina.

Quindi in poche parole, stringendo con i framework soliti, diciamo, si fa hydration, quindi doppia logic che serve al client, con QUIC si spedisce HTML e CSS, che con le connessioni moderne è super veloce ed è per questo anche che è molto performante con i core web vitals, e solamente se l'utente interagisce con una determinata pagina, noi eseguiamo quel JavaScript che serve.

È un discorso molto lungo, lo so, però forse è più facile provarlo che spiegarlo.

Quando dici eseguiamo, intendi lo scarichi e lo esegui o lo esegui soltanto? Perché tu hai parlato, do soltanto l'HTML e il CSS e poi esegui il JavaScript, però quando lo scarichi, il JavaScript, nel momento dell'interazione, subito dopo, o c'è qualche automagia in mezzo? Sì, sì, allora io ho usato giustamente la parola eseguiamo, che sarebbe a dire parsiamo ed eseguiamo.

Per quanto riguarda la parte di download, ci si affida al service worker, quindi con il rendering della pagina c'è un service worker che dietro le quinte già prebufferizza tutti questi cianchettini, un po' come un video streaming che guardiamo su YouTube, noi guardiamo il minuto 1, ma dietro le quinte YouTube sta già caricando il minuto 1 e mezzo, 2, 3, è pronto lì per essere utilizzato.

Lo stesso fa quick e quindi poi alla fine mette da parte questi cianchettini e solamente quando noi li vogliamo andare a fruire, lui, in realtà andiamo a fare una chiamata che però arriva prima al service worker e poi esce al server e chiaramente siccome il service worker ha la risorsa, gliela ritorna subito.

Quindi diciamo l'obiettivo non è tanto da non eseguire JavaScript, ma eseguire il meno possibile sul main thread, insomma per mantenere tutto più reattivo, quindi con un service worker effettivamente deleghiamo tutta quella parte di esecuzione JavaScript che normalmente bloccherebbe il main thread in un altro thread.

Sì, il download avviene tramite il service worker, poi l'esecuzione è solo l'esecuzione di quella piccola parte che necessita l'applicazione per diventare interattiva.

Però nel download di fatto c'è tutto.

Giusto per avere un'idea, scusami Carmio, giusto per avere un'idea, quanto piccoli sono questi chunks? Cioè del livello di funzione, del livello di oggetto, di file? Beh, allora, innanzitutto per creare i chunks poi c'è dietro tutta una configurazione che fa delle logiche sue dietro le quinte che sono anche, tra le altre cose, configurabili, però sostanzialmente non è che fa un chunk per ogni funzione che può essere isolata.

Mette insieme più funzioni, magari anche guardando che magari una funzione va poi a modificare più componenti, perché modifica lo stato, eccetera, eccetera.

Quindi non abbiamo mille chunkettini, abbiamo un insieme di chunkettini che fa dei bundle.

Questi bundle poi dipende chiaramente dai codici che ci mettiamo all'interno e soprattutto una cosa interessante è che se noi abbiamo dipendenze esterne, solamente se andiamo ad utilizzarle scarichiamo il chunkettino della dipendenza esterna.

Quindi puoi immaginare, non so, utilizziamo dei JS, solamente se poi andiamo a chiamare le funzioni della libreria andiamo ad eseguire la libreria stessa, il JavaScript della libreria stessa.

Questa è una cosa interessante.

È interessante perché diciamo all'inizio, quando mi hanno parlato un po' di Temporal Cod, io inizialmente mi ero fatto un'idea diversa, un'idea che era più vicino a quello che fanno LiveView o LiveWire o comunque queste tecnologie che sostanzialmente servono tutta la parte di interazione con sistemi di WebSocket, una parte viene eseguita sul server, una parte viene mandata, eccetera, eccetera.

Quello che mi chiedo è come funziona tutta la parte di eventi, perché nel senso, gli event handler sono il core della pagina web, come interazioni.

Come funziona, ad esempio, quindi si fa che quel piccolo chunk che magari prendo mi va a mettere solo in quel momento l'event handler in quella parte del DOM, però quella parte del DOM deve esserci già, me la mette lui, nel senso come funziona.

Il componente che io scrivo nel mio codice sorgente ha più o meno una rappresentazione in quella parte di pagina che sto vedendo, in quella parte di interazione con cui sto effettivamente facendo i compiti sul browser.

Ho fatto questa domanda malissimo, se non sei capito dimmi.

No, no, beh, io ho capito, nel senso, credo di aver capito, nel senso che quello che io poi scrivo nei codici lo ritrovo nell'HTML più o meno.

Sì, sì.

Alla fine sì, nel senso che quando poi tu, ad esempio, fai un classico bottone che fa un contatore, quando tu agganci l'evento onclick, che in QUIC si chiama onclick$, il dollaro non credo sia per richiamare PHP, ma è...

Perché bisogna fatturare! Ok, penso di sì.

Il dollaro è un marker che serve all'ottimizzatore che è scritto in RAST, quindi noi abbiamo detto il core team scrive sia la parte di rendering che la parte di building, e il building è scritto su un server che è VIT, un bundler VIT, con del codice RAST, e praticamente questo codice RAST guarda i nostri file e cerca di identificare questi cianchettini.

Dietro le quinte poi che cosa fa? Va a generare dell'HTML e mette all'interno dell'HTML degli attributi che servono poi a lui per capire che cianchettino scaricare, quindi l'evento onclick lo trasforma, se non erro, in on2.click, e poi all'interno c'è una closure che fa un import di un file.

Quindi in realtà una rappresentazione di quello che tu scrivi c'è.

È un po' cambiato, però c'è.

Quindi diciamo, ad esempio, se penso a Next, abbiamo comunque tutta quella parte isomorfica che un po' viene eseguita sul client, un po' viene eseguita sul server, mentre così fa tutta la parte di server rendering.

C'è anche questo tipo di funzionalità, nel senso c'è del codice che viene eseguito solo sul server, solo sul client, oppure in entrambi i posti contemporaneamente? Sì, c'è questa parte qui anche su QUIC, quindi ci sono alcune funzioni, soprattutto anche il rendering dello stesso componente avviene lato server, poi viene servito sul client, addirittura se il componente non ha iterazioni, non ha dinamicità, viene proprio neanche inviato il javascript, viene inviato solamente HTML e CSS.

Inoltre, una cosa super figa, se si può dire in questo podcast figa, è che alla fine si può mettere nel client, si può scrivere server dollaro e poi la nostra funzione e quella funzione verrà eseguita lato server.

Quindi io scrivo server dollaro e sono in grado di poter fare eseguire quel pezzo di codice all'interno del server.

Questa è già una prima cosa che solitamente un po' lascia di stucco, nel senso che io poi scrivo un qualcosa nel nostro componente, però quel codice lì avviene lato server.

Una cosa ancora più interessante, che non è ancora documentata se non sbaglio, a meno che non l'abbiano aggiunta da poco, è che si può scrivere worker dollaro.

Quindi se io devo fare magari una trasformazione di un'immagine per magari ottimizzarlo, applicare dei filtri, posso mettere worker dollaro e lì metto la mia logica per andare a modificare un'immagine, applicarli dei filtri ed eseguire quel pezzo di codice all'interno del worker in modo da non fermare il main thread che è il nostro, diciamo, peggior nemico quando si tratta di eseguire del javascript.

Quindi possiamo delegare parte delle nostre funzioni, sia con valori in input e anche ricevere dell'output, sia al server che al worker.

Ok, ma come...

Apriamo un attimo il cofano, perché io sono sempre curioso di aprire il cofano e vedere come funziona.

Facciamo la cosa più facile, forse.

Appunto questo server dollaro che segue una funzione sul server, da sotto alla fine che cosa fa? Scatena un evento che chiama un endpoint che è nascosto da qualche parte o c'è una connessione socket o qualche altra magia che io posso ignorare? Alla fine fa una chiamata HTTP su un endpoint conosciuto ed esegue, gli dice eseguimi questa funzione e poi mette l'hash della funzione ed il server la esegue e poi ritorna indietro i dati.

Quindi utilizza una chiamata HTTP.

Se noi la volessimo fare, diciamo, con un altro framework che non ha questa funzionalità, dovremmo prendere la cartellina, diciamo, API, esporre l'endpoint e dire che quella magari è una POST piuttosto che una GET e quindi poi gestirci anche quel file lì, con la logica ovviamente all'interno di quel file.

Una cosa che non ho detto prima, noi possiamo inserire questa parte server o worker all'interno del componente e magari per alcuni che hanno sviluppato, sviluppano in PHP, inserire delle logiche all'interno del componente, logiche server all'interno del componente frontend è cosa naturale, però magari per i frontendisti, quelli più accaniti, inserire e mischiare le logiche tra backend e frontend è un'eresia.

Si può prendere quella funzione, spostare su un file apposito e tenerlo lì.

Quindi si possono suddividere le due logiche.

Ok, quindi diciamo, volendo ritornare anche un po' al core concept che ho letto in questi giorni sulla documentazione di Qwik, quindi c'è l'idratazione dell'applicazione, che è quello che sostanzialmente avviene negli altri framework, e invece in Qwik c'è tutto il concetto di resumable, che non so come tradurre in italiano, lo lasciamo così in inglese.

Quindi quello di cui abbiamo parlato ora fa parte di questo concetto e perché si chiama proprio resumable? Perché effettivamente è come se mettessi in pausa una cosa del genere.

Si esatto, è stato coniato, in inglese non esiste resumability come termine, perché viene eseguita la logica, lato server, viene messa in pausa, serializzati eventuali dati che bisogna appunto spedire, vengono spediti all'interno del nostro browser e l'applicazione di fatto è in pausa.

Nel momento in cui poi l'utente interagisce passa da stato pausa a stato resumed ed è qui che poi nasce il termine resumability, cioè si riaccende.

Ok, quindi diciamo per i frontendisti che sono all'ascolto o per chi fa già la scritta in generale è come se fosse questo grande function generator che può essere messo in pausa e si continua l'esecuzione, se così lo voglio rappresentare.

Scusa Carmine, giusto perché mi è venuta una metafora al volo, sembra quando tu stai cucinando qualcosa e fai metta cottura sui fornelli e poi finisci la cottura al forno.

Se proprio volessimo fare un esempio per me è quello, cioè metti in pausa, trasferisci in un altro contesto e premi.

Gli spadelli.

Esatto.

È scritto il modo in cui io faccio la pizza.

Per le ricette solo ai Patreon.

Le ricette di Luca.

Luca is the new Benedetta.

Scusa Carmine, stavi dicendo qualcosa di interessante e l'ho buttata in puttana.

No, no, no, in realtà è una metafora molto più calzante di quella che avrei potuto trovare io.

Quindi in realtà c'ho una domanda che è più una provocazione, un po' come tutte quelle che stiamo facendo qui, ormai siamo fatti così.

Quindi essendoci comunque un server che appunto serve questa applicazione, diciamo dal punto di vista di performance e di scalabilità, come funziona? Nel senso, se dovessi pensare ad una single page application classica, se non voglio preoccuparmi di questa cosa qui, la metto su un bello bucket, poi ci metto Cloudflare oppure mi osto questi file statici da qualche parte, più di tanto non mi preoccupo di questa cosa.

Quando invece parliamo di applicazioni che vengono servite da un server, quindi c'è anche tutta la parte computazionale dietro, è una cosa da tenere a mente.

Come funziona la scalabilità di QUIC? Si possono mettere diverse repliche? Non lo so, sto parlando a caso.

Sì, diciamo che con QUIC oltre a server-side rendering, non abbiamo detto, ma si può fare anche static site generation.

Quindi la stessa logica che viene eseguita quando io vado su una determinata rotta, viene eseguita nel momento della build.

Io produco l'HTML, tutti i cianchettini e poi lo vado ad inserire su un S3.

Ed ecco che replichiamo, non dico lo stesso modello della single page application, perché quello funziona in maniera diversa, però andiamo a replicare un po' quello che può essere un Oswald kit in static site generation.

Quindi poi in termini di scalabilità di quello non c'è problema, in termini di scalabilità di un server-side rendering si comporta come qualsiasi altro framework che fa questo.

Quindi questa domanda qui perché l'ho fatta, perché ultimamente parlando anche con colleghi così stiamo vedendo sempre più spesso ad esempio Next utilizzato come un vero e proprio framework monolitico.

Ci faccio il front-end, ci faccio il back-end, ci faccio qualunque cosa.

Quindi diciamo si ritorna un po' verso il vecchio framework monolitico che per un periodo abbiamo detto che non andava bene, tra un periodo c'è stato addirittura il micro front-end con il servizio, ora invece si sta un po' ritornando così all'ovile, che è anche un po' la stessa cosa che puoi fare con revizzo similare.

Con QUIC c'è questa possibilità, è consigliato farlo o è sconsigliato farlo? Perché ti faccio questa domanda? Perché se andiamo ad interpellare le persone che ad esempio utilizzano Next non c'è una vera e propria risposta a questo, nel senso puoi farlo, il grado di libertà dove ti puoi spingere a fare questa cosa, questa cosa qui non è ben definita.

È direttamente proporzionale al dolore che provi appena ti sei sparato nei piedi.

Esattamente, esatto, era proprio questa cosa qui.

Ed è legato alla domanda che vorrei fare subito dopo.

Ok, ho visto utilizzare Next come un brutto larevel, con ancora più complessità dentro, quindi con QUIC questa cosa si può fare, non si deve fare, è sconsigliato farlo? Come funziona? Direi come con Next, non è opinionata la cosa, nel senso che al momento non c'è un'opinione forte, rimane poi nella sensibilità di chi sta sviluppando di capire quando è ora di inserire della logica all'interno della stessa applicazione o quando è il momento di dire ok però se noi facciamo così andiamo a schiantarci su un muro.

Quindi si può inserire della logica e esporre delle rotte lato back-end, poi sta al singolo sviluppatore la sensibilità e anche maturità d'esperienza di non farlo in determinati momenti.

È interessante quello che abbiamo appena detto, io voglio apportare una mia esperienza.

Qualche progetto fa arrivò un cliente e ci disse io voglio questo sito super sbrillucicoso che si muove da destra a sinistra facendo un doppio balzo carpiato rimbalzando qua e là con le lucine colorate ma voglio anche che si veda con la gente nei device vecchi con tipo mezzo k di memoria, cioè una roba, adesso sto scherzando, mezzo k di memoria, però dei device vecchi oppure dei device con javascript disabilitato perché siamo legati a alcune normative che esistono ancora per cui dobbiamo per legge supportare queste cose.

E quindi si apriva la porta della progressive enhancement, o del progressive enhancement, non so come declinarlo, comunque sia in quel momento io avevo degli spike per delle discovery session per capire che cazzo usare perché quello che noi cercavamo era la stessa dev experience che ci dava react perché comunque in un modo o nell'altro react ha rivoluzionato la dev experience nel frontend che piaccia o meno così è e a quel punto a quel punto ho pensato noi abbiamo bisogno di avere questa zona di comfort per essere veramente produttivi o comunque per non lavorare con i template pug io non so chi lavori ancora oggi con i template pug o mustache poverino lui nel senso che se lo paragoni al JSX la developer experience è tipo completamente diversa.

Qual è stato il vero problema? Posto che si potrebbe discutere su che cos'è il progressive enhancement, si javascript no javascript ma tutti i device hanno javascript se lo vuoi disabilitare devi andare forzatamente a disabilitarlo quindi sei tu che ti stai escludendo non è il mondo che ti esclude su questo potremmo rimanere tipo settimane a parlarne ma io ho quasi finito l'autonomia vocale e quello che mi sono trovato a fare è trovare un framework per fare questa roba e a parte remix che all'epoca era tutt'altro che stabile tipo mi cagavo in mano a portarlo in un client enterprise abbiate pazienza chi è che si prende la responsabilità l'avevano appena rilasciato open source perché prima chi lo sa era un prodotto a pagamento.

Morale della favola si cercava un tool per il progressive enhancement alla fine si optò turandoci pesantemente il naso su next e si andò a utilizzare next che è stato un po' come davvero spararsi nei piedi è una delle cose che ha complicato di più in assoluto l'utilizzo di next e a parte il fatto che tu puoi dire a next di non mandarti il javascript al client se non lo usa ma glielo devi dire settando una variabile che tipo si chiama non settare questa variabile perché ancora in beta appunto non mandare il javascript al client una roba di questo tipo è una cosa che ho notato cercando forzando provando tinkerando quella una cosa che ho notato è che la sfumatura tra ciò che era back end e ciò che era front end diventava sempre più blurred ok sempre più sfumata e dove prima c'era una chiara distinzione che era legata al concetto di richiesta risposta che settava bene i due limiti quando mi son trovato a lavorare con next in quel modo dove dovevo per forza definire i limiti e non avendo questi limiti mi sono un po' trovato spaisato anche nel capire come avrei dovuto fare con quick tu puoi fare la stessa cosa tu puoi eseguire del codice server side decidere se farlo girare solo server side client side e via discorrendo e tutta la parte che noi anziani del codice siamo abituati a qui noi anziani del codice siamo abituati di richiesta e risposta viene in qualche modo nascosta silenziata ok resa trasparente e non pensi che questa cosa possa essere un problema io non lo so forse sto traslando la mia esperienza in un contesto dove non fitta però boh è un'ottima domanda e anche il caso d'uso che ci ha portato secondo me è interessante anche condividerlo con tutti secondo me ti direi che guardando anche un'altra libreria che è trpc che più o meno fa la stessa cosa c'è da front end chiami un unico endpoint che solitamente è slash api slash trpc e lì vai in query parameter a passare tutte le funzioni che vuoi eseguire e per poi eseguirle lato server quindi diciamo anche lì di fatto ti nasconde la complessità di dover creare degli end point gestirti le cose come diciamo siamo sempre stati abituati a fare quella libreria lì già sui 25.000 stelle su github e 220.000 download su npm quindi è molto molto popolare quindi ti direi che ok magari ci può far storcere un po' il naso però probabilmente è perché siamo non dico vecchi però siamo abituati a un altro modo di ragionare che non dico che sia sbagliato è solitamente solamente diverso.

Forse non tanto vecchi o non vecchi ma forse maniaci del controllo almeno almeno questo è il mio caso io devo sapere quello che succede da sotto al mio sedere non so voi il mio grande limite è proprio è proprio questo.

Sì che poi in realtà roba nuova si nel senso sì ok non sono concetti comunque ho alla fine tutto un corso di corso storico come c'era xml rfc c'era grfc e c'era amf php che solo i più impavidi conoscono e chi programmava in flex 3 e aveva il back-end in php che funzionava allo stesso modo era mi avete aperto un cassetto della memoria c'ho fatto dei crm complessissimi così in realtà perché questa domanda sulla strazione della richiesta client server perché in realtà è uno dei motivi per cui a me non piace tantissimo grpc e tutta la famiglia trpc pipo pluto rpc perché in realtà la percezione dello sviluppatore è quella che la rete non esiste che tu stai chiamata facendo una chiamata di funzione è solo una questione filosofica e non una questione meramente tecnica ma cazzo la rete è una delle fonti di entropia più grandi dei sistemi dove lavoriamo concordate con me e quindi questo mi porta a dire a un po aver paura e non è solo qui a spaventarmi sono next in primis ripeto io io mi cagavo addosso e dicevo sì va beh ma aspetta questa roba dove gira hanno aspe c'è una funzione nel componente che si chiama get server side props quindi quel cianchettino gira sul server il resto sul client ma in parte sul server questa unione dei concern che viene un po credo dall'approccio della della della dell'unione dei concern fatto da react dove ti butto dentro sul componente logica css logica javascript css html e divido in slice verticali no un po sarò conservatore sarò sarò vecchio alla fine un po mi dice va bene finché il progetto a uno scope contenuto e ok e quando lo scope esplode riusciamo ancora a gestirlo senza prenderci in carico la responsabilità di avere un over all su dove sta girando il nostro codice io ricordo una cosa che mi diceva sempre il mio professore di informatica a uno no e mi diceva mauro tu devi capire non solo cosa sta scrivendo ma dove lo farei girare e minchia aveva ragione da vendere oggi questa cosa un po l'abbiamo persa con i tanti layer da strazione che abbiamo che abbiamo inserito e l'inserimento di un ulteriore layer da strazione boh mi mi fa dire ok altra cosa tra l'altro visto che parlavamo di astrarre certi concetti e prima parlavi di più opinionato meno opinionato noi sappiamo che qui che viene dal creatore di angular ok dalla stessa mente e che cazzo è successo giorgio spiega me lo trovi che un tuo amico no e quindi lo conosci come cioè hai avuto modo di capire per quale motivo da un tool fortemente opinionato come angular che è un binario battuto dove diciamocelo se tu te lo sei studiato è difficile smerdare fuori ok a un tool veramente libero dove la distinzione back end front end è una delle libertà che hai ma anche immagino tante altre e quindi mi chiedo c'è stato un percorso condiviso con la community o un percorso del creatore che l'ha portato ad aprirsi allora lui ha raccontato dall'annuncio della versione 1.0 quindi pochi giorni fa ha raccontato un po quello che l'ha portato a scrivere scrivere quick e lui ha detto che in una conferenza che ha avuto nel 2018 se non mi ricordo male parlava già di questa idea che lui aveva di poter magari renderizzare solo quello che serviva eccetera eccetera cioè aveva messo un po la pulce all'orecchio alla community su quello che voleva poi realizzare solo che ha detto che lui ha lanciato l'idea però nessuno l'ha colta e poi nessuno degli sviluppatori che conosceva comunque delle community in generale si era poi messo a lavorarci seriamente quindi poi si è messo lui di sua spontanea volontà perché comunque ci credeva e poi ha trovato nella società che sta seguendo quick un partner per poterla andare a sviluppare e realizzare la sua idea lui in realtà dopo anni di google ha deciso e è venuto in mente come poter sistemare il problema che affligge molte applicazioni frontendiche quelle delle performance perché se andiamo a vedere le performance di molti siti le andiamo a verificare su pagespeed che è un tool offerto da google vediamo che molti dei siti non passano appunto questi famosi parametri necessari per rendere le applicazioni performanti comunque fruibili tranquillamente lui aveva questa idea e quindi se l'ha poi portata avanti nel corso del tempo quindi è da un po che c'è dietro.

Quindi questo tipo di quick immagino aiuti anche dal punto di vista serio a questo punto che era anche uno diciamo di che non è anche uno dei punti tipoli di tutto il mondo delle single page application che nonostante siano belle fighe e sbrucci cose sui core web bytas vanno benissimo devi inventarti qualche soluzione un po più così dal punto di vista se sono proprio ben viste col corso dei anni sono state migliorate tante cose però effettivamente per come me lo stai descrivendo perché è un tool che aiuti anche da questo punto di vista io ho sentito frizzata la voce anche io va bene allora ripeto tagliamo da come mi stai descrivendo qui che mi sembra che venga in conto anche diciamo a quell'esigenza di ottimizzazione dal punto di vista serio che è una di quelle cose che affligge comunque tutt'oggi seppur con tanti miglioramenti le single page application quindi con qui che è possibile fare un first meaningful render che sia veramente pensato nel senso io voglio che appaiano queste sezioni con questo html con questa semantica perché fa bene anche alla mia parte serio insomma sì sì sì ti dirò alla fine non bisogna neanche sbatterci più di tanto la testa nel senso che si sviluppa l'app come sia sempre sviluppato e tra l'altro come sintassi per la parte di templating si usa jsx può piacere non può piacere però comunque è uno dei più famosi e quindi si è stato è stato deciso di utilizzare quello perché appunto è tra i più famosi e quindi io sviluppo l'app tranquillamente poi di fatto per come è pensato il framework mi ritrovo già ad avere delle performance che non sfiorano il 100% poi chiaramente le immagini che sono in webp ti portano al 100% oppure della dimensione caricata correttamente ti portano al 100% però già di suo sviluppando quindi potrei dire anche uno junior mi posso anche vendere questa cosa cioè lo junior sta sviluppando l'app e di suo non è che deve pensare questa parte di applicazione devo caricarla l'easy piuttosto che l'altra lo fa già di suo il framework quindi posso avere già un'applicazione che permette di avere performance e SEO che sono necessari per i siti pubblici per esempio.

Faccio il ravecchio della situazione, posso avere controllo qualora lo volessi sapere o controllare cosa viene renderizzato prima cosa viene renderizzato a runtime cosa viene renderizzato sul server che poi viene spedito alla client perché da quello che hai detto c'è hai detto non ci devi pensare ci pensa il framework però siccome appunto sono vecchio se ci voglio pensare posso pensarci o ci sono c'è la possibilità c'è la possibilità tramite configurazione di poter decidere cosa renderizzare come e perché c'è la possibilità per chi vuole effettivamente spingersi al di là di quello che poi già il framework ti dà out of the box perché ci piace usare gli inglesismi e si può fare appunto tramite configurazione.

Ok, una domandina che avevo in mente in questi minuti allora qui che quindi abbiamo detto un framework perché un framework c'è la diatriba su react che è una libreria un framework quindi QUIC è un framework e che cosa cosa non ha il suo interno che ci dobbiamo apportare tipo non lo so per fare richieste esterne HTTP o interazioni col database o che altro c'è qualcosa internamente che offre QUIC o ci dobbiamo apportare le nostre librerie di fiducia di fiducia dentro? Allora è come più o meno come come gli altri framework quindi come come react cioè non è come un angular che già ti dà tutto un pacchetto pronto di fatto però quello che vai ad utilizzare adesso che ormai fetch è diventato lo standard si utilizza fetch per fare le chiamate HTTP e poi già nel nel core quindi nel core del framework ci sono tutta una serie di integrazioni che è possibile utilizzare tramite CLI quindi io posso non solo andare a decidere di aggiungere ad esempio Tailwind e quindi c'è chi piace chi non piace comunque posso aggiungere Tailwind e quindi dico QUIC add Tailwind e lui già ci configura tutto ma per parlare con il database c'è già l'integrazione con Prisma piuttosto per andare a fare end to end c'è Playwright piuttosto che Cypress e anche tutta la configurazione per quanto riguarda il cloud quindi abbiamo Azure Cloudflare e Google non vorrei dimenticarvi qualcuno quindi poi c'è la lista non vorrei elencarli tutti.

So che stavate facendo qualcosa con AWS perché te l'ho sentito dire nel podcast degli amici di Continuous Delivery no? Sì sì sì aziendalmente stiamo siccome siamo partner AWS stiamo portando avanti l'integrazione con AWS Lambda.

Nota a margine risalutiamo come in quasi tutte le puntate Edo Paolo e tutti i ragazzi di Continuous Delivery hai parlato di testing è una roba che io ho utilizzato a parte Playwright e Cypress per fare gli end to end test una roba che io ho usato fino alla nausea e l'ho amata e odiata contemporaneamente era Testing Library nel caso specifico React Testing Library è utilizzata prevalentemente per fare dei test end to end la utilizzavo io almeno per fare i test scusate dei test unitari di componente.

Abbiamo qualcosa del genere in ambito QUIC? Attualmente che io sappia no però comunque i progetti che partono dagli sviluppatori individualmente ne sono tanti ad esempio c'è tutto il modulo per gestire le form un po' come fosse React Hook Form quindi alla stessa maniera più o meno c'è una libreria che ti permette di farlo quindi sono tanti sviluppatori che stanno un po' cavalcando l'onda e stanno creando la propria libreria per il proprio caso d'uso tra l'altro qui mi faccio autosponsorizzazione ho sviluppato il componente Image che è il componente che ti permette di avere delle immagini ottimizzate e l'ho messo appunto come libreria per QUIC.

E questo dimostra il fatto che essendo un framework giovane scommettendoci addosso rischieresti di comunque ritagliarti un pezzo importante in quella community che è una cosa interessante ed è un po' la scommessa che hai fatto tu hai fatto all in su QUIC io mi ricordo sei venuto qua ai nostri microfoni e hai parlato di Svelte, Svelte e Svelte Kit tra l'altro mi sono divertito un sacco in quell'episodio a fare lo stronzo a provocarti ma non ti ho fatto arrabbiare infatti ho detto adesso devo capire se Giorgio è tipo un monaco buddista o cosa perché aveva attenuto la plomb super tranquillo e io rompevi i coglioni come pochi no però a parte questo tu hai veramente fatto all in su QUIC e la community sta crescendo e ci sono un sacco di spazi so che hai lavorato anche ad altri elementi all'interno di QUIC no altri sottoprogetti chiamiamoli così o progetti correlati come è stato costruire un progetto all'interno di quella community come l'hai vissuta l'esperienza? Allora diciamo che comunque come community è molto coinvolgente non ci sono diciamo i cattivi di turno quindi quando si fanno magari delle domande semplici non ti dicono vai a leggerti la documentazione ti cercano comunque di dare una mano e questo è un grande vantaggio e come ho detto forse da altre parti secondo me è l'API quella che non è con il codice è l'API quella feature che effettivamente ti può fare la differenza tra un framework che poi prende effettivamente piede e uno che invece rimane indietro.

Essendo che ho scommesso fin dall'inizio su QUIC poi ho avuto la fortuna di poter entrare all'interno del server c'è un canale che sono i QUIC heroes chiamato così che sono quelli un po' che sono gli early adopter quindi molti annunci come quello dell'annuncio della versione 1 che sarebbe stato appunto fatto l'ho avuto in anteprima quindi alcune informazioni vengono comunque date in anteprima e alcuni progetti come quelli che sto seguendo sto seguendo la libreria di componenti per QUIC quindi sono maintainer di quella libreria e l'idea è nata da lì l'idea di fare una libreria di componenti e lì poi ci siamo messi abbiamo diciamo settimanalmente ci troviamo per andare a decidere come poter sviluppare il tutto e ci abbiamo investito diverso tempo non lo nego però comunque sono soddisfazioni.

Ti faccio una domanda che è avuta ora mentre parlavamo come funziona tutta la pagina o almeno è integrabile tutto diciamo il sistema di RPC sostanzialmente con il singolo end apponti le sezioni delle funzioni sul server con una possibile autenticazione nel senso c'è già qualcosa di pronto diciamo per tutta la parte di autenticazione più nel dettaglio autorizzazione della serie se replico quella chiamata e la forgio e quel pezzo di codice che viene subito sul server è solo per gli utenti o per l'utente di un copallo il framework ha un modo nativo con integrazione per prevenire che io faccia questa cosa se non ho l'autorizzazione giusta.

Sì sì c'è l'integrazione con Out.js che diciamo è il vecchio Next Out.js poi ha cambiato nome quando è diventato cross framework e c'è l'integrazione se non sbaglio forse fatta direttamente da un core del team non vorrei sbagliarmi e quindi direttamente si può integrarsi e avere la sessione tramite che è un po' quello che mi chiedevi la sessione dell'utente quando poi io eseguo le varie chiamate eccetera eccetera quindi c'è già questa integrazione e come prossimi step diciamo dalla versione 1 adesso abbiamo un qualcosa di stabile il team ha detto che vuole in un futuro nelle prossime settimane prossimi mesi aumentare ancor di più queste integrazioni per poter dire ok abbiamo praticamente tutto cioè voglio integrarmi con GraphQL lo posso fare ecco che con la CLI lo posso integrare velocemente voglio fare quest'altra cosa ecco che ho già tutto pronto quindi l'obiettivo è anche andare in questa direzione.

Ok ok e Quick City invece? Sto parlando adesso sulla documentazione.

No mi ha detto Alberto che si chiama? Allora Quick City è praticamente la parte di routing quindi la libreria che da routing e fa il server side rendering è stata chiamata City onestamente non so perché si chiama City però credo che sia per le route che sono le rotte quindi ho immaginato fosse strade quindi poi un gioco di parole e l'hanno chiamato Quick City è un nome a mio avviso poco felice però alla fine un nome dovevano dare è andato quello quindi Quick diciamo è la parte di rendering la parte di logica applicativa se così la possiamo chiamare mentre la libreria quella che ti da routing e altre funzionalità è Quick City.

Scusami a parte che quando hai detto Quick City a me è iniziata a suonare in testa la canzone di Mattafix giusto a dimostrare che sono super vecchio Big City Lights no? Però cazzo mi sono dimenticato la domanda sono proprio una merda no volevo chiederti in realtà hai parlato della Klee il concetto di Klee è un concetto potente che si vede pesantemente in Angular ma che in altri framework è un po' più remissivo lo spazio della Klee per la logica del codice generato dolore nel mantenerlo come lo vedi nel contesto di Quick questo tipo di problematica lo so sono rompicoglioni non volerne io ti voglio bene ma sai faccio sempre domande stronze.

Allora devo dire che sono molto attenti a questa cosa e qui posso portare un mio caso personale nel senso che avevano chiesto all'interno del server Discord chi aveva voglia di poter implementare quella famoso componente immagine che alla fine cosa fa? Vrappa l'immagine ma ci aggiunge magari le funzionalità di pre-loading eccetera eccetera quindi ti arricchisce già quindi ti vrappa un po' le difficoltà di poter renderizzare un'immagine che strizzi l'occhio alle performance e avevano detto ok chi ha voglia di implementare poi le inseriamo nel codice core e ho detto va bene benissimo ho la possibilità di poter entrare dentro il codice core e ho implementato la funzionalità.

Una volta implementata però passa il tempo passa il tempo la PR rimane lì e a un certo punto ho chiesto Lumi e mi hanno detto guarda mi dispiace ma non vogliamo includere altro codice che poi dobbiamo mantenere all'interno del codice core e quindi poi io facendo parte di questi qui Kiros che abbiamo detto prima abbiamo anche un account GitHub e quindi ho creato lì la libreria.

Direi che loro sono abbastanza attenti a queste cose diciamo che poi lo starter per quindi le nuove integrazioni non è troppo codice da dover mantenere.

Mi ero segnato questa cosa, l'ho ritrovata.

Leggendo un po' in giro ho trovato anche persone che utilizzano React con Qwik, questa idea si chiama Qwik React.

Allora che senso hanno? In che senso? Uno perché immagino il motivo sia utilizzare quello che uno ha già ma come riesce ad integrarsi il tutto e soprattutto è una cosa consigliata? Si ma io posso vendere qualunque libreria React e potercela mettere dentro? Grosso modo ti direi di sì nel senso che è stato fatto perché comunque va bene React e JSX quindi il templating è simile e poi per aumentare l'adozione è stato deciso di fare questa API che sostanzialmente wrappa il componente React e lo rende utilizzabile in Qwik.

Questo è pensato non certo per andare in produzione o comunque per portare questo tipo di approccio alla lunga ma per appunto pensare a una migrazione graduale delle proprie applicazioni con Qwik.

Diciamo che si va a perdere un po' i benefici che sono la resumability eccetera eccetera però in una fase di transizione è più che accettabile.

Ok Carmine mi aveva rubato la domanda che era esattamente quello che volevo fare.

No mi trovo molto molto molto interessante il concetto che ha la base di Qwik quindi dividere il JavaScript in chunk che vengono caricati in anteprima dal service worker senza interferire con il main thread e poi caricare ed eseguire anzi soltanto quello che solo quello che serve e tant'è che stavo pensando caspita stavamo rifacendo il nostro back office in React che quasi quasi mi sarebbe piaciuto provare e cominciare a mettere i tasselli di Qwik.

Cosa adesso ho considerato che siamo in una fase ancora di templating di appunto di mockup quasi quasi stavo vedendo se esisteva un tool o un qualcosa non si le hai un comando che potesse fare una migrazione automatica ma questo mi sembra che non sia possibile quindi non usare React dentro Qwik e poi migrare pian piano ma proprio una migrazione uno a uno di componenti o moduli o modelli o non so che cosa quindi cosa mi consigli fare di fare detto detto in soldoni? Ha senso interrompere tutto rifare da zero quello che stavo facendo o a fare un usare un approccio mi piacerebbe provarlo ecco ok allora quello che solitamente consiglio è se tu hai un'applicazione che già ti dà diciamo dei soldi ti sta facendo guadagnare eccetera eccetera magari non prevedi dei nuovi sviluppi prevedi che magari possa rimanere così a lungo quindi senza nuove funzionalità non ti consiglierai di andare a migrare tutta la codebase per passare a Qwik solo perché esiste Qwik diverso invece che se hai un sito pubblico che ha bisogno magari delle performance che diciamo prima che magari sono difficili da ottenere e bisogna ottimizzare parecchio per raggiungerle lì invece ti direi magari prova in maniera incrementale a migrare il tuo sito la tua applicazione sempre nel server discord ci sono molti esempi di magari dei siti che sono magari di diaste che magari l'home page che è quella che magari viene visitata di più e che viene raggiunta dai motori di ricerca viene migrata solo alla home page a Qwik il resto invece è con la tecnologia che hanno sempre utilizzato quindi fanno anche questo approccio ibrido proprio per sfruttare il fatto che come performance è il top.

Hai parlato di siti ma secondo te è maturo abbastanza da provare a scommettere per fare un back office quindi proprio un gestionale, un dashboard forma su forma immagini e chi più ne ha più ne metta? Sì sì al mio avviso sì per quanto riguarda invece diciamo il back office se hai già un'applicazione che gira e funziona l'utente del back office anche se aspetta quel secondino in più non fa la differenza.

C'è da dire che comunque per l'approccio che ha quindi se io vado a interagire con una determinata pagina eseguo quel javascript non importa se la tua applicazione è piccola o enorme alla fine quello che sono le performance sono sempre le stesse cioè lui spedisce html e css e quel singolo kilobyte di javascript quindi anche se la tua applicazione è enorme non vai a pagare il javascript di tutta questa applicazione enorme perché tanto la vai a eseguire in maniera lazy.

Esattamente quello che appunto pensavo come vantaggio perché mentre un sito bene o male può rimanere fisso nel tempo un back office di un'applicazione che è sempre in continua evoluzione può complicarsi anche a piacere oppure anche in modo esponenziale nel corso degli anni e quindi quello che per te non è una priorità quindi la sovraottimizzazione dei tempi o il fatto di non tenere in considerazione le performance a un certo punto comincerà ad essere una priorità ma sarà anche troppo tardi per poter intervenire chirurgicamente a migliorare le prestazioni.

Io ho una domanda, un beso di Giorgio, se io dovessi ad oggi iniziare un nuovo progetto con Qwik cosa mi consiglieresti di fare? Che percorso mi consiglieresti di prendere anche per apprendere quelle che sono i nuovi concetti per esempio la riesumabilità è uno ma so che ci sono altri concetti under the hood che un po' cambiano.

Questa è una bellissima domanda se io doveressi approcciarmi a una nuova applicazione con Qwik o comunque in generale a questo punto è un discorso che farei più in generale con una tecnologia che non ho mai utilizzato comunque nuova andrei a cercare di capire quali sono i pezzetti che mi servono cioè mi serve l'autenticazione fatta con Cognito provo a fare un POC dove integro quel tool, quello strumento, dopo devo utilizzare server postgre e utilizzare Prisma, provo a fare un POC dove mi connetto al database e dialogo quindi faccio delle prove per verificare che effettivamente la tecnologia ok è nuova però va a coprire le mie necessità perché magari il rischio è quello di dire ok partiamo con Qwik perché è il nuovo framework, è in hype, tutti siamo contenti di lavorare eccetera eccetera poi ci troviamo che alla settimana 7 di 15 dove quindi siamo a metà del nostro percorso e dobbiamo rilasciare assolutamente ci accorgiamo che magari non riusciamo a integrarci con l'autenticazione e quindi ci troviamo fermi bloccati e quindi conviene pensarci prima magari con delle spike, dei POC per verificare che tutti i pezzetti possano effettivamente tornare e poi lavorare, iniziare a lavorarci seriamente.

O magari sarebbe una buona occasione per contribuire al progetto sviluppando quello che ti manca e quello che ti serve, piccola sponsorizzazione al mondo dell'open source.

Chi è che usa la produzione Qwik davvero? Allora ci sono diverse aziende, poi chiaro che ci sono quelli che le usano e quelli che lo pubblicizzano.

La stessa azienda che l'ha creato ovviamente è il sito principale e altri siti tra l'altro se non sbaglio anche il sito quello del Super Ball che quando accade ha un carico non da poco, è stato fatto con Qwik e poi c'è un'altra persona che ha sempre presentato il proprio use case durante la presentazione della versione 1.0, detto che ha fatto un sito, no profit eccetera eccetera e gli era capitato appunto di fare una presentazione all'interno di uno stabile che era situato in una città dispersa e quindi poca connettività e oltretutto l'ha fatto in un sala meeting dove effettivamente prendeva poco segnale.

Quello che è successo è che anche i partecipanti al meeting che hanno visto la presentazione si sono domandati se il sito che caricava in pochi millisecondi fosse un mock o un sito vero e proprio, così poi il presentatore ha detto ok andate con il vostro cellulare a vedere e le persone coinvolte hanno detto che effettivamente tutti i siti che andavano a visitare essendo che la connettività era bassa solitamente ci mettevano diversi secondi mentre quello che poi ha creato lui e che presentava al pubblico ci metteva pochissimo.

Devo dire che l'idea di Quick è geniale, ditemi se mi sbaglio, ma io la trovo molto molto molto vicina all'idea che ebbe Daniel Ek quando fece Spotify, non so se vi ricordate no, Daniel Ek aveva come obiettivo non mi ricordo forse 30 millisecondi per il caricamento della canzone e quello che fece con Spotify fu possiamo immaginarlo come un web worker perdonami un service worker che quando tu stai ascoltando una canzone in background tu ti sta scaricando anche le successive pronte per essere playate quindi un po' lo sento questo flavor quando ci parli di Quick, mi sbaglio ha un po' un ritorno un po' il concetto non conosco nello specifico il caso che hai portato però credo di sì se tu hai visto delle somiglianze non posso che dirti secondo me sì naturalmente questo lasciamo la discussione al gruppo Telegram però lo sentivo l'odorino di ambito diverso ma più o meno stesso concetto quindi io ti servo quello che ti devo servire subito nel minor tempo possibile e poi con calma ancora prima che tu me lo chieda o appena che me lo chiedi io te lo do subito mi immagino che ne so un domani si potrà arrivare a dei framework dove se tu passi il mouse troppo vicino a un pulsante lui quel pezzo di funzione se lo scarica ancora prima di cliccarlo sarebbe fighissimo una feature di questo tipo no e quindi in questo caso controlli non solo quello che viene dato in carico al main thread di javascript ma anche quello che viene dato in carico alla rete sì sì ci sono dei concept che lo fanno diciamo anche che in base che in base credo che si chiami guess.js o qualcosa del genere cioè in base poi anche a delle metriche che vengono che vengono salvate dicono ok l'utente quando entra la prima cosa che fa è cliccare quel link e quell'altro link invece non lo clicca mai quindi è chiaro che magari si dà la precedenza al download di quel determinata sessione sì ma proprio per come è costruito quick per come funziona quick secondo me questa cosa sarebbe fighissima per i siti di contenuto d'altro ta...

l'autotraffico ho visto che intanto doveva dovevamo sempre essere rapidi ormai sono anni tre anni che esiste il podcast tre anni diciamo che dobbiamo stare dentro l'ora e siamo come di consueto abbondantemente oltre l'ora grazie giorgio per aver condiviso guess.js nel gruppo interno è arrivato il momento tipico e topico di geek bar il momento il paese dei baluchi momento in cui i nostri guest e i nostri host condividono con noi qualcosa che abbia catturato la vostra attenzione la loro attenzione e che pensano sia porti valore condividerla nella nostra community io non riesco più a articolare il discorso quindi lancio subito la palla a giorgio hai qualcosa da condividerti con noi? e conducono il paese dei baluchi! ah il paese dei baluchi! sì allora io volevo condividere un libro per gli amanti anche della module federation e il libro è building a micro frontends in camera si vede ok e del mio amico luca mezzalira a me è piaciuto molto soprattutto perché nella parte finale sono racchiuse tutta una serie di esperienze che i vari utenti che sono stati intervistati hanno lasciato quindi l'ho letto molto volentieri e lo ringrazio per questo questa perla dai che ci ha regalato bello bello bello è stato luca venne la prima volta qua quando lo stava ancora scrivendo è venuto la seconda volta per parlarcene ed è veramente un bel libro e luca è anche lui un amico un amico di gitbar quindi super baloco super apprezzato carmine e luca allora io vorrei portare qualcosa che ho scoperto qualche giorno fa è un libro si chiama i programmers introduction to mathematics puoi guardare anche la mia app sono abbastanza tappato anch'io ed è praticamente un libro in inglese dove sostanzialmente vengono trattati gli argomenti di matematica base che sono secondo l'autore una base solida da avere per chi sviluppa software la chiamo matematica base ma in realtà è abbastanza variegato va dai polinomi ai grafi alle atrici a le equazioni alle serie numeriche insomma diciamo è un po eccetto c'è diciamo un po un misto sia con degli esercizi sia insomma con la parte teorica che viene spiegata io sono una caprissima ma tematica ho fatto analisi 6 volte a 24 lo dico senza senza vergogna anche per me è stata una ripetizione ed è spiegato molto molto bene perché è spiegata in una maniera molto pratica e legata a concetti di programmazioni che sono strettamente legati alla matematica ma che spesso magari ignoriamo e che c'è più facile comprendere nella loro declinazione nella loro declinazione della programmazione è un libro gratuito che potete scaricare con 0 o più euro se volete fare una donazione all'autore oppure potete comprare la copia fisica su waw mi pare una garantia di euro.

Bello bello e un backlog.

Luca? Bello allora proprio oggi mi è capitato tra le mani anzi davanti agli occhi un video di youtuber che fa riferimento a un libro che avevo già balloccato proprio nell'episodio con Luca Mezzalira che è da software The Architect Elevator, quello era il libro già balloccato e quindi non lo riciclo in realtà oggi ho visto mi è capitato tra le mani un video dove proprio l'autore Gregor Hop fa sostanzialmente un riassunto di una parte del suo libro di questo libro che è molto interessante e che cito quello che ho detto l'altra volta dobbiamo lavorare in modo che il sogno di un software architect non diventi l'incubo dei programmatori, degli sviluppatori e in generale dell'azienda, dell'azienda stessa che lascerò il video il link del video in descrizione però mettiamo anche il link del libro certo che è valevole di condivisione.

Bello, bello cioè praticamente io pensavo di avevo pianificato di farvi un po' di vacanze tra qualche settimana e praticamente mi avete rovinato le vacanze raga cioè aspetta non mi avete rovinato le vacanze a me avete regalato delle bellissime vacanze le avete rovinate a mia moglie Mauro vuoi uscire? No aspe un altro capitolo per favore questa sarà la situazione standard io non vi porto un libro perché ne abbiamo condiviso abbastanza vi porto due giocattoli il primo è un browser io su mac è da tempo che utilizzo arc in preview è un browser particolare con un sacco di funzioni ne ho già parlato in un altro episodio però questo periodo ho ripreso a utilizzare la mia macchina windows e mi mancava arc mancava arc non esiste per windows esiste solo per mac os e cercavo un browser che mi permesse mi permettesse di avere dei tab always on delle folder ben gestite funzionalità di notifiche integrata fatta bene con i beggettini nell'applicazione che riceveva insomma mi serviva un browser un pochino più intelligente del classico chrome ne ho beccato uno che non è arc ma in qualche modo ci si avvicina il suo nome è sidekick usa chrome sotto il cofano è un browser carino ci sono diversi works puoi crearti diversi workspace è una roba bellina quindi buttateci un occhio se se anche voi avete windows o simili perché credo sidekick ci sia per tutte le piattaforme non vorrei sbagliare secondo balocco balocco game changer se sei se non sei un native speaker balocco baloccato tante volte ma c'è stato una major release devastante grammarly raga allora io ho l'abbonamento pro a grammarly e ho anche siccome sono proprio capra ho anche l'abbonamento pro a word tune un tool che fa sentenze rewriting li ho fatti prima che uscisse con tutto il clamore gpt e i suoi baldi giovani amici e ho fatto i due abbonamenti da un anno questa settimana credo grammarly è uscita con una feature che praticamente mi fa chiudere l'altro abbonamento che è word tune che si occupava appunto della riscrittura delle frasi perché in realtà ti permette la riscrittura delle frasi ma la cosa più bella è del motivo per cui a me stavano antipatici questi tool e mi ero sviluppato il mio text editor ne ho parlato con qualcuno di voi e anche in un episodio credo se non l'ho fatto vi farò un episodio a breve dove vi racconto con l'esperienza di farsi un text editor perché mi ero fatto il mio text editor perché non riuscivo a integrare tutti questi strumenti no e allora facendo un po di reverse engineering di impiastriciamenti e hacking vario mi ero fatto il mio text editor dove avevo sinonimi e contrari ben integrati avevo sentence rewriting grammarly le api di reverso che non sono pubbliche ma io lo sappiamo basta una fetch fatta bene e insomma tutte queste belle cose e poi grammarly esce con una feature dove il grammarly plugin non è più solo ben integrato nel browser motivo per il cui io per lungo tempo ho utilizzato slack nel browser ma si integra perfettamente col sistema operativo quindi qualunque casella di input di testo all'interno del sistema operativo sia l'input box di slack che la chat qua su stream yard c'è il plugin floating c'è l'iconcina floating di grammarly e tu hai tutte le funzioni di grammarly compreso il test rewriting con l'ai ovunque all'interno del tuo sistema operativo per chi come me scrive un inglese racapricciante beh e anche per chi lo scrive abbastanza bene un ottimo modo per andare a spottare porcherie o alienismi che tanto ci scappano perché non siamo native speaker.

Detto questo io ringrazio tantissimo Giorgio per essere venuto a trovarci come sempre e tu ben sai gitbar è anche casa tua se riesci a ritagliarti del tempo perché ho visto che anche tu stai facendo più date dei Rolling Stones stai girando parecchio questo periodo quindi comunque quando vuoi qua c'è sempre una birra fresca per quanto virtuale pronta a essere stappata.

Grazie mille grazie mille è veramente un piacere innanzitutto parlare con voi e spendere del tempo insieme parlare di tecnologia è qualcosa comunque di molto bello e sapere che qui poi posso sempre trovare una birra fresca è una figata anche perché la birra calda fa cagare a me quindi io ringrazio anche Carmine e Luca e devo dire una cosa io oggi sto veramente di merda non siete accorti che la mia lucidità è praticamente assimilabile alla lucidità di Uncle Bob mentre twitta quindi devo davvero ringraziare di cuore Carmine e Luca che praticamente sono gestiti la puntata e tra l'altro si sono gestiti una puntata che mi è piaciuta un botto e che quindi voglio dirvi che il fatto che i cost gestiscano buona parte della puntata sarà il mio obiettivo del 2023 quindi cazzi vostri raga ma in realtà ti ricordi gli ammutinati in realtà ti stiamo abbelenando pian piano così ti facciamo fuori e prendiamo di nuovo finalmente un proprio delabro.

Si no è davvero bellissimo io sono in un brodo di giugiole grazie grazie di cuore.

Grazie a te e soprattutto speriamo di aver dato di aver fornito gli strumenti necessari per essere anche oggi anche questa settimana sviluppatori migliori con un occhio alle performance che sono spesso distrattate spesso sottovalutate ma secondo me sono importanti e ci dobbiamo dare sempre più occhio attenzione.

Io vi ringrazio di cuore ragazzi e vi do appuntamento alla prossima settimana anticipandovi che ci saranno tantissimi tantissimi topic interessanti ve ne spoilero giusto uno per mettervi la culina in bocca uno sarà parleremo di.

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.

Ma che stronzi questi programmatori telefono a quelli di metri a Cambridge..