Deno:una guida semplice

Il 13 maggio 2020 è stato fatto un passo avanti molto promettente nella comunità JavaScript. È stata rilasciata la prima versione stabile di Deno, in sviluppo da oltre 2 anni. Deno è stato pubblicizzato come un nuovo approccio ad alcuni degli errori e dei problemi che si sono verificati nello sviluppo originale di NodeJS nel 2009.

Questo post sul blog mira a eliminare gran parte del clamore che potresti vedere intorno a Deno nel tentativo di presentare i fatti, quindi anche un principiante assoluto dell'ecosistema JavaScript o NodeJS può comprendere Deno e il suo impatto.

Cos'è Deno?

Deno è un runtime JavaScript creato da Ryan Dahl, il creatore originale di NodeJS. È stato originariamente annunciato da Ryan alla JSConf EU 2018, nato dal desiderio di Dahl di migliorare e ripensare alcuni aspetti del runtime JavaScript che aveva originariamente creato.

Sul sito web di deno, lo slogan recita:

Che cosa significa in pratica significare? Analizziamolo e chiariamo parte del gergo.

Un runtime JavaScript è un ambiente che contiene tutto il necessario per eseguire un programma scritto in JavaScript. Nel caso di NodeJS, il runtime è composto da 2 concetti di alto livello:

  • Il motore JavaScript V8 . Un motore JavaScript compila ed esegue il tuo codice JavaScript. V8 è un motore JavaScript specifico scritto in C++ creato e mantenuto da Google e utilizzato per alimentare NodeJS, Chrome e Chromium.
  • API e moduli. Questi includono moduli per interagire con il file system, effettuare richieste HTTP, timer ecc.

Quindi, con questo in mente, siamo in una posizione molto migliore per capire Deno e come è diverso da Node.

Deno è un runtime che utilizza ancora il motore V8 per eseguire codice JavaScript. Deno differisce perché è scritto in ruggine anziché in C++. Ciò include la CLI e tutti i simpatici strumenti forniti da Deno, che vengono impacchettati in un unico file eseguibile. Il codice ruggine si interfaccia con il motore V8 tramite il pacchetto ruggine rusty_v8 (o cassa, come sono conosciuti nell'ecosistema ruggine). La cassa arrugginita Tokio è usata pesantemente in deno sotto il cofano per comportamento e programmazione asincroni.

I moduli e le API in Deno sono scritti in TypeScript che è un cittadino di prima classe del runtime. Il codice TypeScript viene compilato in JavaScript internamente in Deno. Ciò consente agli sviluppatori di scrivere TypeScript, compilarlo ed eseguirlo come se fosse solo JavaScript, senza installare strumenti aggiuntivi.

Perché Deno?

Quindi ora sappiamo come differiscono i tempi di esecuzione effettivi. Ma perché ? Cosa c'era di sbagliato con quello attuale in Node? Perché Ryan Dahl e il resto del team di deno hanno trascorso 2 anni a sviluppare questo? Lo stesso Ryan Dahl entra nel dettaglio di questo qui. Descrive in dettaglio i rimpianti che aveva per la costruzione di Node in primo luogo, che ha gettato le basi per deno. Ryan annuncia Deno in questo discorso, anche se nelle fasi iniziali.

Se non vuoi guardare il video o non hai tempo. Rispetto quello. Riassumiamo i punti.

Rimpianti:non mantenere le promesse

NodeJS si basa sul concetto di callback. I callback sono funzioni che vengono eseguite al termine dell'esecuzione di un'attività. Ad esempio, quando leggi un file utilizzando fs modulo:

const fs = require("fs");

fs.readFile("index.html", function(err, data) {
    if (err) {
        console.log("Error Reading File!", err);
    }
    console.log(data);
});

La funzione passata come secondo argomento a fs.readFile ecco la richiamata . Questa funzione verrà eseguita ogni volta che il nodo ha terminato la lettura del file e restituirà i dati (se ha esito positivo) o un errore (se qualcosa è andato storto). Da allora i callback sono stati eclissati dalle promesse, che forniscono un'API più semplice e potente per gestire il comportamento asincrono in JavaScript.

Successivamente, è diventato possibile convertire funzioni con callback per utilizzare le promesse utilizzando il promisify funzione sul util modulo in Nodo. Ecco la versione promessa dell'esempio sopra.

const util = require("util");
const fs = require("fs");

const readFilePromise = util.promisify(fs.readFile);

readFilePromise("index.html").then(data => {
    console.log(data);
})
.catch(err => console.error("Error Reading File!", err))

Un po' prolisso, ma fa il suo lavoro. Possiamo migliorare ulteriormente questo codice usando il async /await funzione, che mirava a far leggere il codice JavaScript asincrono come codice sincrono. Ecco l'esempio sopra riscritto per usare async/await .

const util = require("util");
const fs = require("fs");

const readFilePromise = util.promisify(fs.readFile);
async function readFile() {
    try {
        const data = await readFilePromise("index.html");
    } catch (err) {
        console.error("Error reading file!", err);
    }
}

readFile();

Le promesse sono state effettivamente aggiunte a Node nel giugno 2009, ma rimosse di nuovo nel febbraio 2010 per mantenere le cose semplici nella base di codice di NodeJS. Questo è stato un rimpianto di Ryans, poiché l'uso unificato delle promesse avrebbe accelerato la consegna e la standardizzazione o async/await .

Deno supporta le promesse pronte all'uso e ciascuna delle sue API asincrone è stata scritta pensando a Promises. Non dover combinare promesse e callback offre un'esperienza di programmazione asincrona più semplice e coerente. Vediamo come eseguiamo lo stesso compito di cui sopra utilizzando la libreria standard deno.

const file = await Deno.open("index.html");

try {   
  await Deno.readFile(file, Deno.stdout);
} catch (err) {
    console.error("Error reading file!", err);
}

file.close();

Nessuna richiamata. Tutte le API deno async ci restituiranno una promessa.

Rimpianti:sicurezza

Node ha accesso a diverse cose per impostazione predefinita che potrebbero essere considerate sensibili. Ciò include il file system, la rete e le chiamate di sistema. Dahl desidera aver dedicato più pensiero e impegno alla sicurezza in NodeJS. L'esempio che ha dato è stato l'esecuzione di una linter. Linter come ESLint probabilmente non dovrebbero avere pieno accesso al tuo computer e alla tua rete. Sfortunatamente, lo fanno.

Deno, tuttavia, è sicuro per impostazione predefinita. Il runtime non ti consentirà di accedere al file system o di eseguire chiamate di rete a meno che tu non gli conceda esplicitamente le autorizzazioni. Parleremo di alcuni esempi in seguito.

Rammarico:il sistema di costruzione (GYP)

Secondo Ryan Dahl, il sistema di build NodeJS è il suo più grande rimpianto.

Per quanto tutti vorremmo, non possiamo scrivere tutto in JavaScript. A volte abbiamo bisogno di prestazioni molto migliori di quelle che JavaScript può fornire. È qui che dobbiamo compilare moduli nativi scritti in linguaggi di livello inferiore come C++.

Se stai scrivendo un modulo NodeJS che si interfaccia con una libreria C++, il tuo codice utilizzerà GYP (Generate Your Projects). GYP e più specificamente node-gyp è uno strumento utilizzato per compilare moduli nodeJS nativi scritti in C o C++ in modo che sia possibile accedervi con require , come qualsiasi altro modulo JS.

Il nodo originariamente utilizzava GYP perché Google Chrome utilizzava pesantemente GYP. Il team di Chrome è poi passato a GN. GN mira ad essere un formato di file più leggibile e manutenibile rispetto a GYP. Offre anche prestazioni notevolmente migliori.

Ciò ha lasciato Node nel limbo come unico utente di GYP. Deno cerca di risolvere questo problema utilizzando una miscela di GN e cargo, il sistema di costruzione di Rust. Ciò fornisce prestazioni di compilazione molto migliori e API più amichevoli per la compilazione di moduli nativi.

Rimpianti:Package.json

package.json è la pietra angolare del JavaScript moderno. Include le dipendenze per il tuo progetto e dice a Node cosa installare quando esegui un npm install . NPM è un repository centralizzato di pacchetti JavaScript ed è da dove scaricherai la stragrande maggioranza dei pacchetti JS. Come sviluppatori JavaScript, generalmente non passiamo molto tempo senza dover interagire con NPM in un modo o nell'altro.

Dahl si rammarica di package.json Per diverse ragioni. Non gli piace il fatto che tu debba definire le tue dipendenze in 2 posti - package.json e anche all'interno del tuo codice quando require il modulo. Si rammarica anche del fatto che questa non sia un'astrazione che esiste sul web, dal momento che puoi semplicemente aggiungere un <script /> tag con un URL al tuo HTML.

package.json contiene anche un sacco di altre informazioni, come il nome, la descrizione e il repository del tuo progetto. Dahl chiama questo "rumore" e crede che non sia necessario.

Deno cerca di risolvere questo problema rimuovendo il concetto di package.json del tutto . Deno ti consente di richiedere moduli direttamente dagli URL, semplificando drasticamente l'intero concetto di richiedere moduli esterni nei tuoi script e applicazioni.

Rimpianti:node_modules

Quindi package.json dice di quali moduli hai bisogno, ma i moduli stessi sono installati nel tuo node_modules directory all'interno del tuo progetto. Ogni progetto ha il suo node_modules cartella, che richiede di duplicare le dipendenze tra i progetti. Questo concetto devia molto dal modo in cui funzionano le dipendenze nel browser.

Deno adotta un approccio nuovo a questo. node_modules non esiste in Deno. Quando hai bisogno di un modulo esterno in Deno, viene scaricato e le tue dipendenze vengono archiviate in una directory specifica definita da te. Tuttavia, il tuo programma non recupererà più gli stessi moduli, poiché deno memorizza nella cache le dipendenze per te.

Rammarico:require("module") senza estensione (".js", ".ts")

In Node, puoi richiedere file senza .js estensione. Questo crea la necessità di interrogare il file system e controllare cosa effettivamente significava quando il caricatore di moduli del nodo sta risolvendo i tuoi moduli. Ryan sostiene che questo è meno esplicito e si discosta dal modo in cui viene eseguito nel browser, che assomiglia a qualcosa di simile al seguente:

<script src="myscript.js" type="text/javascript"></script>

Deno applica il .js o .ts estensione sulle importazioni per alleviare questo.

Rimpianti:index.js

In Node, se require un modulo, index.js viene generalmente utilizzato come file di "immissione" per un modulo o un'applicazione. Questo è simile a come index.html viene risolto per impostazione predefinita in un server Web. Ciò significa che puoi richiedere una cartella come questa.

const mymodule = require("./my-cool-module")

Il nodo cercherà un index.js file all'interno del my-cool-module directory per impostazione predefinita per risolvere il modulo. Lo stesso vale per i moduli importati da node_modules . Dahl se ne rammarica perché non è esplicito, ma più pratico, ha complicato il sistema di caricamento dei moduli del nodo introducendo un altro passaggio implicito per verificare l'esistenza di index.js .

Installazione di Deno

È piuttosto semplice iniziare a funzionare con deno. Su OSX, esegui semplicemente:

brew install deno

Questo comando dovrebbe installare il singolo eseguibile deno sulla tua macchina. Puoi verificare che ha funzionato eseguendo:

deno --version

Se non ha funzionato, o sei su un altro sistema operativo, controlla la guida all'installazione di deno.

Funzionalità

Ora che abbiamo deno attivo e funzionante, tuffiamoci in alcune delle nuove brillanti funzionalità.

Supporto TypeScript

TypeScript è un cittadino di prima classe di Deno. Ciò significa che possiamo scrivere il nostro codice in TypeScript senza doverci preoccupare di aggiungere strumenti per la nostra fase di compilazione. Quando eseguiamo il codice TypeScript con deno, digiterà check e lo compilerà per noi ed eseguirà come se fosse un normale JavaScript. Questo rimuove completamente il sovraccarico della configurazione del compilatore TypeScript nel tuo progetto.

Nessun NPM - Deno Packaging

Deno adotta un approccio nuovo e diverso all'importazione di codice esterno. Non ha un gestore di pacchetti. Puoi eseguire del codice esterno semplicemente passando un URL al deno run comando.

deno run https://deno.land/std/examples/welcome.ts

Questo comando estrarrà il modulo da Internet, lo compilerà, lo inserirà nella cache a tempo indeterminato e lo eseguirà, il tutto senza NPM. Se vuoi import un modulo e usarlo nel tuo codice, non devi installare un modulo da NPM e require esso. Supponiamo di creare il seguente file, test.ts .

import { assertEquals } from "https://deno.land/std/testing/asserts.ts";

assertEquals(2, 2);

Possiamo quindi eseguire questo con:

deno run test.ts

Il nostro modulo risolverà i moduli dal Web ed eseguirà il codice. La prossima volta che lo fai, deno non deve recuperare di nuovo il modulo poiché è memorizzato nella cache. Possiamo eseguire codice da qualsiasi URL pubblicamente accessibile. Ad esempio, se vuoi eseguire del codice direttamente da github, puoi usare il seguente comando:

deno run https://github.com/shogunpurple/deno-test/blob/master/src/hello.ts

Autorizzazioni di runtime sicure

Deno è un runtime sicuro. Ciò significa che opera in base al principio di concedere solo i permessi forniti esplicitamente. Ciò differisce da NodeJS in quanto il nodo fornisce automaticamente i permessi a cose come il tuo file system e la tua rete. Alcune cose che deno non ti permetterà di fare senza abilitare esplicitamente le autorizzazioni sono:

  • Lettura/Scrittura dal file system
  • Fai richieste HTTP e accedi alla rete
  • Esegui processi secondari

Per dimostrarlo, eseguiamo un esempio. Eseguiremo uno script che legge un file sul file system.

$ deno run https://deno.land/std/examples/cat.ts /etc/passwd

Otteniamo il seguente output:

$ deno run https://deno.land/std/examples/cat.ts /etc/passwd  
error: Uncaught PermissionDenied: read access to "/etc/passwd", run again with the --allow-read flag
    at unwrapResponse ($deno$/ops/dispatch_json.ts:43:11)
    at Object.sendAsync ($deno$/ops/dispatch_json.ts:98:10)
    at async Object.open ($deno$/files.ts:37:15)
    at async https://deno.land/std/examples/cat.ts:4:16

Ops. Ciò accade perché deno non ci consente di leggere dal file system a meno che non specifichiamo i permessi di lettura dei file nel nostro deno run comando.

$ deno run --allow-read=/etc https://deno.land/std/examples/cat.ts /etc/passwd

Questo funziona! Ora vedrai i contenuti di /etc/passwd file nell'output del terminale. Ciò fornisce un potente livello di sicurezza che ci consente di configurare solo le autorizzazioni esatte che vogliamo che il nostro programma abbia quando viene eseguito. Alcuni altri esempi di cose per cui potresti voler concedere le autorizzazioni al tuo programma durante l'esecuzione sono:

  • --allow-net - consenti richieste HTTP dal tuo programma
  • --allow-env - consentire l'accesso alle variabili di ambiente.
  • --allow-run - consenti al tuo programma di eseguire sottoprocessi.

La maggior parte di questi flag accetta argomenti, consentendoti di limitare l'accesso a determinate risorse. Ad esempio, se desideri solo consentire al tuo programma di inviare richieste HTTP a https://myapi.com:

deno run --allow-net=https://myapi.com my-program.ts

Libreria standard

La libreria standard limitata in Node è sempre stata un punto critico per gli sviluppatori. C'è un forte affidamento su moduli esterni per eseguire attività in Node che sono incluse nella libreria standard di molti altri linguaggi di programmazione. La generazione di UUID ne è un esempio, in cui la libreria uuid è la soluzione de facto per gli sviluppatori Node, tuttavia non fa parte della libreria standard del nodo. Deno fornisce un'ampia libreria standard basata su quella del linguaggio di programmazione go che include alcune funzionalità interessanti come:

  • funzioni data/ora
  • Server http
  • registrazione
  • autorizzazioni
  • test
  • generazione di fluidi
  • WebSocket
  • utilità del file system (fs)
  • hashing e crittografia
  • analisi dei flag della riga di comando

Essere in grado di fare queste cose senza moduli esterni dà a deno la possibilità di creare una miriade di applicazioni diverse solo con la libreria standard.

API compatibili con browser

Nella libreria deno standard sono inclusi anche un impressionante set di API che aderiscono agli standard web e quindi possono essere eseguite nel browser, consentendo al codice scritto e compilato con deno di essere eseguito sia sul client che sul server!

Uno dei più importanti che include deno è un'implementazione di fetch , un'API del browser utilizzata per effettuare richieste HTTP. In node, devi importare un modulo esterno per questo come node-fetch oppure usa il nativo http module in node, che è un po' goffo e prolisso. Se volessimo usare fetch per effettuare una chiamata a google.com con deno, potremmo utilizzare il seguente codice:

const response = await fetch("http://www.google.com");

console.log(response);

Nota anche come siamo in grado di utilizzare un await di livello superiore qui - un'altra caratteristica che deno supporta immediatamente. Eseguiamo il nostro codice sopra con:

deno run --allow-net fetch_google.ts

Il risultato della nostra chiamata HTTP a Google verrà mostrato nella console. Nota come abbiamo specificato il allow-net autorizzazioni per consentire al nostro codice di effettuare una richiesta HTTP. Ecco alcune altre API comuni del browser che deno supporta.

  • addEventListener
  • removeEventListener
  • setInterval
  • clearInterval
  • dispatchEvent

Puoi vedere l'elenco completo delle API compatibili con il Web in deno qui.

La conformità agli standard web renderà l'API deno molto più a prova di futuro e fornirà utilità agli sviluppatori front-end.

Strumenti Deno

Oltre alle effettive funzionalità linguistiche di cui sopra, deno ci offre strumenti aggiuntivi che eseguono attività attualmente svolte da artisti del calibro di webpack, rollup e più graziosi. La differenza è che deno include questi strumenti fuori dagli schemi.

Raggruppamento

Il raggruppamento è il processo di prendere l'applicazione e le dipendenze e di inviarle in un unico file JavaScript che può essere eseguito. Questo lavoro viene generalmente eseguito da bundler di moduli come rollup, webpack e pacchi. Deno ci offre un approccio semplice per raggruppare il codice con il deno bundle comando. Se vogliamo raggruppare del codice, possiamo fare quanto segue con deno.

$ deno bundle https://deno.land/std/examples/echo_server.ts server.bundle.js
Bundling https://deno.land/std/examples/echo_server.ts
Download https://deno.land/std/examples/echo_server.ts
Warning Implicitly using master branch https://deno.land/std/examples/echo_server.ts
Emitting bundle to "server.bundle.js"
2661 bytes emmited.

Ora possiamo eseguire il nostro pacchetto come qualsiasi altro script normale.

$ deno run --allow-net server.bundle.js
Listening on 0.0.0.0:8080

Test integrati

Deno ha un test runner integrato che ci consente di testare il nostro codice JavaScript e TypeScript. Se hai familiarità con le librerie di test JavaScript come Jest o Jasmine, questa sintassi sembrerà familiare.

Deno.test("deno test", () => {
     const name = "John";
     const surname = "Wick";
     const fullname = `${name} ${surname}`;
   assertEquals(fullname, "John Wick");
});

Usiamo il test funzionalità sul Deno namespace per creare un test. Possiamo quindi eseguire i nostri test con il deno test comando:

$ deno test test.ts
Compile file:///Users/martinmckeaveney/Development/deno-test/.deno.test.ts
running 1 tests
test deno test ... ok (4ms)

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out (5ms)

Questa è una funzionalità potente, poiché potresti semplicemente eseguire una suite di test completa puntando il tuo deno test comando a una suite di test ospitata da qualche parte online, senza dover aprire ed eseguire la suite di test da solo.

Installazione script

Il pacchetto dei tuoi script in un singolo eseguibile è una cosa molto utile quando vuoi che qualcuno sia in grado di eseguire il tuo script sul proprio computer senza installare Node. Attualmente se vuoi farlo con uno script node, puoi farlo con il fantastico modulo pkg di vercel, che richiede l'installazione di quel modulo esterno tramite NPM.

Deno fornisce un programma di installazione di script integrato, che ti consente di distribuire i tuoi script come un singolo eseguibile. Vediamo come funziona. Installeremo lo script di base deno "Hello World" dal sito Web deno.land come script eseguibile.

$ deno install https://deno.land/std/examples/welcome.ts
Download https://deno.land/std/examples/welcome.ts
Warning Implicitly using master branch https://deno.land/std/examples/welcome.ts
Compile https://deno.land/std/examples/welcome.ts
✅ Successfully installed welcome
/Users/martinmckeaveney/.deno/bin/welcome
ℹ️  Add /Users/martin/.deno/bin to PATH
    export PATH="/Users/martin/.deno/bin:$PATH"

Gli script vengono salvati per impostazione predefinita in .deno/bin cartella situata nella nostra home directory. Possiamo eseguire direttamente il nostro script:

$ ./.deno/bin/welcome 
Welcome to Deno 🦕

Come menzionato nel messaggio sopra, se vogliamo eseguire questo script da qualsiasi punto del nostro sistema, dobbiamo aggiungere il .deno directory al nostro PATH . Il PATH variabile dice alla nostra macchina dove cercare gli script quando li eseguiamo dal terminale. Una volta aggiunto il .deno directory nel nostro percorso, possiamo eseguire lo script da qualsiasi luogo!

$ welcome
Welcome to Deno 🦕

Formattazione

Più carino è il formattatore de facto per il codice JavaScript. Deno fornisce un formattatore integrato (che in realtà utilizza più carini sotto il cofano) tramite il deno fmt comando.

Possiamo formattare del codice dall'aspetto brutto in questo test.ts script eseguendo deno fmt su di esso.

import { assertEquals } from "https://deno.land/std/testing/asserts.ts";

Deno.test("deno test", () => { const name = "John"; const surname = "Wick"; 
const fullname = `${ name} ${surname}`;
   assertEquals(fullname, "John Wick"); }
    )
  ;
$ deno fmt

Il nostro risultato è un codice ben formattato.

import { assertEquals } from "https://deno.land/std/testing/asserts.ts";

Deno.test("deno test", () => {
  const name = "John";
  const surname = "Wick";
  const fullname = `${name} ${surname}`;
  assertEquals(fullname, "John Wick");
});

deno fmt fornisce una bella utilità per impostazione predefinita che può essere un po' faticoso da configurare in progetti JavaScript standard. Alcuni altri comandi sono supportati da deno fmt includere:

  • deno fmt --check - controlla se i file sono già formattati
  • deno fmt file1.ts - formattare file specifici

Svantaggi

Una semplificazione radicale e un approccio completamente diverso a un runtime JavaScript non sono privi di limitazioni.

Compatibilità con le versioni precedenti con Node

Deno non è la "versione successiva" di node. È un'implementazione nuova di zecca che non è più compatibile con pacchetti NPM e moduli nodo esistenti. L'https://deno.land/std/node/ API è in fase di creazione per consentire ciò, ma al momento della stesura di questo documento non è completo. Ci sono alcune porte di moduli nodo esistenti sul sito Web deno che puoi utilizzare. Dai un'occhiata al sito web deno.land. Man mano che Deno matura, questo elenco di librerie trasferite per il supporto di Deno crescerà in modo esponenziale.

Compilatore TypeScript

Deno usa il compilatore TypeScript per controllare i tipi e compilare il codice in JavaScript. Ciò fornisce un collo di bottiglia in cui il codice deve passare attraverso quella fase di compilazione aggiuntiva e di controllo del tipo prima dell'esecuzione. Il compilatore TypeScript è scritto in TypeScript, il che significa che le prestazioni del controllo del tipo in TypeScript non corrisponderanno mai alle prestazioni grezze di linguaggi nativi come C++ o Rust. Ci sono potenziali piani per implementare il controllo del tipo per deno in rust, che è un progetto enorme e non sarà pronto per molto tempo.

Questa limitazione si applica principalmente a progetti molto più grandi, in cui il tempo di compilazione del codice TypeScript diventa sempre più un problema man mano che la base di codice cresce. Per la maggior parte dei progetti di piccole e medie dimensioni, questo non sarà un problema per la maggior parte degli sviluppatori.

Conclusione

Internet ama le dicotomie.

Molte persone vogliono sapere se dovrebbero abbandonare la cosa che stanno imparando per passare a quella nuova calda quasi ogni giorno, per paura di essere lasciati indietro. Puoi vederne la prova con i normali post e tweet di reddit che urlano il titolo "è morto?!", o la battuta comunemente lanciata - "Non dovresti usare (tecnologia matura e ben consolidata), (cosa nuova e brillante) è meglio, a causa di (caratteristica)".

Deno non è un sostituto di NodeJS. Ci sono troppi programmi di nodo attualmente esistenti, con molti altri scritti ogni ora di ogni singolo giorno. Deno è una nuova interpretazione e una nuova filosofia verso la creazione, il confezionamento e la distribuzione di script e applicazioni nell'ecosistema JS, basato su tecnologie moderne con un'attenzione particolare alla fornitura di un potente ambiente di scripting con gli strumenti necessari integrati.

Deno ha ancora molta strada da fare. Affinché Deno diventi un successo, la comunità deve usarlo e costruire moduli per esso. Deno deve trovare il suo posto nel flusso di lavoro quotidiano degli sviluppatori JavaScript.

Uno dei problemi fino a questo punto con JavaScript moderno è la forte dipendenza dagli strumenti. Sebbene gli strumenti JS abbiano aperto porte che non erano mai state ritenute possibili in passato, possono essere travolgenti per i principianti e persino per gli sviluppatori esperti che non hanno familiarità con l'ecosistema JS. Deno nasconde molto di questo e prende quelle decisioni per te. Questo è un enorme vantaggio per molti ingegneri.

Spero che tu abbia imparato qualcosa. Grazie per aver letto!

Sentiti libero di contattarmi o seguimi su Twitter, dove twitto e bloggo su JavaScript, Python, AWS, automazione e sviluppo senza codice.