È risaputo che le moderne applicazioni web sono sempre più utilizzate, giorno dopo giorno. Lo sviluppo è davvero rapido e consente di pubblicare applicazioni su tutte le piattaforme, dove l'unico requisito è avere un ambiente che gestisca un determinato stack tecnologico. Il linguaggio che può essere definito il re di tutti gli altri all'interno di questo ambiente è JavaScript. Oggi condividerò con voi alcuni fatti sullo sviluppo del software relativi a questo linguaggio.
Definizione di sviluppo rapido di applicazioni
L'espressione "sviluppo rapido" può essere interpretata in molti modi sbagliati. Per evitarlo, spieghiamo quali sono le nostre aspettative. La cosa più importante è il budget. Per creare molte versioni della stessa applicazione, abbiamo bisogno di molti sviluppatori di diversi stack tecnologici e di pagare ognuno di loro. Per costruire applicazioni mobili native, dobbiamo duplicare le nostre applicazioni. codice per funzionare bene su entrambe le piattaforme, Android e iOS. Un approccio comune è quello di mantenere entrambe le applicazioni simili, utilizzare le stesse API, mantenere lo stesso comportamento e così via. Di conseguenza, dobbiamo duplicare il codice per creare due versioni della stessa applicazione. JS è un linguaggio che ci permette di costruire applicazioni mobili e applicazioni web allo stesso tempo. Sembra impossibile? Lasciate che vi spieghi di cosa sto parlando.
Mobile? Web? Non mi interessa.
Supponiamo di voler creare un'applicazione che utilizzi la libreria React. Questa libreria può essere usata per costruire applicazioni web e applicazioni mobili con React nativo. I meccanismi logici dell'applicazione, come l'autorizzazione, l'elaborazione, il filtraggio dei dati e così via, possono essere realizzati con gli hook React. Il punto è che questi hook possono essere condivisi da entrambe le versioni dell'applicazione, web e mobile. Grazie a questa opzione, abbiamo i seguenti salvataggi:
- Non è necessario duplicare il codice responsabile della stessa cosa,
- Non è necessario assumere sviluppatori mobili nativi per implementare la stessa parte delle applicazioni,
- Non è necessario mescolare linguaggi diversi per implementare la stessa applicazione su piattaforme mobili diverse (Android/iOS),
- Uno sviluppatore può essere responsabile dell'implementazione di specifiche funzionalità dell'applicazione su tutte le piattaforme.
Per riassumere questo paragrafo, non è detto che un'unica base di codice alimenterà tutte le versioni dell'applicazione, anche se possiamo dividere il codice condiviso e usarlo in ogni versione per rendere il processo di sviluppo davvero più rapido.
Conclusione - se volete costruire un'applicazione web e una mobile allo stesso tempo, prendete in considerazione la libreria React che può condividere una base di codice nella versione mobile e web dell'applicazione.
Ma che dire del backend?
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. Lo sviluppo di questa lingua è sorprendente e i suoi frutti possono essere raccolti ancora oggi.
Di cosa sto parlando? Se si assume il giusto Sviluppatori JSSi scopre che possono scrivere non solo il frontend dell'applicazione, ma anche il backend, cioè 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'è motivo di avere questo atteggiamento! Backend con JS può essere implementato in due modi popolari: in una modalità estensibile e configurabile, che express.js può fornirci, e in una modalità strutturata che utilizza il pattern DI - nest.js.
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.
Non è ancora abbastanza? Analogamente alla condivisione del codice tra applicazioni web e mobili, il backend può condividere le risorse sia con le prime che con le seconde. La parola chiave da usare qui è TypeScript: tra le altre cose, ci permette di condividere una base di codice, cioè una definizione di tipo di dati comune tra tutte le piattaforme.
Con le applicazioni costruite esclusivamente sulla JavaScript / TypeScript 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à di logica tra tutte le applicazioni, il che accelererebbe decisamente i tempi di realizzazione di una particolare applicazione. Non vi sembra fantastico?
JS può alimentare le applicazioni desktop?
È 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ò essere Slack. Slack è un'applicazione utilizzata per squadra comunicazione: oltre alla messaggistica standard, presenta molte funzionalità diverse e vari tipi di integrazioni esterne. Tutto ciò la rende una delle applicazioni più popolari, utilizzata soprattutto nel settore IT.
Come si è 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 è electron. La creazione di interfacce grafiche con tecnologie web rende molto più semplice, veloce e generalmente possibile lo sviluppo di applicazioni per diverse piattaforme allo stesso tempo.
JS è abbastanza maturo?
A giudicare dalla parte frontend dell'applicazione, non c'è da illudersi che JS è 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à di JS sul frontend, non c'è dubbio che sia l'unico reale.
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.
Molti fornitori di cloud forniscono SDK che permettono di utilizzare direttamente nuvola metodi. Stranamente, una delle schede più popolari, proprio accanto a C#, Go e Java, è Node.js. Questa piattaforma è ideale per scalare e costruire applicazioni basate su microservizi o architetture serverless. Conclusione - JS è uno dei linguaggi più popolari per lo sviluppo di applicazioni basate su microservizi/architettura serverless. Nelle schermate sottostanti, possiamo vedere che la santa trinità (Google Computing Services, AWS, Azure) dei fornitori di cloud ci permette di costruire applicazioni utilizzando nodo.js.
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 è diventato uno dei più popolari nell'intero ecosistema ed è una sorta di modello per varie altre librerie che utilizzano, ad esempio, l'architettura serverless.
Conclusione - JS è un linguaggio abbastanza maturo per mettere tutte le carte in tavola e costruire sia il frontend che il backend. Inoltre, è un linguaggio abbastanza fresco che trova facilmente spazio nelle moderne architetture applicative. È fantastico che un programmatore che conosce un solo linguaggio possa padroneggiare entrambi i lati (full stack) di un'applicazione.
JS è abbastanza veloce?
Il motore più utilizzato per l'esecuzione di codice JS è il v8, basato sul linguaggio C++. Questo motore sviluppato da Google è dedicato all'esecuzione di applicazioni per piattaforme web. Una cosa interessante è 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. È ancora più veloce e ci dà risultati molto buoni in termini di prestazioni.
JS è abbastanza corretto per quanto riguarda le prestazioni? Sì, lo è. Finché si mantengono gli algoritmi abbastanza equi, non c'è alcun problema a usare JS sul lato server. L'altra cosa è mantenere il codice asincrono il più possibile. Con queste pratiche, il codice può gestire richieste parallele senza problemi. Non è necessario preoccuparsi del cambio di tecnologia a causa delle prestazioni, soprattutto se l'architettura dell'applicazione è scalabile.
Ho già discusso in dettaglio le prestazioni e i benchmark in questo articolo.
Il JS non è forse una stranezza tra le altre lingue?
Beh, queste sono decine di opinioni secondo cui il linguaggio JS si comporta in modo strano in alcuni casi e gestirlo è qualcosa che vi farà esplodere la testa durante il processo di sviluppo. Non posso essere d'accordo 🙂 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 è spiacevole.
Soprattutto l'osservazione "asincrono" subito prima di JS fa rabbrividire alcuni sviluppatori. È difficile da capire quando non si ha alcuna esperienza in merito. Tuttavia, è 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à collegate - l'utente e il server - può emettere e ricevere eventi in parallelo. Se il codice che alimenta l'applicazione è sufficientemente asincrono e non blocca il thread principale, possiamo facilmente gestire migliaia di richieste in poco tempo.
Confrontiamo JS e PHP con il contesto dei websocket. L'PHP è un linguaggio di programmazione sincrono, quindi la risoluzione di argomenti relativi ai websocket dà 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.
Mescolare il tutto
Riunendo tutti i paragrafi, possiamo affermare alcuni fatti:
JavaScript è un linguaggio che può essere usato per costruire ogni tipo di applicazione, dal web, al mobile, al desktop;
Le applicazioni scritte in JS possono condividere vari frammenti di codice tra loro, come quelli responsabili della formattazione dei dati o dei tipi in Typescript;
Grazie alla crescita del web, le prestazioni offerte da JS sono sufficientemente buone da poter optare per lo sviluppo di applicazioni sia frontend che backend;
Grazie al suo design insolito, l'JavaScript è in grado di supportare le moderne infrastrutture applicative, come websocket e WebRTC;
Assumendo uno sviluppatore adeguatamente qualificato, si è in grado di sfruttare il suo potenziale su tutti i frontend disponibili che utilizzano questo linguaggio;
JS è un linguaggio che sta scalando le classifiche di popolarità da diversi anni e non ci sono indicazioni che questo cambierà in qualche modo.
Per dare la mia opinione, per quanto di parte, sfruttare la possibilità di JavaScript di riutilizzare lo stesso codice su tutti i fronti disponibili è qualcosa che sicuramente velocizzerà lo sviluppo delle applicazioni e ridurrà il numero di sviluppatori coinvolti nella manutenzione del backend delle applicazioni scritte in altre tecnologie. A conferma di ciò, 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 crescono di anno in anno e i suoi sviluppatori possono facilmente agganciarsi alla tendenza del full stack.
Per saperne di più:
Perché si dovrebbe (probabilmente) usare Typescript
Come non uccidere un progetto con cattive pratiche di codifica?
Strategie di recupero dei dati in NextJS