Gibt es einen guten Grund, node.js für Nicht-Echtzeit-Webanwendungen zu vermeiden?

Ich habe viel darüber geredet, wie großartig Node.js für Echtzeit-Web-Apps ist - Dinge, die Sockets, Comet, AJAX-lastige Kommunikation und so weiter benötigen. Ich weiß, dass das ereignisgesteuerte, asynchrone, threadgesteuerte Modell auch für Parallelität mit geringem Overhead geeignet ist.

Ich habe auch Node.js Tutorials für einfachere, "traditionelle" Nicht-Echtzeit-Apps gesehen (z. B. das Standard-Blog-Beispiel, das anscheinend der Standard "Hello World" für Leute ist, die die App-Entwicklung lernen). Und ich weiß auch, dass Sie mit node-static statische Assets bedienen können.

Meine Frage lautet: Gibt es einen guten Grund, Node.js für herkömmliche Web-Apps wie Kleinanzeigen, Foren, das oben genannte Blog-Beispiel oder die Art von CRUD-Apps, die Sie für interne Geschäftsanwendungen erstellen, zu vermeiden ? Nur weil es all die funky Echtzeit-Sachen übertrifft, ist das für einen eher gewissenhaften Gebrauch kontraindiziert?

Das einzige, woran ich denken kann, ist der Mangel an ausgereiften Bibliotheken (obwohl sich das ändert).

(Der Grund, den ich frage, ist, dass ich in Erwägung ziehe, PHP für Node.js aufzugeben, um die Impedanzinkongruenz beim Umschalten zwischen Sprachen zu überwinden, aber auch, damit ich Validierungscode und so weiter wiederverwenden kann. Mein Überich ermahnt mich, den zu wählen Das beste Tool für diesen Job , aber ich habe nicht viel Zeit, um fünfzehn Sprachen und all ihre Userland-Bibliotheken zu lernen, nur um ein umfassendes Arsenal zu haben. Es ist auch beruhigend, dass mir Node.js einen einfacheren Optimierungspfad bietet als PHP / Apache in der Zukunft, wenn ich anfangen muss, über starken Verkehr nachzudenken.)

[EDIT] Vielen Dank für die bisherigen Antworten, Leute; Ich möchte nur sehen, ob sich noch jemand anmeldet, bevor ich eine Antwort wähle. Die Antwort von @Raynos bestätigt irgendwie, was ich denke, und die Links von den Kommentatoren boten gute Denkanstöße, aber ich möchte sehen, ob jemand andere knotenspezifische Antworten hat, wie "KEIN NODE FÜR PROBLEM X VERWENDEN" '. (Neben Aufgaben mit hoher CPU, das weiß ich schon :-)

Gibt es einen guten Grund, Node.js für herkömmliche Webanwendungen zu meiden?

Ja, wenn Sie N Jahre Erfahrung mit Webplattform X haben, können Sie eine Anwendung auf Plattform X deutlich schneller entwickeln.

Wenn Sie Y ausführen möchten und Plattform X eine vorgefertigte Lösung Y hat, die X ausführt, tun Sie dies.

Alle allgemeinen Gründe, warum Sie eine Plattform über einer anderen verwenden sollten.

Welche CRUD-Apps erstellen Sie für interne Geschäftsanwendungen?

Ja, es gibt eine andere Plattform, mit der Sie eine allgemeine Anwendung schneller schreiben können.

Das sagte jedoch. Ich habe Erfahrung mit Node und kann nicht behaupten, dass ich eine andere Plattform anstelle von Node wählen würde, es sei denn, sie bietet eine Vielzahl von Funktionen, die für mich sofort einsatzbereit sind.

Im Grunde ist es eine einfache Frage von

Gibt es ein Tool, das das alles für mich erledigt? Nein, dann wählen Sie die bequemste Plattform, um das Tool zu schreiben.

Es gibt keine stichhaltigen Gründe, warum node.js eine unbequeme Plattform ist (außer "ich hasse Javascript")

Nachdem ich ein paar Wochen mit node gearbeitet habe, würde ich sagen, ja, es ist sehr cool. Aber nicht unbedingt etwas, das Sie verwenden möchten, um Ihre alltäglichen Web-Apps durch ... zu ersetzen, und das soll es auch nicht sein.

Denken Sie daran, dass der Knoten ein eigener Server ist. Dies führt zu Komplexitäten, wenn Sie mehr als nur die Anwendung node.js ausführen möchten. dh, wenn Sie mehr als eine Site / Domain auf einem Computer gehostet haben. Es ist nicht wie ein LAMP-Stack, in dem Sie ein Dutzend PHP-Anwendungen für ein halbes Dutzend verschiedene Domänen haben können, die auf demselben Server ausgeführt werden (mindestens auf Port 80). Es gibt Frameworks für Nodes, die dies wahrscheinlich ermöglichen. Dies erhöht jedoch die Komplexität, die Sie nicht benötigen, wenn Sie sich an herkömmliche Webplattformen halten. (Sie können natürlich auch Proxys einrichten, indem Sie einen Webserver vor den Knoten stellen. Diese Art von Einstellungen hat jedoch den Vorteil, dass der Knoten verwendet wird.)

Imo, Node ist perfekt für die Arbeit mit einem herkömmlichen Webserver. Die Art und Weise, wie ich die Dinge jetzt organisiert habe, besteht darin, die statischen html / js / images über Apache bereitzustellen und die 'Echtzeit'-Datenanforderungen durch langes Abfragen an die Knotenanwendung zu bewältigen.

Ein guter Grund, um Sekunden Gedanken über Knoten zu haben, sind nicht technisch - es ist großartig und erstaunlich, was es tut.

Sie sind Unternehmen und speziell Humankapital, dh Programmierer, die wissen, wie viel sie kosten und wie verfügbar sie sind. Es ist nicht so schwer zu lernen, aber wie bei jeder neueren Technologie ist die Anzahl der Leute, die es gut kennen (oder wollen), ein Teil der größeren Pools von Arbeitnehmern.

Dies ist eine sehr gute Frage, die wir uns stellen müssen, um den Stand der Technik zu verbessern.

Ich war sehr neugierig zu wissen (wie Paul d'Aoust), wo die Beschränkungen von Node.JS bestehen. Leider stecken viele Antworten voller subjektiver Befangenheit und vorübergehend relevanter Gründe.

Ich fragte mich: KÖNNEN WIR SUBJEKTIVE BIAS HERAUSFILTERN UND UNBEGRENZTE ANTWORTEN AUF DIESE RELEVANTE FRAGE ERHALTEN?

Die restlichen Punkte scheinen zu sein:

1. NodeJS ist nicht so ausgereift wie herkömmliche Frameworks. Wie Paul d'Aoust vorschlägt, handelt es sich hierbei nur um einen vorübergehend relevanten Grund, nicht um eine vollständige Vermeidung, sondern um eine Überprüfung und Due Diligence. Es wird von uns erwartet, dass wir unsere Hausaufgaben als Web-Profis erledigen, und es ist unsere Aufgabe, die bestmögliche Anpassung der Technologie an die Organisation, ihre Bedürfnisse, ihre Zukunft, das Team (und nicht uns) zu bestimmen. Reife ist ein Klärungsbedürfnis und eine Beurteilung der Risikobereitschaft, aber keine Vermeidung.

2. NodeJS als Proxyserver. Ein kluger Vorschlag, der nach vorheriger Erörterung geprüft und geprüft werden sollte. Es ist die Idee, Node in Korrelation mit vorhandenen Technologien als Entwurfsmuster für Front-End-Schnittstellen-Proxys zu verwenden. Es ist jedoch auch kein Grund, die Verwendung von Knoten zu VERMEIDEN, sondern ein Grund, die Verwendung als vollständigen Ersatz zu vermeiden. Entscheiden Sie sich stattdessen für einen konsequenten Ansatz.

3. Debugging-Knoten. Im Gespräch mit den Entwicklern von Core Node bei Joyent gibt es viele Probleme mit der Debug-Fähigkeit und der Rückverfolgung der Hauptursache von Problemen, die sich aus dem Core ergeben (basierend auf der Ausführung einzelner Threads und der Unfähigkeit, frühere Threads einzusehen). Dies ist eine Überlegung und Bewertung wert - aber (wieder) wahrscheinlich keine Abneigung gegen den allgemeinen Gebrauch, nur Randfälle, die den Umschlag drücken können. Vielleicht fallen Ihre spezifischen Bedürfnisse in diese Kategorie und vielleicht auch nicht.

4. Personalwesen. Dies ist der beste Grund, JS auf dieser Seite NICHT zu verwenden, und meiner bescheidenen Meinung nach ist es eine harte und unbequeme Wahrheit. Es stellt sich die Frage: Verfügt Ihr Unternehmen über die richtigen Fachkräfte, um das Projekt über den gesamten Lebenszyklus hinweg zu begleiten? Wenn nicht, müssen Sie NodeJS unbedingt vermeiden. Oder überlegen Sie sich stattdessen A) das richtige Talent zu finden oder B) das vorhandene Talent zu schulen.

Beschwerden: Meine Beobachtung der Beschwerden bei JavaScript ist, dass viele mehr auf Benutzerfehler als auf konsistente Sprachfehler zurückzuführen sind. Wir haben viele Behauptungen gegen "The Hate JavaScript Diatribe" entlarvt und werden weiterhin viele weitere entlarvt. Solche Probleme wie - Dokumentation ist nicht gut genug, es ist nicht sexy genug, aber die Leute mögen es nicht, es ist Krebs, es ist der Teufel oder es ist zu "typo-anfällig" (-CRichardson), sind subjektiv und voreingenommene Beschwerden, die beseitigt werden müssen, um korrekte Unternehmensentscheidungen zu treffen.

Am Ende könnte die richtige Antwort lauten: Es gibt keine guten Gründe, NodeJS ZU VERMEIDEN . Vielleicht erfährt es deshalb ein schnelles Wachstum, eine schnelle Akzeptanz und einen schnellen Beitrag. Aber für uns alle ist die Antwort vielleicht, NodeJS weiter zu evaluieren, zu erforschen und besser zu verstehen - und nach konkreten Abneigungen Ausschau zu halten. Um genau zu verstehen, wo Node.JS noch nicht ausgereift ist - wir finden genau dort, wo wir es verbessern müssen. Und das ist ein Segen.

Gute Frage. Ich bin immer noch neugierig auf jemanden, der einen besseren Grund vorbringt, NodeJS zu meiden - als diese.

Gibt es einen Vorteil bei der Verwendung von Node over X für Nicht-Echtzeit-Anwendungen:

• Skalierung : Node bietet eine gute Leistung, andere Plattformen jedoch auch. PHP, Ruby, Python und Java sind alle skalierbar. Sie können GROSSE Namen finden, die von Millionen von Benutzern verwendet werden.
• Eine Sprache für Frontend und Backend : Es ist ein Witz, genau wie Javas "Write once run anywhere"
• Heiß und sexy : Der einzig gültige Punkt. Aber niemand kümmert sich darum, dass Ihre Website mit nervöser Technologie arbeitet!

Nutzen der Verwendung von X over Node für Nicht-Echtzeitanwendungen:

• Best Practice : Da Node neu ist, gibt es weniger Best Practices als andere Plattformen, insbesondere für CRUD-Webanwendungen.
• Javascript Sprache : Leute mögen kein Javascript. Während Node.js heiß ist, ist Javascript nicht. Aus diesem Grund haben die Leute Coffeescript erstellt, um zu vermeiden, dass Javascript auch für die Kundenseite geschrieben wird.
• Entwicklungsgeschwindigkeit : Die alten und langweiligen Frameworks, einschließlich und nicht beschränkt auf Rails und Django, wurden über viele Jahre hinweg für CRUD-Websites getestet und verbessert. Während Sie ähnliche Anwendungen in Node implementieren können, ist dies im Framework Ihres Großvaters einfacher.
• Stabilität : Die Web-Frameworks von Node werden schneller besser. Dies bedeutet, dass sie sich ändern und in naher Zukunft mehr API-Inkompatibilität aufweisen werden.
• Bibliotheken und Tools : Die älteren Technologien mit mehr Benutzern verfügen über mehr Bibliotheken und Tools.

Meine Antwort wird 2015 definitiv nicht gültig sein. Überspringen Sie 2014 den Knoten für Nicht-Echtzeit-Webanwendungen, aber behalten Sie ihn im Auge.

Jedes Webframework hat eine Stärke. Sie werden glücklich sein, wenn Sie es für diesen Punkt verwenden. Nicht-Echtzeit-Webanwendungen sind keine Stärke der Node-Web-Frameworks.

Node.js ist eine sehr beliebte Plattform mit vielen interessanten Funktionen, aber die Verwendung eines Tools ist eine persönliche Präferenz. Ich habe Node.js vier Mal gegeben und war damit nicht zufrieden. Hier sind meine Gründe. Bitte beachten Sie, dass einige dieser Gründe veraltet oder einfach nur persönlich sind: P

• Ich bevorzuge eine andere Sprache / Syntax (ich mag Python, Scala, meine Lieblingssprache ist Prolog, also ja).
• Die Qualität der Dokumentation für Frameworks und Bibliotheken, die ich verwendet habe, ist für Java-, Scala- und Python-Bibliotheken nicht so gut.
• Designer der Nodejs sind eher von Callbacks als von Ereignismodellen, Beobachtern oder Futures besessen.
• Es gibt fertige Lösungen für das, was ich in Ruby, Python, Java, das ich 2005 entwickelt habe, machen möchte. Ich muss nur die Konfigurationsdatei bearbeiten.

HTTP ist zustandslos, es gibt also keine Nicht-Echtzeit-Webanwendung und daher keinen Grund, warum Sie den Knoten nicht für alles verwenden können.

Der Knoten eignet sich jedoch besser für eine bestimmte Art von Anwendungsarchitektur. PHP ist HTML-Dateien mit ein bisschen Code. Knoten ist Code, der optional ein bisschen HTML enthält.

Dies bedeutet, dass PHP einfacher ist, wenn es sich bei Ihrer App um HTML-Standardformulare ohne clientseitiges Skript handelt. Node verfügt zwar über Template-Tools, ist aber offensichtlich nicht so ausgereift wie PHP.

Wenn Sie viele clientseitige Skripte haben und die Daten mit Ajax speichern, erhalten Sie einen statischen HTML-Client, der Funktionen auf dem Server aufruft. Genau das kann der Knoten. Obwohl CRUD-Apps normalerweise nicht so erstellt werden, können Sie mit dem richtigen Framework etwas ziemlich Schönes produzieren.