C'est un peu difficile à dire car ces mots ne sont pas bien définis. Dans le langage courant, je pense qu'il est un peu atypique d'appeler Node.js un framework, bien sûr, mais j'aurais du mal à me demander pourquoi il n'en est rien.
Tout cela devient risqué, et je vois souvent de très mauvaises utilisations du langage, je vais donc être explicite et commencer par le bas
JavaScript est un langage informatique, c'est-à-dire, de manière étroite, un ensemble de conventions qui nous permettent de lire et d'interpréter un groupe de textes comme ayant une sémantique d'exécution - un mot sophistiqué pour "une manière d'interpréter le langage comme un ensemble d'instructions". Des classes de programmes appelées interprètes , compilateurs , transpileurs , linters , surligneurs , etc. prennent toutes du texte et tentent de faire quelque chose avec cette compréhension conventionnelle de l'exécution du code.
- Les interprètes en fait exécuter la sémantique d'exécution en actionnant une machine habituellement votre ordinateur. Vous pouvez les considérer comme un petit homme à l’intérieur de votre ordinateur qui bascule des commutateurs du type "print this character" (imprimer ce personnage) en fonction d’instructions écrites dans votre programme JavaScript.
- Les compilateurs essaient de convertir le texte JavaScript en un nouvel ensemble de texte comportant une sémantique d'exécution pour un langage différent, par exemple un avec la propriété spéciale que les ordinateurs peuvent exécuter directement.
- Les transpilers sont une forme généralisée de compilateur dans la mesure où ils prennent du texte JavaScript dans et produisent du texte d'une autre langue. La différence est donc un peu subjective, mais on pense généralement à un compilateur produisant du code de très bas niveau et à un transpiler de générer du code de haut niveau .
- Les linters , les surligneurs , les vérificateurs de texte , etc. prennent tous en JavaScript le texte et produisent une sorte de produit analytique, le texte surligné, par exemple, qui est influencé par la sémantique d'exécution, mais qui n'est pas réellement représentatif de celle-ci.
Maintenant, creusons un peu la sémantique d'exécution. Généralement, la sémantique d'exécution implique un processus de lecture de texte en langage et aboutit soit à une description d'une machine abstraite, soit à une description des effets secondaires observables . Ce que j'aimerais suggérer, c'est que ces deux systèmes supposent la nécessité d'une sorte "d'API de bas niveau" permettant de faire fonctionner la machine ou de produire les effets observables. Celles-ci sont généralement considérées comme faisant partie de l' environnement d'exécution
- L' environnement d'exécution ou l' environnement d' exécution est un ensemble de primitives supposées requises par la convention de langage pour pouvoir fonctionner. En ce qui concerne le langage, il peut exister des hypothèses sur leur comportement, mais ils ne sont pas observables. Dans l'imagerie de l'interprète ci-dessus, "l'homme à l'intérieur" actionne simplement les commutateurs d'exécution - il ne peut pas inspecter personnellement ce qu'ils font.
Le mot exécution est généralement utilisé de manière abusive pour désigner à la fois l’ensemble des primitives supposées et leur instanciation réelle.
Donc, maintenant nous arrivons à quelque chose de poilu. Un langage est un ensemble de conventions qui suppose l'existence d'un runtime afin de donner un sens à sa sémantique d'exécution. Il ne "sonde" jamais car ils sont hors de portée.
Pour utiliser réellement un langage, vous voulez quelque chose comme un compilateur ou un interpréteur associé à une implémentation d'exécution. Le compilateur / interprète et ce moteur d'exécution vont de pair dans l' exécution de votre code.
- Le V8 de Chrome , souvent appelé moteur , est un contrat contenant un interpréteur, un compilateur, une implémentation d'exécution compatible avec l'interface d'exécution requise par les conventions JavaScript du standard ECMA.
Alors, où se situe Node.js dans tout cela?
Nous devons le diviser en plusieurs parties:
- Node.js étend le langage JavaScript en fournissant un plus grand nombre de primitives d'environnement d'exécution, celles qui sortent du cadre des normes ECMA. Ceux - ci comprennent des choses comme fichier E / S . Cela signifie que Node.js change de langue et est en quelque sorte un nouveau langage: "Node.js JavaScript"
- Node.js, en tant que package, contient un interpréteur et un compilateur. Il vole juste ces de V8.
- Node.js fournit une implémentation de l'environnement d'exécution Node.js qui permet l' exécution de "Node.js JavaScript".
- Node.js fournit un ensemble de bibliothèques standard construites sur les nouvelles primitives, ce qui les rend plus accessibles aux utilisateurs finaux de "Node.js JavaScript".
Donc Node.js, c'est beaucoup de choses!
Mais est-ce un cadre?
C’est là que la terminologie s’écroule totalement: personne n’a une définition correcte, cohérente et significative de ce qu’est un cadre.
Il y a des débats qui font rage: "Qu'est-ce qu'un cadre par rapport à une bibliothèque" et ils se terminent par des choses insatisfaisantes telles que "une bibliothèque est quelque chose que vous appelez et un cadre est quelque chose qui vous appelle". Je ne veux même pas vraiment donner une explication aussi triste à la lumière du jour - mais JavaScript, et Node.js JavaScript en particulier, porte un dur coup à cette définition car toute la technique de passer des rappels signifie que vous passez constamment d' un appel à l'autre. et être appelé.
À mon avis, il y a quelque chose de substantiel ici. Je ne veux pas tracer une ligne claire, mais je vais simplement dire
- Un ensemble de code est semblable à une bibliothèque s'il fonctionne comme un ensemble de legos : divisible et conçu pour être assemblé. Bien qu'il puisse y avoir des exemples d'utilisation de la bibliothèque, il appartient généralement à l'utilisateur de l'assembler elle-même pour répondre à ses besoins.
- Un ensemble de code est semblable à un cadre s'il est non divisible et implique des conventions *: le fait de séparer des morceaux de celui-ci peut entraîner l'échec de nombreuses hypothèses. Vous devez donc comprendre l'utilisation conventionnelle pour pouvoir utiliser un cadre correctement.
C’est une ligne à la main, certes, mais j’aimerais tirer un point très intéressant sur les frameworks:
Les frameworks impliquent un ensemble de conventions d'interprétation du code; ils sont donc une langue à part entière.
C’est peut-être quelque chose que les gens veulent aussi discuter, mais si vous avez acheté ma définition précédente selon laquelle un langage n’est qu’un ensemble de conventions qui donnent vie à un bloc de texte, chaque fois que vous en établissez un nouveau calque, vous ' Nous avons construit un nouveau langage. Peut-être qu'avec les frameworks, les matériaux bruts sont les interprétations sémantiques de leur langage hôte au lieu de fichiers texte bruts, mais l'idée est la même!
Ceci dit, je suis tout à fait heureux d’appeler Node.js un framework, même s’il va un peu à l’encontre de la norme! Node.js ajoute des fonctionnalités au code JavaScript brut pour développer le langage . Avec cela apporte de nouvelles hypothèses et outils pour travailler dans cette langue étendue. Sur le plan fonctionnel, ces idées sont identiques à celles d'autres frameworks bien acceptés tels que Ruby on Rails .
Je dirais que si, en ce moment, vous vous sentez un peu mal à l'aise et que vous voulez affirmer qu'il y a un énorme fossé entre Ruby on Rails et Node.js dans ce sens, je suis bien sûr avec vous . Les types de mondes conceptuels dans lesquels vivent les deux sont radicalement différents - je veux simplement dire qu'ils sont du même genre: des ensembles de conventions pour étendre les pouvoirs d'un langage de base dans un domaine particulier.
Je suis également heureux de suggérer que le domaine de Node.js est petit et étroit et que les conventions qu'il ajoute sont simples à raisonner et relativement faciles à rendre correctes. OTOH, Ruby on Rails vit dans un domaine complexe et mal défini d’applications Web professionnelles, ce qui signifie que les conventions qu’il établit sont certainement floues et brisées.
Mais tout cela est un long chemin à dire, oui, les recruteurs n'ont probablement aucune idée de ce qu'ils veulent dire quand ils disent ça. J'imagine que "framework" sonne simplement comme un mot meilleur et plus acceptable que "runtime" ou "engine".