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.Bene benvenuti, ventiduesimo episodio di GITBAR, io sono BrainRepo e prima di iniziare come nostra consuetudine vi devo ricordare i nostri contatti potete trovarci nel sito www.gitbar.it la troverete tutti gli episodi con le note della puntata i link degli argomenti più interessanti che abbiamo trattato durante l'episodio e il transcript automatico quindi la trascrizione di ciò che noi ci diciamo inoltre potete scrivermi a info@gitbar.it oppure su twitter a @brainrepo sto già iniziando a ricevere alcune email direttamente da voi per cui siccome iniziano a essere un po' sto iniziando a pensare alla creazione di una piccola community però magari è una cosa su cui ci tornerò i prossimi episodi e nel frattempo iniziamo a metabolizzarla un po' a capire che tipo di strategie possiamo adottare per creare questo legame tra me e voi in un modo più solido e più duraturo insomma in qualche modo github bar ha nel suo nome appunto la parola bar che indica e descrive quel luogo dove gli sviluppatori si incontrano per lo scambio e se dallo scambio nasce la crescita beh appunto la comunità la community la creazione di una piccola community è un passo indispensabile per cui fatemi sapere cosa ne pensate scrivetemi a info www.getforkioscelogitpark.it o su twitter @brainrepo dicendomi se secondo voi questa è una buona idea oppure no quindi aspetto le vostre qualche giorno fa ho ricevuto una mail e ve la voglio leggere ciao Mauro mi chiamo Stefano e sono un full stack dev da più di dieci anni ormai ho trovato il tuo podcast da un paio di giorni e sto ascoltando una dopo l'altra le puntate che hai pubblicato grazie Stefano.Le sto trovando interessanti considerato che mi trovo in un periodo dove al lavoro sento un po' di stagnazione sulla tecnologia.Tecnologia che stiamo ormai utilizzando da diverso tempo e sto cercando nuove idee e spunti su quello che offre al momento il mercato per quanto riguarda i framework di front-end e non solo.Inizialmente la mia ricerca era improntata su angular piuttosto che reacto view per capire quale potrebbe essere il framework che svecchiasse il nostro attuale stack di front-end basato su tecnologia IBM.Ci sono molte alternative e capire quale faccia al caso mio e che sia un investimento per il futuro a lungo termine è abbastanza complicato.Se non, cominciando a leggere e provare in prima persona una alla volta, ma richiede tempo e risorsa più preziosa per noi.Hai qualche consiglio e merito? Come ti muoveresti nel mio caso.Partendo da queste informazioni, beh, è veramente difficile dire qual è il framework migliore.Anche perché in realtà la domanda che Stefano non ha posto, ma che spesso mi viene posta, qual è il framework migliore, è una domanda a parer mio del tutto sbagliata.Questo perché? Perché in realtà il framework migliore è per fare cosa? E' come chiedere qual è la macchina migliore? Non esiste una risposta.Esiste una macchina sportiva migliore in alcune in alcuni casi in alcune condizioni ma non esiste la macchina migliore in assoluto.Tu puoi avere una Ferrari che è migliore sicuramente di una Pandina 4x4 ma se vai in campagna la Panda 4x4, il pandino, riesce ad arrivare dove la Ferrari in realtà ti lascerebbe a piedi.Per cui qual è il framework migliore probabilmente è la domanda sbagliata.La domanda giusta dal mio punto di vista da fare è qual è il framework migliore per me e qual è il framework migliore in questa condizione.Per rispondere però a queste domande c'è la necessità di in qualche modo conoscere tutta una serie di variabili che derivano un po' dallo stile di programmazione, dal livello di competenza, da tutta una serie di fattori che in realtà a priori un'altra persona non può conoscere e non può conoscere con questo livello di profondità ed è per quello che è la cosa più importante in questo caso è quella di andare a esplorare con la propria esperienza e se non c'è l'esperienza andarla a costruire un po' come quando da bambini i nostri genitori ci dicevano non toccare il fuoco.Probabilmente il non toccare il fuoco era un consiglio, avremmo dovuto seguirlo, ma non l'abbiamo seguito e abbiamo imparato che il fuoco è caldo e fa male solo mettendo la mano sulla stufa.Questo esempio è abbastanza drastico devo dirlo, però allo stesso tempo ci in qualche modo introduce a un meccanismo, il meccanismo che in qualche modo ci insegna che l'unico modo veramente per imparare per farsi permeare da una serie di concetti e di idee è quello di fare l'esperienza e partendo da questa esperienza poter prendere delle decisioni che vincolano altra e che generano sulla quale poi si costruisce altra esperienza per cui quando mi si chiede qual è il framework io già dico il framework migliore io già dico e non è il caso va bene in questo caso di Stefano, ma ne ho approfittato per introdurre questa questa visione.Comunque io dico sempre "Ehi, è sbagliata la domanda a priori".Quindi si sta sbagliando l'approccio.Quando poi si arriva a chiedere qual è il framework migliore per me, la risposta che io spesso do è quella che ti rende più felice, più produttivo e quel framework nella quale costruiresti la tua carriera.ma per costruire la carriera e per misurare felicità e produttività è indispensabile sempre e comunque fare dell'esperienza.Ecco perché quando Stefano dice "il tempo e le energie per noi sono una risorsa preziosa" la mia risposta è sì, verissimo, però in qualche modo è importante potersi ritagliare del tempo per fare delle piccole esperienze.Non è necessario sviluppare un mega progetto per capire come ci si sente, qual è il feeling che si ha nell'utilizzo di un framework, ma è comunque importante provare a vederlo.Anche perché oggi i parametri con cui misuriamo solitamente i framework sono diversi.Sono le feature, la dimensione della comunità, la qualità della documentazione, la velocità e la performance, la popolarità, la longevità, la qualità del supporto che è fondamentale e in realtà quanto questi framework scalano poi quando il progetto cresce ma sono comunque tutta una serie di fattori che in realtà sono più o meno supportati e più o meno soddisfatti dalla triade.I tre framework che oggi sono nel mercato e hanno posizione stabile che sono angular react e view.Tutte e tre si posizionano comunque dando allo sviluppatore una serie di feature e più o meno sono le stesse.Chi fa le cose in un modo, chi fa le cose in un altro, ma le feature generalmente sono le stesse.Le comunità.La comunità attiva è un altro parametro importante ma entrambi i tre progetti hanno una comunità molto attiva.l'altrettanto si potrebbe dire per la documentazione documentazione di view di angular di react e una signora documentazione certo c'è un progetto che spica più dell'altro per qualità che ne so di per attività della community o per qualità della documentazione ma comunque sono tutti più o meno allineati così come in termini di velocità e di performance e quindi a questo punto i parametri che usiamo solitamente per valutare un framework in qualche modo iniziano a non essere più così distintivi tra uno e l'altro e tra l'altro spesso mi capita di vedere scelte di framework guidate dalla performance quando in realtà l'incremento di performance tra un framework e l'altro e di che ne so 50 millisecondi che poi se vai a vedere nell'esperienza complessiva è un lasso di tempo del tutto marginale per cui in realtà il parametro sul quale secondo me si dovrebbe scegliere il framework e parlo più di professionisti che in caso di progetti è comunque quanto ci si sente il feeling e sulla base di quella scelta guidata dall'esperienza che vuol dire provali tutte e tre anche se fai un semplice to do ma provali tutte e tre beh iniziare a costruire dell'esperienza è possibile che domani non ci si ritrovi più bene con quel framework ma esistono dei trucchetti delle quali vi parlerò proprio alla fine dell'episodio di oggi che in qualche modo ci svincolano dal legame matrimoniale che poi si fa quando si sviluppa utilizzando un framework.Detto questo proviamo ad andare a vedere un po' le caratteristiche di questi frameworks.Voi per competenza, che per tempo non mi trovo nelle condizioni di dare tutte le caratteristiche tecniche nel dettaglio, però in qualche modo ci danno una visione di insieme che è la mia visione del tutto personale su come mi sono trovato nella mia esperienza professionale ad utilizzare tutti e tre i framework perché sì li ho utilizzati tutte e tre in progetti diversi anche in fasi della mia vita professionale differenti e in un modo o nell'altro mi sono trovato comunque abbastanza bene ho realizzato dei prodotti che poi sono andati sul mercato costruiti su questi tre framework.Angular.Eeeh, Angular lo uso da diverso tempo.Lo uso dalla versione AngularJS che era proprio un altro framework però con l'arrivo di Angular beh senza dubbio sono rimasto affascinato.Il mio uso ne conseguiva semplicemente da un'esperienza.Dovevo sviluppare delle app ibride, un bail, e la soluzione più più comoda e più completa e per farlo in time window abbastanza ristretti era Ionic.Ionic allora implementava e utilizzava come framework Angular per cui volente o nolente siccome si era deciso di utilizzare quella tecnologia ho iniziato la mia esperienza con Angular e devo dire che una delle cose che mi ha colpito in quella mia fase specifica proprio a a livello professionale, era il fatto che Angular è di per sé un full framework, cioè c'è tutto.Quindi questo in una prima fase professionale mi rendeva veramente felice perché qualunque cosa mi servisse era già presente nei moduli di Angular, per cui non dovevo stare a cercarmi il pacchetto, la libreria o la funzione che faceva il caso mio.Certo è che poi andando avanti con le esperienze, anche con lo studio e approfondendo alcune cosettine mi sono sentito un pochino sovraccaricato da tutto quello che angular ti metteva a disposizione e quindi in qualche modo ho iniziato a sentire il peso del framework.Un'altra cosa interessante che mette a disposizione angular così come tutti i framework sono i componenti.Un modo facile appunto per realizzare applicazioni front-end partendo da moduli di funzionalità specifici, quindi degli elementi con i quali interagisci e che si occupano di porzioni specifiche della nostra applicazione.Angular realizza questi componenti attraverso l'uso di classi e di annotation.Senza dubbio in una prima fase il fatto che Angular usasse le classi e le annotation mi ha reso chiaro il concetto del componente anche perché sono arrivato dopo una piccola piccola piccola esperienza con Polymer sono arrivato nel mondo angular venendo da jQuery e quindi i componenti per me era un qualcosa di veramente strano e contorto da poter comprendere e il fatto che Angula li descrivesse in delle classi e che dividesse i tre elementi concettuali no? Il fatto della logica quindi il file javascript o typescript per essere più precisi, il file relativo alla parte dell'html e il file relativo al css.Beh fare questa distinzione mi ha reso facile quello shifting di ragionamento dato dal passaggio da un mondo come quello di jQuery dove avevo la mia pagina, avevo la mia interazione costruita in jQuery e il mio stile CSS a un mondo fatto a componenti quindi quella distinzione logica tra CSS per vestire, colorare e definirne la parte estetica, HTML per definire la struttura degli elementi all'interno della pagina e il javascript digi query per l'interazione.ritrovarmi questo punto di riferimento anche nei componenti mi ha aiutato a fare questo passaggio questo shifting e poi ho trovato anche della documentazione fatta veramente bene però una cosa che io ricordo sempre a tutte le persone che mi chiedono un consiglio è quella di andare a cercare un mentore perché perché spesso lo studio, partire dalla documentazione, lo si trova noioso.A parte quando partono le botte di curiosità, a quel punto si approfondisce senza sentire il peso, però leggere le documentazioni spesso diventa anche un po' statico, un po' noioso.Per cui avere un mentor con il quale confrontarsi che ti segue, ti affianca e senza dubbio una delle cose più importanti per chi vuole diventare sviluppatore.Un'altra cosa interessante che Angular ha è in realtà che il linguaggio che utilizza è TypeScript.TypeScript è un superset di JavaScript che gli permette di avere alcune funzionalità come per esempio i tipi e questo lo viene dato out of the box con angular un linguaggio molto potente che ci permette in realtà di gestire la complessità quando in realtà la nostra codebase cresce perché? perché semplicemente utilizzando i tipi abbiamo modo di incontrare gli errori a build time e non a runtime.Un'altra cosa importante è quella che comunque angular mi ha spinto ad approcciare a un nuovo pattern.Ho dovuto con l'utilizzo di angular imparare il pattern nvvm che insomma mi ha un po' in un primo primo acchito stranito poi in realtà è un pattern che ha abbracciato a pieno anche perché quasi tutti i framework moderni lo implementano e che in qualche modo mi ha affascinato perché portava nel processo di sviluppo della parte front-end delle mie applicazioni non dimentichiamo che non sono un front-ender ma un full stack quindi anche la mia competenza è un pochino più orizzontale rispetto a un frontender puro mi ha portato a vedere la logica frontend in un'altra ottica e devo dire che in realtà questa cosa mi ha gasato particolarmente.Qual è il concetto che sta alla base del pattern NVVM? E' il concetto che in realtà ogni vista ha il suo modello di vista.noi siamo abituati a vedere le nostre applicazioni ragionando in termini di model view controller quindi il controllore che fa certe azioni che vanno a inficiare sul modello e la vista che renderizza il modello e chiama le azioni del controllore.Beh questo paradigm è stato shiftato.Si è avuto questo shifting perché con l'avvento di internet e il fatto che l'utente prevedeva ed esigeva delle interfacce più complesse si è avuta l'esigenza di creare qualcosa in mezzo tra il modello e la vista.E' quello che si è andato a creare appunto il ViewModel.Che cos'è? non è altro che un oggetto puro che ha delle proprietà e dei metodi.Le proprietà rappresentano il modello della vista, i metodi la logica della vista, non necessariamente la logica di business dell'applicazione ma la logica della vista in questione.Vi faccio un esempio.Se io ho una lista di elementi, la funzione per aggiungere un elemento nella lista o per ordinare la lista beh potrebbe tranquillamente essere un metodo ed è limitato alla logica di quella vista specifica.Quel metodo sta dentro quest'appunto view model.View model che essendo disaccoppiato dalla logica di interazione col DOM rende la nostra applicazione più testabile e quindi oltre che più ordinata anche più sicura e più error proof a prova di errori e questo shifting mentale mi è stato guidato appunto dall'utilizzo del framework in questo caso di Angular perché è stato appunto appunto il primo framework che io ho abbracciato.Tra l'altro un'altra cosa molto bella che ho trovato con Angular è il fatto che in realtà il framework è completamente integrato con gli editor, con Visual Studio Code, con Sublime Text o con WebStorm o PHPStorm.Perché? Perché esiste un tool che è Angular Language Service che ti permette di utilizzare l'autocomplete del framework direttamente nel tuo editor.Questo ti permette di da una parte limitare e checcare gli errori in modo rapido già quando stai scrivendo il codice, dall'altro ti permette di saltare da un template al componente al modulo alle direttive in modo molto rapido e quindi ottimizza anche i tempi di sviluppo.Tempi di sviluppo ottimizzati anche da un tool a linea di comando molto potente.Una delle caratteristiche che mi ha catturato l'attenzione è stata quella che il tool a linea di comando, il tool generatore appunto di Angular, NG Generate, ha tutta una serie di funzionalità e una è quella della generazione delle librerie di componenti.Uno dei concetti per cui si usa un framework è quello di non dover reinventare la ruota.Beh avere un tool, linea di comando che con un comando ti permette di creare una libreria di componenti che tu puoi utilizzare e riutilizzare in più in più progetti non solo è una cosa che ho trovato utile per un progetto specifico, tu sviluppatore o team sei portato a realizzare il tuo set di componenti e riutilizzarli poi nei tuoi progetti ottimizzando tempi e anche aumentando la qualità perché hai più tempo per scrivere un componente se tu non lo devi riscrivere ogni volta e quindi avendo più tempo da dedicarci beh anche la qualità del componente sali altra cosa è il fatto che angular spinge l'adozione del one way data binding che cos'è il data binding? beh se dovessi riassumerlo in modo semplice il modo con cui si scambiano i dati tra i componenti e il DOM.Beh in realtà Angular 1.4 le versioni precedenti utilizzavano appunto un two-way data binding quindi quando aggiornavi il componente si aggiornava il DOM e viceversa.In realtà il one-way data binding è un modo per farlo generando meno errori.Poi magari potrò dedicarci una puntata per andare a vedere questi dettagli tecnici anche perché ha un senso andare a vedere come si comportano e cosa c'è sotto queste dinamiche.Comunque è anche possibile avere un two way data binding particolarmente utile in realtà quando si lavorano quando si lavora con le form e infatti per utilizzarlo con angular è necessario includere il form naturalmente angular ha anche dei lati che dal mio punto di vista per me sono stati dei contro abbastanza presenti, sono riuscito a percepirli forti uno di questi è il fatto che in realtà in angular non devi solo memorizzare i componenti come buona parte dei framework ma devi anche capire cosa sono gli injectable, cosa sono le pipes, cosa sono i moduli, elementi comunque molto legati all'ecosistema angular che per un neofita come ero io all'epoca sono diventati un ostacolo quindi ho dovuto sedere il sederino sulla sedia e provare a pensare a cosa fossero gli injectable e iniziare a pensare a studiare la dependency injection.Questo non è necessariamente un contro perché questi concetti comunque vanno studiati vanno approfonditi però in realtà quando tu approcci col framework in una fase 0 queste cose un po ti spaventano senza dubbio angular è un framework pronto per il mondo enterprise non sono io a dirlo ma se microsoft apple adobe youtube Paypal, Google, Amazon e WS, Ionic lo usano e ne ho detto solo alcuni potrei rimanere un quarto d'ora a dirvi le grandi società che utilizzano Angular è senza dubbio un framework potente.Naturalmente ha una serie di caratteristiche sulla base delle qualità del progetto quindi delle caratteristiche del progetto e delle caratteristiche di te come sviluppatore beh beh potrebbe fare il caso insomma utilizzare questo tipo di framework adesso parliamo di React, React che è il framework che utilizzo che sto utilizzando adesso pensate che anche il sito di Gitbar essendo sviluppato con Gatsby fa ampissimo uso di React React è un framework progettato in casa Facebook poi rilasciato con licenza open source ed è un framework che si presta in realtà allo sviluppo di applicazioni di tutte le scale dalla piccola single page application come può essere appunto il nostro sito alla grande applicazione enterprise come può essere facebook instagram whatsapp.La particolarità di React è che in realtà col tempo si sta portando verso l'utilizzo ancora sempre più spinto del paradigma della programmazione funzionale.Questo paradigma rende e fa sì che il codice che tu scrivi usando la base React sia ancora più semplice da riutilizzare.Naturalmente dal suo canto c'è il fatto che utilizza JSX.Che cos'è JSX? JSX è una sintassi tipo HTML.In realtà e per chi non l'avesse vista, beh è a metà tra l'html e il javascript.Mettete insieme html e insieme al javascript avete shakerato il tutto e avete una specie di JSX.So che è il modo più sbagliato per spiegare questo tipo di linguaggio però diciamo che questo è il modo più semplice che ho trovato.La particolarità in realtà di JSX è che spesso i neofiti hanno dei problemi.Perché? Perché a differenza di Angular e di Vue che poi andremo a vedere utilizzando JSX non ha la disponibilità di costrutti come l'aif o come il for cosa che viene simulata attraverso l'uso di attributi particolari appunto con angular e view con react invece il for per esempio dobbiamo farlo iniettando un piccolo blocchetto di javascript dove facciamo la map del contenuto quindi già un approccio un pochino più funzionale e invece le if dobbiamo simulare utilizzando il conditional rendering delle cosettine che magari in uno dei prossimi episodi andiamo a vedere più nel dettaglio però diciamo non hai questi due elementi che in realtà non tanto per uno sviluppatore senior quanto in realtà per uno sviluppatore junior sono due degli elementi principali che lui conosce cioè due dei pilastri della programmazione e non trovandosi lì appunto nel JSX spesso si è portati in confusione e spesso si è spaventati cosa che alle volte allontana il programmatore junior da quel framework specifico però devo dire che in realtà React è ben documentato così come in tutte e tre i framework di cui di cui vi parlo per cui è abbastanza facile poter capire questi concetti e diciamo utilizzarli.Una una particolarità che in realtà è quella che io amo di React, ma è ripeto una mia opinione è quella che in realtà il codice boilerplate è veramente veramente poco e da quando si è adottato e sono stati creati i React Hooks il framework diventa quasi trasparente a differenza per esempio di angular che utilizza ampiamente elementi specifici del framework.In realtà con React il framework lo si percepisce poco e questa cosa a livello di maturità che ho raggiunto poi negli anni è una cosa che ho iniziato ad apprezzare perché in realtà il focus rimane sulla logica che stiamo sviluppando.Ci concentriamo un attimino più sul nostro codice rispetto al codice del framework e devo dire che tra quello e la programmazione funzionale questi due elementi sono stati, l'approccio più funzionale, questi due elementi sono stati il driver che mi hanno spinto verso React.Vedete però come, come vi dicevo prima, le caratteristiche personali, le attitudini personali ritornano nella scelta dei framework posto che tutte e tre i framework di cui vi sto parlando sono enterprise ready.Quindi in realtà nella scelta del framework le caratteristiche e le attitudini lo stile di programmazione deve essere il driver principale.Poi in realtà anche il caso fa la sua nel senso che se non trovate lavoro e entrate in una società che usa React e voi magari siete più portati per un approccio angular style beh alla fine utilizzate react però poi ripeto nella parte finale voglio dirvi qual è la mia visione e il modo per svincolarvi da queste guerre di religione tra framework e framework.Vi dicevo react presuppone e spinge l'utilizzo del one way data binding e questo come perangulare evita delle confusioni.Una degli elementi principali delle caratteristiche delle funzionalità principali dei framework javascript è quella della renderizzazione di codice html a partire dal modello che vogliamo visualizzare.Per farlo in realtà React utilizza il concetto di virtual DOM.Nella seconda puntata del nostro podcast ne ho parlato e ho spiegato cos'è il virtual DOM e come funziona e ho anche detto che in realtà rispetto ad altri framework come Svelte, infatti nella seconda puntata parlo di Svelte, il virtual DOM di React è un pochino più lento rispetto a un approccio come quello di Svelte e quello di Angular Heavy però devo dire che comunque esistono tutte le rendering optimization che danno un pochino più boost a questo tipo di visualizzazione.E ritorno sul punto.Se grandi companies come Facebook, come il New York Times, come Yahoo, come Dropbox, come Slack utilizzano questo framework, forse questa marginale "lentezza" virtual dom non è significativo quindi perché nello sviluppare le nostre applicazioni salvo che non siano applicazioni particolari dove il millisecondo è importante perché stare là impazzire cercando magari un framework più più complesso o che non fitta che non fa il caso nostro solo perché è più performante oppure quante volte ho visto davvero persone scegliere il framework performant tenendo come driver principale la performance per fare cosa una single page application quindi in realtà React è super adottato nonostante il fatto che appunto le funzionalità di rendering sono un pelino ma davvero un pelino più lente rispetto ad altri prodotti altri framework sul mercato.Dal suo canto però per esempio il suo pro è che il server side rendering quindi la renderizzazione dei componenti lato server è super semplice perché? Perché React in realtà permette un ottimo supporto appunto di questo tipo di renderizzazione.Un'altra cosa interessante di React è che permette appunto l'utilizzo di TypeScript o facebook flow e come per angular in realtà ha una command line interessante per la creazione lo scaffolding di un'application che si basa su react e tra l'altro con un solo comando è possibile creare una progressive web app perfettamente compliant una cosa che in realtà però spaventa chi utilizza un framework e lo shifting, il passaggio di versione.E questo probabilmente grazie alla comunità è stato mitigato dall'ingresso di tool per la migrazione facile.In realtà React ha una serie di tool di script che permettono di migrare da una versione all'altra senza troppi mal di testa e vi devo dire che quest'altra cosa è molto interessante quando si utilizza React per applicazioni che devono durare un po più nel tempo quindi si ha la possibilità di passare senza troppi mal di testa da una versione all'altra.Altra cosa importante oltre che a un mercato che è florido per quanto riguarda appunto gli sviluppatori React nel senso che sono super richiesti e si trova lavoro senza troppe difficoltà è anche il fatto che sviluppando il react il passaggio da react a react native è abbastanza facile quindi in realtà con un piccolissimo effort si può insomma andare a sviluppare applicazioni native mobile partendo dalle stesse skill di base e questa cosa quando in realtà si deve convertire le proprie capacità in progetti monetizzabili, da una parte è un grosso risparmio sia di tempo che d'investimento, dall'altra appunto è un mercato di lavoro, di possibilità di lavoro che si ampie.Certo è che prima vi ho cantato le lodi di React come un framework trasparente, quindi è un framework che in tanti casi non prende decisioni per te cosa che di solito fanno i framework e cosa che di solito fa per esempio angular spiegandoti come devi utilizzare la dependency in action e imponendoti tutta una serie di scelte invece react rimane un po più agnostico da questo punto di vista e questo devo dire che per un sviluppatore alle prime armi può essere un problema perché in realtà non ha ancora consapevolezza per come prendere delle scelte.Posto che dal mio punto di vista oggi si ha un pochino meno bisogno, questo è stato un altro driver che mi ha spinto ad approcciare a React, c'è sempre meno bisogno di framework e più bisogno di pennelli quindi più pennelli e meno cornici se proprio dovessi fare appunto un piccolo inciso per rappresentare la mia visione beh avere un framework che in qualche modo non ti impone troppe cose ecco può può essere positivo però allo stesso tempo vedete cambia la persona può essere spaventoso il fatto di dover fare tutto da sé quindi prendere una serie di scelte da sé senza esserne consapevole altra cosa che in realtà è un po' confusionaria in react è l'utilizzo di css in realtà la community è spaccata in due fazioni c'è chi supporta l'utilizzo e chi che in qualche modo propone l'utilizzo dei css in file quindi dei file css e un altro che invece, un'altra fazione che è molto sostanziosa che supporta il concetto degli styled components utilizzando le template string di javascript insomma una serie di tecnologie che comunque dovendo riassumere potremo descrivere come buttare il css in mezzo al nostro javascript fondamentalmente si tratta di questo un altro limite che per me invece era un vantaggio di react è il fatto che gli entry level, il fatto che react stia passando da un paradigma di programmazione oggetti a un paradigma sempre più ispirato alla programmazione funzionale, beh questo potrebbe spaventare molti junior o comunque molti programmatori che vengono dalla programmazione oggetti e con la quale si sentono più confident.E questo shifting di questo passaggio di React potrebbe in qualche modo spaventarli e limitarne l'adozione.Facebook, Instagram, Netflix, New York Times, Yahoo, Whatsapp, Dropbox, Airbnb, Microsoft, Slack e chi più ne ha più ne metta utilizzano quotidianamente appunto React per lo sviluppo delle applicazioni frontend.Vue.js nuovo entry nell'appunto olimpo dei framework enterprise javascript.Nel 2013 Evan Yu programmatore google si mise e realizzò un framework, un framework che si distingue dagli altri per alcune caratteristiche peculiari che da una parte lo rendono e lo avvicinano più a chi vuole sviluppare entry level quindi ai programmatori junior che vogliono sviluppare le proprie applicazioni ma che ha comunque delle particolari caratteristiche che lo rendono super produttivo con una curva d'apprendimento molto bassa ma allo stesso tempo gli permettono di scalare dalla piccola applicazione il componente da buttare dentro il nostro sito che non ha bisogno di essere una single page application ha una sofisticata punto single page application.In realtà dobbiamo immaginare i view come in qualche modo i superpoteri per l'html è una frase che in qualche modo ci permette di visualizzare il view un pochino per stile più vicina ad angular che a react e infatti il compito di view è quello di portare i componenti nelle pagine web e lo fa in realtà in un modo molto semplice con una curva d'apprendimento molto bassa che permette a chi non ha particolari conoscenze oltre che alle conoscenze di base di html javascript e css di sviluppare una un'applicazione a tutti gli effetti quindi non devi necessariamente conoscere e sapere che cos'è la dependency injection o che cos'è la programmazione funzionale però allo stesso tempo puoi iniziare a sviluppare un'applicazione con tutte le caratteristiche appunto di un'applicazione enterprise perché no e e che scala bene anche al crescere della tua applicazione.La particolarità secondo me di Vue è da una parte la curva d'apprendimento perché è super piatta.È veramente semplicissimo da usare e poi una documentazione che se la documentazione di Angular e di React è scritta bene perché così è la documentazione di Vue è super.io non ho mai visto una documentazione così fatta bene così completa e soprattutto così semplice.In realtà la base appunto dello sviluppo di questo framework c'era l'idea di rendere semplici le cose.Voi perché da una parte c'è stata una spinta molto forte da ciò che era l'ecosistema Laravel.Taylor Orwell ha deciso di implementarlo per un lungo periodo su Laravel già out of the box adesso va beh ha in qualche modo disaccopiato un po la parte della della UI dal framework complessivo però comunque è diciamo una delle scelte anzi la scelta principale la scelta preferita per chi usa il framework Laravel che dal suo canto è uno dei framework più adottati nel mondo PHP credo.Naturalmente rispetto a Angular e React è molto giovane quindi anche meno adottato e ci si trovano meno lavori e offerte di lavoro su appunto tecnologia Vue, framework Vue.Wizz Air, Euronews, Grammarly, GitLab, LaraCast, Adobe...tutte queste società utilizzano Vue e non mi sembrano affatto dei progetti piccoli o che non abbiano esigenze appunto di scalabilità per cui insomma anche Vue si posiziona come un framework pronto per il mondo appunto enterprise.Allora, se questi tre framework sono pronti per sostenere progetti che scalino, qual è il framework che in questo caso Stefano deve scegliere? Beh, non lo so.I framework sono come dei matrimoni.Vanno bene fin quando non iniziano ad andar male, fin quando non ti senti da una parte in qualche modo oppresso da questi framework.Posto che come vi dicevo prima sono tutti adatti per le app enterprise io dico dipende dall'esperienza.Il mio consiglio è quello come vi dicevo prima di prendere una piccola applicazione una semplice to-do list e provarla a realizzare utilizzando questi tre framework e a quel punto scegliere il framework che più si avvicina al tuo stile di programmazione, il framework che più ti fa sentire a tuo agio quando sviluppi perché comunque i framework si basano fondamentalmente su quattro elementi il rendering, la gestione dello stato e e poi la pipe di building.Tutte e tre i framework di cui ho parlato si comportano benissimo, ti mettono a disposizione questo tipo di elementi per cui in realtà la dipende molto da come ci si ci si trova e qua entrano in gioco anche degli outsider per esempio ci sono framework che io reputo molto interessanti come Svelte che non ho citato oggi perché da una parte è molto nuovo dall'altra perché ne ho parlato approfonditamente nella seconda puntata di questo podcast quindi se volete avere più informazioni su Svelte andatevela a cercare sono sicuro che vi piacerà o almeno spero e dall'altra magari ci sono altre soluzioni come alpinejs dove in realtà vuole portare la natura dichiarativa di Vue però in un modo meno invasivo e super semplice anche super leggero quindi in realtà ci sono altre scelte però le tre più gettonate sono queste.Ricordando che comunque qualunque framework tu scelga prima o poi lo sentirai.Molti dicono che il framework è uguale al debito tecnico cioè la velocità che il framework ti dà nello sviluppare delle applicazioni alla lunga si trasforma appunto in debito tecnico.Allora mi chiedo e questa è una domanda che mi sto ponendo spesso questo periodo se in realtà io uso il framework per fare delle cose specifiche, il rendering, lo state management, il routing e il building.Allora forse perché nello studio del framework non mi fermo un attimo e vado a vedere in realtà qual è la logica che sta sotto alcune scelte che il framework ha preso per me.Qual è il funzionamento del rendering? Come funziona il virtual DOM? Come invece funziona la gestione dello stato? Qual è il paradigma che sta sotto la programmazione reattiva? Come funziona il router di React? Come funziona invece il router di Vue? Io un po' l'ho fatta questa esperienza ho trovato tantissime similitudini però gli elementi sono quelli se noi andiamo a vedere appunto come funziona sotto il cofano ci rendiamo conto che fondamentalmente il framework non fa altro che astrarre e semplificare alcuni concetti per risolvere dei problemi che sono chiari e questi problemi sono risolti sia da Vue sia da React e sia da Angular con stili diversi però spesso anche utilizzando gli stessi pattern vedi appunto la gestione dello stato con angular oppure attraverso appunto redux o vux fondamentalmente il problema è lo stesso l'approccio alla soluzione è più o meno simile cambia semplicemente il framework quindi provare il mio consiglio è quello di provare ad andare oltre il framework e andare a vedere quella che è il funzionamento sotto il coffano.In fondo anche gli astronauti e i piloti prima di salire a bordo devono sapere come funzionano i motori e cosa c'è sotto il coffano e questo lo si fa solo ed esclusivamente andando a studiare e cercando di vivere il più possibile le esperienze.Vi voglio lasciare appunto con una frase che riguarda le esperienze, che è una frase di Henry Ford che dice che l'errore ci dona semplicemente l'opportunità di iniziare a diventare più intelligenti.Spero che questo episodio vi sia piaciuto.Forse mi sono dilungato un po' troppo di quanto avrei voluto però mi interessava fare un focus.Mi rendo conto che in realtà stare là a dire qual è il framework migliore è un terreno molto scivoloso questo perché in realtà le competizioni si creano dal fatto che quando si sceglie qual è il framework migliore non si contemplano tutti i casi e tutte le variabili in gioco quindi si dice sempre esclusivamente una cazzata nel dire qual è il migliore per cui quello che invece mi premevera qual è l'approccio alla scelta del framework quali sono le caratteristiche che mi fanno sentire più confidente il fatto che soprattutto sia legato a come ci si sente e le competenze che si hanno in un certo periodo storico nella propria vita professionale.Quindi scegliere un fremon non è mai una cosa semplice e quando devi scegliere la fidanzata spesso è sbagliato affidarti ai consigli o a quello che ti dicono i senior solo perché magari hanno 30 anni più di matrimonio rispetto a te.Quindi il mio consiglio è sempre quello di provare a fare sbagli a scegliere provare a fare delle piccole esperienze su ognuno dei tre framework quattro framework se vogliamo metterci anche svelto al pain provarli.Puoi prendere una scelta non sarà mai la scelta migliore tu possa fare la scelta giusta è la tua scelta però e su quella scelta tu ci costruisci un prodotto e una carriera e tutto può cambiare ma se tu hai studiato le basi se tu sai come funziona l'essenza senza troppi fronzoli non un framework ma se tu sai come funzionano le logiche di cui hai bisogno o come si risolvono i problemi beh probabilmente diventerai più autonomo e sarai più autonomo e quindi vedrai i framework come una chiave inglese come un cacciavite e nella tua cassetta degli attrezzi hai il cacciavite, la chiave inglese e il martello e potrai usarli a seconda dell'esigenza io spero di aver risposto anche se so di non averlo fatto quindi Stefano non volermene però diciamo e questa è la mia risposta alla tua domanda non è la risposta giusta ma è la mia giusto per tornare in argomento detto questo io prima di lasciarvi vi ricordo i contatti ci trovate su www.gitbar.it oppure potete scriverci su info@gitbar.it o @brainrepo su twitter spero che questo episodio vi sia piaciuto se vi è piaciuto aprite gitbar con il vostro client preferito di podcast e iscrivetevi al podcast se proprio vi è piaciuto davvero tanto consigliatelo a amici colleghi aprite iTunes o l'applicazione podcast da Apple e lasciateci una recensione mi fa sempre molto piacere sapere cosa ne pensate di questo progetto e come possiamo migliorarlo detto questo io vi do appuntamento alla 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 delle attrezzi dei Full Stack Dev.[Musica]
