[Musica] 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.[Musica] Bene e benvenuti su...[Risata] Iniziamo bene questa puntata! Bene e benvenuti su Gitbar, nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori.sì mi vedete un po' bianco in realtà sono stanco e stavo dormendo nel divano quindi se la maglietta è un po' aggrinzita il motivo è quello e adesso ormai non posso più nasconderlo e...visto che avete la possibilità di vederci su youtube ecco stavo dormendo sul divano, lo devo ammettere ma a parte i miei pisolini presserali sono qua per ricordarvi una piccola cosa i nostri contatti info@gitbar.it @brainrepo su twitter il nostro gruppo telegram la casa di Gitbar il posto dove ci incontriamo per discutere e confrontarci e talvolta anche riscaldarci e poi e poi abbiamo il nostro canale youtube se non l'avete ancora fatto iscrivetevi cliccate sul campanaccio perché è il modo per rimanere aggiornati e mi raccomando fatelo perché è importante.Detto questo io direi di saltare subito subito nel cuore del nostro episodio e presentarvi il nostro ospite.Google Developer Expert, Microsoft MVP, presentissimo su qualunque tipo di social nel quale evangelizza al mondo di TypeScript, no? Quel mondo evanescente che sta on top a un linguaggio ma che tu lo vedi ma non c'è, come disse il buon Matteo Collina in uno dei nostri nostri primi episodi.Abbiamo con noi Luca Del Pupo.Ciao Luca! Ciao ragazzi, ciao Mauro, grazie per l'invito e comunque sono d'accordo con Matteo quando dice che è qualcosa di magico.Ogni tanto mi sembra di fare il mago Merlino ma in verità lo adoro anche per questo.È la cosa che mi piace di Tarset.La cosa carina da pensare come metafora è che in realtà tanto effort per fare magari delle type gymnastic o cosa, ecco, type calisthenics e poi vai a vedere, puff, sparisce tutto.No, in verità sono ancora con tanto tempo e anche tanto tempo di build che va buttato lì a poi.Stiamo già iniziando a scaldare gli ingrenaggi.Voglio innanzitutto farti una domanda.Posto che io, mio maigrado, sono amante di TypeScript, quando la sigla dice "il tuo linguaggio fa cagare il mio pure e questo è uno dei motivi no? Però cos'è? Qual è stato il percorso d'avvicinamento a TypeScript e soprattutto quali sono state le sensazioni quando ti sei avvicinato a questo diciamolo impropriamente linguaggio ma è improprio e lo vedremo tra un po'.Allora partiamo da...io io ho iniziato a sviluppare il C# e facevo pagine webform, non so chi le conosce però è una cosa bruttissima sappiatelo.In quel momento c'era...Neanche i COBOL, peggio di quello.All'inizio c'era JavaScript e ovviamente a me JavaScript piace ma avevo dei colleghi con me che non capivano una beata mazza di quello che succedeva e avevano bisogno dei Allora giusto in quel periodo è uscito Timescape e abbiamo iniziato ad adottarlo con tutte le complicazioni, anzi con tutte le semplicità che c'erano in quel momento.Alla fine era un file che veniva direttamente traspilato dal buon Visual Studio Code e in verità non era nulla di così difficile.Da lì in verità è stata tutta una continuo seguire il linguaggio e le sue nuove feature e da lì a un piano sono spostato in diversi progetti in cui c'è la Angular in cui eri costretto ad utilizzarlo.Sono partito a AngularJS in cui non eri costretto ad utilizzarlo ma comunque l'avevamo introdotto.Poi è arrivato Angular 2.x e adesso siamo alla 17-18 quello che è arrivato ormai e da lì nel senso è ricostretto.All'inizio c'era l'area, vai.Tra l'altro l'approccio, l'approccio, il mio per esempio approccio a TypeScript è stato proprio in quella fase, avevi un'applicazione Angular 1.qualcosa che funzionava, generava, era anche figo poterlo scrivere.Io ricordo quando scrivevamo applicazioni Angular 1.qualcosa era una figata perché era come un jQuery o un steroids fondamentalmente e poi arriva Angular 2 e tu eri felice nel tuo sistema javascript, eri molto più preso a fare il php del back end potenzialmente symfony quindi porta a con sé tutte le annotation o i file yaml o xml di configurazione, vabbè morale della favola arriva Angular 2 "debiamo migrare tutto sarà un casino mantenere le robe" vabbè migriamolo con questo Angular 2 non sarà poi così diverso che era completamente diverso per chi se la ricorda è stata una delle migrazioni più dolorose della storia del front-end se non la migrazione più dolorosa e la seconda in realtà forse la prima migrazione più dolorosa mia è stata da Flash a jQuery qualcosa, però è stata abbastanza dolorosa e a quel dolore, a quella via crucis, ci si è messo anche TypeScript con, lo ricordo ancora con un certo disgusto, le annotation.Diciamo che...La metaprogrammazione! già stavi approcciando un mondo dove c'erano i tipi e tu facevi immacinare le peggio cose a javascript e quindi questo voleva dire inserire nel tuo processo un po' più di disciplina no? Però poi c'erano anche quelle annotation, quelle cose un po' esoteriche che non conoscevi e che ti dovevi studiare e che ti limitavano almeno in una prima fase la produttività nel contempo il business pusciava "eh ma dobbiamo deliberare, che cazzo non ci capisco niente di sta roba" Eh, quelle sono ancora forse il problema più grande secondo me, nel senso non essendo tutte quelle chiocciola che ci sono in Angular non sono ancora davvero standardizzate e non saranno probabilmente lo standard, però sono quelle che hanno anche portato probabilmente molta gente nel mondo JavaScript/Tilescript secondo me.Perché la fortuna/sfortuna di Tilescript e Angular è stata che tutti quelli che facevano Spring Boot hanno visto le chiocciole e si sono buttati a fare frontend pensando fosse esattamente la stessa cosa.Tanto ci sono dei servizi, tanto è tutto uguale e in verità non era proprio così.In senso io conosco gente che conosce gente...no che qua in Francia è una cosa molto comune che hanno fatto il percorso Spring Boot, Angular, Nest, JS e sono ritornati a fare back end in JavaScript pensandolo Java! E poi bro, c'hai un problema forse! Ti dico solo che mi sono trovato un progetto una volta in cui era un un progetto AWS Lambda che era strutturato come se fosse una applicazione Java.Tutte le cose che potevi fare all'interno di un'applicazione Spring Book le avevano portate in un contesto Lambda serverless che non aveva senso in quel momento.C'erano anche cache in memoria.te dico solo quello.Cioè, doppia call start, cioè, call start della Lambda, poi un quarto d'ora per avviare tutta la baracca per farlo.Però vediamo.Ma...Ah, scusa se ti interrompo.Là si evidenzia una cosa specifica, cioè il fatto che spesso quella zona di comfort, per non dire sempre, con la zona di comfort è un bordello da buttare giù e quando poi si usa typescript spesso la zona di comfort che è typescript stesso diventa un bordello da buttare giù.Sto pensando no a io che faccio lo scriptino che fa una cosina semplice e mi vado a fare ma sto parlando dello scriptino di, che ne so, 50 righe.In totale! Fai 55 col package.json.Però alla fine mi dico uso TypeScript e quindi vai di TypeScript, Node.js, mille baracche, burattini, bim bum ba ba ba ba ba ba, se non avessi lo scaffolder già fatto probabilmente ci perderei anche qualche ora e alla fine sto facendo uno script che potrei farlo in bash in 5 minuti e mi sto portando tutto questo.o anche banalmente solo in javascript.o in javascript appunto.ti dirò anch'io questo problema a certe volte tant'è che tante volte magari mi impongo e dico no è è talmente facile che lo faccio direttamente in javascript, sono veramente 5 rimi di codice, e al switchare la mia mente sul pensare senza i tipi o anche banalmente fare una funzione e non metterci argomento a due punti il tipo, oppure lo metto anche se sono in javascript, dopo compilo e faccio.perché non va? ah no, ma non devo compilare, c'è javascript direttamente.quindi mi serve anche me quel momento per mettere la testa a posto perché ormai comunque anche la mia mente non lo faccio apposta ma è ormai fissata a vedere i tipi e anche a scriverli senza che me ne accorga ecco ogni tanto mi chiedo perché non possono in javascript togliermi direttamente loro i tipi guarda me lo chiedo tutti i giorni così almeno posso far fuori i tsc no però hai ragione in realtà quello che ho percepito quando ho iniziato ad adottare in modo intensivo TypeScript è stato proprio uno shift mentale, cioè io ho iniziato a pensare in tipi ed è un modo completamente diverso da pensare come pensavo io quando scrivevo Python o PHP prima del PHP 7, io vengo dal php3 quindi di strada ne è passata sotto i ponti però ecco io per esempio pensavo in termini di funzioni di flusso di azione e per me le variabili erano delle scatolette dove potevo metterci qualcosa qualunque cosa senza preoccuparmene quando ho iniziato a utilizzare i tipi e questa cosa l'ho iniziata a vivere già con le type annotations in php e sto parlando di...non mi ricordo forse se c'era in php 5 ma in php 7 sicuro, alla fine è cambiato completamente il mio modo di pensare e oggi ancora prima di scrivere una funzione mi faccio la signature perché è un modo per dirmi se qualcosa va male questo entra e questo esce che non è molto lontano da fare tdd no perché anche quando fai tdd cosa fai stai definendo cosa entra e cosa esce e quindi ne stai definendo il comportamento in modo ad alto livello no ti stai dando delle regole stai definendo un'interfaccia.Certo a quei tipi vedo il tutto molto più esplicito.Per dirti una cosa che ho imparato da quando c'è TypeScript, ho scoperto che TDD non vuol dire solo Test Driven Development ma anche Type Driven Development.Esiste pure un libro su questo che non conoscevo, fino a che me l'hanno messo davanti un giorno.E effettivamente ti fa vedere come puoi andare a pensare ai tipi prima di andare a scrivere le cose.Tu ti aspetti che lì arrivi quel determinato tipo e non è come hai detto prima te, c'è una scatoletta che dovrebbe avere quelle cose, so che ci ho buttato dentro qualcosa e me la ritrovo però ecco.Forse abbiamo in testa lo stesso libro.Penso di sì è quello della...non mi ricordo se Manning forse ma dovrebbe essere lo stesso.Perché il libro veramente che mi ha aiutato a pensare in modo strutturato ai tipi è stato quello di "Vlashing".Il titolo non è specifico riguardo ai tipi ma il titolo è "Domain Modeling Made Functional" che parla di functional domain driven design ma praticamente metà del libro ti spiega come pensare in tipi e in flow e quando ho letto quel libro ho iniziato a fare un po' di esperienze io riprende venivo dal mondo domain driven design in PHP, quindi mi facevo le classiche, ne so, facevo l'aggregato e poi le entità e poi evaluate object con 7000 classi in estate che sembrava tipo di essere in un cimitero o le matriosche, cioè alla fine quando ho letto quel libro e poi contestualmente ho ripreso a lavorare in modo molto più intensivo in javascript/type script, ho iniziato a dire sì vabbè tutto bello ma le classi mi servono, ma queste strutture innestate mi servono, a me bastano le funzioni se le so scrivere bene, sono ancora più leggibile e a quel punto ho iniziato proprio a ragione gli intermedi flow, quindi funzioni che magari possono essere messe in sequenza e di tipi che entrano e escono entrano escono entrano escono e sta cosa ha sconvolto completamente il mio modo di scrivere del codice il mio il mio codice è diventato molto più leggero zero boilerplate ha iniziato a starmi sul culo tutto con la programmazione tutti quei framework che mettevano dei paletti fissi tipo cosa ne so il service bus ma io non ho bisogno di un service bus per fare dependency injection ed è uno dei tranelli che si porta dietro ci si porta dietro quando si lavora con typescript cioè stai lavorando con typescript ma sotto il culo c'è il javascript non c'è il java il contesto è completamente diverso, la formamenti del linguaggio è completamente diverso.E questo forse è uno dei veri problemi che ha Typescript, che ha avuto anche e che continua a avere secondo me, è che la gente con la sua greve di tipi si dimentica che sotto c'è davvero JavaScript ma lo vede come il classico linguaggio Java style C# style e purtroppo come hai detto ci troviamo con le persone che pensano di fare uno spring boot o comunque vanno su nestjs, vanno su quelle cose che assomigliano esattamente a quello che è quello che usavano prima senza javascript quindi nestjs se sei in frontend o angular nel frontend in questo caso e ti dirò è un peccato secondo me perché la gente si perde il bello di javascript perché se avessero iniziato direttamente con javascript probabilmente o forse non parlo su tyescript perché la gente poi quando pensa che javascript è perfetto quando è puro così non si vuole muovere verso il mondo tiescript o vede il tiescript in modo diverso, nel senso non lo vede come il mondo object oriented di java o c# ma lo vede come un tipo che ti può aiutare a dare del lessico al tuo javascript e secondo me è quello che può, cioè che aiuta, almeno a me aiuta molto nei progetti soprattutto in quelli grossi, dove ci sono tante persone che mettono le mani e dove non tutti possono sapere cosa è successo due mesi fa magari, o un mese fa perché l'ha fatto qualcun altro, ma leggendo i tipi, entrato ed uscita, almeno mi faccio un'idea di quello che sta succedendo.Se non fossimo a migliaia di chilometri di distanza ti abbraccerei Luca, perché hai detto esattamente il punto.Che è quello che facevo fatica quando ero nel mondo JavaScript, se andavo a mettere a mano il codice che avevo scritto io magari un anno prima e non sapevo cosa mi entrava, cosa mi usciva, ma magari avevo anche delle persone un po' diciamo non molto lige nella scrittura del codice e che prendevano gli oggetti che arrivavano in input, andavano a manipolarli mettendoci dentro cose, non li ritornavano ma sapevano che erano per reference e poi facevano cose nel resto del codice senza per magia sapevano solo che stavano succedendo.Ecco magari con Typescript quello che mi è piaciuto è proprio il fatto che se tu lo usi nel modo giusto dai un assignator e le persone che lo leggono non hanno neanche bisogno di vedere cosa succede dentro la funzione magari vedono cosa entra vedono cosa esce leggono se sei bravo scrivere anche il nome del metodo potrebbe anche bastarli per capire quello che sta facendo il tuo codice magari a loro non interessa neanche andare a fondo su quel metodo in quel momento perché è semplicemente sistemare un bug e però sanno che gli succede questo poi succede questo con quel tipo e vanno ad aggiustare solo le cose effettivamente che devono andare a essere toccate per fare quel fix con annessi problemi di compilazione poi ma ne parleremo più avanti.No infatti è quello io mi capita spesso di mettere mano a degli libriri anche importanti scritte in javascript e devo ammettere che buona parte del tempo della code exploration immaginate no anche libri difficili pensate per le performance per esempio non farò nomi le librerie pensate pensate per le performance dove ci sono le cose che hai detto tu ma non per incapacità dello sviluppatore ma proprio perché rendere immutabili un oggetto vuol dire alloccare memoria e vuol dire sovraccaricare quando si può essere più snelli.Dov'è? Non capisci bene cosa stia succedendo qual è il flow non è chiaro perché ripeto hanno la performance in testa come priorità cioè alla fine dire ma se io almeno avessi TypeScript potrei passarci sopra vedrei che cazzo sta entrando che cosa sta uscendo e capirei un po di più al posto di mettere 70 console log o breaking point no? Anche poi i breaking point in javascript li raccomando specie quando si parla con la parte Async, che sono il grande pain in the ass, per gli amici italiani il granchio al culo, che hai.Però alla fine, vedi, questo forse Luca evidenzia una differenza sostanziale tra all'uso del TypeScript per le librerie per la scrittura di librerie quindi codici di terze parti o mattoncini da riutilizzare e applicazioni.Come vedi appunto l'utilizzo di TypeScript in questi due mondi se vedi che sia necessario un approccio, una proiezione mentale differente? Allora partiamo dalla parte che mi è più facile ancora, cui dare una risposta che è applicazioni enterprise o applicazioni che devono avere una lunga vita.Secondo me bisogna trovare il trade giusto che si la build ci mette un po di più ma si tutti possono essere consapevoli che di quello che sta succedendo e di poter toccare il codice diciamo consapevolmente quindi utilizzando Tilescript in una applicazione direi meglio grande aiuta magari all'inizio bisogna trovare tutte quelle bellissime code style eccetera perché magari c'è nel team quello che vuole punti e piccola ma quelle cose lasciamo restare però quando si è trovato la quadra secondo me con Typescript e avendo tutte le cose tutti il mindset giusto su Typescript aiuta a progredire più velocemente aiuta anche a capire a un junior che entra cosa sta succedendo, che magari con un puro javascript fa ancora più fatica probabilmente, ma aiuta anche noi a capire cosa avevamo fatto meglio un anno fa se dobbiamo riprendere mano probabilmente.Adesso io ho qualche problema mentale e tendenzialmente quando scrivo il codice non so perché mi resta in testa per dieci anni.Quindi se uno mi ripresenta poi lo stesso codice un anno dopo, so esattamente cosa faceva se non me l'hanno toccato, ma so che non è così per tutti.Avrai un figlio anche tu, Luca.Avrai un figlio e vedrai che le amnesie e arriveranno.Immagino che arriverà anche il mio turno prima o poi, però so che è lì e diciamo che quella persona del futuro potrei essere io, che non vi ricordo, e avere la scritta potrei dire "grazie Luca di due anni fa, un anno fa, che hai scritto quel tipo e hai dato un senso a quel codice perché ora sai come andare a sistemarlo.Lo stesso vale se lo fa qualcun altro.Librerie.Librerie è un bel topic dove secondo me sta molto anche ai gol che vuole avere quella libreria.Faccio l'esempio, se deve essere una libreria super mega performante che fa cose mastodontiche, dinamiche e fuori per fuori, io sono il primo a dire che probabilmente andare a scriversi i tipi è la cosa che ti rallenta di più lo sviluppo di quella libreria, anche perché tendenzialmente se vai a fare cose di performance sai esattamente cosa fa javascript, come lo fa e puoi usare dei meccanismi che da tipare o da rendere dinamici ti creano dei tipi che sono veramente difficili da leggere a chi arriva troppo in quel momento.Quindi probabilmente diventa una curva di apprendimento più grande per chi deve mettersi le mani o anche per andarla a sistemare che non ne vale la pena secondo me.Ha più senso andare a fare quello che fanno milioni o miliardi di librerie in questo momento che è utilizzare javascript e creare quel bellissimo file .d.ts con le firme di quello che dovrebbe essere l'entrata per quelle funzioni.Ecco lì però bisogna ricordarsi che quella nuova li va tenuta aggiornata se no quei poveri cristi che utilizzano davvero TypeScript si trovano a utilizzare "any" o "unknown" che è un finto tipo che è quello che effettivamente voi vi aspettate e creano un po' di "disaggi" agli utilizzatori.Va a incastrare dei mattoni deformi alla fine diventa un bordello e tira fuori tanto smell anche nella tua codebase.In realtà voglio aggiungere una cosa a quello che hai detto che sposo appieno ed è perfetto.Per quanto riguarda la scrittura delle librerie, e qua porto una mia esperienza personale, quello che io ho trovato nell'utilizzare TypeScript per scrivere una libreria di terze parti, non che l'operazione sia meno dolorosa se la fa in javascript, perché già scegliere il module system stai apprendo tipo che possiamo chiederlo al nostro amico Michele Liva che stava bestemmiando quando dovette sistemare la questione del modul system su Arama però ecco quello che io ho percepito è stato la creazione di due vere fasi di sviluppo o almeno il dover pensare due differenti parti dell'applicazione la prima era la logic della della libreria scusatemi la prima era la logic intrinseca della libreria quindi la "behavioral logic" cosa deve fare, come lo deve fare, cosa deve spostare e quando lo devo spostare.L'altra fase era quella di pensare a non più ai tipi come li pensi nella scrittura di un'applicazione, ma pensare a una vera e propria logica dei tipi.Quando inizia a tirar dentro i generics, a dedurre tipi, fare cose particolari, type transformation, queste cose in realtà entri, quelle che spesso si chiamano type gymnastics, entri in un lavoro abbastanza complesso di pensiero della logica dei tipi, che non è più legato alla dev experience di scrivere la libreria, cosa che invece è così con la scrittura dell'applicazione, ma è legato a far ragionare bene il language server per chi utilizzerà quella libreria e questo è un grande pain in the ass per chi va a scrivere la libreria stessa perché a quel punto sta elevando a potenza la complessità di quello che sta scrivendo.Tenendo presente che si nasconde un altro threat, un altro insidia che è lo scollamento tra le due.Perché capita quando tu ti concentri in modo similcilo in queste due livelli di complessità che sono molto spinti, a quel punto è normale, è fisiologico che ci sia uno scollamento e in qualche modo i due rischino di prendere direzioni differenti e quindi questo dimostra che TypeScript va usato in modo completamente diverso secondo di quello che si sta facendo...e che aggiunge un ulteriore livello di confusione, no? - Sì e soprattutto anche perché poi tante volte le persone non capiscono che quei tipi che tu esponi come libreria sono solo delle aggeverazioni che dai a loro tante volte e in verità a te che stai facendo libreria in javascript non te ne puoi fregare di meno.Che hai pro e contro nel senso...ma questo è il javascript nel senso io posso mettere i tipi a qualsiasi cosa ma posso essere talmente...non voglio dire la parola con la "s" ma posso essere non disciplinato e mettete un esami dappertutto in verità sto ripassando il time system e penso che quello che ti faccio passare io vada a influire la tua libreria in qualche modo e le persone da lì fanno magie e pensano che Tilescript non funziona, ma io ho messo il tipo numerico perché non mi torno in tipo numerico, cose varie e è anche uno dei motivi per cui la gente tante volte non capisce che se ho messo un tipo number nel mio tipo interfaccia o tipo come vuoi e nella mia API non mi arriva un number non è colpa di TyScript è perché TyScript una volta che l'avete compilato va via e è stato un piacere quello che funziona è JavaScript alla fine.Ci sono diversi modi per continuare a sperare che quei dati che vi arrivino siano come i tipi che avete che avete descritto durante la vostra fase di sviluppo però ecco banalmente quello che mi ha fatto venire in mente è che servono due mindset completamente diversi per scrivere una libreria e per scrivere un'applicazione.Per capirci in modo molto semplice se io volessi dire che questa funzione prende una stringa ma ma non una stringa non nulla, non posso farlo con TypeScript.Prendi una stringa e va bene così, perché se provo a fare una stringa non nulla gli devo passare come generics e quindi deve essere una costante e questa è una discussione che avevamo con alcuni colleghi proprio l'altro giorno.Quello che a questo punto va detto è appunto che, proprio per come è pensato secondo me il javascript il typescript nella libreria è più un elemento di dx di developer experience invece sull'applicazione è più un elemento di formamentis come dicevamo prima perché per come è pensato javascript poi possono essere un milione di eccezioni a quello che sto per dire quindi è opinabilissimo io sono il primo a opinarlo quindi non fatemi a merda nei commenti però quello che voglio dire è immaginate le librerie di javascript perché esiste npm come si è sempre detto e come dice il libro del buon mammino javascript è pensato per avere delle librerie con una superficie molto ridotta, quindi che fanno poche cose e solo quelle.Quindi non c'è quella complessità o almeno si presume non ci sia quella complessità o quella enormità per il quale usare i tipi ti aiuta tantissimo.Però invece esporli aiuta tantissimo chi sta usando.C'è da dire che tantissimi libri sono tipizzate col culo e quando noi le usiamo il 90 per cento diciamo TypeScript fa schifo perché perché devi stare là as unknown come dici tu a string as unknown as mio oggetto super figo e alla fine è più che altro un problema di ecosistema.Ma oggi come vedi l'ecosistema TypeScript/JavaScript? Tanto probabilmente ha rubato, JavaScript ha rubato il mercato a Java che quando lo installavi ti diceva che rannava su Billion ID device, adesso c'è JavaScript che gira dappertutto, quindi direi che probabilmente l'ecosistema JavaScript ha preso molto mercato.Come lo vedo secondo me ancora probabilmente nell'onda giusta, nel senso vedo tanta gente che si butta in rast perché possiamo fare diverse cose sia nel lato node che anche con web assembly e cose di questo tipo qua, però non è ancora del tutto maturo forse.O comunque i developer non hanno ancora iniziato a metterci davvero la testa come su JavaScript.C'è talmente tanto codice JavaScript in giro che prima di toglierlo tutto probabilmente sarà il prossimo Cobble, secondo me.Arriveremo a un punto che tutto quel JavaScript da qualche...non riusciremo a avremo le persone pagate a dobloni d'oro per fare javascript o tiescript, dipende come era fatta quell'applicazione, ma secondo me quello sarà il futuro di javascript se proprio dovrà finire, perché non ne sono ancora sicuro, almeno da qui ai prossimi dieci anni non ne sono proprio sicuro sinceramente.Più avanti non si sa, è troppo parlare già di dieci anni secondo me nel Il mondo Tilescript secondo me continua ad essere amato e odiato in base alle persone e a quello che si trovano davanti e a quanto l'hanno imparato.Nel senso che quello che vedo adesso è che l'intero ecosistema Javascript comunque comprende una parte di Tilescript, cioè chi lo utilizza no, Chi utilizza TypeScript comunque sta utilizzando JavaScript, quindi fa parte dell'ecosistema JavaScript secondo me.E dentro a quel piccolo ecosistema TypeScript secondo me continuerà a crescere, perché comunque come sviluppatori continuiamo a crescere, ma secondo me a un certo punto o JavaScript lo include in qualche modo o non so che succederà.Adesso c'era questa retipi con JSDoc che sinceramente a me non piace.E dai, parliamone che è un'altra questione calda, calda, dai ci divertiamo! Non lo so, nel senso, capisco il senso di JavaScript, sapendo che per come è fatto JavaScript non vuole rompere nulla, ok? Sappiamo che JavaScript continua a far girare siti che sono del 1900 e non so cosa.- Se non hanno dipendenze - Ma l'idea è quella di non rompere mai nulla, ecco.Capisco che l'introduzione dei tipi, come l'ha fatto Taisi, è molto facile che rompa qualcosa, ecco.Però utilizzare quella sintassi non so come potrebbe aiutare le persone davvero, nel senso è così facile finché devo mettere che è una stringa un numero tutto va bene secondo me non è un problema quello che puoi fare con javascript che è la questione dell'override delle funzioni secondo me è un disastro da poter gestire non è poi così facile JSDOC è un livello abbastanza elementare di typing, se solo pensiamo alla complessità degli optional, dei partial, quindi tutte le type utility, dei generics, cioè a me viene impossibile immaginarli, poi non conosco JSDOC, ti dico la verità, però mi viene quasi impossibile immaginarli in quel ecosistema cioè finché stai facendo una classe che ha quattro proprietà e ti tipizzi quelle quattro proprietà serve davvero tipizzarle.Quello che io mi chiedo è lo use case che copre JSDoc con la sua portata è davvero uno use case che ha bisogno di avere un supporto di tipi? non lo so è una domanda non una risposta.Siamo in due a non avere la risposta probabilmente.E a questo ci aggiungo che è una sintesi iperverbosa e se alla fine la codebase typescript e su questo ci voglio tornare con te tende a smerdicchiare un po' in giro con type definition un po' e quella roba...non lo so, immagino commenti qua e là...Io ogni tanto penso...allora ci si lamenta di TypeScript perché in questo momento aggiunge dei tipi e è vero, chi non è abituato è una cosa che deve aggiungere, ma con JSDoc immaginiamo che io ho tipato davvero una cosa che mi aspetto che sia un numerico, ma in verità per qualche arcano motivo da qualche parte non c'è una JS doc definition e arriva una stringa e mi ritrovo con gli errori a runtime che non so bene come verranno gestiti in questo momento, ma me ne accorgo solo al runtime di quella cosa lì perché è abbastanza facile da sbagliare secondo me.Certo lo si può fare anche con TypeScript, basta che metto una nida in una parte e mi aspetto una stringa.La differenza è che probabilmente con TypeScript se sei fortunato la stringa è un 1 e ti aspettavi un 1 e non ci devi fare altro che visualizzarla, in quel caso la visualizzi lo stesso dentro a un html non te ne frega che sia un numero o una stringa, sei ancora fortunato e ancora tutto funziona.Lì se davvero c'è un controllo a runtime del linguaggio in verità hai un errore a runtime che devi sistemare in qualche modo, è dovuto a tipi che non sono molto facili da gestire forse.Ecco, non riesco a vedermela ancora questa situazione con JSTOP, faccio fatica a crearmi anche in mente le possibili situazioni di beneficio e non beneficio in questo momento.Sarà perché sono abituato a TypeScript e mi piace, ma non lo so.Come dici te, è davvero la scelta giusta lo scopriremo, nel senso come TypeScript magari ha fatto l'errore più grande di Carry Decorator, forse Javascript sta facendo un errore portandosi dentro JSTORP per la tipificazione, ma in verità non sono nessuno per dirlo e l'unica cosa che possiamo fare a vedere come andrà a finire e lo scopriremo solo lì.Abbiamo detto che i tipi di TypeScript sono utili a compile time, al run time tutto sparisce e non hai più il seggiolone, le barriere sul quale muovete quindi cadere dal precipizio è un attimo.Esistono però dei metodi che ci permettono di costruire un bridge tra il compile time e il run time.Non sono gratuiti e so che tu sei molto fan di alcuni di questi no? Sì, in verità nell'ultimo per i...nell'ultimo ormai un po' d'anni che esiste...che esistono librerie tipo Zod o Tidebox, ce n'è una che non mi ricordo il nome che dovrebbe essere Valibot che è tipo una specie di Zod fatto da un altro ragazzo per per sviluppo tipo di ricerca e sviluppo che è una specie di Zod ma diciamo più light perché ti permette di importare solo dei determinati pezzi della libreria diciamo il tree shading funziona meglio che ti permettono con lo scotto di creare degli oggetti javascript quindi hai delle cose che finita la compilazione continuano ad esistere e quando parte la compilazione hai degli oggetti che davvero esistono, cioè javascript sa cosa sono, che non sono altro che degli oggetti che contengono della validazione per i tuoi tipi.In poche parole descrivi con un oggetto come ti aspetti che sia il tuo tipo, ti trovi tramite le utility di Typescript la possibilità di convertirli da oggetto javascript o il typeof in qualche modo in un tipo che è davvero typescript, quindi hai il beneficio di utilizzare taskscript, ma hai anche la possibilità di poter controllare a runtime che quell'oggetto che ti arriva, che ti sta arrivando da un API o da qualsiasi cosa esterna, rispecchi davvero il tuo tipo che avevi definito quando eri nel tuo bellissimo Visual Studio Code o qualsiasi cosa che volete utilizzare e diciamo divente sereni che il vostro codice andrà a funzionare con i tipi che vi aspettavate in fase di sviluppo e non perché nelle piave l'hanno cambiata e hanno deciso che invece che esserci una stringa vi passano un oggetto perché hanno deciso di cambiare la firma o perché vi hanno tolto un capo.Sapete che in qualche modo potete sapere direttamente se le cose vi cambiano.Ovviamente dovete mettersi un bello strato di observability della vostra applicazione, prendere i log, buttarli su, farvi arrivare le notifiche se qualcosa non va, però almeno diciamo che la notifica la ricevete perché sapete quello che sta succedendo e non perché vi ha chiamato un cliente che vi dice "ma perché c'è un not the number nella mia schermata" o perché c'è un errore, un undefined che non capisco, però ecco diciamo che hanno lo scotto che comunque del codice che vi portate dietro nel senso del codice che dovrà andare avanti.Sì io devo dire che questo periodo sto scrivendo tanti microservizi con TypeScript e col nostro buon vecchio Fastify a base e di per sé questo approccio è stato secondo me il game changer per quello che sto andando a fare quindi dei microservizi che fanno delle robe e che parlano con altri 70.000 microservizi cioè il fatto di avere una fase di validazione strettamente accoppiata a quei tipi della mia applicazione fa sì che io possa creare questo quest'ambiente sicuro dove sono sicuro che quello che mi sta entrando è un intero o quello che mi sta entrando è un oggetto che ha questa certa shape e quello che esce è questo perché sono sicuro che è così anche a runtime perché avendo come diceva Luca questa fase di validazione iniziale e di serializzazione o validazione finale ho la possibilità di dire "ah non è come me l'aspetto ciao è stato un piacere ma esci via di qui non è qua non entri" e quindi a quel punto si va a creare un ambiente molto sicuro per esempio quello che io sto facendo adesso è prendere le specifiche di OpenAI, OpenAPI scusatemi, che sono dei JSON o dei YAML, caricarli, convertirmeli in dichiarazioni della libreria di validazione del caso, io sto usando AGV e contemporaneamente utilizzare una libreria che mi esporta i tipi direttamente dall'YAML o dai JSON di OpenAPI e a quel punto siccome mi trovo in un ambiente a microservizi ho la validazione iniziale e la validazione finale sono sicuro che il contesto che sta all'interno del microservizio rispecchia perfettamente quei tipi è un brodo di giugiole.Eh sì, a dire la verità quando ho iniziato a lavorare quello che mi avevano insegnato è il back-end non si fida mai del front-end, ma ho imparato anche che il front-end non si deve mai infilare il back-end ultimamente.Per quanto uno scotto le porti, non possono aiutare tutte e due le parti.È un attimo che ci sia una cosa che non torna, o ci sia la giornata sbagliata di un tuo collega che per caso cambia qualcosa e almeno lo scopri subito.Subito è sempre relativo, però ti può aiutare.Certo, hai anche la test suite.Esatto.Finché il back-end è nel tuo team, probabilmente è più facile non arrivare neanche in produzione.In quel caso sono abbastanza sicuro che in qualche modo dovresti fermarti prima.Le API non sono tue, ma in verità, dato che mi hai fatto pensare a OpenAPI, un'altra soluzione effettiva che stiamo utilizzando anche nel progetto dove sono io è proprio quella di andare a definire un OpenAPI che è il punto di incontro tra back-end front-end.Il contratto sì.Esatto e lì praticamente vengono generati, non so se è la stessa che stai utilizzando te, ma viene generato il JSON proprio, che è il JSON di riferimento dello schema in proprie parole, che viene importato su fastify e genera i tipi che puoi tranquillamente utilizzare sia per tipare, ma ci sono 20 mila milioni modi di farlo nel senso puoi anche avere se vi piacciono i monorepo potete farvi una libreria che ha le validazioni in una libreria comune che contiene solo quelle e condividere quella libreria che contiene le validazioni tra backend e frontend e farci quello che volete.Non fatelo qui pulireppo se volete un consiglio.Esatto.Perché se no vi ritrovate a fare 70 pull request per mettere in produzione una feature presente quello che sta facendo attualmente questo signorino e che quindi si deve fare gli script per andare a sistemare ad aggiornare automaticamente.Lasciamo stare.Ti capisco però ci sono dei contesti dove i polirepo ci sono e sono enforsati quindi devi farlo per forza però hai ragione.Ho detto infatti apposta al polirepo perché io lo vedo utile lì perché appena cambi quella libreria se hai una test switch corretta, se hai il tileset settato correttamente ti accorgi subito se hai modificato o aggiunto qualcosa, soprattutto una proprietà, dove anche devi andare a toccare sia nel back end che nel front end, diciamo forse nel front end meno perché qualcosa da aggiungere che ti arriva, diciamo ti manca il flusso che lo vada a visualizzare quindi devi andare a capire dove lo vai a utilizzare.Se sei nel back end hai un API che già ti torna quel tipo diciamo non compila se hai messo lo strict mode quella proprietà manca quindi devi andare a sistemare il codice in qualche modo non è che puoi lasciarlo lì e attendere che lo faccia qualcun altro se no la compilazione non va bene.No vabbè, bold opinion, se non c'è lo strict type la flag strict type script non serve a niente.Domanda invece organizzazione della codebase che è un altro punto dolente lo sappiamo no? Con typescript la dimensione della codebase si si ingrandisce e c'è il type definition e c'è i funzioni...come organizzi il tuo codice con TypeScript? prossima domanda perché ogni volta è una è una lotta in ogni team probabilmente in verità allora tendenzialmente cerco di non far stare lontani i tipi da dove vengono utilizzati, se no dopo la gente diventa matta, con gli f12 vai in giro, apri i dividi in due, viso studio code per capire cosa succede, quindi tendenzialmente cerco di avere le cose abbastanza vicine.Certo, certe volte servono dei tipi globali che magari di cui non abbiamo il controllo e che magari ci arrivano da qualche parte strana delle applicazioni, le cartellina types devono essere il meno possibile perché quelli possono essere un problema serio perché se mi ricambiano devo cambiarle, però tendenzialmente il più vicini possibile, che siano nello stesso file o in due file vicini dipende molto anche da quanto inizia a crescere il file, da quante cose iniziano ad esserci dentro il file.Ovviamente se iniziano ad esserci tante cose è più facile che devo dividere quel file in un altro file e ci porto via i tipi che c'è da una parte all'altra o creiamo un filetto proprio se c'è qualcosa in comune, se no tendenzialmente un tipo è per un file, un tipo è per l'altro e li vado a spostare dove serve.Anche perché l'occhio non scrollare e non cambiare il contesto per capire cosa succede con i tipi ti aiuta anche a essere più veloce.Se invece devi iniziare a muoverti a destra e a sinistra diventa più complesso anche per la testa probabilmente in quel caso.Concordo con te e a quel punto se proprio proprio devo fare questi salti mortali con i tipi a questo punto mi faccio i test e non scrivo più i tipi e mi leggo i test per vedere cosa sta succedendo perché, questo lo dico perché una delle grandi battaglie che spesso si fa amanti di TypeScript con amanti di JavaScript, si basa sul fatto che se io voglio quel minimo di safety me la metto nella test suite e non utilizzo i tipi.Sì stai sentendo bene ciao Manuel Però poi alla fine ci devi andare nella test suite a leggerli e soprattutto la devi mantenere la test suite anche in quei minimi marginali test che fai proprio a copertura dei tipi, perché sono test diversi, no? Non sono più behavioral ma sono a copertura dei tipi.Per cui sì, oggettivamente tenerli vicini rende le cose più semplici, centralizzare quelli che stiamo definendo o facendoci il nostro hot-hat è types.d.ts.Che brutti, io non li recono, i file di type definition, ma tu e io lavoriamo immagino con fastify e noi sappiamo bene che dobbiamo farli.Grazie Matteo, ti vogliamo bene.Matteo si sta ricredendo in quelle cose, non so se hai visto una issue su GitHub, quindi forse forse arriviamo ad una svolta, però non sarà un lavoro molto facile.No, e soprattutto sarà per loro un botto di lavoro, quindi ci sta.Fase di compilazione.Lentezza di TSC.Ma questa doveva essere una chiacchierata per endorsare TypeScript.Stiamo facendo una merda praticamente.In verità, di solito le cose che ami ti piace vedere le parti brutte e fare in modo che chi ti ascolta magari poi capisce che...c'è anche il rapporto è bello tranquilli, magari ci ascoltano qui i task che capiscono cosa devono sistemare.Ma a dir la verità, a parte di compilazione, ecco uno dei veri problemi è che TSC è lento e tendenzialmente la gente non lo usa, preferisce prendere e utilizzare altre cose tipo osbuild, osvc, quello che volete.Anzi tendenzialmente la gente fa questo, lancia tsc solo per controllare i tipi come fa vite o byte, come volete chiamarlo, e poi fa la compilazione con vite o quello che alla fine è un programma di fatto che ti avvia i tipi è stato un piacere nel senso tendenzialmente la cosa più veloce.Domanda ma tu quando lo lanci TSC? In che senso? Quando lo lanci? Non lo lancio, io lancio...Lancia la CI? Esatto, Ascii forse dai, il git hook pre-commit che ti fa il controllo in modo da non smerdare il commit però quello che voglio evidenziare è che io lavoro in TypeScript e di lanciare i TSC per controllare i tipi credo di non averlo mai fatto a mano negli ultimi mesi però qua emerge il mio grande amore verso TypeScript perché adesso con te abbiamo parlato di TypeScript come linguaggio ok? linguaggio metalinguaggio chiamiamolo come cavolo ti pare come superset dai così rispettiamo aderiamo bene alla terminologia.Abbiamo parlato di TypeScript come compiler, potremmo parlare di TypeScript come un linter in qualche modo ma non abbiamo parlato secondo me della vera rivoluzione TypeScript, cioè il concetto di Language Server Protocol, cioè quello che TypeScript ha fatto e che è stato game changer e che ha permesso a JSDoc di emergere, ha permesso a tanti linguaggi di essere potuti usare in un editor che funziona e che suggerisce qualcosa.E il concetto proprio di language server.Cioè TypeScript ha migliorato l'esperienza anche di chi scrive javascript perché con quel protocol aperto a disposizione di tutti e di tutti i linguaggi c'è stata la rivoluzione quindi io adotterei TypeScript per riconoscenza anche solo per questo.C'è da ringraziarlo solo per il fatto che hanno fatto l'angular service language basato su Tankscape che ti permetteva di avere un aiuto quando scrivevi i template HTML e non è poco in quel momento.però sì ecco quella è una delle probabilmente è la cosa di cui meno si parla ma che ha aiutato molto di più tutti noi sviluppatori.Chi ha adottato Tilescript ha subito amato l'intelligence, fare il punto e sapere cosa poteva andare a scrivere e banalmente ci ha ridotto quanto poco anche i problemi di typo, nel senso quante volte...adesso stavo pensando oggi, non so, ho una dislessia in questi giorni e scrivo "toggle" con due "o" e una "g".Guarda, è un errore che fa sempre anche Carmine, tra l'altro penso che l'abbia detto in uno dei nostri episodi.È un errore che facciamo tutti.Per fortuna, perché sennò penso di stare ore e ora di buggare perché comunque la differenza tra una 1G e una 1G quando vedi codice tutto il giorno non è poi così accattante quindi per fortuna mi aiuta lui.Sono quelle cose che magari non te ne rendi conto o nella velocità tipo non so quanti di voi si muovono tra le varie finestre solo con la tastiera quindi con il tab e con lo faccio talmente veloce che non mi ricordo non ricordo se è command o option, vabbè avete capito.E capita ogni tanto che prima di cliccare quel bottone clicco una Z, una X a caso e arrivo di là e dico "perchè non funziona?" Poi torno subito al studio e dico "Tiè Albino, ho quella riga, lo sai che mi dice? Ah, guarda che ho cliccato qualcosa prima di passare nell'altra finestra".Mi risparmia ore di cose che magari per caso non ho fatto volontariamente.però ecco sì, sono d'accordo con te.È una cosa di cui pochi parlano ma che in verità ha creato non so quante estensioni su Visual Studio Code o su altri editor che permettono questo utilizzo.completamente completamente d'accordo stavo pensando a un futuro potenziale di typescript cioè typescript non è il primo a me viene in mente flow mi viene in mente reason.ml ci sono sono stati tanti linguaggi che hanno provato a portare degli approcci a scala JS, anche il più sfigato forse, ma è perché mia moglie ama tanto Scala e quindi mi viene in mente sempre FanFact, un po' di tempo fa me ne arrivo con della roba SYNIL React scritto in scala JS ha detto che cos'è questo mostro? E prego sparatevi! Comunque linguaggi ripeto come Flow come ReasonML non hanno avuto poi tutto questo successo.TypeScript nonostante tutto e nonostante DHH e i suoi tweet al vetriolo come quello che state vedendo adesso sullo schermo dicano che non serve a niente che vada rimosso o librerie come Svelte che tirino via i tipi sostituendo li con JSDoc comunque TypeScript rimane e sta rimanendo e sta venendo adottato sempre di più e sempre ovunque.Quindi mi chiedo da qui a pochi anni cosa vedi che si possa evolvere in TypeScript? In verità io continuo a vederlo come un super set di cose che non è come si può ma cosa possiamo portare più velocemente nel mondo javascript? ma compilandolo prima con TypeScript? non so, tutta la trafila che serve per portare nuove funzionalità in javascript alla fin fine è del tempo che tendenzialmente tante volte i developer non vogliono ottenere, dicono "ma c'è 'sta roba figa che potrai già utilizzare con ES 2025" ecco tendenzialmente con TypeScript lo introducono subito in qualche modo ti fanno loro tutto il polyfill per poterlo utilizzare e lo puoi andare ad utilizzare prima con NSCrojet secondo me continuerà a essere questo quindi un super set di cose che vengono introdotte in JavaScript col tempo che migliorano tutti e due gli ecosistemi, perché la fine fine tutto quello che c'era su Tyescript in qualche modo piano piano credo che sta andando a finire su JavaScript.Quindi anche chi odia le cose che ha fatto Tyescript tante volte si rende conto che alcune cose le hanno fatte arrivare loro per portarle compliance anche su un progetto che magari doveva andare con un internet explorer fino a poco tempo fa e quindi questa è una parte la seconda è secondo me tutte quelle cose sui tipi che possono migliorare lo strict type poco fa hanno rilasciato il satisfy, non so chi conosce quella bellissima funzionalità chi non ha mai capito l'esconst probabilmente non capirà il Satisfye in questo momento, ma sono delle cose che se usate nel modo corretto ti permettono di avere uno strict check e ti aiutano nel flow della tua applicazione.Poi sono quelle cose che cambiano la vita, dipende dallo sviluppatore.Io sono dell'idea che lo strict va strict fino a un certo punto "my team", nel senso che dovete trovare la soglia fino a quanto volete essere davvero strict su tutte le cose.Capisco anch'io che ci sono dei casi in cui è più comodo fare "as unknown", quello che è perché sapete che qualcun altro ha fatto la funzione sotto e non avete voglia di toccarla perché così non risulta che il blame è vostro su github o dove volete.Però anche lì quanto deve essere strict il vostro tipo è una cosa che tendenzialmente è molto sullo sviluppatore sul team in quel momento.Alla fine cosa cambia tra un Satisfy o un S-Const tante volte o cose strane? Quasi niente se la vediamo nel processo del software.Se uno la vuole vedere nel vedere esattamente quello che succede, ecco usare un Satisfy.Mi ricordo l'esempio banale che c'era di una Prisma Query che prima era stata utilizzata con la SCONST e rispecchiava esattamente il read only con il satisfy di quel tipo gli dava esattamente il tipo corretto e sapevi che qualsiasi cosa andavi a fare comunque rispecchiava quel tipo che ti aspettava.Senza una parte visuale un po' difficile, sembra tipo magia quello che mi sto dicendo, e non l'ho neanche spiegata molto bene probabilmente.Sì, ma ci sarà un tuo short dove lo fai vedere? No, forse le Satisfy no, però ce n'era uno bellissimo appena uscito che magari poi lo vado a cercare e lo lascio per… Nella notte degli episodi.Esatto.Ma era veramente fantastico quell'esempio.ma banalmente anche il dispose, non so chi conosce il dispose che c'è in questo momento, non mi ricordo di che versione di ECMAScript, ma è stato aggiunto lo using in TypeScript per poter gestire il dispose.Io la vivo da C# e so perché hanno utilizzato lo using banalmente, perché lo era quello che gestiva il dispose in C#, se utilizzate un'interfaccia è disposa voi con lo using, fa da solo lui la chiusura dei file, fa cose per voi, quindi aiuta anche che arriva la C# probabilmente a utilizzare quello using nel modo che si è usata.C'è molto C# in TypeScript, oltre che al creatore.esatto però ecco è una cosa che è disponibile su Tilescript già adesso e se dovete compilare per ES6, avete la possibilità già di utilizzare in questo momento su Tilescript senza troppi problemi non ho altre idee in questo momento di come può crescere ecco quello che posso capire...Io ci metterei una una semplificazione del TypeScript Conf.Sì e no, nel senso, detto tra me e te, nel 90% dei casi dei progetti che ho visto la gente potrebbe fare npm x tsc - - init e arrivi to use poi se vuoi metterci ovviamente tutto quel mondo di react o cose strane devi avere un bug non puoi farlo direttamente con tsc secondo me perché diventa pazzi, non si può gestire secondo me, ma un progetto node banalmente per quanto sono quando se fai TSC per compilare puoi aspettare dopo domani, in quel momento là, quando cresce ma nel senso, probabilmente il progetto Node NPN XTSC Init in questo momento potrebbe creare problemi con i vari modi builder, non con i moduli che vuoi usare, c'è qualcosa che...esatto, quello sono d'accordo con te, ma banalmente basterebbe fare un init node nel modo giusto ok? o init quel che è che non è poi così complesso secondo me da standardizzare se le persone hanno voglia di mettersi lì, è che ho come l'impressione che il team Tilescript non ha intenzione di mettere becco in queste cose nel senso loro il tool te l'hanno dato, sta a te configuratelo e però sì ora che mi fai pensare probabilmente...no a quel punto vince, strumenti come nx o scaffolder vari uno dei problemi di penpoint risolvono è anche questo, io guardavo turbo l'altro giorno, Turbo Repo.Può essere sì.È in realtà uno dei problemi che risolve anche questo.Io credo che ci sarà prima o poi una convergenza sulle...io le chiamo annotation ma è un modo improprio no? perché mi viene in mente Symfony e si chiamavano così.Però per esempio una convergence tra quelli di javascript e quelli di typescript che sono divergenti o un modo un po più più semplice per vedere cosa succede col module system perché è abbastanza per quanto configurabile ancora non immediato non immediata la lettura mi piacerebbe tantissimo non passare per una fase di traspirazione ma per una roba che semplicemente è un runtime che semplicemente ignora i tipi e ti fa funzionare la cosa, semplificherebbe tantissimo.Sì, sono d'accordo con te su quello.Però per quello credo che almeno nella parte back-end dovremmo subire ancora un po' di battaglie tra Node e Dino, Node, Dino e Banner, per vedere cosa succede.Io questa perioda sono più back-ender, quindi il mio focus point sta là, però non lo so.Non voglio entrare nella diatriba, ma è un po' difficile togliere tutto quello che ha ha creato node in questo Mac, non so, la vedo molto difficile.Anch'io sono della fazione di node, anche perché come si può essere diversamente? A parte questo io credo che più o meno abbiamo un po' dato una prospettiva generale di TypeScript molto opinionata, me ne rendo conto.Ci manca una cosa che buon Matteo dice sempre ricordatevi di testare anche i vostri tipi.Il testing sui tipi vero questa cosa è vero me l'ha insegnato anche a me Matteo e infatti se voi andate a vedere le codebase tipo fastify della situazione mercurio 6 ci sono i tivi mi ricordo delle pr bloccate perché non c'erano i test stessi tipi e cavolo non lo fa nessuno perché? poi quando hai capito come funziona sono veramente veloci, sono silli, ci metti due secondi a farne ecco però la gente non sa cosa è TSD banalmente, lo racconti un attimo perché è una cosa importante secondo me.Torniamo alle librerie perché tendenzialmente è una cosa che si fa quando si fa una libreria? Quello che si fa è grandfile.d.ts che contiene le interfacce di tutti gli aspetti che esponga la tua libreria in quel momento, che sono le firme delle funzioni, qualsiasi cosa che viene portato verso l'esterno viene anche scritto dentro lì perché è quel punto che aiuta lo sviluppatore che utilizza la tua libreria ad avere la developer experience corretta.Ecco, uno dei problemi che può esserci è che arriva un maintainer o una persona che vuole dare una mano, cambia i tipi senza accorgersene e nessuno lo sa.E' un po' difficile che nessuno lo sappia perché di solito le PR passano sotto review, ma tendenzialmente quello che succede è che ci si aspetta che un tipo, soprattutto quando iniziate a lavorare con i generics, entri in un certo modo ed esca in un altro c'è un pacchettino che si chiama tsd, non so se sia mai lo standard effatto o se è semplicemente più utilizzato in questo momento che vi permette di andare a creare un file che tendenzialmente, non mi ricordo se è .d-types.ts o una cosa del genere dove potete andare a creare la funzione utilizzando il vostro TypeScript proprio come se fosse un file TypeScript, fate le procedure che farebbe una persona per utilizzare la vostra libreria se fosse in un file TypeScript e quello che fate alla fine non è lanciare il codice ma è usare dei metodi, sono dei Type Utility alla fine di TypeScript che vi permettono di cercare se il tipo di ritorno rispecchia esattamente quello che vi aspettate ad esempio, immaginatevi di avere un partial, l'utility partial da testare, in cui passate un generico T che è vostro tipo, quello che potete fare con TSD è prendere il partial e ci faccio un oggetto che ha due proprietà name e surname che sono di tipo stringa e sono obbligatorie.Voglio testare che alla fine il partial mi ritorni un tipo che è name e surname ma dove in realtà non sono più obbligatorie ma sono opzionali quindi possono essere anche antefame.Lo potete fare tranquillamente utilizzando tsd e è quello che tendenzialmente utilizzano le librerie, anzi i framework, barra librerie fatte JavaScript che vi espongono il bellissimo file .d.ts per poterlo utilizzare nel vostro contesto o timescript.Se volete un esempio andate su github, cercate qualsiasi cosa di Fastify probabilmente e potete trovarne un esempio.Giusto per dare un'anforta al nostro amico Manuel mi ho appena dato una mano a lui e a Matteo a sistemare il pacchettino Fastifyorama con la possibilità di avere i tipi e in cui c'è proprio la gestione anche del tipo di ritorno che fa quella libreria, fatta tutta in JavaScript ma con il tipo.Ovviamente Manuel è molto contento nel vedere quello che succedeva con TypeScript ma era contento alla fine.Anche lui sta iniziando convertirsi ma non lo sa.Manuel è contento, non vederlo da lontano quello che succede sul javascript, ti vediamo bene Manuel.Ciao ragazzi ho preso un minuto mentre montavo l'episodio per fare questo piccolo video da mettere nell'episodio.Mi trovo a Milano all'Inafe, il mio volo per Parigi è tipo in ritardo di quattro ore, allora ho colto l'occasione per cercare di montare l'episodio che abbiamo registrato con Luca e provare a rilasciarlo per tempo nonostante il delirio di questi giorni.Noi ce la mettiamo tutta per fare l'episodio in tempo e voi in qualche modo ci date una mano e sostenete parte dei costi di clipart per farlo naturalmente vi impegnate e noi vi ringraziamo, ringraziamo le vostre birre a questo punto io devo ringraziare alcuni di voi, devo ringraziare documenti Livio Livio Francesconi che ci fa due donazioni tra l'altro vicinissime di data, grazie Livio scrivendo "ciao ragazzi è un piacere continuare a supportarvi per la vostra condivisione di informazioni veramente preziosa continuate a aimai paypal taglia il messaggio abbiamo un altro messaggio sempre il suo ciao ragazzi ciao community ho fatto una donazione nella sua bibbia mentre volevo filmare prepper questo è l'integrazione approfitto per ho dovuto interrompere perché sono oggettivamente uno gnubo.Ho dovuto interrompere perché sono oggettivamente uno gnubo, stavo cercando la continuazione del messaggio di Livio che dice "Aprofitto per condividere un mio balocco, forse già condiviso da qualcuno cioè il sito javascript.info".Javascript.info è un sito veramente veramente figo, tra l'altro se non sbaglio c'è anche la versione in italiano e se non sbaglio su github c'è anche la possibilità di contribuire alla traduzione quindi se volete approcciare al mondo open source ecco quello potrebbe essere un buon entry point per poterlo fare scendendo indietro perché penso di essermi saltato qualcuno dobbiamo ringraziare Alessandro Balza che ci dona due birre e no dovrei dovrei aver detto tutti vi ricordo che per supportarci c'è l'apposita area nel nostro sito, la area supportaci e bom se mi sono dimenticato qualcuno importante perché in realtà abbiamo anche il value for value e e altri modi per supportarci.Infatti sto provando ad aprire fontane, ma ho l'abilità di un trick con un balsamato.Se ci siamo dimenticati qualcuno, per favore pingatemi in privato perché voglio davvero ringraziarvi durante l'episodio.Grazie di cuore.Bene, guardavo l'orologio, siamo già a un'ora e venti, e quindi arriviamo al momento tipico e topico del nostro episodio.Il momento dove condividiamo un libro, un talk o qualunque cosa abbia catturato l'attenzione e sia in qualche modo valevole da scerare con la nostra community.E lo facciamo nel momento "Il Paese dei Balocchi".Vi conduco nel Paese dei Balocchi.Ah, il Paese dei Balocchi.quindi ti chiedo luca hai qualcosa da condividere con noi? allora dato che ne abbiamo parlato c'è se volete una libreria molto snella che sta prendendo piede in questo momento per validare i vostri javascript object a runtime, avete un occhio o a Zod o a Valibot, sono due ottime alternative.Altra cosa, dato che ne abbiamo parlato sempre prima, c'è un bellissimo libro che è quello che dicevo prima della Manning, probabilmente non è quello che intendevi te secondo me, che è Type Driven Development, che vi fa capire come ragionare a tipi se entrate in un modo TypeScript.Non è scritto in TypeScript, vi avviso, quindi è ancora più bello perché imparerete un nuovo linguaggio che in questo momento non mi ricordo perché ovviamente non l'ho imparato che non l'ho imparato perché mi interessava solo i concetti del TDD che era TypeDriven Development in quel momento e ho fatto le prove in quel momento ma non me lo ricordo perché come al solito utilizzo un linguaggio e se lo uso tutti i giorni poi me lo ricordo se no sparisce e ti direi che questo è tutto poi ti lascio anche il link del bellissimo short su Satisfied di Tilescript ma andiamo a cercarlo perché tipo non mi ricordo dove.Chiaro, chiarissimo.Sai che metterò anche il libro che suggerito in backlog, mamma mia, io prima o poi soccomberò dal peso di queste cosine.Io in realtà non ho un vero e proprio balocco, ma mi viene in mente in 3, 2, 1...ok mi è venuto in mente qualcuno di voi può avere l'esigenza di scrivere un piccolo editor di testo all'interno della propria applicazione react io ricordo librerie mostruose tipo anzi non ricordo neanche i nomi con comunque dei mostri da tirare dentro pesantissimi orrendi con delle skin bruttissime e poi capita l'esigenza di dover customizzare l'editor per fare delle cose funzionalità aggiungere delle robe x fare dei behavior particolari e qua inizia veramente la parte dolorosa.Da qualche tempo a questa parte i buoni compagni di facebook o di meta hanno rilasciato un framework per fare degli editor di testo che si chiama Lexical e che è tanto tanto figo perché in realtà è facile da utilizzare si integra bene con React e potete customizzare praticamente qualunque tipo di dettaglio dai comportamenti ai tag specifici a veramente credetemi qualunque qualunque tipo tipo di cosa la potete customizzare nel dettaglio e quindi ve lo suggerisco.Altro balocco se siete come me che vi siete completamente dimenticato il css visto che ormai da un po' che lavoro con col back end ma dovete fare il front end come voi sapete sto sviluppando questa applicazione per scrivere i feed rss meta enrast con l'interfaccia react usate Tailwind perché sì perché Tailwind è tipo il salvatore in questa cosa anche se il codice che vi infuori è orribile però è il salvatore ma poi scoprite che Tailwind non è Bootstrap cioè Tailwind fa una cosa diversa e la fa in modo diverso soprattutto e quindi vi mancano tutti i componenti alla bootstrap tipo il file input, gli headers, il date picker, il banner, i bottoncini e cosa fate ve li fate ma anche no a questo punto avete due modi per farlo o andare a copiare in qualche modo il codice a rubarlo da Tailwind UI, io penso di essere uno dei pochi ad aver comprato le licenze delle loro UI e ha speso una quantità di soldi inenarrabile e non le sto usando tra l'altro.Oppure c'è un bellissimo sito che si chiama Flowbyte.com tra l'altro ho visto pubblicato nella newsletter del nostro amico Luciano Mammino dove ci sono tutta una serie di componenti e ce un gozziliardo con componentino e il codice html con tailwind bello pronto quindi se volete semplificare e velocizzare non vi interessa di avere una uai completamente nuova custom beh questo può essere un modo dove andare a rubare una navbar o una card o qualcosa che vi può essere utile per la vostra applicazione quindi buttateci un occhio.Wow Luca siamo arrivati ci abbiamo fatto io non sono svenuto nel frattempo ma ci siamo.È stata una puntata interessante anche un po' calda devo dire mi sono divertito.anche io sicuramente, tra l'altro mi è piaciuto il parlare di TypeScript senza fare una sviolinata lecca culistica ma andando a evidenziare quasi più i pain point dei vantaggi anche se io e te siamo dei fanboy, quindi facciamo un po' con te.- Sono d'accordo con te.Diciamo che è molto facile che vedermi con gli occhi a cuore se mi dici "task".- Siamo siamo in due, siamo veramente in due.C'è da dire che però quando si inizia a usare un linguaggio fortemente tipato e che i tipi si li tiene anche a build time, ti vieni da dire "ma TypeScript potrebbe darmi qualcosa in più?" E allora la domanda che volevo lasciare a tutti a te a tutti i nostri ascoltatori è "TypeScript potrebbe darci qualcosa di più? E con questa domanda aperta io vi ricordo rapidamente i nostri contatti info@gitbar.it @brenrepo su Twitter e il nostro gruppo Telegram insieme al nostro canale YouTube dove se non l'avete fatto cliccate sul campanaccio.Vi lascio nelle note dell'episodio anche tutti i contatti di Luca quindi stalkeratelo o seguitelo o basta che non li bussate sotto casa perché non vi dico dove abito.Detto questo ti ringrazio nuovamente per essere venuto qua a trovarci Luca.Grazie a voi è stato un piacere condividere con voi questa oretta e mezza penso ormai quindi è proprio un piacere e un onore per me essere qui.È un piacerissimo per noi e ci ci vediamo domani mattina in ufficio.Esatto, che è questo? *risate* Ciao, alla prossima! 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.grave.[Musica]
