Wann sind Framework-Threads besser als ereignisgesteuerte Frameworks? (d. h. wann sind Schienen besser als node.js?)

  

Wo sind die Nachteile von ereignisgesteuerten Frameworks?

1. Vertrautheit. Da die ereignisgesteuerte Webprogrammierung so anders ist, wird es eine Weile dauern, bis die Programmierer damit vertraut sind. Wenn Sie an einer Frist arbeiten, ist es einfacher zu verwenden, was Sie wissen, das funktioniert.
2. Bibliotheksunterstützung. Knoten hat eine erstaunliche Anzahl von Modulen, aber es ist noch ein weiter Weg bis zu Ruby und Python . Update: Knoten verfügt jetzt über mehr veröffentlichte Module als Python oder Ruby .
3. Bereitstellung. IT-Mitarbeiter sind an Framework-Threads gewöhnt. Wenn Sie ereignisgesteuerte Frameworks nutzen möchten, sollten Sie asynchron von oben nach unten vorgehen. Jetzt können Sie in Node.js entwickeln, aber können Sie es effektiv bereitstellen, oder müssen Sie Ihre eigenen Server verwalten?
4. Unbegründete Bedenken. Dinge, die wie Probleme erscheinen, aber nicht wirklich:
   • Ereignisgesteuerte Programmierung ist schlecht für CPU-intensive Anwendungen : Der Grund dafür ist, dass eine CPU-intensive Berechnung den Server blockieren würde. Dies ist strikt richtig, aber praktisch wird es dadurch überwunden, dass ein anderer Prozess erzeugt und als I / O behandelt wird, zum Beispiel durch Verwendung von Nodes child_process.exec .
   • Event-driven Programmierung ist nur für Anwendungen, die hohe Parallelität benötigen : Der Grund hier ist, dass ereignisgesteuerte Programmierung ist "härter" als herkömmliche Web-App-Programmierung, so dass es nicht wert ist, wenn Sie einen triftigen Grund haben zu. Ich persönlich denke nicht, dass dies der Fall ist - Event-Driven-Programmierung ist nicht schwieriger, aber es ist sehr anders. Irgendwann wird eine kritische Masse von Programmierern mit dem ereignisgesteuerten Ansatz vertraut sein und diese Sorge wird verschwinden.
   • Die ereignisgesteuerte Programmierung ist eine Verschwendung von verschachtelten Callbacks. Das mag wahr sein, wenn Sie es zum ersten Mal lernen, aber schließlich werden Sie herausfinden, wie Sie Ihren Code lesbar strukturieren können.
5. Dokumentation. Die Dokumentation für Node und die Bibliotheken von Drittanbietern ist schrecklich und besteht normalerweise nur aus einem README.md . Aus der Python-Welt kommend, wo wir eine hervorragende Dokumentation gewohnt sind, ist dies ein großer Nachteil. Das wird langsam besser (wir brauchen mehr Dokumentation so ).

  

Wann sollte ich Rails Node.js vorziehen?

• Wenn Sie oder Ihr Team Ruby gegenüber JavaScript bevorzugen.
• Wenn Sie oder Ihr Team mit Node nicht vertraut sind und Sie die Aufgabe erledigen müssen.
• Wenn Sie Funktionen verwenden müssen, die Rails in diesem Knoten noch nicht hat.
• Wenn Sie eine Bereitstellung in einer vorhandenen Rails-basierten Infrastruktur durchführen müssen.
• Wenn Sie das Management davon überzeugen müssen, dass Sie Node.js verwenden sollen, aber Sie nicht derjenige sein wollen, der den Fehler beseitigt, wenn das Projekt fehlschlägt.

  

Warum werden alle neuen Webserver nicht mit EventMachine, Twisted oder Node.js geschrieben?

Siehe oben.

  Werden berühmte Rahmen wie Django oder Rails ereignisgesteuert oder sterben?

Django und Rails werden eine lange Zeit sein. In diesen Frameworks gibt es viele Apps, und es gibt keinen Grund, sie neu zu schreiben. Und es gibt einen großen Talentpool, der oft bei der Entwicklung einer neuen Web-App berücksichtigt wird.

(Aber siehe diese Quora-Antwort vom führenden Entwickler von Django, der Node unterstützt).