Le applicazioni desktop di utilit\u00e0 appartengono al passato perch\u00e9 tutto pu\u00f2 essere fatto in un browser. In effetti, anche le applicazioni che devono utilizzare API di livello inferiore non disponibili nel browser vengono scritte utilizzando motori e linguaggi per browser, perch\u00e9 ci\u00f2 ne facilita la manutenzione.<\/p>\n
Le applicazioni mobili possono essere facilmente sostituite da strumenti usati per web<\/a> sviluppo - vedi React<\/a> Nativo<\/strong>, NativeScript. Inoltre, abbiamo le PWA, che \"imitano\" facilmente il funzionamento delle applicazioni mobili. Inoltre, i componenti che alimentano un'applicazione scritta in Vue<\/a><\/strong> o React<\/strong> possono condividere facilmente vari codice<\/a> elementi tra le piattaforme. <\/p>\n Dobbiamo ammettere una cosa: le applicazioni web sono attualmente una potenza che sar\u00e0 difficile far scendere al piano terra. Come utente, le uso praticamente ovunque: per comunicare via Slack, per usare un editor di codice, per fare presentazioni o persino per scrivere un articolo sul blog.<\/p>\n \u00c8 difficile prevedere cosa accadr\u00e0 tra qualche anno. WebAssembly sta entrando in gioco e permetter\u00e0 di noi<\/a> per spostare le applicazioni che richiedono calcoli pi\u00f9 complessi nel mondo dei browser. Un fatto, tuttavia, rimane invariato: \u00e8 davvero difficile trovare un ostacolo per costruire con l'uso delle tecnologie web un'applicazione che possiamo solo sognare. <\/p>\n Per arrivare al punto, torniamo per un attimo al passato, prima che apparissero i primi framework web pi\u00f9 significativi e che le applicazioni venissero sviluppate in modo imperativo. Ogni meccanismo interattivo di una pagina veniva gestito manualmente ed era responsabile di un'azione specifica.<\/p>\n Il miglior esempio che si possa citare \u00e8 la libreria jQuery, all'epoca una delle soluzioni pi\u00f9 popolari per la gestione di eventi semplici. Con il suo aiuto sono stati implementati vari menu a discesa, transizioni, animazioni, calcolatori e meccanismi simili.<\/p>\n Vale la pena ricordare che gi\u00e0 allora si notavano problemi nelle applicazioni pi\u00f9 complesse, dove parti diverse e indipendenti dovevano, ad esempio, reagire a un clic o alla digitazione di qualcosa. La maggior parte delle applicazioni non aveva uno stato esplicito ed era invece salvata, per esempio, dagli attributi degli elementi o dalle classi che avevano.<\/p>\n All'epoca era chiaro che l'approccio attuale mancava di reattivit\u00e0, ovvero di un modo strutturato in cui i componenti potessero comunicare tra loro e condividere, ad esempio, il loro stato o i diversi eventi, il che rendeva le applicazioni pi\u00f9 facili da mantenere e consentiva loro di offrire una buona esperienza utente a basso costo.<\/p>\n Nel corso del tempo, sono comparsi all'orizzonte i primi framework di front-end, con l'obiettivo di strutturare l'architettura per applicazioni pi\u00f9 complesse.<\/p>\n Questi framework erano principalmente basati sul pattern MVC - alcuni suggerivano un approccio pi\u00f9 manuale, come Backbone.js, mentre altri, come Knockout.js, si agganciavano a due vie dati<\/a> vincolante.<\/p>\n Tuttavia, si potrebbe pensare che scrivere l'applicazione sia stato pi\u00f9 difficile, abbia richiesto una maggiore quantit\u00e0 di codice e non abbia necessariamente prodotto i risultati previsti o compensato il tempo perso nello sviluppo dell'applicazione.<\/p>\n La ragione principale per cui la ricerca della media aurea nel JS<\/a> L'ecosistema era difficile perch\u00e9 era un po' una stranezza tra i pi\u00f9 conosciuti linguaggi di programmazione<\/a> che hanno da tempo la strada spianata.<\/p>\n Non voglio soffermarmi su quali percorsi hanno accompagnato lo sviluppo dei vari framework nel corso della storia. Tuttavia, \u00e8 importante notare una cosa: il periodo di maturazione dell'ecosistema JS nei browser non \u00e8 stato facile e ha affrontato molte prove.<\/p>\n Questo \u00e8 l'unico motivo per cui oggi possiamo costruire applicazioni web e svilupparle in modo molto semplice e indolore.<\/p>\n Invece di gettare carne al fuoco, come \u00e8 consuetudine su Internet, diamo un'occhiata a entrambe le biblioteche, raccogliamo informazioni su di esse e confrontiamole - sia in teoria che in pratica.<\/p>\n NOTA: La descrizione dei meccanismi che funzionano in Vue <\/strong>si riferisce specificamente alla versione 2. La versione 3 introduce molti cambiamenti significativi, ma non \u00e8 un vero e proprio concorrente di React<\/strong> al momento, se non altro per la sua maturit\u00e0 - Vue 3 data di uscita: 18 settembre 2020.<\/p>\n Chiariamo subito una cosa: approfondendo le due librerie, si pu\u00f2 notare che in realt\u00e0 ci sono pi\u00f9 somiglianze che differenze. Tralasciando le modalit\u00e0 di utilizzo delle librerie in quanto tali, entrambe hanno concetti di funzionamento molto simili. Entrambe sono alimentate da un ecosistema simile e il loro utilizzo non \u00e8 diametralmente diverso.<\/p>\n Il diavolo si nasconde nei dettagli: pi\u00f9 spesso usiamo uno strumento, pi\u00f9 notiamo gli svantaggi delle sue diverse soluzioni. Un buon esempio pu\u00f2 essere il binding bidirezionale dei dati, che viene usato pi\u00f9 spesso in Vue<\/strong> come propriet\u00e0 del modello v: spesso semplifica le cose, si occupa automaticamente di molte cose e non richiede la codifica di un supporto aggiuntivo per la modifica dei valori.<\/p>\n Tuttavia, ci sono casi in cui \u00e8 necessario tracciare in modo specifico un tentativo di modifica e reagire di conseguenza, nel qual caso i componenti basati su v-model ci costringono spesso a giocare con altri Vue<\/strong> meccanica come la propriet\u00e0 calcolata, facendo s\u00ec che l'effetto ottenuto risulti spesso molto peggiore rispetto a quello ottenuto con un approccio manuale;<\/p>\n Un altro aspetto interessante \u00e8 JSX, che \u00e8 un modo cos\u00ec \"vagabondo\" per modellare il contenuto reso utilizzando React<\/strong>. La comunit\u00e0 degli sviluppatori ha opinioni diverse.<\/p>\n Dalle mie osservazioni, sembra che gli sviluppatori che utilizzano ambienti diversi da JS, ad es. PHP<\/a> o C#, sono pi\u00f9 inclini a modellare i punti di vista in modo che Vue<\/strong> fa.<\/p>\n Per riassumere - modelli noti da Vue<\/strong> permettono di definire le viste in modo molto chiaro ed elegante, mentre il JSX di React consente di costruirle in molti casi pi\u00f9 velocemente, su misura per le esigenze specifiche e spesso richiede meno codice per costruire strutture diverse;<\/p>\n Esaminiamo anche gli ecosistemi di questi due strumenti. In linea di principio, possiamo dire che non differiscono in nulla. Entrambi si chiamano librerie per un motivo: forniscono il minimo indispensabile per il supporto delle applicazioni web reattive.<\/p>\n Mentre il resto, relativo alla comunicazione con API<\/a>, Il flusso di dati, i componenti dell'interfaccia utente utilizzati per le diverse sottopagine, sono i cosiddetti venditori - librerie prese dall'esterno, che devono essere correttamente allegate al sistema. progetto<\/a>. \u00c8 un po' come il mondo dei Lego: se si vuole costruire un insieme coerente, bisogna metterlo insieme partendo da blocchi singoli e piccoli.<\/p>\n Questa allegoria si riferisce proprio ai componenti collegati, che sono la forza delle applicazioni create con React<\/strong> o Vue<\/strong>;<\/p>\n Una cosa importante, soprattutto per chi non ha molta esperienza nell'ambiente JS, \u00e8 il livello di ingresso in una particolare libreria. In altre parole, la complessit\u00e0 dello strumento, che consiste nel tempo diretto da dedicare alla comprensione dei suoi meccanismi.<\/p>\n Credo che una cosa debba essere affermata in modo inequivocabile: nel caso di Vue<\/strong>\u00e8 molto pi\u00f9 semplice. Abbiamo un binding bidirezionale dei dati, abbiamo un template elegantemente specificato che \u00e8 ingannevolmente simile alle soluzioni di altri linguaggi, per esempio twig, e infine - non abbiamo il mal di testa causato dall'apprendimento di teorie riguardanti il funzionamento dei singoli ganci e i casi in cui devono essere utilizzate meccaniche specifiche.<\/p>\n Seguire direttamente la voce della folla non \u00e8 esattamente una buona scelta. Tuttavia, un buon passo per prendere una decisione corretta \u00e8 analizzare ci\u00f2 che dicono le persone che hanno interagito con queste biblioteche.<\/p>\n E s\u00ec... stelle su github <\/a> pu\u00f2 essere un indicatore di quanto la comunit\u00e0 di una particolare biblioteca sia coinvolta nel suo sviluppo, di come sia percepita dagli sviluppatori e se siano interessati alla sua direzione. Ingegneri<\/a> che hanno come protagonista un particolare repository spesso ricevono notifiche sulle nuove release o sulle modifiche al codice, il che si traduce nella loro conoscenza diretta della libreria.<\/p>\n Tuttavia, il numero di stelle su github non dovrebbe essere visto come un oracolo - non tutti gli sviluppatori che amano uno strumento lasceranno un segno - piuttosto, lo prenderei come un segno della pura passione che gli sviluppatori hanno per un particolare progetto open-source.<\/p>\n Tendenze di Google <\/a> \u00e8 un servizio molto conosciuto che ci permette di studiare l'interesse per argomenti specifici nel tempo. Sebbene non sia un indicatore razionale della qualit\u00e0 o dell'uso, pu\u00f2 fornire ogni tipo di analisi.<\/p>\n \u00c8 facile notare che il corso degli ultimi 5 anni si \u00e8 delineato in modo abbastanza simile quando si tratta di confrontare i due protagonisti dell'articolo di oggi. La conclusione di base che si pu\u00f2 trarre dal grafico \u00e8 che React<\/strong> \u00e8 superiore in termini di popolarit\u00e0 di ricerca rispetto al suo avversario.<\/p>\n Per essere chiari, essere in cima a Google Trends non significa che una biblioteca sia migliore. Si tratta di popolarit\u00e0 della folla, come ho detto prima - probabilmente pi\u00f9 persone hanno sentito parlare di questo strumento, potrebbe aver suscitato pi\u00f9 interesse tra i lettori. CTOs<\/a>, sviluppatori di software<\/a> <\/strong>o persone che vogliono solo imparare un particolare strumento.<\/p>\n Questo grafico si riflette nella realt\u00e0? In un certo senso, s\u00ec. In generale - tra le persone intervistate, un numero maggiore di persone mostra una conoscenza diversificata e sofisticata di React<\/strong> di Vue<\/strong>. Quali opinioni si possono ottenere parlando con queste persone? Cercher\u00f2 di illustrare questo aspetto nel prossimo paragrafo.<\/p>\n Stato di JS\u00a0<\/a> \u00e8 un sito che ogni anno effettua un sondaggio tra le persone che lavorano nel settore delle tecnologie JavaScript. Il suo obiettivo \u00e8 raccogliere informazioni dagli sviluppatori su come vedono gli strumenti con cui lavorano quotidianamente.<\/p>\n Le domande riguardano strumenti individuali per scopi diversi, ad esempio strumenti utilizzati sul front-end e sul back-end, ma anche strumenti per il test, la gestione dello stato dell'applicazione, ecc. Ognuna di queste domande non \u00e8 una semplice risposta s\u00ec\/no, il sito pone una serie di domande sullo strumento stesso, sugli interessi, sulle esperienze e una valutazione complessiva che si riduce alla frase \"Utilizzeresti questo strumento in progetti futuri?\".<\/p>\n Il sito stesso permette di fare molte analisi, confrontare strumenti rilevanti e talvolta scoprire librerie meno conosciute che stanno iniziando a fare bene nel mondo JS, raccogliendo popolarit\u00e0 e godendo di un alto tasso di \"felicit\u00e0 d'uso\". Vi invito sinceramente a sfogliare i contenuti di questo sito.<\/p>\n Riassumiamo la sezione con le statistiche. L'analisi di diversi tipi di grafici pu\u00f2 spesso essere un'ottima opzione per confrontare diversi aspetti di determinati argomenti. Tuttavia, \u00e8 importante tenere presente che seguire la voce della folla non \u00e8 necessariamente la cosa pi\u00f9 intelligente da fare. \u00c8 invece possibile prendere una decisione informata utilizzando alcune delle lezioni apprese dalle analisi dei grafici.<\/p>\n In precedenza, ho menzionato la soglia di ingresso pi\u00f9 bassa per Vue<\/strong> - Infatti, permette di concentrarsi un po' pi\u00f9 velocemente sullo sviluppo vero e proprio dell'applicazione, utilizzando lo strumento e riducendo al minimo il tempo necessario per familiarizzare con l'ambiente, i meccanismi e i vari casi d'uso.<\/p>\n In generale, la mia opinione \u00e8 che Vue<\/strong> \u00e8 pi\u00f9 adatto a chi non ha ancora avuto a che fare con le librerie front-end. Certamente, vi permetter\u00e0 in modo pi\u00f9 incoraggiante di ottenere risultati soddisfacenti in breve tempo.<\/p>\n Tuttavia, diciamolo ad alta voce: la mancanza di conoscenza del linguaggio in cui utilizziamo strumenti specifici prima o poi ci danneggia. \u00c8 un elemento trascurabile per le cose semplici, ma man mano che la complessit\u00e0 delle applicazioni create aumenta, sar\u00e0 sempre pi\u00f9 difficile costruire applicazioni in modo decente senza una buona conoscenza del linguaggio di programmazione. JavaScript<\/a>.<\/p>\n Non mi riferisco alla capacit\u00e0 di scrivere funzioni sofisticate, perch\u00e9 questa parte pu\u00f2 essere ampiamente sostituita, ad esempio, dai fornitori. Mi riferisco ad alcuni errori comuni che si possono commettere nel linguaggio e al fatto che non ci si rende conto che il comportamento scorretto non \u00e8 dovuto all'uso della libreria, ma all'uso del linguaggio. L'errore pi\u00f9 comune che si manifesta in questo caso \u00e8 la cosiddetta immutabilit\u00e0, ovvero la conoscenza del meccanismo di riferimento in JavaScript.<\/p>\n Non sono in grado di suggerire quale libreria sia migliore per gli sviluppatori che hanno pi\u00f9 o meno familiarit\u00e0 con l'JavaScript. Ma so una cosa: se volete avere un'idea reale di come sia lo sviluppo con entrambi gli strumenti \"dall'interno\", provate a scrivere applicazioni in ciascuno di essi. Questo vi dar\u00e0 un'idea e vi permetter\u00e0 di capire quali meccanismi vi attraggono di pi\u00f9 e quale sia la scelta migliore per voi.<\/p>\n Come ho gi\u00e0 detto, entrambe le librerie sono alimentate da ecosistemi simili e hanno una visione simile della costruzione di applicazioni con piccoli componenti. Entrambe le librerie stanno andando bene e non c'\u00e8 alcuna indicazione che una delle due possa scomparire nel prossimo futuro. Di conseguenza, le offerte di lavoro in entrambe rimarranno a un livello simile.<\/p>\n Le conclusioni sono semplici: usate ci\u00f2 che vi conviene, fate esperienza e valutate. Questo vi aiuter\u00e0 a sviluppare un approccio razionale per decidere se \u00e8 meglio usare una o l'altra libreria in un particolare progetto; inoltre, cercate di sperimentare: niente insegna cos\u00ec profondamente come gli errori commessi in passato.<\/p>\n Non \u00e8 un segreto che non esiste un mezzo aureo che sia la soluzione migliore per un particolare progetto. Soprattutto per quanto riguarda il front-end, gli strumenti utilizzati per costruire le applicazioni invecchiano rapidamente e spesso \u00e8 difficile orientarsi tra le ultime tendenze.<\/p>\n Tuttavia, la scelta della tecnologia non \u00e8, o almeno non dovrebbe essere, un gioco di parole su ci\u00f2 che si adatta alle tendenze attuali. Dovremmo invece orientarla verso aspettative e ipotesi specifiche sull'applicazione che stiamo per realizzare. Ognuna delle librerie a confronto ha i suoi punti di forza e di debolezza, che abbinati al caso d'uso ci permetteranno di fare la scelta pi\u00f9 ragionevole.<\/p>\n Un'opzione interessante potrebbe essere rappresentata dalle sintesi tecnologiche delle grandi aziende, che spesso descrivono i loro casi d'uso, come si \u00e8 svolto o si sta svolgendo lo sviluppo di grandi applicazioni e quali errori hanno commesso in passato. Forse troveremo tra questi casi casi particolarmente interessanti nel contesto della scelta di una libreria per un particolare progetto.<\/p>\n Le caratteristiche che dovremmo considerare per scegliere gli strumenti giusti per l'applicazione che stiamo costruendo sono: il tempo di sviluppo dell'applicazione, la facilit\u00e0 di manutenzione dell'applicazione<\/a>La complessit\u00e0 dell'applicazione e l'esperienza degli sviluppatori nell'uso di librerie specifiche.<\/p>\n Gli sviluppatori sono le persone che passano pi\u00f9 tempo con gli strumenti che metto a confronto e sono quelli che possono fornire i migliori consigli e aiutarvi a fare la scelta migliore nel grande scontro delle librerie. \u00c8 durante lo sviluppo dell'applicazione che si vedono i vari problemi che derivano direttamente dalla scelta della tecnologia e si ha la migliore visione di quali sono gli elementi che compromettono l'uso di un particolare strumento per determinate funzionalit\u00e0.<\/p>\n Come ho detto in precedenza, entrambe le librerie non sembrano essere scomparse dal sito di mercato<\/a>Almeno non nei prossimi anni. Invece di prendere decisioni basate su statistiche e opinioni Presentare loro ci\u00f2 che ci si aspetta dall'applicazione, il tempo a disposizione per la consegna e consentire uno scambio di opinioni su ci\u00f2 che pensano di entrambe le soluzioni prima di prendere la decisione finale.<\/p>\n Le guerre su Internet di solito - o forse in ogni caso - sono inutili. Ci saranno sempre persone che si ostineranno a sostenere che la loro scelta \u00e8 migliore senza fornire alcun argomento razionale a conferma della loro decisione.<\/p>\n Invece di essere accecati da scelte specifiche, concentriamoci sull'analisi, cerchiamo di trarre conclusioni appropriate e usiamole per aggiustare o rifiutare una soluzione specifica.<\/p>\n Come dice il titolo, non intendo incoronare una particolare libreria come cura per ogni dolore. Al contrario, sono state presentate alcune ipotesi e sono stati rivelati i punti di forza e di debolezza di entrambe le librerie. Ho dato alcuni consigli su cosa cercare quando si sceglie tra le due librerie, in modo da prendere una decisione saggia e non lasciarsi guidare dalle tendenze o da persone a caso su Internet.<\/p>\n Ognuno di questi strumenti \u00e8 in grado di soddisfare le esigenze del progetto. Nessuno dei due scomparir\u00e0 rapidamente dal mercato nei prossimi anni. Entrambi hanno comunit\u00e0 potenti e un certo grado di maturit\u00e0, il che dimostra che stanno andando abbastanza bene.<\/p>\n La scelta finale \u00e8 nelle vostre mani. Tuttavia, se avete dei dubbi o volete semplicemente discutere il vostro caso con The Codest<\/a> - non esitate a contattarci!<\/p>\n Per saperne di pi\u00f9:<\/b><\/p>\n Perch\u00e9 si dovrebbe (probabilmente) usare Typescript<\/a><\/p>\n Come non uccidere un progetto con cattive pratiche di codifica?<\/a><\/p>\nIl big bang nella realt\u00e0 di internet <\/h2><\/p>\n
Primi passi verso strutture ben conosciute<\/h2><\/p>\n
Informazioni di base e un leggero confronto<\/h2><\/p>\n
![\"React](\"\/app\/uploads\/2024\/05\/tabela-art-.jpg\")
<\/p>\nCosa dicono le statistiche?<\/h2><\/p>\n
![\"grafico](\"\/app\/uploads\/2024\/05\/bez-tytulu.png\")
<\/p>\n![\"react](\"\/app\/uploads\/2024\/05\/aaaaaabbb.png\")
<\/p>\n![\"Classifica](\"\/app\/uploads\/2024\/05\/1.png\")
<\/p>\n![\"stato](\"\/app\/uploads\/2024\/05\/2.png\")
<\/p>\n![\"React](\"\/app\/uploads\/2024\/05\/3.png\")
<\/p>\nLa scelta migliore per gli sviluppatori<\/h2><\/p>\n
La scelta migliore per CTO<\/a> <\/h2><\/p>\n
\ndi varie persone da Internet - forse un'opzione migliore \u00e8 quella di parlare semplicemente con gli sviluppatori.<\/p>\nConclusioni<\/h2><\/p>\n