Bene e benvenuti su Geekbar, nuova settimana e nuovo episodio.Oggi proviamo a esplorare un argomento che non abbiamo mai trattato nei nostri microfoni, davanti ai nostri microfoni, ma anche all'interno del gruppo Telegram, se non in modo accidentale e comunque marginale.Quindi è il caso di dare il giusto spazio a questa tecnologia emergente.Per farlo oggi ho un super ospite ma prima di presentarlo il mio ruolo anche un po palloso è quello di ricordarvi i nostri contatti info@gitbar.it via email o @brenrepo su twitter sono i modi canonici per entrare in contatto con noi e poi c'è il nostro gruppone telegram anche se vedo che molti di voi non si sono ancora iscritti allora cosa aspettate oggi abbiamo parlato di ralma quello ne parliamo sempre ed è sempre l'amicia che scatena tutti i flame ma abbiamo anche parlato di tastiere meccaniche per finire provando a dare un epito un epiteto descrittivo del track point quella cosina rossa che c'è a metà di tante tastiere e ne abbiamo sentito delle belle ma sono cose che naturalmente non possiamo ripetere in puntata per cui se ve la siete persa allora andatela a recuperare all'interno del nostro gruppo telegram Benvenuti su Gitbar, il podcast dedicato al mondo dei full stack developer, i mezzo artigiani, i mezzo artisti, che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.detto questo io credo che possiamo presentare l'ospite di oggi abbiamo con noi Michele Aponte CEO di BlackSync, CTO di Helicode, fondatore di Blazor devello per italiani e MVP Microsoft.Ho dimenticato qualcosa Michele? No, direi che c'è tutto.Perché in realtà la lista era lunga e io ho sempre paura di dimenticarmi in realtà è una bugia.Questo è il secondo take di presentazione.Raramente facciamo due take per la stessa cosa ma oggi sono completamente bullito quindi confido anche a livello conduttivo di Michele ti prego sostenimi perché oggi per ora siamo da soli aspettando che qualche ammutinato venga a bersi una birra con noi però di cosa parliamo oggi Michele? parliamo del mondo Microsoft, del modo dello sviluppo Microsoft e di Blazor in particolare la novità del momento.Te l'avranno chiesto tutti ma è un pokemon? Non è un pokemon, si scrive Blazor non Blazort ed è un framework frontend dai possiamo dirlo.Però prima di parlare di tecnologia voglio chiederti una cosa intanto come ti sei avvicinata al mondo della programmazione e perché ti sei avvicinato al mondo Microsoft? Io ho visto dei talk tuoi penso che tu sei stato credo l'unico sviluppatore Microsoft col Mac qualcosa del genere.Ho avuto un periodo da vegetariano ho avuto anche un periodo da maccaro come diciamo noi.In realtà a 13 anni Commodore 64 non mi ho prestato e mentre tutti ci giocavano io ho preso il manualetto, ho creato la famosa mongolfiera che era sul manuale e da lì in poi è stato amore per la programmazione a prima vista.il primo 886 di mio padre gli aveva regalato il suo commercialista che era passato al 286 e lì c'era il dv basic in rom quindi se non avevi un disco collegato partiva il dv basic e quindi da lì è stato un amore a prima vista poi ho fatto gli studi tecnici e poi sostanzialmente...ah c'è stato un momento in cui ho lavorato per un periodo in un'eticola e lì ho trovato un malloppone di volumi di micro computer, non so se la ricorda la rivista, e in uno dei numeri c'era Visual Basic 4, così ho incontrato Microsoft per la prima volta.Da lì in poi è stato un pochino...al lavoro usavamo Java comunque, nelle prime esperienze lavorative ho usato Java, mentre nel tempo libero utilizzavo Visual Basic.Poi sono riuscito a passare nel team Microsoft, della prima azienda in cui ho lavorato e da lì in poi sono rimasto sempre sul mondo Microsoft.Il Mac lo ricordi perché in un periodo abbiamo fatto sviluppo mobile in azienda e per sviluppare su iOS ci vuole un Mac necessariamente, quindi siamo stati un po' costretti.Poi io mi annoio con una certa facilità e quindi di tanto in tanto devo cambiare.C'è stato un periodo in cui volevo cambiare completamente, mi ero un po' scocciato di fare sempre le stesse cose proviamo in Mac nel mondo completamente nuovo mi è piaciuto molto però con Windows 10 sono ritornato a casa insomma.Windows 10 è il sottosistema Linux di Windows da lì in poi sono ritornato adesso Windows 11 sono tornato sul mondo Microsoft.Ne parliamo tra un po' del sottosistema Linux perché è una cosa che sto vedendo e usando da due settimane appena è è arrivato il computer nuovo di Gitbar come lo chiamo io perché in realtà l'obiettivo è farci tutto il lavoro del podcast su questa macchina però devo dire che lo sto usando ed è strano ma ne parliamo dopo.Voglio però raccontare questa cosa a dire il vero anch'io tra i miei inizi hanno ovvero la Microsoft come molti perché in realtà io a scuola programmavo in VB6 e i primi veri lavori di web dinamico quindi con server alle spalle li ho fatti niente po' di meno che in ASP Classic.Non ci credo, non l'avrei mai detto.E ti svelo anche il perché.Stiamo parlando del 2002 forse 2003 una roba...praticamente si girava ancora con la carrozza all'epoca.Però la cosa divertente è che scelsi quel tipo di tecnologia perché Aruba, questa è da segnare, dava l'hosting, c'è da dire che Aruba dava l'hosting anche per php.La vera differenza è che con l'hosting ASP, quindi con l'hosting Microsoft, tu potevi utilizzare il database access a SAS senza dover acquistare un servizio aggiuntivo che vergogno di MySQL che era poi l'alternativa e quindi iniziai davvero a fare i pannelli di amministrazione in ASP e devo dire che è stato divertentissimo perché io mi scrivevo i miei filet iniziavo ad avvicinarmi al concetto che ne so di singola responsabilità quindi provava a fare quei failetti uno che si occupava solo della connessione uno proprio uno schifo schifoso però devo dire che ancora qualcuno di questi failetti è in produzione in una piccola azienda ma non vi svelerò mai neanche sotto tortura dove e come ho paura che dopo questa rivelazione perderà e perderemo tutte le persone che sono sul gruppo telegram è una vergogna quindi non hai toccato il fondo con PHP No, no, c'è anche di peggio.No, però era particolare, dai, devo dire che mi sono veramente divertito anche perché, ripeto, è stata una prima esperienza ed era strano aprire il codice con parentesi angolare per cento.Ricordo bene, no? Sì, ricordi benissimo.I brividi sono passati, ma ricordi bene.Però da allora io ho mollato il mondo Microsoft, un mondo Microsoft che è un mondo enorme e mi capita spesso di parlare con gli sviluppatori specializzati in quel mondo perché in realtà se sei uno sviluppatore che lavora in ambiente Microsoft sei quello, cioè fai quello e vivi dentro quell'ecosistema un po' come gli sviluppatori iOS che vivono nel loro ecosistema quindi c'è Xcode, c'è i loro strumenti.Ma tutte le volte che io parlo con uno sviluppatore Microsoft questa è a mille di questa tecnologia.E allora mi chiedo io che invece utilizzo tutt'altre tecnologie perché c'è questo entusiasmo a limite veramente del fanboy verso questo mondo? Cioè cosa dà l'ecosistema Microsoft allo sviluppatore che rende lo sviluppatore così gasato dall'ecosistema? Io penso che tutto sia nato un pochino dagli strumenti di sviluppo visuale.Ecco tu hai visto Visual Basic, quindi hai un pochino guardato quello che è l'esperienza, la user experience, la developer experience del mondo Microsoft e ovviamente poi i tool si sono evoluti, Visual Studio che è lo strumento principale di sviluppo del mondo Windows su tecnologia Microsoft si è evoluto e io l'ho provato un po', ho provato Eclipse, ho provato tanti strumenti, Visual Studio è oggi l'ambiente di sviluppo più completo che puoi trovare per sviluppare applicazioni di qualsiasi tipo, sia desktop, web e mobile utilizzando tecnologie Microsoft.Strumenti visuali e questo praticamente ha avvicinato tutti quelli che magari non hanno fatto studi di programmazione ma avevano questa passione volevano creare applicazioni e da lì poi questo strumento si evolveva sempre di più, molte di queste persone che in realtà magari avevano cominciato anche proprio con access, a fare form e report con access, hanno cominciato a fare applicazioni, applicazioni desktop, hanno cominciato a deemployarle, hanno cominciato a farle usare ai propri, ai primi clienti e un po' questo è quello che ha fatto Microsoft, ha avvicinato tante persone non specialiste all'inizio al mondo dello sviluppo, perché c'erano questi strumenti visuali che ti nascandevano tanta della complessità che c'era dietro.Poi è ovvio che da lì a farlo diventare un lavoro bisogna necessariamente passare per uno studio approfondito e capire tutto quello che c'è, però ecco, avendo visto sia il mondo Java che il mondo Microsoft, posso dire che chi che approcciavano il mondo java e arrivavano già da studi molto forti sui pattern, sulla programmazione, mentre invece nel mondo Microsoft è molto...capita spesso insomma che molte persone si siano avvicinate perché era facile dare una forma a trascinare un pulsante, doppio clic sul pulsante scrivi quello che quel pulsante doveva fare in un linguaggio Visual Basic che era veramente molto semplice.Aveva costrutti che col senno del poi erano veramente impressionanti in senso negativo, però ti davano questa possibilità e è probabilmente stato quello.Ebisore Studio ancora oggi è un tool che ti permette di fare tutto, da debug avanzato, a touch remoto dei processi, debuggare del coce che gira dentro un container docker, puoi fare veramente tantissime cose, ovviamente a seconda di quello che devi fare serve un livello di conoscenza importante, però lo strumento di per sé è visuale e quindi c'è tanti wizard, tanti designer che ti aiutano nella parte di sviluppo.Penso che sia questo.Poi ci si mette anche un po' Microsoft che, diciamo, storicamente ha sempre cercato di rendere semplice lo sviluppo e quindi nascondere il più possibile le complessità, magari, dello sviluppo web, per esempio nascondendo un pochino javascript dietro le quinte.Diciamo che come ci siamo detti qualche giorno fa, gli sviluppatori Microsoft, vecchio stampo, chiamiamoli così, Microsoft all in, Microsoft JavaScript, non lo possono vedere tanto, sia perché ci sono le classiche idiosincrasie di JavaScript, ma io dico la mia, perché Il mondo Microsoft, anche basandomi su quello che hai appena detto, è spesso molto opinionated.Cioè, devi fare una cosa in quel mondo, quella cosa si fa così.Punto.Non puoi sbagliare.Il mondo JavaScript è una giungla.E in quella giungla ti devi orientare.e l'orientarti il mondo javascript come una parte del mondo basato su tecnologie open perché comunque chiunque ci mette lo zampino e tira un po' agli approcci differenti per cui ti devi orientare e questo orientarsi è comunque un peso di tipo cognitivo sul lavoro che stai facendo quindi presuppone un investimento di energie che spesso non rapidamente monetizzabile.Oggi javascript va bene dappertutto anche nei frullatori per cui forse un po' è diluito questo e si vede da molte azioni Microsoft verso questo mondo, però diciamo che continua a esserci una fetta di sviluppatori che in qualche mondo repellono questo e tu mi hai anche detto che è uno dei motivi per cui è nata poi la tecnologia di cui andremo a parlare Blazor, ma la mia domanda prima ancora di parlare di Blazor è mi è capitato di vedere così sulla rete che i tool della suite Microsoft 365 spesso permettono l'installazione di estensioni che sono sviluppate invece in React.Questo è quello che ho visto, non conosco profondamente il mondo anche se un po' mi ha incuriosito perché da sviluppatore amante di React un'occhiata mi piacerebbe darcela.Però mi chiedo perché allora se Da una parte c'è tutto il mondo degli sviluppatori Microsoft che in qualche modo cercano di tenere lontano il JavaScript invece si è optato per questo tipo di scelta e non alternative.Nel mondo Microsoft chi è stato a Seattle e le ha visto un pochino come sono organizzati di Redmond ci sono i team che fanno i tool di sviluppo, il team che lavora su windows e ci sono i team di prodotto come, so, SharePoint, Office e ci sono questi team tra di loro sono abbastanza isolati quindi quello che succede è che spesso un team di prodotto sceglie delle tecnologie sulla base dei requisiti che ha in quel momento e se in quel momento la personalizzazione visto il target di sviluppatori è React ti va a scegliere React molti dicono perché Blazor internamente a Microsoft non è usato perché Blazor a suo tempo non c'era, era un framework molto giovane è un team di prodotto sceglie le tecnologie da usare nel prodotto sulla base di tanti requisiti funzionali ma anche non funzionali quindi ci ci sono tutta una serie di cose a cui devono guardare.Di conseguenza capita, non di lato, che anche quando si usano tecnologie Microsoft in questi prodotti, magari non solo l'ultima versione di .NET, non solo l'ultima versione della tecnologia per fare servizi, per tanti anni in circolazione si sono usati i web services vecchio stile, poi sono passate a WCF, adesso WCF non c'è più, insomma, ci sono tutta una serie di cose per le quali un team di prodotto, prima di adottare una tecnologia, fare delle valutazioni di ciclo di vita del prodotto che sta realizzando e alla luce di questo capita che faccia scelte e vado anche fuori dal mondo Microsoft, ma lo fa guardando appunto il suo target di riferimento e il ciclo di vita dell'applicazione che sta realizzando che ovviamente deve essere garantito perché lì l'obiettivo è vendere il prodotto e non realizzare uno strumento di sviluppo, quindi obiettivi diversi, scelte diverse, baramente questo, non c'è niente di strano o di antipatia tra team o cose del genere, semplicemente scelte basate su requisiti funzionali e non.Chiaro, allora voglio farti un'altra domanda appungente, io ho sempre qualche domandina un po' scomoda.Allora, sulla base di quello che hai appena detto detto la mia domanda è Microsoft ha investito un pacco di energie per creare TypeScript? TypeScript che è un linguaggio che io adoro ormai lo sapete cioè sono follemente innamorato di TypeScript che un po' adesso la dico con la zappa come mio solito farò incazzare metà community però un po' è javascript flavor c# perché ci si avvicina parecchio anche perché tra l'altro è stato diciamo ideato dallo stesso ideatore se non ricordo male di c#, non vorrei dire che assurdo, però un po' lo ricorda.Quindi per me era un po' il tentativo di portare il c# nel web e poi mi vedo Blazor e la dico ma allora il tentativo TypeScript che è diventato secondo me uno standard de facto o comunque ambisce a essere quello è fallito quando invece per me è un successo? La risposta è assolutamente no sono due cose completamente differenti e si può usare TypeScript in Blazor per esempio tranquillamente per quanto concerne l'interoperabilità con javascript.Poi ci arriviamo però è importante capire che nel mondo Microsoft per anni Microsoft ha detto ai sviluppatori non usate javascript ci penso io a generare il javascript che serve pure perché il browser di riferimento nel mondo Microsoft non lo nominiamo neanche che adesso non c'è più, non seguiva proprio gli standard web e a un certo punto c'era un framework che venne dopo quello che ho saputo dopo Aspix è venuto un framework che si chiama Webform che si preoccupava di generare ti dava dei controlli già pronti e tutta la parte già la generava anche sulla base del browser che stava invocando la pagina con tutti i rallentamenti e i problemi del caso e quando però poi si si è resi conto che quello strumento purtroppo in alcuni scenari non andava da nessuna parte e si è passati a realizzare un framework basato sul pattern MVC allora lì Microsoft ha cominciato a dire agli sviluppatori "dovete usare javascript, è inevitabile, dovete scrivere HTML, CSS e cominciare ad usare javascript" poi con le varie versioni ci sono stata tutta una serie di helper che hanno aiutato però era chiaro che ad un certo punto se non si doveva lavorare su quello.Il primo step è stato duro, è stato molto pesante e molti programmatori Microsoft hanno detto "fortuna che esiste jQuery che almeno si semplifica un pochino la parte di manipolazione del DOM e le chiamate alberghette".LM: Ricordiamo sempre jQuery, bisogna essere riconoscenti.assolutamente riconoscente.Poi è ovvio che c'è stato un momento in cui Microsoft ha deciso di riscrivere una parte, di dilattare tutto il proprio framework e di avere due versioni, una versione che fosse cross platform che è .NET Core e .NET full framework che invece era il framework di riferimento per lo sviluppo su Windows.In questo passaggio sono successe tantissime cose e a quel punto era chiaro che a un certo punto JavaScript avrebbe comunque avuto un ruolo fondamentale nello sviluppo sia web che non e quindi sicuramente creare uno strumento che in qualche modo intanto ti permettesse di utilizzare degli standard che magari non erano ancora adottati da tutti i browser, usare un approccio tipizzato anche se sappiamo è una tipizzazione a tempo di traspirazione, però una tipizzazione ti permetteva di guardare il typescript un po', devo dare già un po' come tu guardavi C#, effettivamente l'idea era proprio quella e tante migrazioni di clienti che venivano magari da altri mondi sono riuscite perché gli facevi vedere i typescript e loro pensavano "ah beh è C# che gira" in realtà poi gli spiegavano la traspirazione e capivano che c'era il barbatrucco però è chiaro che all'inizio è servito a portare tanta gente su quel mondo e sicuramente è uno strumento che ha avuto un successo cronoso specialmente ti dicevo quando si è passati a dotnet core e gli è stato chiaro che Microsoft ad un certo punto ha detto perfetto per tutto quello che è server side tu hai a spagnolette mvc quindi usi quello lo conosci già ti diamo altre funzionalità continuiamo a lavorare su quello.Con questo stesso framework puoi fare anche delle IP addresse.Perfetto.A questo punto decidi se il frontend lo vuoi renderizzare server side utilizzato da Smart MVC oppure scegliete un framework javascript, Angular, React, Vue, quello che vuoi, col quale puoi usare anche TypeScript se vuoi.In qualche caso era nativo come nel caso di Angular 2+ o React poi è diventato typescript lo state riferimento adesso anche Vue sta adottando typescript come...diciamo che ci prova.Ci prova.L'idea era...Anche se è scritto in typescript questo scusami Michele ma lo devo dire.Assolutamente.È scritto Vue 3 è scritto in typescript ma usare typescript con Vue qualche pain point lo hai? Lo dico con cognizione di causa perché ci sto lavorando e voglio solo piangere.Io me lo ricordo all'epoca di quando Angular fu riscritto in TypeScript, da AngularJS ad Angular fu riscritto in TypeScript, e c'era un famoso post sul blog del team che diceva "adesso non riusciamo a fare le factoring in ore", che prima gli chiedeva giorni, perché c'è l'atmizzazione forte, la possibilità a tempo di traspirazione, di avere tutta una serie di cose che ci permette di evolvere il framework in maniera più veloce, con i rilasci che poi avevano dichiarato di fare.e a quel punto un pochino Angular stava diventando lo standard di riferimento per il mondo Microsoft anche per chi decideva a quel punto di migrare.Era comunque uno sforzo importante.Sì però l'imprinting Angular era comunque molto opinionated quindi un po' ci stava...Anche proprio il framework ricordava molto l'approccio tipico dei framework Microsoft.si vedeva quella...non voglio dire la sua pregione di direzione, però lo vedi quando fai un componente in React e quando lo fai in Angular la differenza, la vedi che c'è un framework sopra per fare un componente quando magari React con due righe di codice, tre righe di codice...esatto e quindi lo vedi che c'è proprio un approccio differente, solo che in mondo Microsoft è abituato a quell'approccio con un framework che ti fa il controlle, ti fa l'action, ti stende la classe base, tutte queste cose qui erano all'ordine del giorno quindi non spaventava così tanto Angular, ci aggiungi TypeScript e hai fatto bingo restava però il problema che tanti non volevano...avevano tanto cosa scritto in C#, volevano continuare a usarlo e soprattutto una cosa di cui si parla poco è che si dice "io scrivo il frontend con Angular, con un framework JavaScript qualsiasi e il back-end se espone dell'API REST può essere scritto in qualsiasi linguaggio ok, vero però se è scritto in .NET se è scritto in .NET o è scritto in PHP come vuoi io devo prendere i oggetti che tu mi restituisci già so che mi restituisci in TypeScript costruimi un'interfaccia che mi tipizza quell'oggetto e se questo oggetto cambia io devo cambiare il codice devo cambiare l'interfaccia perché è tutto dinamico, io non posso sapere se il back-end è cambiato o no che può essere scritto qualsiasi tecnologia.Ed è qui che Microsoft arriva con Blazor dicendo "Se hai un backend scritto in .NET e quindi tu sei un programmatore .NET, quindi C# lo conosci, ho un framework che, usando degli standard web, sottolineiamo utilizzando degli standard web, ti permette di riutilizzare i codici C# che già hai scritto e continuare a scrivere i codici c'è g# per il frontend facendolo girare nel browser.Questo è stato il momento clu perché aveva detto due cose importanti.La prima, posso riutilizzare il codice che già ho.La seconda è che l'oggetto di scambio tra backend e frontend non è una copia, è lo stesso, è lo stesso oggetto e quindi se cambia l'autobackend il mio frontend non compila più, perché è cambiato l'oggetto oppure se faccio le facoltà di autobackend questo può essere fatto anche ad frontend perché non è TypeScript che è tipizzato come dire al tempo di trasferizione qui è tipizzato, C# è tipizzato a livello di compilazione a tempo di compilazione quindi un linguaggio fortemente tipizzato e questo ti permette di sfruttare tutto quello a cui sei già abituato.Per i programatori .NET questa era una cosa incredibile era una cosa incredibile innanzitutto perché Microsoft alla sfidgia diceva dicendo che non deve usare più javascript e non è vero ok è stato quella è stata una mossa un po di marketing però è vero che tu puoi usare c# al posto di javascript per fare la parte di elaborazione della UI Per cui provo a fare dei parallelismi magari anche un po' forzati, ricapitolando Blazor è un modo per portare il codice C# e farlo girare nel frontend quindi scelare, condividere delle librerie, dei blocchi di codice che sono un po' utilizzati sia dal backend che del frontend mi vengono in mente, cosa ne so, le interfacce dei DTO, che tra l'altro devo dire che nel mondo javascript questa cosa si fa, nel mondo typescript questa cosa si fa, io utilizzo typescript frontend e backend e io con il monoripo ho una bella cartellina shared che dove ho tutte le interfacce e a quel punto utilizzo le stesse interfacce per il backend e per il frontend.Certo, questo perché il tuo backend è scritto in TypeScript.Però è interessante vederlo nel mondo Microsoft per quel segmento di sviluppatori che lavorano in quel ecosistema.Esattamente.E mi chiedo, allora non so se tu ne hai mai sentito parlare, sicuramente ne hai sentito parlare ma mi chiedo rispetto all'Aravel, l'Aravel aveva fatto qualcosa di simile con l'Aravel non Inertia ma c'era un altro nome? Purtroppo non conosco, li conosco di nome ma cerco di stare lontano da PHP, ci ho fatto giusto un progetto all'università poi mi sono diventato più possibile.Guarda lo capisco benissimo.No, la Ravel ricordo che da qualche tempo a questa parte ha promosso questo nuovo modo di scrivere dei componenti utilizzando per il componente la logica PHP si chiama LiveWire e quindi un po' diciamo mi viene da fare un parallelismo però non so quanto in realtà quel codice PHP poi giri nel client, giri nel server, c'è una mega punto di domanda.Invece il codice front-end di Blazor dove gira? allora, ci sono due versioni di Blazor, una chiamata Blazor Server in questo caso il codice gira lato server e quello che viene fatto è io ho un DOM iniziale che è stato creato nel browser tengo traccia di questo DOM lato server faccio la mia elaborazione a seguito di un input dell'utente elaboro il nuovo DOM, faccio il diff tra i due prendo questo diff e lo pusho utilizzando WebSocket al mio frontend che applica le modifiche al DOM reale cioè alla libreria JavaScript che applica queste modifiche quindi elaborazione, avvia tutto server-side e uso WebSocket per pushare le modifiche alla UI che vengono elaborate in autoserver questa è stata una delle prime versioni rilasciate di Blazor ed è molto utile quando hai alcuni requisiti uno di questi è "io non voglio che sul client ci sia il mio codice" in quel caso tutto il codice è sul server e tu pushi solo le modifiche al DOM e su client c'è HTML, CSS e JavaScript e c'è un pezzettino di JavaScript di aggaggio con Blazor che prende le modifiche al DOM e le applica al DOM del browser ovviamente da per scontato che ci sia supporto a WebSocket in realtà dietro a noi si usa una libreria molto conosciuta nel mondo Microsoft che si chiama SignalR che ti permette di scalare la comunicazione server client da WebSocket a LongPolling o ad altre tipologie senza che lo sviluppatore sia mai preoccupato, però questa cosa funziona molto bene se c'è il supporto a WebSocket perché le performance qui hanno ovviamente un'importanza vitale e si ha una connettività stabile tra backend e frontend perché se non ce l'ho basta che la connessione viene meno e a quel punto il ping che comunque viene fatto per mantenere attiva la connessione non viene stabilito e la UI si frizza, esce proprio "non c'ho connessione" una piccola banda che ti dice "non c'è connettività" e quindi le applicazioni intranet ha molto senso magari come primo approccio al passaggio da vecchie tecnologie Microsoft a Blazor può essere un primo approccio più semplice e sono tutti quegli scenari in cui sicuramente l'elaborazione server ha i suoi vantaggi.C'è una domanda su questo, scusa se ti interrompo, ti farò un po' di domande perché sono curioso.Ripeto, io tolta con la mia esperienza Microsoft e TypeScript, in realtà per me questo mondo è tutto nuovo, quindi capiterà di farti domande stupide.Perdonami.No, la mia domanda è, abbiamo detto che l'elaborazione viene fatta dal server, io che vengo in questo caso, sì sì poi come dicevi c'è anche un'alternativa allora io che vengo dal mondo di React mi chiedo, React ha la sua particolarità del virtual DOM, del diffing, come funziona se questo tipo di elaborazione viene fatta lato server? semplicemente un'implementazione che non tiene conto di virtualdom e tutte queste cose che ci sono nel browser e semplicemente viene mantenuto lato server lo stato sostanzialmente in maniera ottimizzata lo stato del DOM però ovviamente in una rappresentazione che sia facile da modificare e sulla quale sia facile e veloce fare un diff e alla fine dei conti non è niente di particolarmente complesso io ovviamente lato server ho molte più risorse di quelle che ho nel browser e quindi posso ho multitrading o tutta una serie di cose che mi permettono di lavorare in maniera parallela.Sai perché questa domanda? Perché io mi chiedevo da dagnubissimo ma per fare il diff, ripeto io vengo da un mondo dove il virtual dom ce l'ho stampato in testa quindi quel modo di ragionare mi è molto familiare e probabilmente non c'entra niente però se io devo fare un diff? La mia domanda era ma allora cosa devo devo mandare lo stato del DOM attuale verso il server che fa una...No no lo stato del DOM è sempre server side una cosa che tu mandi al server è l'azione che ha fatto l'utente, cioè ha cliccato su un pulsante ha scelto un elemento da una casella di test insomma l'input dell'utente mandi quello lato server tramite sempre web socket lui applica quest'operazione server-side e calcola il nuovo DOM e manda il diff al client quindi in realtà tutto appena server-side in questo lato per questo la connettività deve essere stabile altrimenti non funziona più banalmente non funziona più nulla.Sì sì è chiaro infatti mi chiedevo se andava a modificare dall'inspector qualcosa cosa succede? Niente, viene sottoposto e mi manda la nuova versione del DOM che lo va a sostituire esattamente naturalmente non ci posso fare delle robe che hanno bisogno di tante performance lato front end nel senso che per esempio delle cose in real time in real time o difficili allora in realtà anche in placer server tu hai la parte di interoperabilità con javascript quindi laddove tu abbia la necessità di eseguire del codice javascript quindi ovviamente qui entri nel mondo non Microsoft, quindi devi conoscere Javascript o usare delle librerie Javascript, puoi fare tutto quello che fai nel browser normalmente.Ovviamente quella parte lì non è sottoposta a change traking da parte di Blazos, quindi di conseguenza tutto quello che fai client-side resta client-side.All'approssimazione server-side, interazione server-side, quella si perde perché il server mi manda una nuova versione del DOM? Se in contemporaneo lavoro in C# e Javascript sullo stesso pezzo di DOM, sì, assolutamente sì.Ovviamente c'è una libreria che permette l'interoperabilità tra C# e Javascript.Quindi tu da C# puoi chiamare una funzione Javascript, la Javascript può invocare un metodo a distanza o un metodo statico in C#.Questo è permesso.e in Blazor Server questa cosa è semplicemente una chiamata attraverso la WebSocket che va a evocare un metodo remoto che si trova lato back-end non è niente di strano, è molto semplice però ti permette comunque a quel punto di far parlare i due mondi e questo aiuta che tu potessi fare qualcosa in JavaScript e poi chiedere a Blazor di modificare il DOM ma che in realtà chiamerebbe comunque alla fine dei conti modifica il DOM, lo manda di nuovo al browser atti dalle differenze al DOM.Bisogna capire fino a che punto può avere senso una cosa del genere.Probabilmente se fai tanta di questa roba forse hai scelto il framework sbagliato.A me questa domanda forse è un po' edge, mi è venuta in mente partendo dal...cercando di proiettare il mondo Next.js perché ci ho trovato dei parallelismi poi lo andremo a vedere dopo con la seconda modalità non di Blazor però ci ho trovato dei parallelismi allora ho detto sì va bene e quindi esiste un modo per i Next si chiama reidratare il DOM con il mio framework e quindi questa domanda insomma veniva da questo.A questo punto però tu mi hai detto che esiste anche un'altra modalità di utilizzo di...Sì perché in realtà questa non è una vera e propria single page application cioè qua stiamo parlando di elaborazione server side con il trucco di pusciare le modifiche del domo tramite websocket questo è tutto ovviamente nella realizzazione ha i suoi benefici però se io voglio realizzare una single page application è dire non funziona se non sono connesso cioè se appena manca la connettività l'applicazione si blocca non è una single page application ok e non è solo un problema di connettività è proprio l'idea che se il mio codice non sta girando nel browser, non sta girando client side in realtà sto ancora facendo elaborazione server side e e quindi esiste una seconda versione di Blazor chiamata Blazor WebAssembly e il nome già dice tutto perchè sfrutta un altro standard web che si chiama WebAssembly che permette di far girare WebAssembly è un linguaggio più a basso livello che gira comunque nel JavaScript runtime e quindi ha le stesse funzionalità anche se non riesce ad accedere ad alcuni contesti del browser però ti permette di lavorare in maniera più performante all'interno del browser lo standard è stato creato e viene utilizzato per poter lavorare con linguaggi di alto livello poter compilare in un linguaggio a più basso livello e avere il massimo delle performance che si possono avere dal browser ok? Microsoft che ha preso questo standard e ha detto alla fine una DLL è una libreria perché nel mondo Microsoft magari DLL non dice niente ma è una libreria di codice scritto in .NET che è sostanzialmente del codice IL Intermediate Language, cioè il compilato di C# che viene fuori dalla compilazione questo codice quando viene eseguito sostanzialmente viene gittato sul codice macchina quindi si fa un'applicazione in .NET, crea una TLL, crea un'assembly in .NET e questo IL non è codice macchina quindi a seconda della macchina su cui sto girando, sull'architettura su cui sto girando c'è un pezzo del framework che converte questo ILL in codice macchina una roba tipo virtual machine di java esattamente, ma molto molto più ottimizzato non c'è una secuzione step by step, c'è un'ottimizzazione molto forte a livello di git compile c'è tutta una parte di ottimizzazione di caching quindi ci sono delle forti ottimizzazioni, c'è comunque un garbage collector c'è tutto quello che magari se viene dal mondo java ti è già familiare ma l'idea è che se io voglio far girare questa roba nel browser, in realtà l'unica cosa che mi serve è avere il runtime di .NET che può fare questa traduzione in questo caso da IL a WebAssembly ok? e posso avere due approcci ok? cioè potevo avere due approcci quando se io fossi Steve Sanderson che molti magari conoscono per Knockout chi magari ha un po' più di anni e se lo ricorda è la persona che ha creato Blazor e lavora sul team di Blazor WebAssembly e lui lamenta sostanzialmente dietro questo progetto e potremmo fare due cose o cerco di prendere il codice C# e compilarlo in WebAssembly però ovviamente questo richiederebbe uno sforzo importante e soprattutto una volta che l'ho compilato il codice WebAssembly basta oppure se io voglio prendere del codice C# e farlo girare sia lato backend o condividolo tra backend e frontend io devo poter eseguire quel codice nel browser allora che hanno pensato di fare? hanno preso il MonoFramework, che è un porting del runtime.net a sistemi non Windows l'hanno ricompilato in WebAssembly e quindi quello che succede è io scarico il codice IL, quindi codice compilato di C# lo eseguo nel browser grazie al runtime di .NET compilato in WebAssembly e quindi è la stessa DLL che gira nel browser perché ho il runtime di .NET che sta girando nel browser quindi è una roba un po' del tipo WebAssembly fa girare Mono che fa girare il mio codice e questa roba non crea dei problemi di performance anche perché la mia domanda è mi devo scaricare il monoframework? quanto è grande? esatto hai beccato i due problemi di Blazor il primo è il primo download dell'applicazione è molto grande perché il runtime di per sé sono 200k 250k, cosa del genere, dipende un pochino a seconda di quale versione di Blazor lo stai usando comunque non è piccolo, non è assolutamente piccolo c'è sicuramente un peso iniziale, poi devi scaricare tutte le DLL del tuo Threat Framework che usi più la DLL del tuo codice, quindi questo primo download è molto pesante poi WebAssembly nasce per esaucere problemi di performance solo che se ci metto questo layer in mezzo che mi fa questa traduzione tutte le performance che mi regalava WebAssembly le prendo tutte perché c'è un layer in mezzo che deve gettare codici e WebAssembly e questa cosa, sostanzialmente, rende ad oggi Blazor molto più lento e molto più pesante rispetto a una Angular dico Angular perché faccio confronto tra framework e non fra...un framework e una libretta, io preferisco fare confronto tra due cose un pochino più complesse però parliamo di 2 MB di template base contro 200 K massimi di Angular sul template base, quindi parliamo di dimensioni completamente differenti questo solo per il primo download poi tutto quello che è cacheabile viene cached e i successivi ovviamente vengono buttati giù, solo le cose che servono però è importante, sono due punti fondamentali quindi Blazor non risolve, grazie a WebAssembly, il problema delle performance di .NET nonostante nell'ultima versione ci sia la possibilità di compilazione diretta webassembly del codice .NET solo questa cosa rende il pacchetto da scaricare ancora più grande e la sola compilazione dura 10 minuti quindi è una cosa impossibile al momento da usare, però se tu hai dei pezzi di codice G# che fanno operazioni CPU intensive si dice allora quella modalità ti potrebbe essere molto utile perché a quel punto hai le performance di WebAssembly valuti a seconda degli scenari che devi coprire se devo creare un qualcosa che fa editing di foto probabilmente ha senso se devo fare una forma in cui metto dei dati da mandare a back-end non ha molto senso tra l'altro Blazor nasce come framework per creare applicazioni si dice line of business applicazioni per mettere in termine gestionali in cui ho tante forme in cui inserisco dati e devo salvare le sue database da lato back-end sostanzialmente e quindi le feature importanti di Blazor si vedono in questo tipo di applicazione quindi sicuramente non solo le performance, almeno in questa versione Ok, hai parlato...Blazor è un insieme di strumenti per ora, nella mia visione hai però parlato anche di Blazor come framework quando tu mi hai parlato la prima volta di Blazor io ho detto ok questo ci fa girare del codice C# fondamentalmente nel browser con il trick di farlo passare per WebAssembly e va bene però adesso ha introdotto il concetto di framework e allora a livello di framework invece Blazor cosa questa porta? questo è molto interessante perché intanto dal punto di vista di framework che io uso in Blazor server o Blazor WebAssembly non cambia nulla, è esattamente lo stesso framework, decido solo se farlo girare l'altro server o farlo girare l'altro client.A livello di framework di Torre Quinte c'è Razor che è l'engine di Microsoft per far girare per quello che tu dicevi anche se non ricevi angolare per cento, no? L'engine che ti permette di trasformare il codice nel linguaggio di riferimento, in questo caso in C#, nel corrispondente DOM.E' la parte di così che ti permette di fare il binding tra il markup e il codice, ma soprattutto introduce il concetto di componente resource, quindi il concetto di componente a cui ci siamo abituati in Angular, in React, in Vue, all'interno del framework frontend.Esattamente stesso concetto quindi posso creare dei componenti come pezzi user interface dove ho un markup, ho del codice C#, ho delle espressioni che mi metto di mettere in binding il codice C# col markup e questa roba alla fine dei conti può generare una classe C# che va a finire dentro una DLL C# che viene eseguita o lato server se utilizzo Blazor server o lato client se utilizzo Blazor WebAssembly tenendo presente cosa importante che la sintassi di Razor è la stessa a cui io sono già abituato se conosco AspNet e MQC.Quindi Microsoft ha detto io prendo tutto quello che tu già sai del mondo .NET e te lo faccio usare lato frontend introducendo il concetto di componente dove componente qui si intende in componente lato frontend ok quindi lo stesso a cui siete abituati se usate un altro framework o libreria di frontend.Hai parlato di markup quindi HTML rimane ci siamo liberati solo di JavaScript allora se voglio far girare la mia applicazione nel browser allora devo usare il markup HTML uso HTML e questo è l'approccio poi esiste una versione di Blazor al momento sperimentale dentro un progetto che si chiama Maui che utilizza un markup diverso per fare applicazioni native come applicazioni per esempio, in quel caso non uso l'html ma uso un markup differente che è simile a quello di Xamarin Form per chi conosce il mondo Microsoft e conosce il framework Xamarin quindi l'idea è che l'approccio è quello, il markup che usi sarà, non è, sarà tra qualche tempo diverso a seconda che tu faccia un'applicazione che gira nel browser o debba girare nativamente Quindi sarà la volta buona che Microsoft si libererà di React Native? No, non penso.A meno per il momento.Sai cos'è? È sempre lo stesso concetto che vale per Blazor.Se io vengo da Modo.net, allora probabilmente mi avvicino a questo framework.Se io Modo.net non lo conosco, non lo imparo per usare quella tecnologia.Conosco Java, script, conosco React, userò React Native.è la ragione per la quale è difficile confrontare Blazor con altri framework perché Blazor ha senso per chi è già nel mondo .NET per chi non c'è avrebbe un debito tecnico altissimo per riuscire a usarlo invece chi è già dentro praticamente io ho imparato Blazor non voglio essere, sai, quello che dice "ah vabbè, ti vuoi vantare" no, conoscendo già i framework di frontend, conoscendo già il mondo .NET è bastata mezza giornata per capire i concetti ed era tutta roba che già conoscevo quindi in realtà seguendo i primi tutorial ti davi dentro la roba e capivi i meccanismi per riuscire a creare applicazioni e il grosso di quello che ti dà Blazor e i framework Microsoft è proprio questa forte integrazione tra qualcosa che già hai studiato, che già conosci, che già hai imparato e che fai parte di quel mondo e poterla riutilizzare, è quella la chiave che poi ha determinato il successo di questo lancio di Blazor Ti faccio un'altra domanda io sono ne ho un gozziliardo, sono super super curioso.Tu hai detto che Bledzor può e sta, ci sono dei tentativi per farlo entrare nel mondo mobile, io ho letto anche che c'è qualcosa relativa al desktop, mi è sembrato di leggere qualcosa tipo Blazor desktop e la mia domanda è ma l'idea che sta alla base di Blazor è quella di compilare in WebAssembly il monoframework e quindi far girare le proprie librerie ma fuori dal ecosistema browser che bisogno c'è di fare questo passaggio intermedio e soprattutto in questo caso Blazor si comporterà in un modo diverso? sì allora l'idea è questa ci sono diversi approcci al momento sono tutti sperimentali quelli fuori dal browser c'è Mobile Blazor Bindings che è un modo di usare Blazor in Xamarin che è un framework per fare applicazioni mobile Microsoft sta lavorando su un framework che si chiama MAUI che promette di permetterti con un unico XAML chi conosce MWPF, MWPF Microsoft, Xamarin phones usando un locksum, che è un altro tipo di markup di utilizzare la tua applicazione per mobile, desktop o web se mai ci sarà al momento in .NET 6 che viene rilasciato il 9 novembre ci sarà una versione di MAU che non è ancora definitiva si spera verso marzo/aprile dell'anno prossimo di avere una prima release da poter utilizzare però stiamo dicendo che Microsoft stava cercando di fare uno sforzo di andare verso un'unificazione dello sviluppo front-end e poterlo applicare a diversi ecosistemi ora, che poi utilizzi Blazor con MAUI o utilizzi MAUI in maniera nativa sono scelte del programmatore se tu vieni dal mondo web e devi fare un'applicazione mobile, ti faccio usare quello che già sai a patto che impari un nuovo tipo di markup che non si accattina mai questo per fare un'app nativa poi puoi sempre fare un'app ibrida quello lo puoi sempre fare o lo puoi fare già adesso a ibrida significa che c'è un'istanza del browser che gira all'interno di un'app desktop o un'app che potrebbe essere per esempio un'app mobile con facilities come per esempio tu hai già un'applicazione desktop Microsoft scritta magari con Windows Form o WPF, sono due tecnologie Microsoft per lo sviluppo desktop c'è un componente chiamato WebView all'interno del quale puoi far girare un'applicazione Blazor in quel caso, in quel caso specifico, anziché usare WebAssembly, che non avrebbe molto senso vi fa girare i codici C# nel processo Windows che già c'è e usa delle chiamate interop verso WebView per modificare il DOM questo ti dà performance molto molto molto spinta ed è anche un modo per dire, tu hai un'applicazione desktop esistente vuoi migrarla al web ma non la puoi fare da oggi a domani comincia le parti nuove, se vuoi svilupparla in Blazor e ospitare la tua applicazione desktop poi piano piano magari te le migri oppure hai un componente Blazor che vuoi riutilizzare la tua applicazione desktop e la tua applicazione web lo puoi fare.Questa è un po' l'idea.Microsoft spinge molto su questi punti perché sono le domande che gli fanno i programmatori Microsoft.Molti stanno ancora sul mondo desktop dove ha senso che restino lì, molti non hanno migrato le applicazioni al mondo web perché avevano paura, avevano timore, dovevano riscrivere troppa roba.Dovevano cambiare metà del team.Quello sicuramente, però è interessante come approccio per questi particolari sviluppatori e quindi ha molto senso nel mondo Microsoft.Quindi ogni volta che sento paragonare Blazor ad altri tipologi di framework che hanno target completamente differenti è sempre solo discorso vogliamo dire che mele e pere sono frutto ok ma ma sono due cose differenti e quindi servono a target di sviluppatori differenti e in questo senso, Playzore ha delle cose che gli altri framework non hanno ed è questo che lo rende un framework unico nel suo settore, nel suo target per esempio, io faccio sempre questo esempio qui perché è comprensibile quando io devo creare una forma in Angular o anche in React una forma è fatta di campi input e validazioni prendiamo il caso di Angular che io usi template form o reactive form io devo comunque esprimere le regole di validazione client-side queste regole client-side io le devo sempre replicare anche server-side perché ci metto due secondi a disabilitare le regole di validazione lato client Quindi io vado a fare questo lavoro due volte e soprattutto se cambiano le regole di validazione io le devo cambiare sia lato backend che lato frontend.Siccome in .NET e in Blazor io posso dire "questa classe è l'oggetto di scambio tra i due e io le regole di validazione le metto in questa classe" o come annotazioni su singoli campi o implementato una particolare interfaccia che a quel punto fa validazione anche complessa.Quella stessa classe è la stessa per il backend e per il frontend, se scritto in Blazor, e a quel punto io le regole di validazione le metto una sola volta, in un'unica classe, e automaticamente il codeci viene validato client-side da Blazor e server-side dal model-binder di MVC.E questo è un risparmio enorme in termini di tempo e di manutenibilità, perché se cambiano le regole di validazione o cambiano i campi che fanno parte del form, io li cambio in un punto solo.Questa io la chiamo la Killer Feature che ha reso Blazor quello che è oggi un framework a cui tutti gli scrittori maestro stanno guardando con grandissimo interesse.Ti faccio una domanda cattivissima questa, hai la libertà di non rispondere.Molti all'interno della community e molti ascoltatori sanno che io per una parte della mia vita ho sviluppato in action script le vere cose fighe le ho fatte in action script 3 ma le hai viste tutte tu? se c'era una tecnologia di merda lo provo no scherzo io ho amato profondamente action script e la cosa bella che facevo quando sviluppavo in ActionScript era per culare gli sviluppatori Silverlight perché nessuno se lo cagava diciamoci la verità a parte il sito credo della Rai pochi altri l'hanno utilizzato adesso io sto estremizzando in realtà l'avevano utilizzato però il supporto e diciamo poi è andato via via a scemare io mi facevo figo del fatto che comunque il supporto per ActionScript c'era e poi come la buona legge del contrapasso dimostra me la sono pigliata in saccoccia anch'io però la mia domanda è per quanto riguarda Blazor ci sono dei segnali sul fatto che è una tecnologia nella quale vada davvero la pena investire perché comunque mi fa star tranquillo che dopo domani non devo riportare tutto su React e studiare JavaScript Allora, la risposta è mentre in C++ tu e anche in Flash andavi a installare un plugin per poter far funzionare tutto questo Microsoft è partita dicendo, in realtà Steve Sanderson che poi è stato tirato dentro Microsoft, dicendo "usiamo degli standard web" questo quantomeno ci consente di rimanere nell'ambito della standardizzazione, del grosso sforzo che si fa nell'ambito della standardizzazione web e questo è un primo punto l'altro è nel passaggio da .NET full frame o .NET core, in particolare .NET 6 che viene rilasciato il 9 novembre è stato abbandonato il framework webform di Microsoft e Microsoft ha detto "migrate a Blazor" quindi ha abbandonato un framework molto molto utilizzato nel mondo Microsoft e ha detto "migrate a Blazor" dicendo questa cosa ha preso un impegno importante un framework che ha 20 anni, quindi una storia di 20 anni, un installato di 20 anni ha detto "non lo mantengo più" nel senso che quello che c'è c'è ovviamente controlleremo il supporto finché ci saranno i termini di supporto ma migrate a Blazor con questa tecnologia a 20 anni e non possiamo continuare a portarla avanti e ha dato Blazor come riferimento.Questo ci dà un'indicazione non la sicurezza, ci dà un'indicazione che ci sia un grosso interesse a investire in questa tecnologia.La verità è che se tu vieni dal mondo Microsoft passare a Blazor è abbastanza semplice, perché usi tutte le cose che già sai.Quindi fai un investimento basso e ovviamente nel momento in cui lo fai, quantomeno la parte di acquisire le competenze è uno step abbastanza veloce.E' ovvio che nel nostro mondo, nel mondo dello sviluppo in generale, ma nello sviluppo front-end in particolare, dire che da qui a 20 anni avremo ancora Brezza, sinceramente non lo può dire nessuno, ma neanche da qui a 10 anni, di conseguenza quello che dico sempre a tutti quelli che mi fanno queste domande, a tutti quelli che continuano a dirmi, a chiedermi, queste domande me le facevano su Angular quando facevo i corsi Angular, facevo gli eventi e le sessioni su Angular, scrivete il codice in modo tale che non sia troppo legato alla tecnologia di frontend che avete scelto.In Angular era mettete più più roba possibile nelle classi di C# perché il C# resterà di quello possiamo essere abbastanza sicuri quindi cercate di scrivere il codice pensando che un domani magari dobbiate cambiare il codice di frontend sembra una paraculata se mi lasci il termine ma in realtà è la cosa che in questi anni anche di azienda ci è stata molto utile per dire noi usavamo TypeScript in AngularJS all'epoca ci prendevano in giro ci prendevano in giro tutti, ma in realtà ci ha salvato perché ci ha costretto a mettere tutto nei service e nelle migrazioni, nelle riscritture perché non erano mai migrazioni da Angular, ci ha salvato la vita, perché nel doverlo fare impostavi già le cose in un certo modo, e quindi stessa cosa vale per tutti i framework di frontend, scrivete il codice in modo che la logica, il vostro codice vero stia fuori dal framework, perché così come in angular, in .NET Core, qui è basato Blazor, tutto si basa sul concetto di Dependency Injection, mettete tutto in una classe, iniettate la dovevi serve e chiamate i metodi della classe.A questo punto lo fate oggi in Blazor, domani in Boo, come si chiamerà? Il vostro codice sarà riutilizzabile.Quindi la sparsa è buona? Non lo so, ma si sta investendo.Noi, diciamo, chi ha visto tutti i framework Microsoft, ci sono tante differenze con i framework che poi sono stati abbandonati, però la certezza assoluta non ve la darà mai nessuno.Di conseguenza, approccio difensivo, tenete il codice fuori dalla tecnologia.Sì, poi tra l'altro ci tengo a ricordare che qualche tempo fa abbiamo fatto, sempre sulla base di quello che ha appena detto, un episodio con Alessandro Minocchieri sull'Hexagonal Architecture, quindi ci tengo a ricordarlo l'episodio 78, se ve lo siete persi recuperatelo perché parla proprio di queste cosine qua e di come rendere il codice diciamo resiliente al cambio delle architetture.Ti faccio una domanda così un po' un po' folle.Folle? Sì, io lo ripeto sempre, un libro che mi ha colpito particolarmente è Functional Domain Driven Design di Zblaszyn, non lo so neanche pronunciare, che ha una particolarità.Gli esempi sono scritti in F#.F# è un po' un linguaggio underrated, però abbastanza interessante.Ci sono degli approcci funzionali a questo mondo o è strettamente legato al C#? Allora, premesso che C# sta diventando sempre di più un linguaggio funzionale? Ad oggi se ci tieni tanto puoi usare C# in maniera funzionale, premesso questo, non sono un fanatico del loro sviluppo della programmazione funzionale, ma da tecnico sicuramente la guardo e vedo vantaggi e svantaggi in alcune circostanze, però la cosa interessante è che C# va molto in quella direzione, hanno introdotto i record, hanno introdotto l'immutabilità, hanno introdotto tutta una serie di concetti e soprattutto noi abbiamo un linguaggio di interrogazione dei dati che si chiama LingQ basato sull'elampada expression che è molto vicino a tanti concetti che sono della programmazione funzionale.Quindi in realtà più che parlare di linguaggio per rispondere alla tua domanda è che C# ad oggi, nella versione 10 in particolare 9/10 è un linguaggio che è sempre più funzionale di cui alcuni si lamentano di questa cosa, altri invece la vedono come una possibilità di approccio perché F#, nonostante anche F# sia pensato per essere un linguaggio funzionale ma anche lì si scende a tanti compromessi per poi poterlo utilizzare insieme alle librerie, framework Microsoft c'è un po' un approccio ipido, quindi l'idea almeno che mi sono fatto io è che nel mondo maso scegli C# principalmente, poi se vuoi avere un approccio funzionale puoi usare gli ultimi costrutti inseriti nel linguaggio che fanno proprio in questa direzione.Ok, no, era una curiosità perché comunque una volta che tu hai il monoproject, come si chiama? Sono un iubizio, sono anche in imbarazzo a parlarne perché veramente ne so pochissimo.Però una volta che c'hai i mono in realtà a quel punto farci girare C# o farci girare F# forse quello che mancava era appunto il framework perché a livello di catena di tool dovrebbe...Sì, ma sai, alla fine dei conti tutti i linguaggi, diciamo che sono basati su un 33 frame, compilano in IELTS, quindi che io lo scrivo da User Basic, da C# o da F#, quello che viene fuori alla fine è sempre codice intermedio.Quindi è stata di approccio alla programmazione diversa, ci sono alcuni linguaggi che ti spingono, che ti danno degli strumenti, che ti aiutano a utilizzare certi approcci, e linguaggi invece che non ti aiutano minimamente e quindi c'è solo la tua buona volontà nell'utilizzare i linguaggi in quel modo.Quello che è successo è che nelle ultime versioni di C# stanno introducendo tanti concetti a livello proprio di sintassi che ti portano a sviluppare laddove ha senso con un approccio molto più vicino al funzionale che alla programmazione ad oggetti classica insomma e sicuramente è un segnale forte sul fatto che probabilmente anche se puoi guardare le ultime versioni dei framework Microsoft, in .NET 6 hanno introdotto le minimal api, hanno introdotto il g# 9, hanno introdotto i record, questo concetto di mutabilità, tutta una una serie di cose che ti fanno pensare che comunque si vada in una certa direzione senza necessariamente prendere posizione senza necessariamente dire "da oggi tu sviluppi il funzionale se vuoi usare G#" l'idea è che puoi usare un approccio o un altro il linguaggio ti permette o ti permetterà quantomeno di usare entrambi gli approcci, scegli quello che ti serve e magari in alcuni casi, senza un approccio di oggetto oriente, in altri casi magari un approccio funzionale è più funzionale ai tuoi requisiti.Chiaro, chiarissimo.Mi piaceva immaginare di fare un'applicazione web scrivendola in F#.Sì, sì, si può, si può tranquillamente.Si dici, te la butti in WebAssembly per i vantaggi web di Blazor, però in realtà puoi farla girare.Ti faccio l'ultima domanda in realtà.in realtà.Io lo ripeto e lo ripeterò fino a finire il fiato, sono inubissimo di questo mondo, però tu hai parlato di .NET Core, dicendo che è fondamentalmente il monoframework, giusto? No, non dire una cosa del genere che ci dica.La versione del .NET Framework è cross platform, quindi si può sviluppare e fare la girale su mac, su linux o su windows in maniera completamente diversa.C'è un supporto a livello Microsoft per far dire un framework che sia completamente cross-platform sia nello sviluppo che nell'esecuzione del codice.Allora perché abbiamo tirato fuori questo, abbiamo tirato fuori Mono? Qual è la relazione? Perché prima dell'arrivo del .NET framework l'unico modo di portare .NET su linux per capirci, era questo progetto non Microsoft che era il monoframework e quel framework lì ha una storia che viene molto da lontano e soprattutto il porting di quel runtime di .NET è facilmente portabile su qualsiasi sistema e portarlo su WebAssembly non dico che è stato semplice ma è stata sicuramente la prima scelta ok perché ovviamente c'erano i layer di separazione dal sistema sottostante e quindi sono andati a implementare quelli e hanno ricompilato in WebAssembly quello che c'era.Ok quindi se ho capito bene questo è stato il primo passaggio che ha fatto Blazor per girare giusto? Questo è stato il primo passaggio che è stato fatto sì perché inizialmente stiamo pensando se era creato utilizzava un'altra libreria che che si chiamava .NET Everywhere, che era un porting di .NET a qualsiasi target poi si è visto che era sicuramente meglio utilizzare Mono e portarlo a WebAssembly perché per la community che c'è dietro, per la conoscenza che c'è e soprattutto per le forti ottimizzazioni che erano necessarie e si decise quindi di abbandonare questo .NET Everywhere e si passò al porting di Mono a WebAssembly questo perchè attualmente .NET Core può targettizzare diverse architetture di processori ma non è pensato nonostante si possa riscrivere l'implementazione tranquillamente, che è quello che viene fatto con Mono ma l'idea è quella di supportare diversi sistemi operativi, almeno i principali e architetture x64, x86, ARM e laddove sia necessario, magari anche cose completamente differenti.Chiarissimo, che esplorazione! Grazie per aver fatto da Cicerone, Matteo tanto non ti lascio andare, almeno non ti lascio andare prima di averti portato in questo momento tipico e topico dei nostri episodi.Il momento come ormai tutti sanno e anche tu ormai sai, è il Paese dei Balocchi.Nulla e quindi ti chiedo se hai un libro, un video, un qualunque cosa abbia catturato la tua attenzione che valga la pena insomma di essere condiviso con la nostra community.riconducono il paese dei balocchi.Ah, il paese dei balocchi! Sì, allora io ormai sono della community, quindi ho seguito molte delle puntate, ho recuperato anche un po' di puntate vecchie e quindi ho visto che la maggior parte dei libri tecnici che io adoro li avete già citati, ok? Un po' perché sono, dico quasi sempre gli stessi, un po' perché alla fine dei conti non sono tantissimi i libri che ti cambiano la vita dal punto di vista tecnico, quindi volevo puntare su qualcosa di non tecnico che ha avuto un impatto su di me e sono tantissimi libri, però ne ho due in particolare.Uno che è tornato alla ribalta grazie a una serie tv uscita su Apple Plus che è di Isaac Asimov, magari i più giovani non lo conosceranno, ma il ciclo delle fondazioni, la trilogia delle fondazioni di Sir Casimus, è uno di quei libri che mi ha scomporto perché mi ha tenuto incollato per sere e sere, quelle cose del tipo.Io sono molto addicto alle serie TV, io sono stato un mese con la TV spenta a finire questa trilogia perché mi ha preso in una maniera veramente assurda e purtroppo l'ho scoperto molto tardi.E quando scopri questo libro molto tardi ti accogli che tutta la fantascienza che ha amato in realtà è nata lì e quindi vi consiglio assolutamente di leggere la trilogia delle fondazioni di Asimov perché è un libro bellissimo, veramente bellissimo.L'altro libro, non c'è tra niente con il nostro mondo, è un libro che si chiama "Lezioni di meraviglia" di Andrea Colamedici e di Mara Tancitano, parla di filosofia senza farti odiare il parlare di filosofia, l'ha regalata a Raffaella, la mia migliore amica, perché sapeva che mi sarebbe piaciuta, infatti mi è piaciuto tantissimo.È un approccio alla filosofia, alle domande esistenziali che ci facciamo, che si fa ognuno di noi, in una maniera secondo me molto molto semplice, anche magari per chi come me non ha fatto studi classici.Poi in generale Maura Cancitano e Adrian Ramerici, i fondatori di Tron hanno creato questa missione di vita, quella di portare la cultura della filosofia alla portata culturale di chi non ha fatto studi classici, proprio perché è fondamentale per rispondere non solo alle domande importanti della vita, ma anche alle domande che ci facciamo ogni giorno, anche sulla quotidianità.Se non conoscete il libro, assolutamente leggetelo, poi seguite i due autori che hanno anche podcast, hanno scritto un sacco di libri, veramente ce ne sono tantissimi.Tra l'altro c'è anche "Libretti della brava bambina", un libro che consiglia a tutte le donne e a tutti gli uomini che vogliono capire il mondo femminile, che è una cosa complicata.E' un altro libro bellissimo, sempre di Mauro e Andrea, seguite i loro podcast, i loro non sono libri tecnici, però sono quei libri che li leggi e ti fanno vedere il mondo in una maniera completamente differente.LM: E poi sono sicuro che sono quei libri che in qualche modo ti colpiscono, ti cambiano, e quel cambiare poi si riflette necessariamente anche nel lavoro che fai.Esattamente.E siccome mi hai provocato, anche io allora ho deciso di portare un balocco off topic, è anche questo libro, quindi non lo so, preparatevi per le ferie di Natale per leggerli tutti.Ce l'ho, me l'ha regalato un amico, si chiama La strategia Oceano Blu.Ho iniziato a leggere questo libro quando nel mio periodo markettaro, quando mi occupavo anche del marketing dell'azienda.In realtà è un libro che non parla di marketing, ma parla di contesto e di analisi del contesto.Il titolo tradotto in italiano fa ridere perché il sottotitolo è "Vincere senza competere", ma voi lo sapete ormai, questi libri, questo tipo di saggi quando sono tradotti risultano banali.però è veramente un libro bellissimo scritto da W Chang Kim e poi da una sua assistente che era poi la sua assistente e pubblicato dall'Harvard Business Review Press quindi insomma non stiamo parlando di...e parla di come trovare il proprio contesto il proprio spazio in un contesto di competizione sia essa una competizione tipo aziendale quindi per trovare un prodotto nuovo e uscire dall'oceano rosso, l'oceano pieno di squali, per andare in un oceano blu dove non ci sono gli squali e nuoti da solo e quindi più semplice raggiungere il successo.Può essere portato nel nostro mondo professionale per trovare un segmento da battere in modo da differenziarci dall'offerta generale ma se letto con un pochino più di attenzione è un libro che stimola l'emersione della propria personalità.Quindi ci sono più livelli da leggere.Io adesso siccome siamo in un podcast tecnico dico se stai cercando il tuo percorso professionale hai bisogno di capire come posizionarti ancora prima di scegliere una certa tecnologia sia essa javascript type script o blazor leggi questo libro perché ti fa capire che metodo devi utilizzare per scegliere poi quella tecnologia quindi sì l'idea è questa quindi anch'io gingillo e balocco topico.Vai, ottimo.È il momento di ringraziare chi ogni settimana supporta il nostro podcast.Noi ci mettiamo il nostro tempo, il nostro effort e molti di voi ascoltatori reputate insomma il nostro podcast di valore e quindi ci fate delle donazioni che per noi sono insomma delle birre invitate all'interno del nostro bar virtuale.Grazie a queste birre noi abbiamo l'ambizioso obiettivo di acquistare i microfoni per tutti i membri di GateBar in modo da portare su il livello di qualità audio che possiamo darvi e quindi portare sui livello generale della qualità del prodotto che ogni settimana vi portiamo nei vostri client di podcast.Per farlo però abbiamo bisogno del vostro supporto che questa settimana ci è stato dato da D3W92 che ci ha invitato 5 birre, ci ha invitato queste 5 birre mandandoci anche un messaggio scrivendo grazie per essere i compagni di viaggio nel tragitto casa lavoro.Fonte inesauribile di spunte e di riflessioni.Ho la mia lista dei desideri stracolma dei vostri ottimi balocchi.Brindo con voi al mio Gitbar preferito alla salute e anche noi brindiamo alla salute di G3W92 ringraziandolo per il supporto che in questo episodio ci ha dato.Quindi grazie e cin cin Guardavo l'orologio siamo già quasi un'ora e venti io credo che La puntata è belle che è andata mi ha fatto super piacere averti qua Con qui qua nei ghit bar a bere una birra con me in realtà tu sei abbastanza presente anche nella community.Oggi insomma ti sei spostato vicino al bancone e ci siamo condivisi.Questa birra mi ha fatto iper piacere così come mi ha fatto iper piacere scoprire questa tecnologia che insomma sicuramente avrà il suo spazio.Hai detto bene che non sarà un competitor nato per essere competitor di altre tecnologie ma ha proprio il suo segmento di riferimento ed è molto precisa da quel punto di vista poi magari un'altra volta possiamo fare un'altra puntata invece su Microsoft l'open source e su Linux subsystem che, devo dirlo, sono due settimane che lo sto usando per lavoro ed è stata l'unica cosa che veramente ha funzionato in modo fluido da subito.Tanta roba, tanta roba.Super Inception però super situazione strana vedere una roba tipo un input form di Gnome su Windows ho detto che cosa è questa roba? Forse un alieno? particolarissimo e soprattutto porta Microsoft ad essere un sistema pratico utilizzabile anche per chi fa back end con javascript, chi fa front end in un certo modo che fino a ieri piangeva sangue diciamoci la verità e soprattutto se lavorate con container e magari lavorate su architetture un pochino più spinte vi dà quell'ambiente necessario a fare alcuni test che invece altrimenti doveste fare in altro modo e soprattutto l'esperienza di sviluppo integrata di questo sottosistema con gli ambiti di sviluppo Microsoft è eccezionale qualcosa che in assi sistema non esiste, veramente non esiste a questo punto è arrivato il momento dei saluti Michele io ti ringrazio di nuovo di essere venuto a trovarci come dico a tutti, Gitbar è anche casa tua quindi vienici a provare quando fuoi o quando hai qualcosa di interessante dal mondo di Redmond ci provo, senza parlare di RAL e senza parlare di tastiere sì assolutamente perché ormai è saturo il gruppo Telegram quando vedo in realtà 160 messaggi da recuperare io so che o si è parlato di RAL o si è parlato di tastiere e/o simili di PHP per parlarne ma di PHP esatto naturalmente scherzo io ho adorato PHP detto questo io vi do appuntamento alla prossima settimana con un nuovo episodio vi ricordo rapidamente i nostri contati info@gitbar.it e te bene il repo su Twitter oppure il nostro fantastico gruppo Telegram raggiungibile cercando git bar all'interno della casellina di ricerca vi ricordo che abbiamo come obiettivo cambiare i microfoni degli ammutinati quindi se vi fa piacere supportate invitate le birre alla nostra community il link lo trovate direttamente nel sito internet detto questo vi ricordo anche perché in realtà mai senza se non l'avete ancora fate avete un device apple mi raccomando lasciate una recensione questo ci aiuta a emergere nelle classifiche di iTunes e siccome molti client di podcast si appoggiano a questo tipo di mi ricordano un po' i siti delle directory degli anni tardo 90 no? quindi l'unico modo in realtà per emergere là e ricevere più Reviews possibile oppure se vi fa andate a lasciarci una recensione su Spreaker detto questo nulla io ringrazio di nuovo Michele grazie davvero e vi do appuntamento alla prossima settimana.Ciao! Gitbar, il circolo dei fullstack developer.Una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei fullstack dev.[Musica] Sottotitoli e revisione a cura di QTSS No.
