Mobile? Web? Non mi interessa.<\/h2>\n
Supponiamo di voler costruire un'applicazione che utilizzi l'opzione React<\/a> libreria. Questa libreria pu\u00f2 essere utilizzata per costruire applicazioni web e applicazioni mobili con React nativo. I meccanismi logici dell'applicazione, come l'autorizzazione, l'elaborazione, il filtraggio e la gestione dei dati. dati<\/a> e cos\u00ec via, possono essere eseguiti con i ganci React. Il punto \u00e8 che questi ganci possono essere condivisi da entrambe le versioni dell'applicazione, web e mobile. Grazie a questa opzione, abbiamo i seguenti salvataggi:<\/p>\n Per riassumere questo paragrafo, non \u00e8 detto che un'unica base di codice alimenter\u00e0 tutte le versioni dell'applicazione, anche se possiamo dividere il codice condiviso e usarlo in ogni versione per rendere il codice di base pi\u00f9 semplice. processo di sviluppo<\/a> davvero pi\u00f9 veloce.<\/p>\n Conclusione - se volete costruire un'applicazione web e una mobile allo stesso tempo, prendete in considerazione la libreria React che pu\u00f2 condividere una base di codice nella versione mobile e web dell'applicazione.<\/p>\n Qualche anno fa, quando si parlava di backend, probabilmente in pochi avrebbero immaginato che la sua manutenzione potesse essere possibile con l'aiuto di un linguaggio come JS<\/strong>. Lo sviluppo di questa lingua \u00e8 sorprendente e i suoi frutti possono essere raccolti ancora oggi.<\/p>\n Di cosa sto parlando? Se si assume il giusto Sviluppatori JS<\/strong>Si scopre che possono scrivere non solo il frontend dell'applicazione, ma anche il backend, cio\u00e8 essere responsabili dell'elaborazione dei dati sul server, della comunicazione con il database, di vari tipi di integrazioni, ecc. Siete ancora titubanti o non siete convinti di questo linguaggio? Non c'\u00e8 motivo di avere questo atteggiamento! Backend con JS <\/strong> pu\u00f2 essere implementato in due modi popolari: in una modalit\u00e0 estensibile e configurabile, che express.js pu\u00f2 fornirci, e in una modalit\u00e0 strutturata che utilizza il pattern DI - nest.js.<\/p>\n Entrambe le soluzioni sono estremamente popolari e alimentano molte applicazioni di produzione i cui proprietari sono \"giganti tecnologici\" del loro settore. Penso che siano maturate abbastanza da convincervi a scegliere una delle due.<\/p>\n Non \u00e8 ancora abbastanza? Analogamente alla condivisione del codice tra applicazioni web e mobili, il backend pu\u00f2 condividere le risorse sia con le prime che con le seconde. La parola chiave da usare in questo caso \u00e8 TypeScript<\/a> - tra l'altro, ci permette di condividere una base di codice, cio\u00e8 una definizione comune di tipi di dati tra tutte le piattaforme.<\/p>\n Con le applicazioni costruite esclusivamente sulla JavaScript<\/a> <\/strong>\/ TypeScript<\/strong> Se si utilizza un monolite, si risparmiano molte linee di codice che si dovrebbero duplicare nei linguaggi di programmazione nativi. D'altra parte, utilizzando lo stesso linguaggio su tutti i fronti, possiamo condividere un'enorme quantit\u00e0 di logica tra tutte le applicazioni, il che accelererebbe decisamente i tempi di realizzazione di una particolare applicazione. Non vi sembra fantastico?<\/p>\n \u00c8 emerso che le tecnologie per la creazione di applicazioni per browser sono ottime per mantenere le applicazioni che utilizziamo nella loro forma desktop: un buon esempio pu\u00f2 essere Slack. Slack \u00e8 un'applicazione utilizzata per squadra<\/a> comunicazione: oltre alla messaggistica standard, presenta molte funzionalit\u00e0 diverse e vari tipi di integrazioni esterne. Tutto ci\u00f2 la rende una delle applicazioni pi\u00f9 popolari, utilizzata soprattutto nel settore IT.<\/p>\n Come si \u00e8 scoperto, anche Slack utilizza le tecnologie web (e, quindi, JavaScript) per costruire la sua interfaccia applicativa. La base che rende possibile l'esecuzione di tali applicazioni sul desktop \u00e8 electron. La creazione di interfacce grafiche con tecnologie web rende molto pi\u00f9 semplice, veloce e generalmente possibile lo sviluppo di applicazioni per diverse piattaforme allo stesso tempo.<\/p>\n A giudicare dalla parte frontend dell'applicazione, non c'\u00e8 da illudersi che JS <\/strong>\u00e8 l'unico ed esclusivo linguaggio che alimenta l'ecosistema. Per il momento, non ci sono alternative valide che possano sostituire questa parte dell'applicazione (anche se penso che WebAssembly potrebbe sorprenderci in futuro). Quindi, parlando della maturit\u00e0 di JS sul frontend, non c'\u00e8 dubbio che sia l'unico reale.<\/p>\n Parlando di backend, molti sviluppatori possono sembrare scioccati o negare immediatamente che JS sia adatto come linguaggio di programmazione per il backend. Tuttavia, la questione deve essere analizzata in modo oggettivo.<\/p>\n Molti fornitori di cloud forniscono SDK che permettono di utilizzare direttamente nuvola<\/a> metodi. Stranamente, una delle schede pi\u00f9 popolari, proprio accanto a C#, Go e Java<\/a>, \u00e8 Node.js<\/a>. Si \u00e8 scoperto che questa piattaforma \u00e8 ideale per scalare e costruire applicazioni basate su microservizi<\/a> o architettura serverless. Conclusione - JS \u00e8 uno dei linguaggi pi\u00f9 popolari per lo sviluppo di applicazioni basate su architetture microservices\/serverless. Nelle schermate sottostanti, possiamo vedere che la santa trinit\u00e0 (Google Computing Services, AWS<\/a>, Azzurro<\/a>) dei fornitori di cloud ci permette di costruire applicazioni usando nodo<\/a>.js.<\/p>\n Per quanto riguarda l'ecosistema node.js, probabilmente tutti conoscono una libreria chiamata express.js: si tratta di uno strumento semplice e diretto che consente di definire percorsi e di fornire loro dati appropriati che sono stati opportunamente elaborati sul lato JS. Inoltre, il modello utilizzato tra le richieste HTTP gestite in express.js \u00e8 diventato uno dei pi\u00f9 popolari nell'intero ecosistema ed \u00e8 una sorta di modello per varie altre librerie che utilizzano, ad esempio, l'architettura serverless.<\/p>\n Conclusione - JS \u00e8 un linguaggio abbastanza maturo per mettere tutte le carte in tavola e costruire sia il frontend che il backend. Inoltre, \u00e8 un linguaggio abbastanza fresco che trova facilmente spazio nelle moderne architetture applicative. \u00c8 fantastico che un programmatore che conosce un solo linguaggio possa padroneggiare entrambi i lati (full stack) di un'applicazione.<\/p>\n Il motore pi\u00f9 utilizzato per l'esecuzione di codice JS \u00e8 il v8, basato sul linguaggio C++. Questo motore sviluppato da Google \u00e8 dedicato all'esecuzione di applicazioni per piattaforme web. Una cosa interessante \u00e8 che questo motore non interpreta il codice JS. Al contrario, esegue la cosiddetta \"JIT\" - \"compilazione just in time\". Grazie ad esso, non dobbiamo interpretare il codice JS riga per riga, ma solo compilarlo ed eseguirlo. \u00c8 ancora pi\u00f9 veloce e ci d\u00e0 risultati molto buoni in termini di prestazioni.<\/p>\n JS \u00e8 abbastanza corretto per quanto riguarda le prestazioni? S\u00ec, lo \u00e8. Finch\u00e9 si mantengono gli algoritmi abbastanza equi, non c'\u00e8 alcun problema a usare JS sul lato server. L'altra cosa \u00e8 mantenere il codice asincrono il pi\u00f9 possibile. Con queste pratiche, il codice pu\u00f2 gestire richieste parallele senza problemi. Non \u00e8 necessario preoccuparsi del cambio di tecnologia a causa delle prestazioni, soprattutto se l'architettura dell'applicazione \u00e8 scalabile.<\/p>\n Ho gi\u00e0 discusso in dettaglio le prestazioni e i benchmark in questo articolo. <\/p>\n Beh, queste sono decine di opinioni secondo cui il linguaggio JS si comporta in modo strano in alcuni casi e gestirlo \u00e8 qualcosa che vi far\u00e0 esplodere la testa durante il processo di sviluppo. Non posso essere d'accordo \ud83d\ude42 Come ogni altro linguaggio, ha diversi modelli\/comportamenti che non sono eleganti, ma se si capisce come funzionano e quali sono i loro obiettivi, sviluppare applicazioni con JS non \u00e8 spiacevole.<\/p>\n Soprattutto l'osservazione \"asincrono\" subito prima di JS fa rabbrividire alcuni sviluppatori. \u00c8 difficile da capire quando non si ha alcuna esperienza in merito. Tuttavia, \u00e8 una parte di JS che ci permette di costruire soluzioni moderne in modo semplice. Diamo un'occhiata ai websocket: essendo basati sugli eventi, ciascuna delle unit\u00e0 collegate - l'utente e il server - pu\u00f2 emettere e ricevere eventi in parallelo. Se il codice che alimenta l'applicazione \u00e8 sufficientemente asincrono e non blocca il thread principale, possiamo facilmente gestire migliaia di richieste in poco tempo.<\/p>\n Confrontiamo JS e PHP<\/a> con il contesto dei websocket. L'PHP \u00e8 un linguaggio di programmazione sincrono, quindi la risoluzione di argomenti relativi ai websocket d\u00e0 un enorme grattacapo. Possiamo notare che l'PHP prende modelli da JS per costruire applicazioni backend interattive che possono utilizzare tecnologie moderne, come webrtc o websocket.<\/p>\n Riunendo tutti i paragrafi, possiamo affermare alcuni fatti:<\/p>\n JavaScript<\/strong> \u00e8 un linguaggio che pu\u00f2 essere usato per costruire ogni tipo di applicazione, dal web, al mobile, al desktop; Per dare la mia opinione, per quanto di parte, sfruttare la possibilit\u00e0 di JavaScript di riutilizzare lo stesso codice su tutti i fronti disponibili \u00e8 qualcosa che sicuramente velocizzer\u00e0 lo sviluppo delle applicazioni e ridurr\u00e0 il numero di sviluppatori coinvolti nella manutenzione del backend delle applicazioni scritte in altre tecnologie. A conferma di ci\u00f2, ricordiamo che un gran numero di cosiddetti giganti dell'IT seguono questo modello e condividono una buona parte del codice base tra le varie piattaforme. Nonostante le diverse opinioni su questo linguaggio, bisogna tenere in considerazione il fatto che le statistiche di utilizzo e di soddisfazione per l'uso di JS <\/strong>crescono di anno in anno e i suoi sviluppatori possono facilmente agganciarsi alla tendenza del full stack.<\/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>\n\n
Ma che dire del backend?<\/h2>\n
JS pu\u00f2 alimentare le applicazioni desktop?<\/h2>\n
JS \u00e8 abbastanza maturo?<\/h2>\n
![\"Avvio](\"\/app\/uploads\/2024\/05\/zrzut-ekranu-2021-08-24-o-12.13.12.png\" "\\"Avvio")
<\/p>\n![\"Confronto](\"\/app\/uploads\/2024\/05\/zrzut-ekranu-2021-08-24-o-12.13.25.png\" "\\"Avvio")
<\/p>\nJS \u00e8 abbastanza veloce?<\/h2>\n
Il JS non \u00e8 forse una stranezza tra le altre lingue?<\/h2>\n
Mescolare il tutto<\/h2>\n
\nLe applicazioni scritte in JS possono condividere vari frammenti di codice tra loro, come quelli responsabili della formattazione dei dati o dei tipi in Typescript;
\nGrazie alla crescita del web, le prestazioni offerte da JS sono sufficientemente buone da poter optare per lo sviluppo di applicazioni sia frontend che backend;
\nGrazie al suo design insolito, l'JavaScript \u00e8 in grado di supportare le moderne infrastrutture applicative, come websocket e WebRTC;
\nAssumendo uno sviluppatore adeguatamente qualificato, si \u00e8 in grado di sfruttare il suo potenziale su tutti i frontend disponibili che utilizzano questo linguaggio;
\nJS \u00e8 un linguaggio che sta scalando le classifiche di popolarit\u00e0 da diversi anni e non ci sono indicazioni che questo cambier\u00e0 in qualche modo.<\/p>\n![\"Consulenza](\"\/app\/uploads\/2024\/05\/cta_2.jpeg\")
<\/a><\/p>\n