Benvenuti su GITBAR, il podcast dedicato al mondo dei fullstack developer, i mezzo artigiani, i mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.Bene e benvenuti, un nuovo episodio di GITBAR.Io sono Brain Repo e prima di partire a palla con questo nuovo episodio mi interessa ricordarvi nostri contatti.Potete scrivermi direttamente @gitbar su Twitter oppure a info@gitbar.it.Ma non perdiamo troppo tempo con le informazioni che ormai iniziate a conoscere anche abbastanza bene, ma andiamo subito sul vivo dell'argomento di oggi.Prima di entrare però sul vivo dell'argomento mi Mi interessa ricordarvi che oggi per me è il 15 maggio 2020, quindi voi mi starete sentendo con qualche giorno di ritardo.Perché vi ricordo la data? Perché in realtà quando mi riferisco ad Avantieri intendo il 13 maggio, perché il 13 maggio è stato rilasciato Dino.Ma prima di partire a parlare di Dino, mi interessa fare un po' il momento c'era una volta e iniziare a raccontarvi una storia.Era il 2009 quando Ryan Dahl, spero si pronunci così, inizia a scrivere e scrive e rilascia il runtime per JavaScript chiamato Node.Un qualcosa di veramente rivoluzionario che porta JavaScript a girare fuori dal browser.è un'applicazione scritta in c++ che integra al suo interno il motore v8 e stravolge il mondo di web dev e non solo perché in realtà questo runtime viene utilizzato in ambienti completamente diversi.Qualche tempo dopo Ryan Dahl abbandona lo sviluppo attivo in node lui giustifica questa azione perché reputa l'attività che faceva dentro node abbastanza noiosa il fatto di riparare bug fix e fare mantenere la code base di node lo annoia quindi abbandona quel lavoro per concentrarsi nello sviluppo di server in Go quindi approfondisce il livello il il linguaggio Go e si concentra su quello.Qualche tempo dopo la sua carriera ha un'evoluzione e si trova in una società a lavorare agli algoritmi di machine learning in javascript.Naturalmente mentre lavora in javascript e mentre usa a piene mani il runtime che è quello di Node, in qualche modo ha ideato lui, si rende conto di una serie di limiti e di una serie di "rimpianti" quindi tornando indietro ragiona su questo e nel 2018 alla JS Conference EU tiene proprio un talk dove parla appunto dei rimpianti che ha in alcune scelte che ha fatto dei...insomma dice che non è più così convinto di alcune scelte che ha fatto nell'implementazione di Node.Però Node ormai è in produzione, Node ormai ha un'adozione massiva in buona parte dell'ecosistema web e non solo quindi sono delle scelte nelle quali non si può più tornare indietro e quindi sempre durante questa conferenza presenta un'idea l'idea di deno che cos'è deno? deno è un runtime un po' come era node per js e java e typescript un runtime però sicuro by default.Poi entraremo nel merito proprio di questa affermazione.Quindi andremo a vedere quali sono le caratteristiche di questo nuovo prodotto che poi in realtà qualche anno dopo è stato rilasciato infatti avantieri.Questo prodotto nasce come side project proprio nel momento in cui Ryan Dahl si trovava a sviluppare algoritmi di machine learning.Nasce come come side project per poi arrivare a un certo punto dove l'AIP che si sviluppa attorno a questa quest'idea lo porta a abbandonare il lavoro in questa società dove si occupava appunto di sviluppo di librerie machine learning in javascript per dedicarsi a tempo pieno in questo ambizioso progetto coinvolgendo con lui anche Bert Belder, spero si pronunci così, un collaboratore conosciuto per essere colui che ha fatto il porting di Node su Windows e dopo tanto lavoro il 14 maggio di quest'anno appunto avantieri è stato rilasciato la prima versione stabile di Dino.molti descrivono Dino come l'alternativa a Node.In realtà Dino si differenzia con Node per tutta una serie di caratteristiche e proviamo per un attimo ad analizzarle una per una e provare a capire in realtà dov'è e quanta distanza c'è tra un runtime e l'altra Intanto la prima è che, come dice il nome stesso di Dino, ha un supporto nativo di TypeScript.Sappiamo tutti che TypeScript è un superset di JavaScript che inserisce la tipizzazione, quindi permette a JavaScript di lavorare con i tipi.Lavorare con i tipi permette comunque di effettuare una scrematura di bug già in fase di scrittura codice.Questo perché appunto ti dà una sorta di type safety che ti permette di evitare quegli errori che si hanno quando non rispettiamo una corretta assegnazione dei tipi delle variabili.Naturalmente Node supporta nativamente solo JavaScript e tutto ciò che riguarda gli Static Types deve essere naturalmente traspilato in JavaScript per cui poter girare dentro Node.Con Deino invece c'è una differenza sostanziale.Infatti con Deino non è più necessaria la compilazione manuale dei file TypeScript.Perché? Perché Deino stesso li prende in consegna e utilizza una tecnica interna per compilarli e per poi eseguirli.Questa tecnica tra l'altro prevede anche l'utilizzo di una cache di compilazione per evitare di ricompilare più volte lo stesso script che magari non ha avuto delle variazioni.In questo caso riesce ad ottimizzarli.Ottimizzazione fatta anche, ottenuta anche, grazie all'uso di una funzionalità chiamata V8 Snapshot che non è altro che una funzionalità che l'engine V8, quindi l'engine che permette l'esecuzione di JavaScript, mette a disposizione per avviare appunto lo stesso engine in modo più veloce e permette quindi una compilazione TypeScript in tempi veramente rapidi.Quindi questo engine cosa fa? Carica il codice in memoria, lo compila e poi lo serializza su un file pronto per un utilizzo successivo, la famosa cache di cui vi parlavo prima.In questa prima fase Dino utilizza il compilatore typescript di javascript quindi in realtà utilizza esattamente in un modo o nell'altro i tool che usiamo noi manualmente per compilarlo però la cosa interessante è che lo fa tutto in modo trasparente quindi non dobbiamo fare noi questa operazione ma ci pensa direttamente lui avendone supporto nativo.C'è da dire anche che il team di Dino sta lavorando per scrivere un compiler appunto TypeScript utilizzando il linguaggio Rust che come è ben noto è un linguaggio molto più performante per questo tipo di attività e che quindi farà in modo che il lavoro del compiler sia ancora più veloce di quanto non lo è adesso.Se volete dei maggiori dettagli su questo tipo di progetto vi allego all'interno delle note dell'episodio anche il link github della repo github proprio di questo progetto che si chiama SWC project.Una delle cose che mi piace evidenziare spesso riguardo ai moderni linguaggi di programmazione è il concetto di ecosistema, concetto che permette a un linguaggio di programmazione di superarne un altro o di permettere un'adozione più massiva dello stesso ed è uno dei concetti in realtà che ha fatto grande Node.All'interno infatti dell'ecosistema node emerge lo strumento npm il gestore dei pacchetti ecco questo strumento ha permesso a node di diventare fondamentalmente quello che è tanto che all'interno appunto dei registri di node troviamo pacchetti per ogni tipo di soluzione e di problematica beh però in realtà In realtà quello che Ryan Dahl evidenzia appunto del gestore di pacchetti npm sono una serie di vulnerabilità.Non per ultima il fatto che Node utilizza una sintasi import che è quella di CommonJS, la famosa Require.una sintesi che è un po' diversa dall'ecosistema per esempio browser e ha tutto un sistema di importazioni diversa c'è da dire però che dalla versione 14.2 di Node c'è un supporto sperimentale agli ECMAScript modules però naturalmente la versione 14.2 è l'attuale versione e il supporto è solo sperimentale quindi in realtà Node ha un suo modo per importare i moduli Altra cosa importante che però ci porta a ragionare in realtà è un limite tipico di diversi ecosistemi e lui lo evidenzia in modo molto chiaro.Uno dei problemi del sistema di pacchettizzazione appunto di Node.js sta nel fatto che in realtà utilizza tutta una serie di passaggi.Ci sono infatti diversi sistemi coinvolti nella gestione dei pacchetti.il primo passo che bisogna fare è includere nel nostro file sorgente la chiamata alla dipendenza quindi il primo passaggio il secondo passaggio è andare a creare un package.json che è comunque anche quello va fatto un terzo passaggio che è quello di fare l'installing dei vari pacchetti richiesti e quindi la generazione della cartella node modules che poi diventa enorme come ben sappiamo e il quarto elemento che entra in gioco in questo ecosistema è il mantenimento dei pacchetti nel database di npm.Tutti questi passaggi solo per l'inclusione di una dipendenza.Dano stravolge questo approccio.In primis implementa gli ECMAScript modules out of the box box.Utilizza quella versione per includere appunto le dipendenze.Altra cosa importante ti permette di includere le dipendenze ovunque esse siano.Infatti tratta le dipendenze come dei semplici file javascript o typescript.Noi possiamo includerli usando appunto gli ECMAScript modules ma questi file possono risiedere in qualunque server, in qualunque spazio, visto che l'unico modo per identificarla in realtà sta nell'url che è un url autoesprimente quindi vuol dire che all'interno dello stesso indirizzo noi abbiamo il nome della libreria, la locazione e il numero di versione.basta non ci serve altro perché nel momento in cui andremo a buildare o eseguire il nostro script verranno scaricate automaticamente buttate o comunque caciate localmente per non far sì che a ogni esecuzione ci sia uno scaricamento e abbiamo in modo completamente trasparente tutte le librerie.Tra l'altro DAL sottolinea un'altra cosa importante.Dice che spesso il concetto del modulo è stato abusato di questo concetto all'interno dell'ecosistema node.E spesso in realtà il concetto del modulo era del tutto superfluo.Una strazione non necessaria come dice lui.E' una strazione che prevede appunto la generazione di elementi boilerplate che possono essere i file readme, il file di licenza e il repositorio description che in realtà non portano nessun valore aggiuntivo alle linee di codice della stessa libreria.Quindi cosa fa? Va a mettere come attore centrale del sistema delle dipendenze di Dino non il modulo ma semplicemente il file javascript o typescript quindi anche qua c'è proprio un ragionamento volto al pragmatismo così come in realtà questo tipo d'approccio fa sì che all'interno dei nostri progetti non si vada a creare quella famosa cartella node modules dove per fare un semplice server http ci tira giù 70 80 mega di dipendenze in realtà non c'è bisogno di tutta questa massa di dipendenze semplicemente ci andiamo a scaricare giusto le dipendenze che sono strettamente legate a quello che vogliamo fare vengono cached centralmente all'interno della nostra macchina che fa appunto la quindi è l'esecuzione e basta quindi c'è un unico punto centrale che archivia le dipendenze e tutto il processo di gestione delle dipendenze è assolutamente trasparente tra l'altro è possibile gestire naturalmente questa cache chiamando appunto e passando il il parametro reload proprio per ricaricare le dipendenze.C'è però un lato negativo in tutto questo che l'idea può anche essere molto interessante anzi dal mio punto di vista è particolarmente innovativa però noi veniamo da un momento dove l'ecosistema node è potentissimo.I moduli che sono presenti dentro npm sono da un certo punto di vista la forza e il potere dell'ecosistema javascript non solo legato a node perché in realtà ormai anche ciò che utilizziamo nel browser passa per npm perché basti pensare a quando scarichiamo le nostre dipendenze poi compiliamo tutto con webpack si stiamo trasformando tutto in un javascript che butteremo nel nostro server però comunque le dipendenze le gestiamo con npm e dino non è compatibile con i pacchetti npm questo vuol dire che dino dovrà o sviluppare un sistema di compatibilità per portarsi a presso anche quei pacchetti oppure dovrà andare a costruire un nuovo ecosistema e questo diventa già un pelino più impegnativo.Quando ho introdotto Dino vi ho detto che Dino è una secure runtime per javascript e typescript ma questa parola secure a cosa si riferisce? Beh quando pensiamo a Node pensiamo che in realtà è un sistema che permette l'accesso completo al file system, alla rete, a tutto l'ambiente.Questo non vuol dire che le applicazioni che noi andiamo a sviluppare su node non siano sicure ma vuol dire che di default permette l'accesso a tutti questi componenti quindi non sono applicazioni secure by default quindi quando noi andiamo a eseguirle la nostra applicazione salvo che noi non blocchiamo alcuni comportamenti potrà avere accesso a tutti questi elementi.Questo fa sì che Node sia veramente flessibile e che ci permetta di interagire senza troppi mal di testa con tutte le componenti del nostro sistema.Però ci sono tutta una serie di edge case che non riusciamo a controllare.Basti pensare a un linter.quando noi lanciamo un linter nel nostro codice questo linter ha accesso completo a tutte le risorse del sistema così come hanno accesso completo tutte le dipendenze che noi includiamo e quindi ha un accesso possiamo dirlo incontrollato a meno che noi non ci andiamo a verificare il il sorgente o a controllare a posteriore il comportamento di questo a tutte le componenti sia essa o fall system sia essa la rete.Bene Dino agisce in modo completamente diverso e a parer mio in modo anche un po più moderno.Infatti ci permette di operare in un'area sandboxata quindi una sorta di cassettina di sabbia dove noi possiamo eseguire il nostro codice che però di default ha tutto questo tipo di accessi bloccati.Saremo noi infatti in fase di esecuzione ad abilitare alcune funzionalità piuttosto che delle altre.Come lo faremo? Andremo a farlo appunto passando nell'istruzione che poi metterà in esecuzione il nostro codice un flag per esempio se noi vogliamo attivare l'utilizzo della rete allora dovremmo per esempio perché stiamo facendo un piccolo serverino http allora dovremmo passare il flag - - allo - net se vogliamo andare a leggere sul file system potremo passare il flag "allow_read" uguale il nome delle cartelle che noi vogliamo andare a permettere ad autorizzare per poter appunto essere visibili dal nostro script.Quindi il fatto di gestire a runtime le autorizzazioni direttamente da Dino ci permette di avere un controllo abbastanza preciso di quelle che sono le risorse del sistema che stanno appunto per essere utilizzate dal nostro programmino, dal nostro software, in modo abbastanza semplice, semplicemente passando appunto un flag in fase di esecuzione.In realtà questo è possibile perché la struttura di sicurezza in realtà è by design con Dino.Infatti Node interagiva con il sistema operativo in tutta una serie di modi.Quindi in realtà mettere una sorta di chiusura all'azione verso alcune componenti del sistema operativo non era poi così semplice.In realtà By Design Dino è pensato per permettere la comunicazione tra l'engine v8 che è il posto dove gira il nostro codice e il sistema operativo attraverso quindi Dino Process fondamentalmente attraverso una sorta di canale di messaggi quindi noi abbiamo da una parte il motore v8 dove facciamo girare i nostri script dall'altra c'è il processo il motore v8 ti permette in modo abbastanza aperto di eseguire tutto quello che vuoi però quando tu poi devi andare a girare a livello di sistema operativo hai bisogno di avere una serie di privilegi privilegi che come vi dicevo prima sono autorizzati run time la comunicazione tra queste due componenti avviene attraverso il protocollo di serializzazione chiamato protobuf.è un protocollo abbastanza usato forse qualcuno di voi l'avrà incontrato e quindi permette semplicemente chiudendo questo canale di comunicazione di scambio di messaggi per alcuni tipi di messaggi di gestire in modo molto pratico in modo molto agile tutto ciò che riguarda appunto la sicurezza creando e portando Dino ad essere un sistema sicuro by default quindi non dobbiamo fare nessun tipo di configurazione o utilizzare nessun tipo di accortezza per mettere in sicurezza la nostra applicazione da questo punto di vista ci pensa direttamente Dino perché è stato progettato per essere così.Una delle funzionalità in realtà che la community javascript impegnata appunto su node.js ha sentito e ha provato in qualche modo a colmare con librerie di terze parti il non supporto nativo delle promises.In realtà c'è da dire che Ryan aveva inserito il supporto in node nel 2009 ma l'avevo rimosso pochi mesi dopo nel 2010.Questo ha permesso in realtà una cosa molto positiva che è lo sviluppo di librerie di terze parte quindi in un modo o nell'altro si è identificata la strategia migliore per l'implementazione appunto delle Promises.Ma ad oggi che ci troviamo nella versione appunto 14 di Node non è presente out of the box il supporto e questo c'è da dire che è un grande limite anche perché ormai le promises sono entrate a far parte io credo del 90% dei nostri script ormai sono entrate nel nostro processo di programmazione veramente in modo invasivo.Dino dal suo canto in realtà le implementa e quindi implementa le Promises e gli Async Iterables in modalità nativa cioè ce li hai già out of the box per cui è molto facile tra l'altro anche per quanto riguarda gli Async Iterables trovare degli await in realtà direttamente senza star dentro una funzione assincrona.Per esempio se noi dovessimo implementare vi consiglio di andarlo a vedere il piccolo server http con dino noteremo di appunto una weight che sta a livello più alto quindi a top level a fianco a un for.Questa è una cosa molto interessante e comunque anche questo tipo di elementi rendono in realtà il codice che gira su dino decisamente più moderno.Tra l'altro una cosa molto interessante è che in realtà tutte le standard libraries di Dino quindi le librerie diciamo che sono escono out of the box con Dino implementano le moderne ECMAScript features quindi in realtà c'è anche una un'omologazione da questo tipo mentre in realtà le librerie di Node.js sono ancora basate su un concetto a piene mani di callback.Quindi diciamo che la standard library di Node utilizza ancora in modo molto forte le callback e con un certo rammarico di Ryan non esiste alcun piano per evolvere questo tipo di libreria.perché prima vi ho parlato di in che cosa è scritto Dino, quello che è in realtà perché è importante capire questa differenza allora Dino all'inizio è stata la prima versione proprio una delle versioni super early era scritto in Go poi però ci si è resi conto che in realtà ci si scontrava con un'incompatibilità infatti c'era era un problema di garbage collection c'era il garbage collector di go e poi c'era a disposizione il garbage collector interno del v8 quindi si aveva una disposizione due garbage collector e bisognava fare dei salti mortali per per gestirli quindi si è deciso di portare il codice appunto iniziale di Dino in Rust.Una cosa molto interessante perché in realtà se noi pensiamo a come è sviluppato Dino riusciamo a capire quelle che sono dal mio punto di vista le sue opportunità e dove può avere spazio per andare a costruire un ecosistema resiliente.Infatti Dino è stato scritto avendo in mente l'approccio a componenti.Questa cosa è molto molto interessante perché in realtà è stato scritto andando a sviluppare una serie di crate spero si dica così perché non sono un esperto dell'ecosistema Rust però immaginiamo una serie di librerie ognuna con delle funzionalità abbastanza verticali.La base, a differenza invece di Node, che si presenta a noi come un un unico eseguibile che poi va a girare.Dino invece è tra virgolette, è sbagliato definirlo un framework, però è sviluppato attraverso appunto una serie di componenti.Componenti in realtà che in modo molto intelligente, pensate in modo molto intelligente perché possiamo andarne a prenderne anche solo alcune, inserirle nel nostro progetto e permettere al nostro progetto di far girare javascript questo apre tutta una serie di opportunità a dino per entrare nel mondo per esempio degli ecosistemi dei sistemi embedded perché tu hai la possibilità includendo queste componenti di avere all'interno del tuo progetto all'interno del tuo prodotto già un sistema integrato, un ecosistema per far girare javascript e typescript.Un ecosistema tra l'altro, per ricollegarci a quello che vi ho detto prima, che mette a disposizione già non solo un linguaggio per far girare gli script ma anche un sistema di dipendenze.E tutto questo out of the box quindi in realtà se io dovessi pensare a un modo per far esplodere Dino è appunto il mondo degli ecosistemi embedded.Se dovessi per esempio immaginare un altro utilizzo e mi immagino che sostituisca i pacchettini electron che sono sempre più presenti all'interno delle nostre applicazioni.Basti pensare che un'applicazione come Slack che usiamo quotidianamente si basa su Electron.L'applicazione di WhatsApp, se non mi sbaglio, si basa anche quella su Electron.Però la cosa interessante in realtà, che ci dà RUST, è il fatto che in realtà noi possiamo compilare il nostro pacchetto direttamente con il nostro codice typescript, prenderlo e shipparlo e distribuirlo.Questa cosa secondo me dà tante possibilità.Un'altra cosa importante legata al concetto di modularità con cui poi è stato scritto Rust, sta nel fatto che se io sto sviluppando il mio sistema e non ho bisogno di avere tutti i componenti di dino ma ho bisogno per esempio di un componente che mi permette di far girare solo il codice javascript io posso utilizzare quel componente specifico e questa cosa è molto interessante perché ripeto amplia veramente in modo importante le possibilità di Dino che non è più solo un runtime per far girare javascript e typescript in modo sicuro ma secondo me deve essere visto anche in un'altra ottica nell'ottica di superpoteri per la nostra applicazione in questo caso Rust che stiamo sviluppando e questo secondo me è una cosa molto importante che differenzia sostanzialmente non solo il senso dei due ecosistemi Dino e Node ma secondo me ne detterà proprio la via di sviluppo e la via di crescita di Dino.Certo Dino è ancora abbastanza immaturo e ha una serie di limiti non per ultimo quello che vi ho citato prima il fatto di non essere compatibile con con npm e quindi di aver bisogno di sviluppare un nuovo ecosistema cosa abbastanza impegnativa quando si parte da zero.E' abbastanza immaturo per cui lo stesso sviluppatore diciamo in qualche modo dice di utilizzarlo in piccoli progettini ma che nel quali appunto non ci scommettereste la casa.quindi si immagina almeno un piccolo approccio, un primo approccio nello sviluppo di piccoli tool.Io so che lo proverò, nel senso che ho provato il tutorial classico, tirare su un piccolo serverino HTTP, però mi piacerebbe approfondirlo un pochino, quindi so che proverò magari a giocare un pochino in questo prossimo periodo con le librerie standard e provare a fare qualcosa.anche perché mi affascina proprio l'idea che sta alla base di Dino, quella di poter essere incluso in altri elementi oppure quello di poter essere compilato tutto insieme compreso il mio codice TypeScript o JavaScript per creare un pacchettino shippabile quindi distribuibile.Questo è molto molto interessante.C'è da dire che in realtà è ancora un un po' un'incognita quello che Dino si troverà davanti poi nei prossimi tempi.Però di una cosa sono sicuro, è una cosa che comunque sono pronto a scommetterci.Sono pronto a scommettere che l'uscita di Dino in qualche modo servirà come stimolo per il mondo di Node.js perché Node.js deve liberarsi di alcuni elementi anche a basso livello che un po' stanno zavorrando ingessando l'ecosistema e che in realtà in realtà è difficile sbarazzarsi anche perché è talmente tanto adottato che insomma i tempi di sviluppo si rallentano parecchio però sono sicuro che questa uscita sarà da stimolo.Dalle mie parti si dice che la fame spinge il vecchio a correre e secondo me l'uscita di Dino stimolerà in qualche modo questo effetto.Quindi che Dino esploda o meno io sono sicuro che con l'uscita di Dino e con l'arrivo di questo tipo di informazioni questo tipo di stimoli agli sviluppatori gli altri ecosistemi non potranno stare a guardare.Spero che questo episodio vi sia piaciuto.Io ho cercato di racimolare tutte le informazioni che ho potuto.Ho guardato diversi talk, ho letto buona parte degli articoli che ci sono fuori su Dino.In realtà non c'è scritto tantissimo quindi più o meno quello che potete trovare in approfondimento e un po' quello che nei miei modi un po' arraffazionati vi ho raccontato io.Spero, ripeto, che vi possa piacere questo episodio anche se avrei voluto farlo uscire magari qualche giorno prima proprio a sottodatta però pazienza questi sono i tempi che abbiamo a disposizione.detto questo e prima di salutarvi mi preme ricordarvi i contatti appunto di github potete scrivermi a info@github.it naturalmente via mail oppure @brainrepo su twitter e trovare tutte le informazioni degli episodi e del podcast in generale su www.github.it se l'episodio vi è piaciuto apritelo col vostro client di posta e scrivetevi in questo modo riuscirete ad avere tutte le notifiche nel momento in cui usciamo con un nuovo episodio e potrete rimanere aggiornati.Se poi l'episodio vi è piaciuto davvero tanto beh allora a questo punto mi sento in diritto di chiedervi di aprire l'applicazione iTunes o podcast di Apple e di lasciare una recensione.Questo ci aiuta a crescere nelle classifiche di podcast di Apple e ci permette quindi di raggiungere più persone possibile.Detto questo io vi saluto, noi ci sentiamo la prossima settimana, da Lione è tutto, 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 degli strumenti immancabili nella cassetta degli attrezzi dei fullstack dev.[MUSICA]
