Quand les frameworks threadés sont-ils meilleurs que les frameworks événementiels ?(c'est-à-dire, quand les rails sont-ils meilleurs que node.js ?)

Question

Je comprends ce qu'est un framework threadé (Rails, Django, Symfony2, …).Et je comprends ce qu'est un framework événementiel (Node.js, EventMachine, Twisted, …) et pourquoi il est idéal pour le live, le chat, la vitesse, … De plus, ils ne semblent pas poser de problèmes pour les cas d'utilisation normaux.Donc:

• Quels sont les inconvénients des frameworks événementiels ?
• Quand dois-je préférer Rails à Node.js ?
• Pourquoi tous les nouveaux serveurs Web ne sont-ils pas écrits avec EventMachine, Twisted ou Node.js ?
• Des frameworks célèbres tels que Django ou Rails deviendront-ils pilotés par les événements ou mourront-ils ?

Answer 1

Alors, où sont les inconvénients des frameworks événementiels ?

1. Familiarité. La programmation Web événementielle étant si différente, il faudra un certain temps avant que les programmeurs s'y sentent à l'aise.Lorsque vous travaillez sur un délai, il est plus facile d’utiliser ce que vous savez et qui fonctionne.
2. Prise en charge de la bibliothèque. Node possède un nombre incroyable de modules, mais il lui reste encore un long chemin à parcourir pour rattraper Ruby et Python.. Mise à jour: Node propose désormais plus de modules publiés que Python ou Ruby.
3. Déploiement. Le personnel informatique est habitué aux frameworks threadés.Pour profiter des frameworks basés sur les événements, vous devrez être asynchrone de haut en bas.À l’heure actuelle, vous pouvez développer avec Node.js, mais serez-vous capable de le déployer efficacement ou devrez-vous administrer vos propres serveurs ?
4. Des inquiétudes infondées. Des choses qui semblent être des problèmes, mais qui ne le sont pas vraiment :
   • La programmation événementielle est mauvaise pour les applications gourmandes en CPU:La raison étant qu’un calcul gourmand en CPU bloquerait le serveur.C'est strictement vrai, mais en pratique, cela peut être surmonté en générant un autre processus et en le traitant comme une E/S, par exemple en utilisant le protocole Node. child_process.exec.
   • La programmation événementielle est réservée aux applications nécessitant une simultanéité élevée:La raison ici est que la programmation événementielle est « plus difficile » que la programmation d’applications Web traditionnelle, cela ne vaut donc pas la peine de le faire à moins d’avoir une bonne raison de le faire.Personnellement, je ne pense pas que ce soit le cas : la programmation événementielle n'est pas plus difficile, mais elle l'est. très différent.À un moment donné, une masse critique de programmeurs sera familiarisée avec l’approche événementielle et cette préoccupation disparaîtra.
   • La programmation événementielle est un fouillis de rappels imbriqués. Cela peut être vrai lorsque vous l’apprenez pour la première fois, mais vous découvrirez éventuellement comment structurer votre code de manière lisible.
5. Documentation. La documentation de Node et de ses bibliothèques tierces est épouvantable et ne consiste généralement en rien de plus qu'un README.md.Venant du monde Python, où nous sommes habitués à une excellente documentation, c'est un gros inconvénient.Cela s'améliore lentement (nous avons besoin de plus de documentation comme ça).

Quand dois-je préférer Rails à Node.js ?

• Lorsque vous ou votre équipe préférez Ruby à JavaScript.
• Lorsque vous ou votre équipe n'êtes pas familier avec Node et que vous devez faire le travail.
• Lorsque vous devez utiliser des fonctionnalités de Rails que Node n'a pas encore.
• Lorsque vous devez déployer sur une infrastructure Rails existante.
• Lorsque vous devez convaincre la direction que vous devez utiliser Node.js, mais que vous ne voulez pas être celui qui prend la responsabilité si le projet échoue.

Pourquoi tous les nouveaux serveurs Web ne sont pas écrits avec EventMachine, Twisted ou Node.js ?

Voir au dessus.

Des frameworks célèbres comme Django ou Rails deviendront-ils événementiels ou mourront-ils ?

Django et Rails existeront encore longtemps.Il existe de nombreuses applications dans ces frameworks et il n’y a aucune raison de les réécrire.Et il existe un vaste vivier de talents, ce qui est souvent pris en compte lors du développement d’une nouvelle application Web.

(Mais voyez cette réponse de Quora du développeur principal de Django, approuvant Node).