Bene e benvenuti su Gitbar, sono iperissimo felice, iperfelice di riprendere le registrazioni, ho un po' perso il ritmo, fondamentalmente rischio di essermi dimenticato un po' come si fa, però riparte Gitbar, intanto devo fare un piccolo ringraziamento agli ammutinati che si sono presi di cura di Gitbar in questo periodo che io ero assente dalle scene e e con questa puntata possiamo dire che riniziamo a registrare i nostri episodi riniziamo, cerchiamo di far partire una stagione un po' diversa come vedete manca il green screen, abbiamo un nuovo studio di Gitbar lo sto ancora un po' definendo ma sarà pronto presto abbiamo una nuova bella stagione con un sacco di episodi è quello di oggi e uno degli episodi super interessanti della nuova stagione.Cercheremo di portare anche qualche, qualche novità.Voglio però prima di iniziare fare un piccolo inciso.Sono un po' sparito dalle scene perché ho avuto un po' di questioni, questioni personali, ho avuto un po' di questioni personali che hanno definito quella che era la priorità delle cose da fare.Come sempre bisogna capire quando è il momento di staccare la spina e riequilibrare un attimo con rischio o comunque prendendo la decisione di lasciare alcune cose ferme e Gitbar è stato uno di questi, non perché la community di Gitbar non sia importante, anzi lo è tantissimo, ma perché certe volte per poter fare qualcosa che valga la pena essere fatto bisogna stare in forma e bisogna stare lucidi e io non lo ero.Quindi questo insomma vuole essere un modo per ammettere le mie debolezze e soprattutto per dire anche a voi stessi se non state bene non abbiate paura di bloccare tutte le attività, prendervi il tempo, ritornare in forma e poi ripartire più forti di prima.Detto questo, bando alle ciance io direi di far partire la sigletta e di presentare il super ospite di oggi.Siamo noi quelli che leggendo il codice cercano lo stronzo che ha scritto quello schifo, Ma ahimè, lo stronzo è mai medesimo, ma l'ho scritto giusto ieri.And I'm sorry.Siamo quelli che santificano il nuovo framework JavaScript preferendo segretamente jQuery, gli stessi per il quale il testing è importante, infatti la nostra codebase ha solo due test, e flakey pure.Siamo noi quelli che il tuo linguaggio fa cagare, ma il mio è peggio.Quelli che la chiarezza nei commit message prima di tutto, e dentro ce l'appella tutti i Santi.Quelli che in call parlano per 5 minuti prima di accorgersi che il mic è muto.Quelli che non si può fare di default, diventa velocemente un tutto e possibile se hai le risorse, tempo e budget dilimitato.Siamo noi quelli che lei ha IVA regolamentata, mai visto questo nuovo modello che disegna gatti di funambuli? Quelli che il dipende e unisci gratis la prigione.E quelli che la RAL...no vabbè, fa già ridere così.Siamo quelli che fanno lo slalom tra le specifiche che cambiano costantemente, ormai rassegnati che la definition of ready è solo una pia illusione.Quelli che si sentano dire "ho un'idea per un'app" ed è subito l'ennesimo social come Instagram, ma meglio.Siamo noi che nonostante il deploy fallito, la CIA rossa, il business incazzato, ci troviamo al Gitbar e davanti a una birra tutto ci sembra un po' meno grave.E una birra risolve sicuramente tutti i problemi, ho bevuto più di una birra con l'amico che abbiamo oggi qua su Gitbar, abbiamo con noi Marco Ippolito.Marco, io non saprei fondamentalmente come fare la presentazione, no? parte del Node.js, TSC, TSC, un sacco di attività, conferenze internazionali, attualmente stai su Herodevs, mamma mia, cioè veramente la prima domanda che voglio farti è come gestisci l'equilibrio lavoro attività e te stesso.Ciao Mauro innanzitutto grazie per avermi qui, è passato un po' di tempo dall'ultima volta che siamo fatti due chiacchiere, che dire ormai soprattutto in questo periodo faccio un po' fatica a bilanciare il lavoro, l'open source, le conferenze.Il primo periodo dell'anno, fino a giugno, ho cercato di prendermi un po' una pausa dalle conferenze perché mi ero reso conto che effettivamente stavano rubando un po' troppo tempo, però cavolo cioè la mia voglia di fare mi spinge veramente a riempirmi la giornata.E adesso ti faccio una domanda difficilissima.Hai messo il lavoro, l'open source, le conferenze, in quale sequenza ordineresti questi tre elementi? Questa è una domanda bastardissima, lo so, ma...Gait Bar è noto per fare queste domande poco friendly! Allora, se dovesse sentirmi il mio datore di lavoro probabilmente non è che sarebbe molto molto contento, però io metto l'open source prima del lavoro, poi ovviamente il lavoro e poi le conferenze.Questo perché? Uno perché il lavoro l'ho trovato grazie all'open source, quindi se non avessi, diciamo, se non fossi entrato in questo mondo probabilmente sarei a fare tutt'altro.E due perché ho trovato tantissimi amici, tantissime persone, community e diciamo alla fine quello viene, secondo me un po' prima.Certo i soldi servono per mangiare quindi se dovessi trovarmi in una situazione sfavorevole sicuramente metterei il lavoro in primo piano, però finché ci sono insomma open source.L: Cosa ti spinge alzarti la mattina o comunque dedicare parte del tuo tempo libero all'open perché sai se il lavoro lo fai perché a fine mese comunque c'è la tua payroll e viaggi bene ma cosa diciamo quali sono gli elementi che alimentano la motivazione nell'open source? - Ma il primo, secondo me, l'elemento principale è quello della community, cioè sentirsi parte di un qualcosa più grande, fare qualcosa che poi viene usato da tante altre persone, cioè io credo che il fatto che le persone usino il mio codice, che se ne parli delle nuove feature, che il progetto vada bene, mi motiva un sacco.E poi un'altra cosa che mi motiva è anche incontrare di persona gli altri contributors, cioè c'è una sorta di feeling, di team, cioè comunque un po' in tutti gli ambiti, quando metti delle persone che fanno volontariamente un qualcosa si crea una bella atmosfera e questo mi fa molto piacere.A proposito di relazioni tra persone, io penso, io lavoro full remote quindi comunque costruire relazioni con persone a livello lavorativo è sempre molto complicato, però in un modo o nell'altro comunque ci sono le classiche water cooler o macchinette del caffè virtuali per cui su slack si chiacchiera del più e del meno, ci si condivide la postazione che è una cosa che va molto di moda, si condividono le foto dei gattini, proprio i gattini e cagnolini, anche questa cosa non sapevo ma va tantissimo di moda e ci sono oggi sono anche i gruppi magari di se l'azienda è abbastanza grande no dei papapancini e cose di questo tipo.In un contesto open source dove alla fine molto della comunicazione è fatta attraverso merge request oppure quest, come si fa a costruire quella relazione umana che poi ti dice "cazzo, cioè quello è un mio amico, non è solo un co-contributor ma è anche un mio amico".Sì, questo avviene molto quando ci sono i vari meet up, per esempio su Node abbiamo due meet up che sono il Node Collaborator Summit, oppure le conferenze, perché online è difficile creare community, cioè mi è capitato di avere le impressioni sbagliate di altri contributors al progetto, cioè magari, non so, io mi ero fatto un'idea di un'altra persona che lavorava con me sul progetto, solamente sbagliata, e poi quando lo incontri di persona, diciamo, ti rendi conto che dietro tutti quei pixel ci sono persone come te che anche loro hanno un lavoro, hanno altri interessi e quello che un po' ti lega è il progetto a cui dedichi il tuo tempo libero, quindi un 90% è meetup, cioè meetup e conferenze.Infatti questa è una delle motivazioni per cui spingo ancora tanto sulle conferenze perché è un po' la mia parte relazionale del lavoro cioè durante il quotidiano non ci sono meeting, c'è davvero poco invece alle conferenze c'è poi quell'occasione di socializzare.Chiaro, questo è verissimo ed era uno dei motivi per cui comunque io ero super attivo nelle conferenze o almeno lo sono stato per un per un periodo parliamo di relazioni con gli altri di comunicare quello che si fa tu qualche tempo fa sei andato super virale giusto con una pure quest.Ancora prima di entrare nel merito della pure quest ti faccio una domanda come hai gestito tutta questa visibilità? Allora per me è stato un...venivo da un periodo un po' particolare cioè io all'inizio di quest'anno anno, 2024, a febbraio ho fatto l'ultima conferenza e ho deciso di prendermi almeno fino a settembre un periodo un po' di tranquillità.Quindi cosa ho fatto? Quest'estate sono andato in montagna, in Abruzzo, in un posto sperduto, un piccolo paesino di 200 abitanti chiamato Santifemia Maiello, dove non prende il telefono, non prende internet, e ho comprato Starlink per passare l'estate e sono venuti altri miei amici e abbiamo fatto praticamente la maggior parte dell'estate smart working da lì quindi mi trovavo in un contesto super rilassante con comunque degli orari flessibili tranquillità e allora mi sono mi sono messo a lavorare su questa feature però mi aspettavo che ricevesse del riconoscimento, però non mi aspettavo così tanto hype rispetto a questa feature qui, quindi immagina ti trovi sperduto nel nulla, il fatto di avere tutta questa visibilità mi ha dato un po' di...diciamo...come dire...ha preso un po' del mio tempo, c'ha fatto...ero con i miei amici, quindi ci ha fatto sorridere, ci siamo divertiti un po' a vedere come le persone commentavano il feedback che ricevevo, quindi l'ho preso in maniera molto positiva, molto...anche le critiche perché comunque...- E infatti volevo arrivare là, no? sono in vista e infatti volevo arrivare là perchè non svegliamo ancora la feature che sarà poi, alla fine, l'argomento centrale dell'episodio però quando si aumenta di visibilità è normale che ci si prenda un po' di merda addosso io lo dico in modo brutale finché questa merda addosso arriva da...pincopallo che neanche conosci possa anche essere famoso va bene ma cosa succede se questa merda arriva da persone o da personalità in vista o personalità che stimi come come ti senti e soprattutto come la gestisci sta cosa? allora io lato social cerco sempre di non rispondere male cioè sui social sono sempre tranquillo accetto la critica e non cerco di non rispondere anche soprattutto su Twitter perché è un secondo che diventa una shitstorm.Invece sul personale spesso ci ripenso molto ad alcune critiche, magari alcune sono costruttive, hanno ragione, altre invece sono un po' frutto di una mancanza o di empatia sotto certi punti di vista, oppure mancanza di contesto.È una roba che ho notato tantissimo e che spesso alcune critiche che arrivano da influencer, persone che fanno corsi nel settore, queste persone mancano di contesto, cioè non hanno messo le mani nel fango sul progetto, non conoscono l'ecosistema così bene, magari conoscono bene un aspetto o molto bene quella tecnologia ma non inserita in un contesto più vario e quindi ho molte persone che magari stimavo che pensavo fossero i massimi esperti del settore poi mi sono reso conto che effettivamente sì, sono molto esperti ma poi girano un po' con i paraocchi ecco.Ma può essere anche un elemento dovuto al fatto sai un ecosistema di per sé ha la sua complessità e il suo carico cognitivo, chi mastera un ecosistema ha dovuto fare i conti con quel carico cognitivo e deve in qualche modo modo proteggere la sua legacy quindi tutto quello che ha appreso e quando qualcosa cambia questa stabilità nel dire ok io sono abbastanza esperto di questa cosa vacilla perché qualcosa di rischiosamente disraptive entra sull'ecosistema e quindi dico cazzo aspetta fammi fermare un un attimo, questa roba può essere rischiosa e magari tutto questo accade in un'area subconscia, non necessariamente è conscia per cui lo dici, agisci con malizia, ma è possibile che accada in un'area subconscia tale per cui dici in modo quasi automatico io sono tentato a proteggere quello che l'ecosistema base.Quindi può essere questo tipo di situazione? Sì, io credo che molto spesso sia proprio questo il motivo, cioè delle persone che sono punti di riferimento di una tecnologia che appunto, come dire, l'hanno fatta propria così tanto che ogni cambiamento esterno poi provoca un attimo di tensione e questo io l'ho notato ed è stata una motivazione secondo me che negli anni ha rallentato un sacco la crescita di alcuni progetti, cioè il fatto di essere poco propensi al cambiamento e di stare sempre, che è una cosa buona perché da un lato tuteli l'ecosistema ti metti un po' a guardiano ma dall'altro blocchi un po' l'innovazione e secondo me questo ora nell'ambito node il fatto di avere concorrenza da altri runtime ha cambiato esattamente questo in alcuni...infatti volevo arrivare là no? voleva arrivare là no? Nel senso oggi parliamo di Node.js e Ban piuttosto che Dino hanno stimolato in quella direzione però cosa...cioè Node ha avuto uno sprint ok ma cosa continua a essere essere sostenuto, perché io lo vedo comunque come il...il...il...il...No, Nod lo vedo un po' e ci lavoro tutti i giorni, amo Nod, ma lo vedo un po' come il vecchietto sano di principi, no? Non so come...come dire, no? E...e...e cosa invece l'introduzione di altri player, big player, perché ormai sono big player o comunque main player nel mercato l'ha portata a cambiare perché noi stiamo dicendo "Nod è cambiato" però io comunque questa sua solidità e questa sua tendenza a lossificazione no? A creare qualcosa che è quello...Cosa è rimasto di questa tendenza a lossificazione e cosa invece si è allentato, si è ammorbidito dell'approccio di Nod? Guarda, secondo me il tema principale è che, ora io senza nulla togliere gli altri runtime, ma Node di fatto detta lo standard del runtime javascript backend, cioè la compliance rispetto a node è uno dei fattori principali sia di BAN che di node2 cioè quindi node ha una responsabilità rispetto a proprio questo cioè quando viene creata una nuova API sai che probabilmente questa verrà implementata da altri due runtime sai che quando scegli, soprattutto sulla parte di moduli o comunque di API che poi verranno consumate da framework frontend, bundler, comunque dal resto dell'ecosistema, hai una responsabilità e quindi c'è bisogno di tempo per pianificare bene, per discutere, quindi è un po' naturale che il Nod sia un po' più lento, sia un po' più vecchietto.Dall'altro punto di vista secondo me c'è stato invece un cambiamento proprio nella parte direttiva di Nod, cioè il tecnica steering committee è cambiato in questi anni alcune persone sono andate via sono entrate nuove persone e c'è più voglia di modernizzare di far diventare il runtime più veloce più performante più api migliorare da developer experience mentre prima diciamo non essendoci competizione non essendoci voglia di innovare appunto era un po' un periodo un po' più stantivo e in questo periodo di innovazione dentro un odo possiamo inquadrare anche la tua la tua feature la tua proposta ci vuoi riassumere in due parole di cosa si tratta? allora le due parole specifiche sono proprio due sono type stripping ovvero prendere un file typescript e togliere i tipi.Quindi il node dalla nuova versione 22.6 permette appunto di utilizzare typescript nativamente, passando un flag sperimentale per abilitare l'afficcio, feature flag però questo nuovo modo di eseguire typescript sul runtime ha suscitato un sacco di interesse perché non è convenzionale aspetta che ti ho perso ti ho laggato un attimo no non è colpa mia stavo parlando muttato e anche per questa stagione la mia bella figura di merda l'ho fatta no dicevo puoi spiegarci bene perché definisci non convenzionale l'approccio allora principalmente TypeScript è una libreria javascript, cioè possiamo riassumerla come una libreria javascript che appunto prende un file .ts e lo trasforma in un file .js facendo questo effettua principalmente due tipi di operazioni quello che è appunto la compilazione e il type checking.Negli anni il typescript ha inserito delle feature nel linguaggio che non esistono nel linguaggio javascript cioè ti faccio un esempio gli enum, che sono una feature di TypeScript, non esistono nel JavaScript quindi c'è bisogno di una trasformazione perché queste feature, tipo gli enum in mSpace, sopravvivono al runtime Questo, come dire, è un po'...secondo me è un po'...ma anche secondo i maintainer di TypeScript, è un qualcosa che è stato un errore di gioventù del linguaggio e che piano piano si sta muovendo in una direzione opposta, ovvero quella di fare in modo che nulla di ciò che è TypeScript persista dopo la traspirazione, ovvero tutto il superset, tutte le feature che TypeScript aggiunge vengono rimosse ed è esattamente quello che fa la nuova feature, il nuovo supporto di TypeScript in Node.js ovvero prendere un file TypeScript, rimuovere tutto quello che si può rimuovere a runtime che non richiede una trasformazione e l'output eseguirlo come javascript questo è particolare perchè non lo fa nessun altro cioè vuol dire che quando ti trovi di fronte a una num vai in errore ora ci sono delle soluzioni, ci sono altre flag che supportano i vari num e tutte queste altre feature però il punto è che fare in questo modo ha dei vantaggi enormi sì perché a questo punto tu non abiliti flag, runni la tua test suite e sai benissimo cosa devi togliere via dal codice typescript per renderlo let's say allineato con quella che è la direzione ovvio come avete o hai implementato il supporto il typestripping dentro dentro node Sai, guardare sotto il cofano è la cosa che mi interessa di più perché è quello che dà un senso un po' poi alla feature, no? In generale tutta la feature è nata un po' da...mi viene in mente l'immagine del Signore degli Anelli, la Compagnia dell'Anello, in cui tutti mettono qualcosa sul tavolo lascia l'arco e un po' Frodo si fa carico appunto di portare l'anello che è un po' il fardello principale però ognuno gioca un ognuno della compagnia gioca un ruolo principale io in questa in questa feature sono effettivamente la persona che ha preso l'iniziativa e ha si fatto carico di questo fardello però la realtà è che senza altri progetti senza altre persone del diciamo intorno al all'ecosistema questo non sarebbe potuto succedere l'esempio più grande è quello di SWC.SWC è un progetto un traspilatore che appunto è quello che c'è sotto al cofano di node ma è anche quello che c'è sotto al cofano di dino.Che cosa è successo? Un altro membro del tecnica steering committee un giorno a caso ha scritto un messaggio su slack dicendo "ma perché non prendiamo SWC e proviamo a metterlo dentro node e a traspilare?" Il problema è che SWC è in Rust e Rust appunto aggiungere Rust alla toolchain di un progetto C++ comunque è impegnativo quindi nessuno l'aveva fatto allora ricerca un po qua scriviamo al maintainer bla bla bla e lui ci dice guarda vi preparo una versione in WASM e allora abbiamo preso appunto questa versione versione WASM, l'ho presa, l'ho smanettata un pochino e ho visto che era molto facile metterla dentro un node.E da lì, grazie all'aiuto di un po' di tutti, soprattutto del maintainer di SWC perché ci ha aiutato veramente tanto a sistemarlo, gli abbiamo chiesto "aggiungi questa feature, togli questa roba qui, fai questo, fai quest'altro" ce l'ha sistemato, ci ha creato una versione ad hoc che è unica solo per Node e quindi alla fine essendo che questa libreria era usata da Dino, quindi testata sufficientemente, un maintainer che l'ha customizzata siamo riusciti a infilarla dentro.E quindi abbiamo chiarito che comunque la parte di traspirazione la fa SWC grazie alle magie di WASM che immagino si sia scelto WASM oltre che per il fatto di non dover portare dentro tutta una toolchain in Rust anche per che io sappia adesso ho portato a diversi ambienti quindi sarebbe stato un grande granchio al culo per tenere una versione per ogni ambiente anche di quello no? immagino.sì questo è lo scoglio principale anche il supporto di alcune architetture piattaforme esotiche che Nod supporta tipo Solaris, ne butto una, che rasta un supporto da pochissimo in stage 2 ecco però in realtà come funziona la traspilazione cioè io scrivo node passo il feature flag e node cosa fa prende il mio file crea l'albero delle dipendenze e via via traspilla file per file come avviene questo processo? allora in realtà appunto cioè non è molto diverso da quello che avviene già in questo momento.Node, quando vede che il file...diciamo tu scrivi "node feature flag e il nome del file .ts" quando node vede che l'estensione .ts fa una trasferenza, una traspilazione come prima cosa prende il codice e lo trasforma in javascript, cioè non fa type checking, quindi non gli importa se quel typescript è valido oppure no.butta via tutto quello che non è javascript e esegue il javascript quindi quando poi si trova a caricare l'albero delle dipendenze effettua la stessa cosa trova un file .ts, strippa tutta la parte di tipi e lo esegue come se fosse un javascript Quindi, la potenza di questo type stripping è che uno, non c'è type checking, perché tanto lo faresti ugualmente dall'IDE e nella fase di testing.Quindi farlo a run time è un costo esagerato che non ha, secondo me, assolutamente senso.Due, non c'è bisogno delle source maps.Perché? Questo in realtà è un po' anche interessante come storia.Mentre scrivo questa feature, ci eravamo resi conto che effettivamente c'era bisogno delle source maps perché andando a cancellare pezzi di TypeScript, tipo un'interfaccia, boom, la togli.E quindi la location non era simile all'originale, quindi bisognava aggiungere source maps che non era proprio una roba simpatica.Un ragazzo su Twitter mi scrive, mi dice "guarda, io ho trovato un modo per evitare di abilitare le source maps" Qual era il modo? Poi c'è un inizio a una conversazione Il modo è semplicemente sostituire quello che tu togli con spazi bianchi che fa ridere, però funziona cioè tu quello che vai a cancellare, per esempio un'interfaccia che non esiste al runtime la sostituisci con spazi bianchi quindi quando la posizione all'interno del file è preservata e funziona perfettamente cioè non ci sono feature di typescript che non si possono sostituire con spazi bianchi che impediscono di sostituire con spazi bianchi.Però messo che l'idea è geniale mi chiedo se questa cosa ha un footprint in in memory in fase di esecuzione ma immagino di no perché quegli spiazzi bianchi in fase di esecuzione verranno completamente strippati poi da node esatto cioè poi essendo che l'output è un file javascript sarà V8 che quando andrà a passare l'abstract syntax tree farà le sue magie con gli spazzi Cazzo è geniale l'idea in realtà, è talmente semplice e banale che è una figata e sto pensando, abbiamo parlato di come il type stripping avviene nei file collegati ma questa roba funziona anche con le dipendenze? tipo non lo so se io pubblico un pacchetto solo typescript lui traversa si becca i file fa sostituzione anche nella dipendenza del modulo per esempio e me lo importa? allora tecnicamente è possibile cioè niente impedisce a questa cosa qui di funzionare, tranne il fatto che abbiamo deciso di disabilitare il type stripping nelle dipendenze.Questa è politica.Sì, perché nelle fasi iniziali del processo siamo riusciti a essere in contatto con il team di TypeScript, quindi abbiamo un meeting ogni due settimane dove ci incontriamo con il team di TypeScript e discutiamo dell'andamento perché diciamo stiamo facendo una joint venture tra Node e TypeScript e poi vabbè un piccolo spoiler TypeScript 5.7 ha implementato delle feature che adesso in beta proprio per la compatibilità con Node ma comunque proprio all'inizio appunto anche il team di TypeScript un attimo non capiva questa del type stripping perché era una cosa nuova che non era mainstream nell'ecosistema.Allora nelle prime conversazioni ci siamo resi conto che se avessimo abilitato TypeScript nei Node modules sarebbe un po' esploso l'ecosistema perché tutti avrebbero iniziato a pubblicare pacchetti npm solo in typescript e questa non è una cosa buona perché 1) l'IDE fa type checking su tutti i file typescript che trova nell'albero quindi anche in node modules e quindi diventerebbe molto molto lento 2) perché comunque typescript ha diverse versioni non segue semver che è stato anche uno dei grossi ostacoli per l'adozione di typescript in node non segue semver quindi una versione successiva spaccherebbe quella precedente e soprattutto le flag di compilazione di typescript potrebbero non essere compatibili tra il consumer e il producer quindi non è cioè è fortemente sconsigliato e quindi abbiamo deciso di bloccarlo.Chiaro e questa cosa ha ha creato un impatto anche nella comunicazione tra il team di Node e il team di TypeScript come per dire sì noi noi onboardiamo TypeScript ma fino a pagina 2 perché se no qua è rischioso non lo so mi chiedo se questa cosa puoi...vai vai scusami.No dicevo, in realtà è stato proprio così cioè cioè la cosa che mi è piaciuta di tutto questo è stato che c'è stato proprio un senso di collaborazione, cioè loro hanno capito l'intento di Nod, la bontà di questa feature e un po' anche la novità di questa feature, perché gli altri runtime si comportano in maniera diversa e soprattutto noi abbiamo deciso di collaborare.Nod non è un nemico dell'ecosistema, cioè Nod vuole muoversi insieme all'ecosistema per portarlo, un po' il guardiano direi quasi, per portarlo in una direzione più sostenibile e nel passato magari ci sono stati sicuramente degli errori e delle cose che magari non ho da sbagliato e che poi sono diventati standard, con questa consapevolezza non si vogliono ripetere gli errori quindi prima di implementare TypeScript abbiamo chiesto appunto il parere del team abbiamo ragionato insieme e tuttora stiamo continuando a fare questi meeting ogni due settimane per portare avanti la feature.Ti faccio una domanda quando si introduce una feature su un ecosistema un tool una software un runtime spesso si rischia di di rompere qualcosa perché in realtà questa feature può avere un impatto su altre feature che ne invalidano il suo utilizzo cioè node è un progetto vastissimo ok con un sacco di componenti quando avete lavorato al type stripping dentro node vi siete trovati a dover patchare sistemare qualcosa di non direttamente correlato ma che veniva impattato da questa feature o viceversa piegare la feature a dei constraint che invece arrivavano da parti che così a pensarci sembravano comunque lontane dalla feature che stavate introducendo.Parlo di regressioni, come avete evitato eventuali regressioni su altri parti di codice oltre alla classica test suite in CI allora ti direi non ci sono stati bug grossi un po' sorprendentemente cioè è stato abbastanza liscio cioè lo sviluppo è andato abbastanza liscio senza bug mostruosi ci sono state dei piccoli bug o comunque degli improvement che abbiamo fatto.Un esempio è il fatto che gli IDE non riuscissero a debuggare, cioè a mettere breakpoint sul codice originale, sul codice typescript appunto perché questo al runtime perdeva la referenza verso il nome del file originale, le linee, comunque il debugger non c'entrava nel file e quindi abbiamo dovuto fare un piccolo tweak a come veniva generato il codice.Abbiamo ancora un problema...- Sono curioso di sapere come l'avete risolto in realtà.- Allora, quando traspiliamo il codice appendiamo alla fine del codice traspilato il source url, cioè il nome del file da cui da cui proviene e quindi il debugger appennando questo source URL alla fine del codice riesce a risalirsi.Perché il debugger legge questo source URL e dice io non devo guardare questo file devo guardare il sorgente in typescript.Esattamente.E questa una feature del debugger giusto? quella di andarsi a pigliare la source URL sì sì quello legge anche con il typescript con tutti i linguaggi traspilati ha bisogno che alla fine ci sia una referenza verso il file originale solo che io giustamente non lo sapevo e quindi qualcuno ha aperto un issue e abbiamo scoperto che bastava appendere questo source URL un'altra roba che per compatibilità abbiamo dovuto fare è mettere un altro flag sperimentale per abilitare la trasformazione delle feature di TypeScript, cioè appunto quegli enum che prima avevamo detto che ci facevano così tanto schifo, purtroppo ho dovuto aggiungere un flag per supportarli.Ok ti ho perso per un secondo però ti ho sentito parlare degli enum c'è qualche altra funzionalità o feature di typescript che ti ha dato delle rogne oltre agli enum? Allora feature che mi ha dato delle rogne ci sono un name space, ah ok è importante parlare un po' dei decorator perché anche li è una feature spinosa.Allora una cosa che mi ha fatto tantissimo piacere è che ho ricevuto un enorme supporto da parte dei membri del tc39.Io ho iniziato a fare parte appunto del tc39 da quando sono entrato in EroDevs, sono diventato un delegato, e ho e ho ricevuto appunto un grosso supporto verso il tap stripping appunto perché va a togliere queste feature che stanno per essere standardizzate dall'ecosistema una di queste appunto sono i decorators cioè decorators sono in stage 3 come proposta quindi praticamente sono a un passo dal diventare lo standard, il nuovo standard per lo sviluppo perché Chrome se non sbaglio ha già preparato l'APR e sarà rilasciato in una nuova versione di Chrome, in V8, quando Node genera V8 avrà i decorator.Quindi quello che fa TypeScript è una una sorta di polyfill, cioè prende una feature del linguaggio e la implementa in un suo modo simile noi abbiamo deciso di non farlo, di non supportare gli enum a livello di traspilazione quindi noi li lasciamo, cioè no li tocca e quando V8 supporterà i decorators, questi verranno supportati direttamente dal javascript engine questa secondo me è una scelta intelligente per evitare discrepanze tra polifill, cioè il modo in cui TypeScript va a trasformarli rispetto a quello che poi sarà lo standard JavaScript chiaro, questo è assolutamente interessante dimmi una cosa, quando hai...ritorniamo a parlare di politica per un attimo Quando hai proposto per la prima volta la feature, come ha reagito il committee? Quali sono state le le eventuali giustificazioni a eventuali pushback riguardanti la feature? Allora devo dire che ho stranamente avuto un sacco di supporto cioè era una una delle cose che ha aiutato un sacco è stato appunto il supporto dagli altri membri dello steering committee, cioè quando ho aperto la conversazione è nata appunto in questo canale privato su slack così, però subito si sono aggiunti altri membri del tsc e mi è iniziato a discutere un pochino però io ho preso e aperto una pr subito dichiarando appunto come intenzione cioè come tra le prime righe della pr e bisogna ammettere che gli user vogliono semplicemente rannare node nome del file punto ts e basta c'è tutte le altre soluzioni che prevedono loader esterni prompt di installazione di pacchetti npm non sono soluzioni valide.Qual è stato un po' il punto che ha messo tutti d'accordo? E' quello di supportare TypeScript però senza supportarlo direttamente, cioè senza mettere il tsconfig, senza fare il typechecking, senza mettere tsc come libreria, typescript compiler come libreria direttamente perché non so se lo sapete ma è un file di tipo 5 mega di javascript quindi insomma non segue semver, ha un sacco di problematiche di adozione che va benissimo per fare type checking ma non va bene per un runtime che ha una stabilità di una release di quasi tre anni, perché Nod porta avanti le release dalla creazione alla Land of Life, sono quasi tre anni.Quindi il fatto di supportarlo senza supportare le parti brutte del linguaggio, come gli enam, ha messo tutti d'accordo.Ci sono stati dei pushback a livello tecnico, proprio su come implementare la feature, perché comunque c'è da considerare che io non avevo mai lavorato su quella parte di codice cioè io mi sono svegliato una mattina e ho detto io oggi metto typescript su node senza aver mai visto la parte di loader perché era perché la parte di loader su node è un po' una parte mistica cioè molto complessa spacchi tutto cioè tocchi una roba e spacchi tutto non lo so mi trovavo in questo ambiente così chill rilassato che ho detto sai che c'era.Oggi mettiamo TypeScript sul noto.Il proof of concept, quanto tempo ti ha preso a sviluppare il proof of concept? Allora, in realtà c'è da dire che quei giorni ho fatto degli orari assurdi, cioè ero letteralmente carico a molla.Mi svegliavo la notte, avevo un'idea, alle 4 mi mettevo giù, programmavo fino alle 7 del mattino, mi ridormentavo, mi risvegliavo, cioè quindi è stato proprio giorni frenetici.Però da che l'ho proposta? Quando è stata emergiata sono passati 20 giorni, che non è niente per le tempestiche di...- Di nodo assolutamente.- Ovviamente la figura all'inizio non era completa, anzi era super super minimale, però l'idea era proprio quella, cioè testa bassa riuscire a deliverare almeno una cosa per poi continuare, perché l'ostacolo era proprio la prima pierre, cioè tutta la difficoltà era lì.Poi la gente che veniva attratta appunto dalla novità poi se ne sarebbe andata e poi non sarebbe interessa doppia a nessuno.cioè quali sono le differenze sostanziali perché il supporto TypeScript lo troviamo anche su Runtime come Dino ma qual è la differenza sostanziale a livello proprio tecnico implementativo e anche di approccio, diciamo così.Dunque, io sarò onesto, non ho mai usato Dino nella mia vita e quindi non so effettivamente come si comporta.So che SWC è stata creata da Dino, cioè è usata da Dino perché appunto è è stata finanziata da Dino al tempo, poi il maintainer è andato via da Dino e adesso lavora in Versen.Però non ho mai effettivamente provato o mi sono informato granché su quello che fa Dino o Ban sotto il cofano.So che Ban usa sbuild, un porting di sbuild in zig però non ti saprei dire l'effettivo.So che Dino usa sia swc che tsc, quindi ti permette di fare il tap checking con tsc e la trasfigurazione con swc, però non so che configurazione usa.C'è da considerare che Dino e BAN hanno delle release molto più frequenti, non hanno garanzie di stabilità come ce le ha Node, ovvero versioni che durano tre anni, quindi proprio degli requisiti sono diversi.E anche un po' quando si parla dei runtime, un po' parlare di pere e mele, cioè uno è molto veloce, si muove velocemente, rilascia velocemente, node invece è stabile è testato su diverse piattaforme c'ha anche un sacco di garanzie in più da questo punto di vista domanda in prospettiva come vedi lo sviluppo di questa feature come l'avete sviluppata nelle prossime versioni se la vedi estesa se si quali sono le funzionalità e se hai già una priorità o un'idea almeno? allora ti direi che in sé la feature è abbastanza pronta cioè non ci sono grosse criticalità o grosse feature diciamo grossi problemi che secondo me potrebbero ostacolare il fatto che venga tolto il flag e abilitata di default in node 24.Una cosa che mi fa molto piacere è che il supporto di TypeScript, cioè che questa feature ha cambiato il modo in cui TypeScript supporta il runtime TypeScript, cioè in TypeScript 5.7 esce un flag di compilazione di TypeScript che appunto riscrive l'estensione dei file TypeScript quando tu fai import file.ts lo riesce a riscrivere quando va a compilare in import file.js e questa è una cosa che TypeScript aveva sempre negato di voler supportare infatti prima di questa nuova flag che esce in TypeScript 5.7 se tu provavi ad usare l'estensione .ts negli import potevi farlo con un flag ma non potevi transpilare in JavaScript ti andava in errore, invece adesso è possibile farlo quindi vuol dire che è possibile usare il runtime type script ed è possibile anche traspilarlo cosa che prima non era supportata da TSC quindi questo è stato secondo me un grosso passo in avanti per tutti i runtime JavaScript un'altra cosa che secondo me c'è bisogno prima di togliere il feature flag è quella di avere sempre un flag typescript che ti impedisce di usare enum, enum spaces, tutte le feature che hanno bisogno di trasformazione a runtime.e pensi che si riuscirà ad ottenere quel feature flag? io dico typescript 5.8 mettiamo la scommessa ma vinci tu ne sono sicuro Marco cool cool figo domanda così a caldo hanno spiegato il team di typescript perché non usano i...non usano semvers semver? o non vi hanno sono quasi più una curiosità mia.Non è stato detto esplicitamente però c'è stata una conversazione soprattutto all'inizio su questo fatto.In realtà il team di TypeTube ci ha garantito assoluta stabilità rispetto alla traspilazione ovvero che è molto difficile, praticamente impossibile, che il type stripping si rompa con una nuova feature di TypeScript.Ovviamente se aggiungi una nuova sintassi al linguaggio, a quel punto sì, però è un cambiamento major.Cioè TypeScript non segue sempre sul type checking.Type checking, secondo me, è molto difficile che sia stabile.Cioè TypeScript si muove velocemente, ci sono diversi bug, quindi per evitare appunto il fardello di dover tirare fuori una nuova major ogni volta che spacchi qualcosa a livello di tap checking hanno deciso di non seguire Sember da questo punto di vista però per l'uso che ne facciamo diciamo che ne fa node del linguaggio ovvero ignorare tutti quelli che sono i tipi da quel punto di vista è assolutamente stabile.Sì sì la strategia occhio non vede cuore non duole funziona fantastico mi varebbe da chiederti se hai un'idea dei potenziali tempi in cui questa feature diventerà diventerà stabile ma so che non mi risponderesti allora ti chiedo quanto impatto pensi possa avere questa feature nel momento in cui diventa stabile cioè ce li vedi gente fare ce la vedi gente fare il progetto e mandarlo in produzione direttamente in typescript o pensi che ci sarà una resistenza ancora? sì io credo che le persone cioè io ho lavorato su questa feature per questo motivo, perché le persone vogliono usare TypeScript nel modo più semplice possibile e nel modo secondo me più stabile, più future proof per le applicazioni io credo un po' che cambi il modo in cui TypeScript viene usato da tutti i runtime perché se va secondo le mie previsioni riusciremo piano piano a far togliere a TypeScript tutte quelle feature che sono un po' sono quelle brutture che rimangono al runtime che anche il team di TypeScript non...come dire, riconosce come degli errori di gioventù del linguaggio e quindi togliendo queste feature, TypeScript non avrà più bisogno di...cioè potrebbe adottare il type stripping potrebbe adottare il fatto di sostituire con spazi bianchi quindi non c'è bisogno più di resource maps quindi si va, secondo me, verso più una direzione di standardizzazione del linguaggio che è anche un po' quella che è la proposta del TC39 di aggiungere i tipi, la type annotation proposal che è una proposta di stage 1 di aggiungere appunto dei tipi al linguaggio che poi verranno ignorati al run time ma utilizzati cioè validati a livello di idee.Ho visto che siamo già praticamente a un'ora di episodio allora prima di passare al nostro momento Paese dei Balocchi ti faccio lanciare un messaggio ai javascriptisti nudi e ai nodisti, nudi e puri quelli che hanno storto il naso quando hanno visto la feature.Cosa ti viene in mente di dire a questi amici? Io dico che non si può negare, diciamo non si può bloccare l'evoluzione, cioè anche io sono un purista javascript, cioè veramente scrivo pochissimo typescript e non mi piace scrivere typescript, che sembra assurdo, però effettivamente basta guardare i grafici sull'adozione di typescript, basta guardare quello che gli utenti vogliono, cioè gli utenti vogliono usare TypeScript, c'è un motivo perché ha i suoi vantaggi, ha anche i suoi svantaggi sicuramente, però il fatto di avere la possibilità di farlo bene, cioè di spostare l'ecosistema verso una direzione, ovvero una direzione un po' più sostenibile, togliere appunto queste feature, standardizzare perché se non supportiamo gli enum ma facciamo in modo che questi vengano supportati da javascript siamo tutti più contenti perché è un polifil in meno quindi standardizziamo il linguaggio javascript e in più miglioriamo un po tutto tutto quell'ecosistema rendere più i tool più facili migliorare un po la vita di tutti che che alla fine è quello che fa la differenza tra un linguaggio e l'altro, tra un runtime e l'altro, la facilità di utilizzo e per quanto è contorto lo sviluppo.In JavaScript è molto contorto, quindi direi ai JavaScript developer un vecchio stampo di provarlo, e un po' vedere come va.Perfetto, io credo che questo messaggio lo verrà ricevuto e soprattutto per chiunque voglia fare follow up nel gruppo Telegram ci fa super piacere ricevere i vostri feedback su questa feature, se l'avete provata, non l'avete provata, cosa ne pensate, è sempre importante avere un vostro feedback.Io mi sono preso qualche istante in realtà perché è il momento di far partire la sigletta In questo periodo che non siamo stati tantissimo attivi abbiamo comunque ricevuto il vostro il vostro supporto per cui dobbiamo ringraziare quegli ascoltatori di Gitbar che ci hanno invitato qualche birra.Il primo è Antonio Bovenzi che ci ha invitato ben 5 birre, grazie Antonio, scorrendo la cronologia oltre a un gozziliardo di pagamenti per abbonamenti online abbiamo anche Livio che invitandoci tre birre ci scrive "Ciao Maurea Mutinati buone vacanze" e sempre Eleonora ci invita cinque birre insieme a Luca Tassano che ce ne invita tre tenendo presente che Livio, che ho citato poc'anzi, qualche settimana prima ci ha invitato a altre tribi.Livio, tu ci vuoi vedere proprio ubriachi forte allora eh? Quindi grazie a tutti gli amici che supportano Gitbar, abbiamo bisogno del vostro supporto in questa nuova stagione quindi se vi fa piacere farlo trovate tutte le informazioni sul sito web www.gitbar.it/supportaci potete farlo con paypal, con le tecniche del podcasting 2.0 potete mandarci un messaggio e qualche centesimo per supportare la nostra attività se vi piace oggi le siglette non partono Tu con il Paese dei Balocchi! Ah, il Paese dei Balocchi! Il Paese dei Balocchi è quel momento in cui i nostri guest e i nostri host condividono con noi un link, un film, un libro, un qualunque cosa, una qualunque cosa abbia catturato la loro attenzione e possa essere utile da condividere qua nella community di Gitbar quindi chiedo subito a Marco hai qualcosa da condividere con noi? allora a livello di risorse un libro che mi sentirei di condividere è un attimo che lo lo ripeto.Di recente ho letto un libro su come scrivere un interprete, che mi ha cambiato radicalmente il modo di vedere javascript.Si chiama...aspetta che lo devo riprendere perché è in inglese.Sto cercando, ma ce l'ho di là.Comunque.Interpreter.Eccolo qua.il crafting interpreters è un mattone di un bel po' di pagine che spiega come scrivere due interpreti uno in java e uno in c lì capisci effettivamente come funziona il javascript come il codice viene passato come si crea l'abstract syntax tree e diciamo un po' tutte quelle cose che ci sembrano strane a livello di language design di javascript ma che in realtà sono delle scelte sensate l'ho preso su Amazon ve lo consiglio "Crafting Interpreters" di Robert Nystrom.Perfetto, lo aggiungiamo nelle nostre note dell'episodio.Cacchio, mi ha incuriosito, devo solo riuscire a trovare il tempo per leggere l'ennesimo libro perché il mio backlog, per quanto si sia ridotto un pochino, è sempre lunghissimo.io non porto un libro questa volta ma porto una libreria javascript a volte capita di sviluppare dei side project e a volte questi side project sono delle web application in quel caso le facciamo magari con fastify ma talvolta hanno bisogno di un sistema di workers no immaginiamo sto banalizzando la classica web application che ha un bel worker che cosa ne so converte i pdf o fa delle robe e spesso questi worker possono essere triggerati da eventi poi ci possono essere due o tre o n worker in parallelo che smashano questi eventi quindi abbiamo bisogno di una coda abbiamo bisogno magari di uno scheduler che fa quello che faceva a suo tempo una buona cron job che tirannava la roba a una certa ora con una certa cadenza quant'altro e quindi cercavo qualcosa di semplice che mi permettesse di avere queste cose e magari fosse backed con un sistema che già supporta in modo efficace queste robe e mi viene in mente un qualcuno un redis della situazione un rabbit mq della situazione volevo della roba effortless e ho beccato bull mq, bull mq è una libreria javascript molto figa è fatta veramente bene con un sacco di robe che ti mette a disposizione questo layer sopra Redis che ti permette di avere delle code, dei worker, fare degli scheduler, costruire dei flow con magari più worker in sequenza, parallelizzare, riesumare o rerunare degli eventuali job che sono falliti e molto figa la aggiungo nelle note dell'episodio buttateci un occhio perché secondo me per side project anche di una certa dimensione quando si entra nel meccanismo dei worker può essere il tool giusto Marco è stata una puntata fighissima direi mi ha fatto super piacere soprattutto mi ha incuriosito voglio voglio assolutamente provarla questa feature perché specie quando quando sviluppo lo scriptino della situazione che può essere lo scriptino che genera le copertine del podcast io che ormai vado di typescript di default e se mi chiedi perché non saprei cosa dire come risponderti mi capita di rannarlo con node.ts magari un chiodo devo installare node.ts e fare tutto sto casino avere node che mi ranna tutto tutto il typescript senza che mi rompa tanto le balle è veramente figo e se il prezzo da pagare è passare una feature flag per abilitare la feature beh la pago più che volentieri quindi è stata super figa questa chiacchierata grazie davvero di essere venuto grazie a te per avermi dato un po' lo spazio per raccontare il lavoro su TypeScript io ti consiglio a tutti di provarla prima di leggere la documentazione innanzitutto per capire bene poi quali sono le limitazioni e come appunto tutti i vari dettagli implementativi perché sicuramente è importante però da ricordare sempre che fondamentalmente state scrivendo javascript con dei tipi quindi se quei tipi possono essere rimossi runtime e il javascript ha senso allora sì se il javascript non ha senso allora non funziona la runtime.Bella questa cosa quindi al posto di scrivere typescript per avere javascript noi stiamo scrivendo, dobbiamo vedere in prospettiva noi scrivendo del javascript con i superpoteri che è un po' quello che è il senso di TypeScript.Figo, fighissimo.Ringraziando Marco e ricordando al mio caro amico Marco che una volta che si prende la tessera di Gitbar e lui l'ha presa da tempo in memore, si diventa anche un po' parte della community, come nel circolo dopo lavoro, poi si può venire qualunque volta si voglia.Io ti ricordo naturalmente che appena metti le mani su qualcosa di interessante o la feature evolve.Sentiti come obbligato a venire a portarci qualche update e qualche insight interessante.Io ti ringrazio nuovamente a nome mio e di tutta la community e agli ascoltatori di Gitbard do appuntamento alla prossima settimana con un altro super episodio qua in questa nuova stagione del podcast.Alla prossima! ciao ciao! siamo noi che nonostante il deploy fallito, la CIA rossa, il business incazzato, ci troviamo al github e davanti a una birra tutto ci sembra un po meno grave [Musica] [Musica] [ Ministero di Salutpremia indossano legge.gov ] marrying sera
