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

29

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 :-)

Paul d'Aoust
quelle
1
@ default.kramer: Danke für den Link, es hat mir sehr gut gefallen!
Zach
1
Wow! Eher meinungsbewusster Junge, was? In dem Folgeartikel scheint er zu sagen, dass ereignisgesteuerte Systeme und Thread-Systeme für Anwendungen mit hoher E / A und niedriger CPU in etwa gleichwertig sind und dass das Problem bei unerfahrenen Programmierern liegt, die nicht wissen, wann sie es tun sollen Gib Events auf und spawne einen neuen Thread. Aber die Unwissenheit des Programmierers bedeutet nicht, dass das Tool schlecht ist, oder? Ich bin damit einverstanden, dass die Verwendung einer Umgebung, deren Forté aus Ereignisschleifen für CPU-intensive Aufgaben besteht, etwas seltsam ist, aber ist es böse?
Paul d'Aoust
1
Sein Hass auf JavaScript scheint ebenfalls ein wichtiges Thema zu sein, von dem ich befürchte, dass es teilweise für die Energie verantwortlich ist, die hinter seinem Argument steckt.
Paul d'Aoust
@ Paul - Sie sollten es wahrscheinlich mit einem Körnchen Salz nehmen. Ich weiß nicht viel über Node.js; Ich fand es einfach witzig. (Wie die meisten seiner Schriften)
default.kramer
@ default.kramer danke für die erinnerung; Ich neige dazu, die Meinungen der Menschen als Evangelium zu betrachten. Sein Hauptkritikpunkt scheint zu sein, dass Sie Node.js nicht für CPU-intensive Aufgaben verwenden sollten. Ich bin verwirrt über seine Kritik an Arbeitsprozessen. Gibt es ein großes Problem bei der Erstellung separater Mitarbeiter für bestimmte Aufgaben?
Paul d'Aoust

Antworten:

13

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")

Raynos
quelle
Sie denken also, dass pragmatische Prinzipien wie Vertrautheit, Verfügbarkeit von Bibliotheken usw. starke Argumente für eine bestimmte Plattform sind, oder? Das sind gute Gedanken, und das sind definitiv Dinge, über die ich nachdenke. (Ich bin überrascht, dass Sie sich für Out-of-the-Box-Lösungen einsetzen. Ich dachte, Sie sind ein eigenständiger Typ!)
Paul d'Aoust,
@ Pauld'Aoust Ich bin ein Roll-Your-Own-Typ. Allerdings bekomme ich nichts fertig und ich habe keine Fristen.
Raynos
heh, danke für die Einschränkung. Ich erinnere mich an Ihre Kommentare im Chat von node.js über die Verwendung der Modellbibliotheken anderer Personen (Backbone.js usw.) und die Erkenntnis, dass ich zu viel Zeit damit verbracht habe, Backbone.js zu lernen, und nicht genug Zeit, nur JavaScript zu nutzen (und zu lernen) prototypischer Vererbungsmechanismus. Guter Rat; Ich fühle mich jetzt viel entspannter.
Paul d'Aoust
4
-1 vage. 1) Nur weil Sie N Jahre Erfahrung in X haben - heißt das nicht, dass Sie Node.JS meiden sollten. Schlagen Sie vor, dass vorsätzliche Ignoranz auf Erfahrung basiert? Und was sind die "generischen Gründe"? 2) "Andere Anwendungen, mit denen Sie eine allgemeine Anwendung schneller schreiben können" - ist rein subjektiv. 3) "andere * als" * Ich hasse * JavaScript "- ist auch subjektiv und kein triftiger Grund, um eine blühende Technologie zu vermeiden. * Rechtschreibung.
Jack Stone
@ClintNash Einige Ihrer Gründe unterscheiden sich nicht von seinen. "Human Resources" vs "N Jahre Erfahrung" sind genau das gleiche. "NodeJS ist nicht so ausgereift wie traditionelle Frameworks." sind auch gleich. Sie sind nicht nur die gleichen, sondern Ihre sind auch nicht messbarer (objektiver) als seine.
aaaaaa
6

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.

GroßmeisterB
quelle
+1 Benutzerfreundlichkeit bei der Einrichtung mehrerer Hosts ist auf jeden Fall eine Überlegung wert.
Paul d'Aoust
Es ist ziemlich einfach, Node-Apps hinter einen Apache-HTTP- oder -Nginx-Server zu stellen und Anforderungen mit der URI-Signatur dieser App an den Node-Port (oder die Ports) weiterzuleiten.
TomG
+1 - Die Vorstellung von node.js als serverseitigem Proxy ('in Verbindung mit einem herkömmlichen Webserver') hat Anfang dieses Jahres an Bedeutung gewonnen und sollte näher untersucht werden - insbesondere, wenn Sie eine große herkömmliche Architektur verwalten müssen. Es ist ein Entwurfsmuster, das für das Unternehmen sinnvoll erscheint. Es ist jedoch erwähnenswert, dass dies kein Grund ist, Node.js zu VERMEIDEN, sondern ein Grund, es für einen bestimmten Zweck zu verwenden.
Jack Stone
4
-1 - Ein Proxy (wie Nginx) vor einen Node zu stellen, ist ein perfekter Anwendungsfall und in manchen Fällen sogar viel sicherer und performanter, als überhaupt keinen zu haben. Es besiegt keine Vorteile des Knotens. Ich neige dazu, meine Node-Apps auf Unix-Domain-Sockets auszuführen und nginx dann als Gatekeeper zu verwenden.
Scott Anderson
3

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.

Michael Durrant
quelle
Sie denken also, dass es nicht wirklich viel dagegen gibt, Node anstelle traditionellerer App-Stacks zu verwenden. Die Probleme haben mehr mit realen Anliegen zu tun?
Paul d'Aoust
+1. Human Resources - und die mangelnde Bereitschaft einiger, JavaScript zu lernen - ist eine unbequeme Wahrheit. Diese Antwort sagt es gut. Aber das Vermeiden von Node, "weil Leute JavaScript hassen", ist auch nicht die logische Folge. Wo wären wir technisch gesehen, wenn wir jede Innovation vermeiden würden - die jemand anderes hasste? Nirgends. Die Herausforderung bei node besteht darin, A) neues Talent zu bekommen oder B) traditionelles Talent zu neuem Talent zu erziehen. Bis zu diesem Punkt - seit John Resigs Voraussicht bei der Gründung der Khan Academy tauchen überall JavaScript-Codeschulen auf. Kurz gesagt, das ist der Weg der Dinge. +1. Gut gesagt.
Jack Stone
3

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.

Jack Stone
quelle
-1

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.

Hossein
quelle
2
-1. Ich bin damit einverstanden, dass diese Antwort 2015 nicht gültig sein wird. Aber das ist auch ein Grund für die Ablehnung. Im Wesentlichen sind die Entscheidungen von heute die Entscheidungen von morgen. Die obigen 8 Aufzählungspunkte werden aufgehoben - wenn wir sehen können, dass sie nur vorübergehend relevant sind. 1) Skalierung - Walmart Mobile-Skalen, kein Grund, Node zu meiden. 2) Isomorphes JS ist kein Witz. Kein Grund. 3) Server Sexyness? Die meisten Benutzer kennen nur ux. 4) Best Practice ist subjektiv, 5) Nicht heiß? 6) Einfacher? -subjektiv. 7) Stabilität ist ein vorübergehend relevanter Punkt. 8) NPM wird voraussichtlich 2014 Maven passieren. Hier gibt es keine Gründe. Downvote.
Jack Stone
-1

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.
David Sergey
quelle
2
-1 - Subjektive Punkte. "Bevorzugte Syntax", "Dokumentation nicht so gut", "Zwangsrückrufe" und "In meiner Sprache bereits erledigt" - alle sind vage und subjektiv. Wir haben das schon mal gehört. Sie werden entlarvt. Kein Grund, Node.JS hier zu meiden. Downvote.
Jack Stone
1
Alle Punkte sind meine persönlichen Vorlieben, die ich offen ausgesprochen habe. Auch wie entlarvt man persönliche Vorlieben?
David Sergey
-9

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.

Tom Clarkson
quelle
Es wird darauf hingewiesen, dass HTTP statusfrei und echtzeitbasiert ist. Ich interessiere mich jedoch mehr für die pragmatischen Bedenken hinsichtlich der typischen Definition von Echtzeit: große Mengen von Anfragen mit geringem Gewicht. Es scheint ein bisschen übertrieben, eine neue PHP-Instanz hochzufahren, nur um manchmal drei oder vier Zeilen JSON herauszuspucken. Habe ich recht oder leide ich nur an einem Papageien-Syndrom?
Paul d'Aoust
Wenn Sie PHP nicht laden, laden Sie Javascript und es gibt verschiedene Arten von Caching, so dass der Unterschied nicht genug ist, um sich Sorgen zu machen. Der große Unterschied liegt im Codierungsstil und damit in der Wartbarkeit. Beide Plattformen können entweder HTML oder JSON ausgeben. PHP wurde jedoch für Benutzer entwickelt, die mit der Bearbeitung statischer HTML-Dateien vertraut sind, während Node für Benutzer entwickelt wurde, die mit moderner Javascript-Programmierung vertraut sind.
Tom Clarkson
Ich weiß, dass ich irgendwann einen Interpreter laden muss, aber ich sehe einen Vorteil darin, dass eine Instanz des Interpreters die ganze Zeit ausgeführt wird (natürlich für Anwendungen mit niedriger CPU), wie in Node.js, anstatt dass sich die Interpreter drehen Starten und beenden Sie mit jeder Anfrage, wie in PHP.
Paul d'Aoust
Ja, und ich würde auch erwarten, dass js eine bessere Leistung auf individueller Anforderungsstufe erzielt, da in letzter Zeit in diesem Bereich viel Wettbewerb herrscht. Ich denke jedoch, dass dies nur ein relativ geringer Teil des Unterschieds ist. Mit Node haben Sie die direkte Kontrolle und genau die Menge an Code, die für die Bearbeitung der Anforderung benötigt wird, während jedes vorlagenbasierte System, das davon ausgeht, dass Sie Seiten bedienen, unnötigen Overhead und Komplexität zur Folge hat andere Szenarien.
Tom Clarkson