È un po 'difficile da dire perché queste parole non sono ben definite. Nel linguaggio comune, penso che sia un po 'atipico chiamare Node.js un framework, certo, ma avrei difficoltà a discutere sul perché esattamente non lo è.
Tutto questo diventa rischioso, e spesso vedo usi del linguaggio davvero scadenti, quindi sarò esplicito e inizierò dal basso
JavaScript è un linguaggio informatico, vale a dire, in senso stretto, un insieme di convenzioni che ci consentono di leggere e interpretare un mucchio di testo come se avesse una semantica di esecuzione, una parola elaborata per "modo di interpretare il linguaggio come un insieme di istruzioni". Classi di programmi chiamati interpreti , compilatori , transpiler , linters , evidenziatori , ecc. Contengono tutti testo e tentano di fare qualcosa con questa comprensione convenzionale di come eseguire il codice.
- Gli interpreti eseguono effettivamente la semantica dell'esecuzione azionando una macchina, di solito il tuo computer. Puoi immaginarli come un omino all'interno del tuo computer che lancia interruttori come "stampa questo personaggio" in base alle istruzioni scritte nel tuo programma JavaScript.
- I compilatori provano a convertire il testo JavaScript in una nuova serie di testo che ha una semantica di esecuzione per una lingua diversa, forse una con la proprietà speciale che i computer possono eseguirla direttamente.
- I transpiler sono una forma generalizzata di compilatore in quanto accettano testo JavaScript e producono testo di un'altra lingua. La differenza è quindi un po 'soggettiva, ma di solito si pensa a un compilatore come a generare un codice di livello molto basso e a un transpiler come a un codice di alto livello .
- Linter , evidenziatori , verificatori di tipi , ecc. Contengono tutti il testo JavaScript e generano una sorta di prodotto analitico, ad esempio testo evidenziato, che è influenzato dalla semantica dell'esecuzione, ma in realtà non rappresentativo di esso.
Ora, scaviamo un po 'nella semantica dell'esecuzione. Generalmente, la semantica dell'esecuzione implica un processo di lettura del testo in lingua e arrivo a una descrizione di una macchina astratta o una descrizione di effetti collaterali osservabili . Quello che vorrei suggerire è che entrambi presuppongono la necessità che ci sia una sorta di "API di basso livello" per far funzionare la macchina o per eseguire gli effetti osservabili. Questi sono generalmente considerati parte dell'ambiente di runtime
- L' ambiente di runtime o runtime è un insieme di primitive presunte che la convenzione di lingua richiede per esistere per funzionare. Per quanto riguarda la lingua, potrebbero esserci delle ipotesi sul loro comportamento, ma sono inosservabili. Nelle immagini dell'interprete sopra, "l'uomo dentro" fa semplicemente scattare gli interruttori di runtime --- non può ispezionare personalmente ciò che stanno facendo.
La parola runtime viene solitamente abusata per indicare sia l'insieme delle primitive presunte stesse che un'istanza effettiva di esse.
Quindi, ora arriviamo a qualcosa di peloso. Un linguaggio è un insieme di convenzioni che presuppone l'esistenza di un runtime al fine di fornire significato alla sua semantica di esecuzione. Non "sonda mai" in quanto sono fuori portata.
Per poter effettivamente utilizzare una lingua si desidera qualcosa come un compilatore o un interprete insieme a un'implementazione di runtime. Il compilatore / interprete e questo vanno di pari passo in fase di esecuzione in realtà l'esecuzione di codice.
- Chrome V8 , spesso chiamato motore , è un pacchetto che contiene un interprete, un compilatore, un'implementazione di runtime compatibile con l'interfaccia di runtime richiesta dalle convenzioni JavaScript standard ECMA.
Quindi dove si inserisce Node.js in questo?
Dobbiamo dividerlo in parti:
- Node.js espande il linguaggio JavaScript fornendo un set più ampio di primitive dell'ambiente di runtime, quelle che non rientrano nell'ambito degli standard ECMA. Questi includono cose come l' I / O dei file . Ciò significa che Node.js cambia la lingua ed è in qualche modo una nuova lingua: "Node.js JavaScript"
- Node.js, come pacchetto, contiene un interprete e un compilatore. Li ruba solo dal V8.
- Node.js fornisce un'implementazione dell'ambiente di runtime Node.js che consente di eseguire "Node.js JavaScript".
- Node.js fornisce una serie di librerie standard costruite in cima alle nuove primitive che le rendono più accessibili agli utenti finali di "Node.js JavaScript".
Quindi Node.js è un sacco di cose!
Ma è un quadro?
È qui che la terminologia cade completamente a pezzi: nessuno ha una buona, coerente e significativa definizione di cosa sia effettivamente un framework.
Ci sono dibattiti che imperversano: "cos'è un framework contro una libreria" e finiscono su cose insoddisfacenti come "una libreria è qualcosa che chiami e un framework è qualcosa che ti chiama". Non voglio nemmeno dare una spiegazione così triste alla luce del giorno, ma JavaScript, e Node.js JavaScript in particolare, è un duro colpo per questa definizione poiché l'intera tecnica di passaggio di callback significa che si passa costantemente da una chiamata all'altra ed essere chiamato.
Secondo la mia opinione personale, c'è qualcosa di sostanziale qui. Non voglio tracciare una linea luminosa, ma quindi dirò semplicemente
- Un set di codice è simile a una libreria se funziona come un set di lego : divisibile e creato per l'assemblaggio. Mentre potrebbero esserci alcuni esempi su come utilizzare la libreria, spetta generalmente all'utente stesso assemblarla in base alle proprie esigenze.
- Un set di codice è simile a un framework se non è divisibile e implica convenzioni *: separare parti di esso può far fallire molte ipotesi, quindi è necessario comprendere l'uso convenzionale per utilizzare correttamente un framework.
Questa è una linea ondulata per essere sicuri, ma voglio delineare un punto davvero interessante sui framework:
I frame implicano una serie di convenzioni su come interpretare il codice; sono quindi una lingua a sé stante.
Questo potrebbe essere qualcosa di cui anche le persone vogliono discutere, ma se hai comprato la mia precedente definizione che una lingua è solo un insieme di convenzioni che danno vita a un blocco di testo, allora ogni volta che stabilisci un nuovo livello di convenzioni, " ho costruito una nuova lingua. Forse con i framework le materie prime sono le interpretazioni semantiche della loro lingua host anziché i file di testo non elaborati, ma l'idea è la stessa!
Quindi, con tutto ciò che ho detto, sono totalmente felice di chiamare Node.js un framework anche se va un po 'contro la norma! Node.js aggiunge funzionalità a JavaScript non elaborato nel modo di espandere la lingua . Con esso porta nuovi presupposti e strumenti per lavorare in questo linguaggio espanso. Funzionalmente, queste idee sono le stesse di quelle di altri framework ben accettati come Ruby on Rails .
Direi che se in questo momento ti senti un po 'nauseato e vuoi sostenere che c'è un enorme divario tra Ruby on Rails e Node.js in questo modo di cose, allora sono proprio lì con te , ovviamente. Il tipo di mondi concettuali in cui vivono i due è drammaticamente diverso: voglio solo dire che sono lo stesso tipo di cose: insiemi di convenzioni per espandere i poteri di un linguaggio di base all'interno di un determinato dominio.
Sono anche felice di suggerire che il dominio di Node.js è piccolo e stretto e quindi le convenzioni che aggiunge sono semplici da ragionare e relativamente facili da correggere. OTOH, Ruby on Rails vive in un dominio complesso e mal definito di "applicazioni web aziendali", il che significa che le convenzioni che stabilisce sono certamente confuse e infrante.
Ma tutto questo è un lungo modo di dire, sì, i recruiter probabilmente non hanno idea di cosa significhino quando lo dicono. Immagino che "framework" suona semplicemente come una parola migliore, più incisiva di "runtime" o "motore".