Node.js est-il un framework? [fermé]

35

Je continue à voir des recruteurs, des développeurs, etc. se référer à Node.js comme un framework. À mon avis, c'est par ignorance de ce que Node.js est réellement.

Souvent, dans les descriptions de travail, Node.js est regroupé en tant que bibliothèque entre AngularJS , React , etc. En général, je le vois comme étant entré par quelqu'un qui ne connaît pas la différence (RH, un 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) de diverses autres API, telles que le système de fichiers (car il fonctionne en tant que serveur et non dans le navigateur).

Pourquoi les gens pensent-ils que Node.js est un framework? ai-je tort? Est-ce réellement un cadre?

ndugger
la source
5
Pas particulièrement, mais je pouvais voir la confusion.
Ndugger
1
Il y a longtemps, lorsque le nœud est sorti pour la première fois, j'ai posté sur SO une réponse disant que ce nœud n'était pas un framework. Cette réponse a été extrêmement réduite à l'époque. Aujourd'hui, très très peu de personnes utilisant un nœud pensent qu'il s'agit d'un framework. C'est un cadre dans le même sens que Swift est un cadre ou Go est un cadre ou Rust est un cadre. Les langages de programmation modernes ont simplement des API de très haut niveau qui étaient implémentées en tant que framework. "Plate-forme" est un bon mot. Je dirais que c'est moi-même un interprète (en utilisant le sens unix traditionnel de ce mot)
slebetman
Notez que ce noeud ne remplace pas l'API DOM et que tout ce que vous pouvez exécuter avec JavaScript est toujours disponible, avec ou sans noeud.
Rob
@slebetman Quel est le "autre" sens de l'interprète? Je n'avais pas réalisé qu'il y avait aussi un débat! : S
J. Abrahamson

Réponses:

44

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:

  1. 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"
  2. Node.js, en tant que package, contient un interpréteur et un compilateur. Il vole juste ces de V8.
  3. Node.js fournit une implémentation de l'environnement d'exécution Node.js qui permet l' exécution de "Node.js JavaScript".
  4. 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".

J. Abrahamson
la source
hé, remarquablement équilibré! donc, probably have no idea"framework" est un mot que vous pouvez comprendre sans être un programmeur, une fonctionnalité utile, même si elle est épargnée car cela ferait réellement une différence.
n611x007
"Node.js ajoute des fonctionnalités au code JavaScript brut pour étendre le langage." Ce n'est pas vrai, il s'agit de développer des fonctionnalités et non le langage. Cela ne change en rien la façon dont vous avez besoin d'écrire du code comme le demandent de nombreux frameworks. Il existe d'autres fonctions ou objets ajoutés, comme peut l'ajouter une bibliothèque incluse. Vous pouvez l'appeler ou l'utiliser comme n'importe quelle nouvelle fonction ou nouvel objet. Le style de programmation ne change pas, les bases de la langue sont les mêmes, mais ajoutent quelques fonctionnalités. Il ne s’agit donc pas d’un framework ni d’une extension du langage, javascript avec des bibliothèques de plate-forme par défaut ajoutées et donc des fonctionnalités.
Codebeat le
Bien sûr, je peux complètement suivre votre côté. Je pense que la ligne est floue. Les deux façons de penser ont du sens. En tant que point strict, le noeud développe JS en fournissant une FFI, qui est ensuite la pièce maîtresse qui permet au noeud de fournir ultérieurement davantage de bibliothèques système. D'un autre côté, alors que le nœud "principal" n'est que l'exécution (et ce FFI), la plupart du temps, lorsque les gens discutent d'un nœud, ils veulent en réalité dire "le cœur de l'exécution, les extensions FFI et les fonctionnalités de bibliothèque de base construites au-dessus", est comment le noeud est empaqueté.
J. Abrahamson
20

Node.js® est un moteur d'exécution JavaScript basé sur le moteur JavaScript V8 de Chrome.

la source

Le nœud est un environnement d'exécution ou un environnement. Ce n'est pas un cadre. Les gens (je pense) se trompent souvent parce que les frameworks comme express sont omniprésents avec node.

plus de lecture sur les runtimes vs frameworks si vous êtes intéressé.

rlemon
la source
inb4 "mais la page à propos dit" En tant que cadre piloté par les événements asynchrones "" Je suis au courant.
Rendez-vous
3
La v8 intégrée n'est-elle pas le moteur d'exécution? ;-)
johannes
@johannes Je suis enclin à être d'accord avec vous sur ce point. La V8 est le moteur d’exécution et le nœud étend simplement les outils à la disposition du développeur (serveur http, util, etc.). Je pense donc que l’étiquette-cadre fonctionne toujours. Pourtant, il s’agit d’un environnement v8 modifié; Le noeud n'est pas quelque chose que vous "incluez" dans votre projet. Tout est une question de perspective, je suppose.
Nick
@rlemon, la structure de la pièce a été supprimée.
ebram khalil