En quoi Node.js est-il différent des autres frameworks côté serveur?

J'ai remarqué que Node.js est devenu très populaire, et j'ai vu plusieurs cas de personnes y faire des projets à petite échelle.

J'ai également examiné les listes des avantages et des inconvénients pour avoir une idée de ce que Node.js peut faire, mais je ne sais toujours pas en quoi il diffère des autres technologies côté serveur plus matures comme PHP, Perl ou Ruby. Rails.

Qu'est-ce qui différencie spécifiquement Node.js des alternatives actuelles et pourquoi?

web-development comparison node.js

— Saeed Neamati
source

@downvoter - pourquoi le downvote? sauf pour le deuxième paragragh (vous ne pouvez pas vraiment demander pourquoi commencer quelque chose quand quelqu'un d'autre l'a fait parce que vous pourriez toujours le faire mieux), je trouve cette question intrigante. J'ai souvent pensé cela moi-même.

— David Peterman,

C'est un peu mineur à choisir, mais si vous recherchez sur Google l' expression "node.js", vous obtenez environ 3 millions de visites.

— Peter Rowell

@Peter, ouais, j'ai essayé, et tu as raison. Mais 3 millions, c'est encore deux de beaucoup. Vous pouvez revenir un an plus tard, et ce chiffre est probablement passé à 10 millions. :)

— Saeed Neamati

@Mark, merci pour le montage exceptionnel. C'est plus clair maintenant.

— Saeed Neamati

Réponses:

Il y a deux choses importantes qui différencient Node.js des frameworks côté serveur existants, les événements asynchrones et l'utilisation de JavaScript comme langage de programmation.

Événements asynchrones

Alors que la plupart des infrastructures côté serveur existantes utilisent une architecture synchrone, Node.js utilise une architecture asynchrone , que JavaScript peut bien gérer. Cela signifie que le serveur réagit aux événements et envoie par exemple des événements (messages) à la base de données. Ce style de programmation est très différent d'un style synchrone et peut être difficile à utiliser avec d'autres langages. Node.js utilise un style asynchrone avec des E / S asynchrones et peut bien évoluer.

Voir aussi Architecture pilotée par les événements

Javascript

JavaScript est le langage de programmation utilisé par les applications Web sur le client. L'utilisation du même langage côté serveur signifie que le développeur peut appliquer ses connaissances JavaScript à la fois sur le client et sur le serveur, et utiliser les mêmes fonctions que nécessaire.

Je recommanderais la présentation Introduction à Node.js avec Ryan Dahl où il explique plus en détail l'architecture événementielle de Node.js.

— Jonas
source

C'est facilement la meilleure réponse jusqu'à présent, mais je mettrais d'abord les événements asynchromes, car c'est vraiment ce qui rend Node.js si attrayant en tant que cadre côté serveur. Bon travail cependant, mentionnant les E / S asynchrones et l'évolutivité. C'est ça le cœur.

— Adam Crossland

Eh bien @Jonas, je ne comprends toujours pas. ASP.NET est également basé sur des événements. Quelle est alors la différence entre Node.js et ASP.NET? Est-ce uniquement parce qu'il est asynchrone? Dans ce cas, je pense que l'utilisation du multi-threading dans ASP.NET peut faire la même chose, n'est-ce pas?

— Saeed Neamati

@Saeed: ASP.NET est fileté et synchrone, par exemple lors de l'accès à la base de données, le thread est bloqué et attend une réponse de la base de données. Et lorsque vous utilisez de nombreux threads (par exemple un par requête), une grande quantité de mémoire est utilisée (chaque thread a besoin d'une quantité de mémoire assez importante), ce qui peut être un goulot d'étranglement. Node.js envoie des messages et réagit aux événements, il ne bloque donc jamais (espérons-le) le thread. Avec node.js, vous utilisez le même modèle de programmation que du côté client avec Ajax ( javascript asynchrone et XML) et le même langage.

— Jonas

Vous avez oublié la grande communauté open source derrière elle.

— Raynos

Lorsque C # 5 roule avec les nouveaux asynctrucs, cela peut changer. Le problème n'est pas que vous ne pouvez pas écrire de code asynchrone évolutif dans d'autres langues, c'est qu'il est plus difficile de le faire (correctement) sans une bonne prise en charge du niveau de langue.

— Davy8

Son diffrent parce que son événementiel . Cela rend le serveur hautement évolutif.

En un mot;

Modèle de fil

Le client demande quelque chose
Le serveur s'éteint et traite la demande
Le redonne au client
Prêt à traiter une nouvelle demande

Modèle d'événement

Le client demande quelque chose
Le serveur transmet la demande de traitement. Prêt à traiter une nouvelle demande
Le serveur traite plus de demandes à mesure qu'elles arrivent
Le serveur rend les données au client lorsque le traitement de la demande est terminé

— Tom Squires
source

@Tom, que voulez-vous dire par événementiel? ASP.NET WebForms est également piloté par événements et vous pouvez voir des gestionnaires comme Session_Startedou Context_Authenticatedou Page_Load?

— Saeed Neamati

L'appeler piloté par les événements est plus ambigu qu'il n'est nécessaire et ne va pas vraiment au cœur de Node.JS: les E / S asynchrones.

— Adam Crossland

J'ai eu l'impression que sa popularité était due à l'utilisation de JavaScript. Étant donné que de nombreux développeurs Web connaissent JavaScript, c'est un argument de vente qu'ils peuvent désormais développer du code côté serveur en utilisant le même langage. Cela présente quelques avantages auxquels je peux penser:

Les fichiers de code peuvent être partagés entre le serveur et le client, empêchant la duplication des efforts uniquement pour gérer les deux côtés du système.
Les développeurs n'ont pas besoin de basculer mentalement entre les langues. (pas un gros problème à mon avis)
Les architectes n'ont pas besoin de choisir plusieurs langues lors de l'architecture d'une solution Web.
Quelqu'un qui n'a jamais développé de code côté serveur peut désormais le faire sans apprendre une autre langue. (Pas susceptible d'être un argument valable, à mon humble avis)

— John Fisher
source

Node.JS est populaire car il est rapide et évolue bien. Que ce soit en JavaScript est agréable, mais largement accessoire.

— Adam Crossland,

Ce qui est plus précieux, c'est que les développeurs côté serveur peuvent écrire du code côté client dans le même langage et que vous pouvez partager des modules côté serveur avec le client. Pas l'inverse. Je ne voudrais pas porter le code client piraté sur le serveur, c'est vous tirer une balle dans le pied.

— Raynos

@Adam: Pourquoi node.js devient-il populaire alors qu'il existe déjà des technologies qui correspondent à la description "rapide et évolue bien"? - Parce que c'est JavaScript.

— John Fisher

@John Il est plus difficile d'écrire des applications qui n'évoluent pas bien dans Node.js. Si votre application est gourmande en disque / réseau plutôt qu'en CPU (la plupart le sont), vous pouvez facilement prendre en charge plusieurs fois plus de connexions simultanées sur un seul cœur que la plupart des autres serveurs, sauf si vous écrivez du code de threading très délicat.

— Davy8

@ Davy8: Je suppose que tout dépend des autres frameworks / systèmes que vous avez utilisés. La facilité d'évolutivité que vous décrivez est déjà simple avec les outils que j'utilise. La seule chose que Node.js offre de mon point de vue est la saveur JavaScript, qui n'est pas convaincante.

— John Fisher