Qu'est-ce qui est si unique à propos de Node.js? [fermé]


48

Récemment, il y a eu beaucoup d'éloges pour Node.js. Je ne suis pas un développeur qui a beaucoup été exposé aux applications réseau. D'après ma compréhension même de Nodes.js, sa force est la suivante: nous avons un seul thread qui gère plusieurs connexions et fournit une architecture basée sur des événements.

Cependant, par exemple en Java, je ne peux créer qu'un seul thread à l'aide de NIO / AIO (ce qui est une API non bloquante de ma compréhension), et gérer plusieurs connexions à l'aide de ce thread, et je fournis une architecture basée sur les événements pour implémenter les données. logique de traitement (ne devrait pas être aussi difficile en fournissant un rappel, etc.)?

Etant donné que la machine virtuelle Java est une machine virtuelle encore plus mature que la version 8 (je pense qu’elle sera également plus rapide), et que l’architecture de gestion basée sur les événements ne semble pas difficile à créer, je ne sais pas pourquoi Node.js attire autant l’attention. Ai-je oublié des points importants?


3
Je me demande pourquoi cela a fait l'objet d'un vote négatif ... Je pense que cette question est davantage une discussion de programmation que je n'ai pas mise en stackoverflow. J'ai également essayé de rechercher des sujets similaires, mais je n'ai trouvé que des informations sur la force de Nodes.js mais mon problème est que je ne comprends pas vraiment pourquoi la "force" est si unique (que je ne trouve toujours pas)
Adrian Shum

6
Essayez d'implémenter ce modèle en Java. Cela fonctionne, bien sûr. Mais vous verrez une chose: en Java, ce sera très très verbeux: vous avez besoin de tonnes de callbacks, ce qui signifie presque toujours la création de nouvelles classes. Cela peut paraître minime, mais dans un gros programme, cela peut devenir très vite moche et trop lourd.
Joachim Sauer

6
Les callbacks Javascript sont tout aussi susceptibles de devenir encombrants - et de tels spaghettis sont beaucoup plus faciles à déboguer et à refactoriser en Java qu'en Javascript IMO.
Funkybro

5
@AdrianShum: c'est un effet de barre oblique, tout ce qui ne correspond pas à l'état d'esprit du groupe sera rejeté - comme l'éloge de Microsoft sur /.
gbjbaanb

3
Je suis surpris de ne voir personne parler du battage médiatique.
deadalnix

Réponses:


33

Bien que ce concept puisse effectivement être implémenté dans de nombreuses langues (et, comme le dit dodgy_coder , il a été implémenté au moins en Ruby et Python), ce n’est pas aussi trivial que vous le dites.

Certes, Java possède des API IO non bloquantes. Ainsi, vous pouvez effectuer des E / S de réseau / disque brutes de manière non bloquante. Cependant, chaque API qui encapsule ou gère les E / S doit être implémentée de manière non bloquante. Chaque analyseur XML, chaque pilote de base de données, chaque convertisseur de format de fichier doit être écrit pour prendre en charge les E / S non bloquantes. En effet, si une seule bibliothèque bloque ce modèle, les performances de votre serveur seront alors dégradées.

Node.js possède cette infrastructure de bibliothèque, car elle a toujours été conçue de cette façon: chaque bibliothèque qui s'efforce de devenir populaire doit fournir une API asynchrone sinon elle ne sera pas utilisée.


18
Oui. En d’autres termes: la plus grande force de Node.js est la faiblesse la plus importante d’ECMAScript: la bibliothèque standard ECMAScript incroyablement moche. Comme les développeurs de Node.js devaient de toute façon réinventer chaque roue, ils ont eu la chance de le réinventer de la bonne façon.
Jörg W Mittag le

4
Pour autant que je sache, ECMAScript a toujours été conçu comme un langage intégré, de sorte qu'il n'était pas nécessaire d'utiliser une API de niveau système (même les E / S réseau étaient abstraites). Ce manque était en effet un avantage pour Node.js.
Joachim Sauer le

"chaque bibliothèque qui s'efforce de devenir populaire doit fournir une API asynchrone ou elle ne sera pas utilisée" Je pense que c'est précisément ce que je recherche. Existe-t-il une ressource à examiner pour savoir comment une api asynchrone est fournie, par exemple, l'analyse XML et l'accès à la base de données, dans Node.js?
Adrian Shum

1
@AdrianShum en général, recherchez des exemples de programmation événementielle. Des implémentations spécifiques sont disponibles dans de nombreuses langues. Outre les modules Node.js, vous pouvez consulter des exemples Twisted en Python, twistedmatrix.com/trac/wiki , des exemples POE en Perl, poe.perl.org , et Ruby sous EventMachine, github.com/eventmachine/eventmachine
mghicks

19

La raison principale en est probablement qu’elle utilise JavaScript pour écrire des composants côté serveur pour des éléments tels que des serveurs Web, des applications Web ou des services Web. Cela unifie le JavaScript JavaScript du langage de développement frontal traditionnel (côté client) avec le langage côté serveur.

Vous avez raison - le fait qu'il soit non bloquant, l'utilisation du schéma de réacteur ne soit pas unique - cela a déjà été fait avant d'utiliser d'autres langages et structures, comme Ruby's EventMachine ou Python's Twisted, par exemple.


5
très peu de technologies ont des fonctionnalités vraiment uniques, la particularité vient de la combinaison particulière de toutes leurs fonctionnalités
jk.

1
D'accord, il y a ici une liste de bibliothèques qui le supportent dans toutes les langues principales ... Modèle de réacteur sur Wikipedia
dodgy_coder

10

Les trois principales raisons que je donnerais sont:

  1. Entrées / Sorties asynchrones non bloquantes. Ceci est haché partout sur le Web et dans les affiches précédentes. Une des choses à laquelle je contribuerais est que la conception de votre code pour assumer explicitement les comportements asynchrones aide le moteur du compilateur à optimiser le matériel. Oui, de nombreux compilateurs JIT et processeurs hyperthreading utilisent un code synchrone et aident à paralléliser l'exécution. Ceci est bien sûr une approche de meilleur effort. En revanche, si vous construisez explicitement l'application pour async io, vous vous assurez que le moteur et le matériel peuvent optimiser le temps d'exécution de votre code. Certes, je n'ai pas de données quantifiables pour le prouver, mais cela me fait chaud au cœur de penser de cette façon.

  2. Base de code unique pour le client et le serveur. Cela présente un certain nombre d'avantages: aider à optimiser les coûts du centre de données en permettant de déplacer la logique métier du serveur vers le client; aider à réutiliser la logique métier / validation des données; réduire la complexité des compétences nécessaires aux développeurs pour prendre en charge le produit (par rapport à Python et javascript).

  3. Faible barrière à l'entrée. À bien des égards, Javascirpt ressemble à Basic, Pascal et Perl d’année précédente. Il est très facile de commencer à écrire du code et ne nécessite pas beaucoup de connaissances de domaine pour commencer. Cela vous permet également de réduire vos coûts de développement en pouvant faire appel à plus de développeurs débutants et en accélérant la mise en place d'un projet. [Bien sûr, vous devez dépasser les idéologues qui croient que les langages de programmation devraient être difficiles pour éliminer les développeurs qui fonctionnent mal]


Je ne suis pas sûr que je recommanderais de construire une équipe de nœuds entièrement avec jr. JS devs. L'architecture n'est pas vraiment une chose à laquelle nous devons penser dans les projets Web / d'interface utilisateur de niveau junior et JS met autant de temps à devenir vraiment performant en termes de construction sur le long terme que n'importe quelle autre langue, même si vous pouvez obtenir des résultats relatifs. rapide à un niveau d’expérience inférieur sur des projets moins complexes que la moyenne.
Erik Reppen

Je suis d'accord avec @ErikReppen; une équipe d'architectes entièrement composée de jeunes développeurs (quelle que soit la langue) revient à concevoir et à construire une maison entièrement à l'aide de charpentiers qui savent bien construire des chaises, des tables et des niches pour chiens.
Wildcard
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.