Node.js est-il un framework?
Je continue de voir des recruteurs, des développeurs, etc. se référer à Node.js comme un framework. À mon avis, c'est par ignorance de ce qu'est vraiment Node.js.
Souvent, dans les descriptions de travail, Node.js est regroupé en tant que bibliothèque parmi AngularJS , React , etc. En général, je le vois comme étant entré par quelqu'un qui ne le fait pas connaître la différence (RH, recruteur, etc.).
À mon avis, Node.js est une plate-forme , ou un environnement d'exécution; il remplace l'API DOM (JavaScript dans le navigateur) pour diverses autres API, comme le système de fichiers (car il s'exécute en tant que serveur, et non dans le navigateur).
Pourquoi est-ce que les gens pensent que Node.js est un framework; ai-je tort? Est-ce en fait un cadre?
C'est un peu difficile à dire car ces mots ne sont pas bien définis. Dans le langage courant, je pense que c'est un peu atypique d'appeler Node.js un framework, bien sûr, mais j'aurais du mal à expliquer pourquoi ce n'est pas le cas.
Tout cela devient risqué, et je vois souvent de très mauvaises utilisations du langage, donc je vais être explicite et commencer par le bas
JavaScript est un langage informatique, c'est-à-dire, de façon étroite, un ensemble de conventions qui nous permettent de lire et d'interpréter un tas de texte comme ayant sémantique d'exécution - un mot de fantaisie pour "façon d'interpréter la langue comme un ensemble d'instructions ". Classes de programmes appelées interprètes, compilateurs, transpilers, linters, highlighters, etc. tous prennent du texte et tentent de faire quelque chose avec cette compréhension conventionnelle de la façon d'exécuter le code.
- Interprètes en fait effectuez la sémantique d'exécution en faisant fonctionner une machine - généralement votre ordinateur. Vous pouvez les considérer comme un petit homme à l'intérieur de votre ordinateur, en basculant les commutateurs comme "imprimer ce caractère" en fonction des instructions écrites dans votre programme JavaScript.
- Les compilateurs essaient de convertir le texte JavaScript en un nouvel ensemble de texte qui a une sémantique d'exécution pour un autre langage - peut-être avec la propriété spéciale que les ordinateurs peuvent directement l'exécuter.
- Les transpilers sont une forme généralisée de compilateur dans la mesure où ils prennent du texte JavaScript et produisent du texte dans une autre langue. La différence est donc un peu subjective, mais généralement on pense à un compilateur comme sortant code de très bas niveau et à un transpilateur comme sortant de haut niveau du code.
- Linters , surligneurs , type les contrôleurs , etc. prennent tous du texte JavaScript et produisent une sorte de produit analytique, du texte en surbrillance, par exemple, qui est influencé par la sémantique d'exécution, mais pas réellement représentatif de celui-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 d'arriver à une description d'une machine abstraite ou une description des effets secondaires observables. Ce que je voudrais suggérer, c'est que les deux supposent la nécessité d'une sorte d '"API de bas niveau", soit pour faire fonctionner la machine, soit pour effectuer les effets observables. Ceux-ci sont généralement considérés comme faisant partie de l'environnement runtime
- L'environnement d'exécution ou l'environnement d'exécution est un ensemble de primitives supposées que le langage convention doit exister pour fonctionner. En ce qui concerne la langue, il peut y avoir 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 de l'exécution - il ne peut pas inspecter personnellement ce qu'ils font.
Le mot runtime est généralement utilisé abusivement pour désigner à la fois l'ensemble des primitives supposées elles-mêmes et une réelle instanciation de celles-ci.
Donc, maintenant nous arrivons à quelque chose de velu. 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 les sonde jamais" car ils sont hors de portée.
Pour réellement utiliser une langue, vous voulez quelque chose comme un compilateur ou un interpréteur à côté d'une implémentation d'exécution. Le compilateur/interprète et ce runtime vont de pair en fait en cours d'exécution votre code.
- Chrome's V8, souvent appelé un moteur, est un package contenant un interprète, compilateur, implémentation d'exécution compatible avec l'interface d'exécution exigée par les conventions JavaScript standard de l'ECMA.
Alors, où Node.js s'inscrit-il dans tout cela?
Nous devons le diviser en plusieurs parties:
- Node.js étend le langage JavaScript en fournissant un plus grand ensemble de primitives d'environnement d'exécution - celles qui sortent du cadre des normes ECMA. Cela inclut des choses comme E/S de fichiers. Cela signifie que Node.js change la langue et est en quelque sorte une nouvelle langue: "Node.js JavaScript"
- Node.js, en tant que package, contient un interpréteur et un compilateur. Il les vole juste de V8.
- Node.js fournit une implémentation de l'environnement d'exécution Node.js qui permet d'exécuter "Node.js JavaScript".
- Node.js fournit un ensemble de bibliothèques standard construites au-dessus des nouvelles primitives qui les rendent 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'effondre totalement - personne n'a une bonne définition cohérente et significative de ce qu'est réellement un cadre.
Il y a des débats qui font rage: "qu'est-ce qu'un framework versus une bibliothèque" et ils se terminent sur des choses insatisfaisantes comme "une bibliothèque est quelque chose que vous appelez et un framework 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 JavaScript Node.js en particulier, est un coup énorme pour cette définition car toute la technique de rappel signifie que vous êtes constamment basculer entre appeler et être appelé.
À mon avis personnel, il y a quelque chose de substantiel ici. Je ne veux pas tracer de ligne claire, mais je vais simplement dire
- Un ensemble de code ressemble à une bibliothèque s'il fonctionne comme un ensemble de legos: divisible et conçu pour l'assemblage. Bien qu'il puisse y avoir quelques exemples d'utilisation de la bibliothèque, c'est généralement à l'utilisateur lui-même de l'assembler en fonction de ses besoins.
- Un ensemble de code est semblable à un framework s'il n'est pas divisible et implique des conventions *: en séparer des morceaux peut entraîner l'échec de nombreuses hypothèses, vous devez donc comprendre utilisation conventionnelle pour utiliser un cadre correctement.
C'est une ligne ondulée à la main, bien sûr, mais je veux tirer un point vraiment intéressant sur les cadres:
Les cadres impliquent un ensemble de conventions sur la façon d'interpréter le code; ils sont donc une langue à part entière.
Cela pourrait être quelque chose sur lequel les gens veulent discuter, mais si vous avez acheté ma définition précédente qu'une langue n'est qu'un ensemble de conventions qui donnent vie à un bloc de texte, alors chaque fois que vous définissez une nouvelle couche de conventions, vous '' ai construit une nouvelle langue. Avec les frameworks, les matières premières sont peut-être les interprétations sémantiques de leur langage hôte au lieu des fichiers texte bruts, mais l'idée est la même!
Donc, avec tout cela, je suis totalement heureux d'appeler Node.js un framework même si cela va un peu à l'encontre de la norme! Node.js ajoute des fonctionnalités au JavaScript brut à la manière de étendre la langue. Il apporte de nouvelles hypothèses et de nouveaux outils pour travailler dans ce langage étendu. Fonctionnellement, ces idées sont les mêmes que celles d'autres cadres bien acceptés comme Ruby on Rails .
Je dirais que si en ce moment vous vous sentez un peu mal à l'aise et que vous voulez faire valoir qu'il existe un énorme fossé entre Ruby on Rails et Node.js dans ce chemin des choses alors Je suis là avec vous, bien sûr. Le genre de mondes conceptuels dans lesquels les deux vivent sont dramatiquement différents - Je veux simplement pour dire qu'ils sont le même genre de chose: des ensembles de conventions pour étendre les pouvoirs d'une langue de base dans un domaine particulier.
Je suis également heureux de suggérer que le domaine de Node.js est petit et serré et donc les conventions qu'il ajoute sont simples à raisonner et relativement faciles à corriger. OTOH, Ruby on Rails vit dans un domaine complexe et mal défini "d'applications Web d'entreprise"), ce qui signifie que les conventions qu'il établit sont certainement floues et brisées.
Mais tout cela est une longue façon de dire, oui, les recruteurs n'ont probablement aucune idée de ce qu'ils veulent dire quand ils disent cela. Je suppose que "framework" sonne juste comme un meilleur mot, plus grokkable que "runtime" ou "engine".
Node.js® est un runtime JavaScript basé sur le moteur JavaScript V8 de Chrome.
Le nœud est un environnement d'exécution ou. Ce n'est pas un cadre. Les gens (je pense) se trompent souvent parce que les frameworks comme express sont omniprésents avec le nœud.
plus de lecture sur les temps d'exécution vs les frameworks si vous êtes intéressé.