PHP oder Node.js? – Vorteile und Nachteile

Dieser Artikel stellt PHP und Node.js gegenüber, und zeigt deren Vor- und Nachteile auf. Während in dem vorherigen Artikel die Gemeinsamkeiten und Unterschiede zwischen beidem herausgearbeitet wurden, erklärt dieser Artikel, in welchen Fällen PHP, und in welchen Fällen Node.js besser geeignet ist.

Grundsätzlich gilt, dass die hier genannten Punkte je nach Einsatzzweck mal mehr und mal weniger Relevant sein können. Daher kann ich auch keinen endgültigen „Sieger“ ausschreiben, dafür aber erklären, worin die Stärken und Schwächen der beiden Technologien liegen. Daraus geht dann hervor, wofür man PHP und wofür Node.js verwenden sollte.

Übersicht #

Vorab aber eine grobe Übersicht, mit den wichtigsten Vorteilen beider Technologien.

Vorteile von PHP #

  • größere Verbreitung und größere Community
  • deutlich mehr Webhosting-Anbieter
  • PHP-Code direkt im HTML-Code
  • kein Neustart (des PHP-Interpreters) bei Code-Änderungen notwendig

Vorteile von Node.js #

  • schnellere und performantere Ausführung
  • Anfragen-übergreifende Variablen
  • weniger Arbeitsspeicher-Nutzung
  • ermöglicht das Verwenden von gemeinsamen Code auf Server und Client (in JavaScript)

Aus unterschiedlichen Vorteilen resultieren auch Unterschiede bei den Verwendungszwecken. Kurz zusammengefasst sind dies folgende:

Wofür PHP verwenden? #

  • einfache Webseiten mit wenigen dynamischen Funktionen
  • für Anfänger mit wenig Programmier-Erfahrung
  • für kommerzielle Software, um ein möglichst viele Kunden zu erreichen

Wofür Node.js verwenden? #

  • dynamische Webseiten mit vielen Datenbankabfragen
  • große Webseiten mit viel Traffic
  • Browsergames und Webanwendungen, z.B. bei Verwendung der WebSocket-Technologie

Verbreitung #

Während PHP bereits im Jahr 1995 veröffentlich wurde, gibt es Node.js erst seit dem Jahr 2009. PHP ist also älter, und daher auch weiter verbreitet, als das noch realtiv neue Node.js. Dementsprechend gibt es zu PHP auch eine größere Community, was vor allem für Anfänger die Hilfe brauchen oder viele Fragen haben vom Vorteil ist.

Laut der Statistik von W3Techs.com verwenden 81,9% aller Websites PHP, dem hingegen aber nur 0,1% serverseitiges JavaScript, also Node.js oder eine ähnliche Technologie. Die Verbreitung und das Interesse an Node.js ist jedoch eindeutig am steigen, wie auch Google Trends zeigt:

Node.js in Google Trends

Node.js in Google Trends, von September 2009 bis (einschließlich) April 2014, in Google Trends ansehen

Webhosting #

PHPEntsprechend der Verbreitung fällt auch die Suche nach einem passenden Webhosting-Angebot für PHP viel leichter, als es bei Node.js der Fall ist. Während es PHP-Webhoster wie Sand am Meer gibt, findet man nur vereinzelt Webhoster, die auch oder speziell Node.js unterstützen.

Anstatt ein Webhostig-Paket zu nutzen kann man aber mit genügend Erfahrung auch einen eigenen Server betreiben, in diesem Fall ist man unabhängig von den Angeboten der Webhoster. Eine Übersicht mit Webhosting-Anbietern für Node.js, sowie Informationen zum betreiben eines eigenen Servers, findest du auf der Seite Node.js-Hosting.

Open-Source & kommerzielle Software #

Auch kommerzielle PHP-Software hat aufgrund seiner Verbreitung mehr potenzielle Käufer als auf Node.js basierende Software. Andererseits ist auch die Konkurrenz bei Node.js-Software geringer als bei PHP, sodass ein Anbieter von Node.js-Software wiederum einen höheren Prozentanteil der zwar geringeren potenziellen Käufer abdecken kann.

Node.jsDer Trend bei Node.js-Software liegt aber eindeutig bei kostenlos und Open-Source, anstatt bei kommerziell und kostenpflichtig. Die meisten Entwickler stellen ihre Open-Source-Software kostenlos zur eigenen Installation bereit, bieten aber gleichzeitig entsprechende Hosting-Services gegen Bezahlung an. So muss man sich um Installation nicht selbst bei einem anderen Hosting-Anbieter kümmern, und unterstützt gleichzeitig die Entwicklung der Software.

Oft werden auch Dienstleistungen speziell zur Software angeboten. Ein Beispiel hierfür ist die Foren-Software NodeBB, deren Entwickler neben zugehörigen Hosting-Paketen auch die Entwicklung von websitespezifischen Designs gegen Bezahlung anbieten.

Code #

Um nun auf die technischen Aspekte zu kommen: Wie im vorherigem Artikel beschrieben, unterscheiden sich Node.js und PHP voneinander. Während PHP lediglich eine Scriptsprache ist, ist Node.js eine komplette Plattform, welche als Basis wiederum die Scriptsprache JavaScript verwendet.

PHP-Code schreibt man normalerweise direkt im HTML-Code, eingegrenzt mit einen öffnenden <?php und einem schließenden ?>PHP-Tag. Der HTML-Code enthält also PHP-Code, und PHP stellt dabei eine serverseitige Erweiterung des HTML-Codes dar, um dynamische Funktionen zu ermöglichen.

Bei Node.js ist es genau umgekehrt, denn hierbei stellt der Code die Basis dar, während alle ausgegebenen Inhalte ein Teil davon sind, und sich technisch gesehen in einer Variable des Scriptes befinden. Hierbei würde man HTML-Code zur Übersicht in eine weitere Datei auslagern, welche dann in die Anwendung geladen wird. Node.js ist also von Grund auf so etwas, wie man es bei PHP erst durch die Verwendung eines Frameworks (oder einer selbst geschriebenen Lösung) kennt, mit dem man den eigentlichen PHP-Code von den HTML-Templates trennt.

Hallo Welt #

Um die Auswirkungen dieses Unterschiedes zu verdeutlichen, zeige ich an dieser Stelle ein „Hallo Welt“-Beispiel von beiden Technologien. Mit PHP würde das folgendermaßen aussehen:

<?php
    echo "Hallo Welt";
?>

Man öffnet den PHP-Bereich, gibt mit dem Befehl echo den Text Hallo Welt! aus, und schließt den PHP-Bereich wieder.

Mit Node.js ist bei diesem Beispiel hingegen mehr Code notwendig:

var http = require('http');
var server = http.createServer(function (req, res) {
   res.writeHead(200, {'Content-Type': 'text/plain'});
   res.end('Hallo Welt!');
});
server.listen(8080);

Während man bei PHP direkt an der Ausgabe arbeitet, arbeitet man bei Node.js am Webserver, der wiederum den ausgegebenen Text erzeugt. PHP selbst besitzt keinen Webserver, weshalb man zum Betreiben einer Website mit PHP auch immer eine zusätzliche Software wie z.B. den Apache– oder Nginx-Webserver verwendet.

Da man mit Node.js die volle Kontrolle über den integrierten Webserver hat, lassen sich mit Node.js neben normalen Webseiten auch andere Dinge, wie z.B. eine Websocket-Verbindung realisieren.

Webseiten und Webanwendungen, die über ein einfaches „Hallo Welt“ hinausgehen, benötigen mit Node.js jedoch meist weniger Code, als mit PHP. Das liegt vor allem an den Modulen von Node.js, die vieles vereinfachen. Dazu aber später im Abschnitt Frameworks & Bibliotheken mehr.

Zusammenfassend kann man bis hierhin sagen, dass sich PHP besser für einfache, und Node.js besser für komplexe Webseiten und Webanwendungen eignet. Im folgenden wird sich diese Regel noch weiter bestätigen.

synchron vs. asynchron #

Während PHP synchron abläuft, also eine weitere Aktion erst dann ausführen kann, wenn die vorherige abgeschlossen ist, arbeitet Node.js asynchron, es können also Aufgaben parallel zueinander ausgeführt werden.

Die asynchrone hat gegenüber der synchronen Funktionsweise klare Vorteile. So ist es beispielsweise möglich, verschiedene Anfragen an eine Datenbank gleichzeitig zu schicken, ohne dass der Programmablauf solange angehalten wird, bis die Antwort von der Datenbank empfangen wurde. Die parallele Ausführung verkürzt die Generierungszeit der Webseite und macht sie schneller, vor allem wenn man mit vielen Datenbank- oder anderen externen Abfragen arbeitet.

Server & Datenbank #

Sowohl bei PHP als auch bei Node.js läuft im Hintergrund ein spezieller Prozess. Bei PHP ist es ein Interpreter, der beim Aufruf einer PHP-Webseite vom Webserver das zugehörige PHP-Script übergeben bekommt, worauf dann ein eigener Scriptablauf erzeugt wird. Je nach Konfiguration des Webservers, wird entweder bei jedem Seitenaufruf ein eigener Interpreter-Prozess gestartet, oder eine bestimmte Anzahl an Interpretern für alle Seitenaufrufe verwendet.

Dem hingegen wird beim Start einer Node.js-Anwendung ein eigener Prozess gestartet, in dem aber nur ein Scriptablauf für alle Seitenaufrufe stattfindet. Denn die asynchrone Funktionsweise von Node.js ermöglicht es, dass sich Verarbeitungen der einzelnen Anfragen nicht gegenseitig blockieren. In PHP ist so etwas nicht möglich, weshalb auch für jeden Seitenaufruf ein eigener Scriptablauf gestartet werden muss.

Mit Node.js kann man dadurch beispielsweise eine einzige Datenbank-Verbindung für die Verarbeitung aller Seitenaufrufe nutzen, und muss nicht für jedem Aufruf eine eigene Verbindung starten, wie es bei einem PHP-Script in der Regel der Fall ist. Das spart pro Seitenaufruf etwas Zeit, und verringert somit ebenfalls die Generierungszeit der Webseite.

Speziell für Datenbanken bietet PHP mit sogenannten persistenten Datenbankverbindungen eine ähnliche Möglichkeit, womit Datenbankverbindung zwischen mehreren Scriptablaufen vom Interpreter offen gehalten werden. Dies funktioniert allerdings nur, wenn PHP entweder als Webserver-Modul, -Plugin oder über FastCGI verwendet wird. Über normales CGI funktioniert dies hingegen nicht, da für jede Anfrage ein eigener PHP-Interpreter gestartet wird.

Viel bedeutsamer ist aber, dass es mit Node.js durch das Verwenden eines einzigen Scriptablaufes möglich ist, Daten zwischen zwei Anfragen zu speichern, ohne den Umweg über eine Datenbank nehmen zu müssen.

Beispiele für die Anfragen-übergreifende Speicherung #

So könnte man beispielsweise für einen Besucherzähler grundsätzlich eine Variable anstelle der Datenbank verwenden. Lediglich um die Besucherzahl dauerhaft, also auch zwischen einem Neustart des Node.js-Servers zu speichern, wäre die Speicherung der Variable in einer Datenbank notwendig.

Mit Node.js müsste man den Besucherzähler nicht nach jedem einzelnen Besucher in der Datenbank speichern, sondern könnte ihn auch alle x Besucher synchronisieren, oder in einem Interval von y Minuten. Für das bloße Auslesen des Besucherzählers – z.B. wenn jeder Besucher anhand der IP-Adresse nur einmal gezählt wird, auch wenn er mehrere Seiten aufruft – wäre kein extra Datenbankzugriff erforderlich, schließlich befindet sich der Zähler in einer Variable.

Ein weiteres Beispiel sind die Einstellungen eines Forums, CMS, oder einer beliebigen anderen Webanwendung. Diese muss man mit Node.js nicht bei jedem Seitenaufruf aus der Datenbank lesen, sondern kann dies stattdessen einmalig beim Start des Servers erledigen. Einen weiteren Datenbank-Zugriff benötigt man erst dann, wenn die Einstellungen geändert wurden, nämlich um sie dauerhaft in der Datenbank zu speichern.

Man könnte auch einen Chat programmieren, bei dem man überhaupt keine Datenbank benötigt. Hier würde man die letzten Nachrichten in einer Variable inklusive Zeitstempel speichern, und z.B. per AJAX abfragen, ob neue Chat-Nachrichten verfügbar sind.

Oder noch besser: Man hält eine WebSocket-Verbindung offen, und benachrichtigt alle Chat-Teilnehmer, sobald es eine neue Nachricht gibt. Dann braucht man auch keine Variable mehr für die Speicherung der Nachrichten, da man sie überhaupt nicht speichert, sondern stattdessen sofort an alle Teilnehmer schickt.

Ein Tutorial zu einen solchen Chat findest du übrigens hier: Chat mit Node.js und WebSocket.

Performance vs. Neustart #

Die Verwendung eines einzigen Scriptablaufs gibt Node.js viele Vorteile gegenüber PHP, vor allem bei der Performance, da das Zwischenspeichern von Daten und weniger Datenbankaktivitäten automatisch zu einer geringeren Generierungszeit der Website führen. Da nicht für jeden Seitenaufruf ein eigener Scriptablauf gestartet wird, wird zudem auch weniger Arbeitsspeicher benötigt, da global benötigte Variablen und Code auch nur einmal definiert bzw. geladen werden, und nicht für jeden einzelnen Aufruf extra.

Aber trotz allen Vorteilen bringt dies auch den Nachteil mit sich, dass man beim Ändern des Quellcodes den Node.js-Server neu starten muss, damit die Änderungen aktiv werden. Bei PHP werden Änderungen hingegen bei allen nachfolgenden Aufrufen aktiv, da – wie schon erwähnt – bei jedem Aufruf ein eigener Scriptablauf gestartet wird.

Timing & Cronjobs #

Einen weiteren Vorteil bietet Node.js beim Timing, also der Ausführung einer Aktion zu einem bestimmten Zeitpunkt. Da der Scriptablauf dauerhaft aktiv ist, kann dies mit Node.js ohne weiteres erledigt werden. Aktionen können so entweder mittels den JavaScript-Funktionen setTimeout() und setInterval() nach bzw. alle x Millisekunden ausgeführt werden, oder man erledigt dies mit Modulen wie cron, womit man dies auch zu bestimmten Uhrzeiten tun kann.

Da ein PHP-Script hingegen bei jedem Aufruf extra gestartet, und somit nicht dauerhaft aktiv ist, ist eine solche Vorgehensweise mit PHP nicht möglich. Stattdessen verwendet man hier meistens Cronjobs, man ruft ein Script also zu einem bestimmten Zeitpunkt auf, was dann die gewünschte Aktion erledigt.

Cronjobs sind jedoch etwas aufwendiger und umständlich, vor allem wenn man viele Aktionen hat, die zu unterschiedlichen Zeitpunkten ausgeführt werden sollen. Hier bietet Node.js dank der dauerhaften Aktivität eine deutlich elegantere Lösung.

Maschinencode vs. Bytecode-Caching #

Eine Scriptsprache, wie es sowohl PHP als auch das bei Node.js verwendete JavaScript ist, wird typischerweise durch einen Interpreter gezogen. Dabei handelt es sich um ein Programm, dass den Code Zeichen für Zeichen auswertet, und währenddessen den Scriptablauf erzeugt. Meist geschieht dies nicht direkt, sondern es wird zunächst eine Art Zwischensprache (der sogenannte Bytecode) erzeugt, mit dem dann die eigentliche Inteperetierumg stattfindet.

Da der Code während der Ausführung interpretiert wird, sind Scriptsprachen in der Regel langsamer als kompilierbare Programmiersprachen wie C, die vor der Ausführung in Maschinensprache übersetzt werden.

Um diesen Nachteil auszugleichen, wurden für PHP sogenannte Bytecode-Caches entwickelt. Dabei handelt es sich Erweiterungen, welche den erzeugten Bytecode zwischenspeichern, sodass er nicht bei jedem Aufruf neu erstellt wird. Seit der Version 5.5 besitzt PHP einen integrierten Bytecode-Cache, der lediglich über die Einstellungen konfiguriert und aktiviert werden muss.

Node.js verwendet hingegen die V8-Engine, welche den Quellcode während der Ausführung in nativen Maschienencode kompiliert. Da Node.js mit nur einem Scriptablauf auskommt, geschieht dies auch nur einmal, nämlich beim Start der jeweiligen Anwendung.

Für PHP stehen aber ähnliche Technologien wie PHC oder HipHop zur Verfügung, die etwas vergleichbares tun, und den PHP-Code in C bzw. C++ übersetzten, und anschließend kompilieren. Diese Erweiterungen müssen allerdings manuell installiert werden, und unterstützten teilweise nicht alle Funktionen von PHP.

Frameworks & Bibliotheken #

Oft will man das Rad nicht neu erfinden, und verwendet deswegen Software-Bibliotheken und Frameworks, die häufig verwendete Funktionalitäten bereitstellen und Standardanforderungen abdecken. Frameworks sind allerdings dafür bekannt, dass sie ein Programm in der Regel langsamer machen, was einen klaren Nachteil darstellt.

Dies kommt vor allem bei PHP-Frameworks zustande, da sie bei jedem Seitenaufruf erneut in den jeweiligen Scriptablauf geladen, initialisiert und ausgeführt werden. Anders ist das bei Node.js, denn hier muss dies nur beim Start der Anwendung, und nicht bei jedem Seitenaufruf erledigt werden.

Module in Node.js #

Die gesamte Philosophie hinter Node.js basiert auf Modulen, also einzelnen Software-Bibliotheken und Frameworks, die bei Bedarf in eine Anwendung geladen werden. Da dies nur ein einziges Mal getan werden muss, verringern sie die Geschwindigkeit einer Node.js-Anwendung nur kaum bis gar nicht.

Das Modul-System von Node.js erlaubt es zudem auch, dass Module wiederum andere Module verwenden, und so ein umfassendes Ökosystem zwischen Modulen aufgebaut wird. Durch die Möglichkeit diverse Module zu verwenden ist der Code einer Node.js-Anwendung meist um einiges kürzer, als der eines vergleichbaren PHP-Programms. Das ist vor Allem bei komplexen Anwendungen ein entscheidender Vorteil von Node.js.

Da jeder moderne Webbrowser JavaScript unterstützt, ermöglicht es das Modul-System zudem, gemeinsam genutzten Code in die Node.js-Anwendung zu laden, der dann sowohl auf den Server als auch im Webbrowser läuft. Diese Möglichkeit ist vor allem für Webanwendungen und Browserspiele interessant.

Fehler & Debugging #

Ein weiterer wichtiger Punkt ist das Debugging, also das Auffinden und Beheben von Fehlern im Quellcode.

Tritt bei der Ausführung eines PHP-Codes ein Fehler auf, so wird der entsprechende Scriptablauf gestoppt, und je nachdem, ob sich PHP im Entwicklungs- oder Produktivmodus befindet, wird der Fehler entweder direkt als Antwort zurückgegeben und somit im Webbrowser angezeigt, oder in eine Log-Datei geschrieben.

Tritt bei Node.js während der Ausführung ein Fehler auf, so wird ebenfalls der Scriptablauf gestoppt, der Fehler wird aber immer in der Konsole zurückgegeben. In einer Entwicklungs- und Testumgebung würde die Ausgabe der Konsole dann dem Entwickler angezeigt, während sie bei einem Produktivsystem ebenfalls in eine Log-Datei geschrieben würde.

Wichtig ist aber, dass beim Auftreten eines Fehlers die gesamte Node.js-Anwendung gestoppt wird, da Node.js nur einen Scriptablauf erzeugt. Somit wäre die Website auch für alle anderen Besucher nicht mehr aufrufbar, bis die Node.js-Anwendung erneut gestartet wird. Ein Produktivsystem für Node.js sollte deshalb dafür sorgen, dass die entsprechende Anwendung beim Auftreten eines Fehlers erneut gestartet wird. Dazu verwendet man z.B. das Programm forever, welches neben dem automatischem Neustart auch dafür sorgt, dass – wie soeben beschrieben – die Ausgabe der Konsole in eine Log-Datei geschrieben wird.

Generell sollte man Fehler im Code vermeiden, und da Node.js nur einen Scriptablauf erzeugt, gilt das hier besonders. Für den Fall, dass aber tatsächlich mal ein Fehler auftritt, sollte man diesen mit einer try-catch-Anweisung abfangen, damit im Produktiveinsatz nicht die gesamte Node.js-Anwendung gestoppt wird.

Dass beim Auftreten eines Fehlers die gesamte Node.js-Anwendung gestoppt wird, stellt einen klaren Nachteil seitens Node.js dar, der bei PHP nicht vorhanden ist. Vor allem für Anfänger und unerfahrene Entwickler kann das nachteilhaft sein, da man als Neuling häufig mal Zeichen vergisst, und damit einen Syntax-Fehler auslöst.

Debugging-Konsole #

Neben Fehlern bei der Ausführung wie z.B. Syntaxfehlern, die eine entsprechende Fehler-Meldung erzeugen, können auch Fehler im Programmablauf auftreten, die zu unerwünschten Verhaltensweisen führen. Solche Fehlverhalten werden auch als Bugs bezeichnet, und lassen sich umso schwerer auffinden, je komplexer der Programmcode ist.

Anders als PHP, stellt Node.js zur Aufspürung solcher Fehler eine Debugging-Konsole zur Verfügung. Damit lassen sich Unterbrechungsstellen im Code setzen, und – während der regulären Ausführung eines Scriptes – Anweisung im Scriptablauf Ausführen. So ist es möglich, Fehler schneller und effektiver ausfindig zu machen, da man sich so z.B. den Inhalt von Variablen im laufenden Betrieb ausgeben lassen kann, ohne dafür den eigentlichen Quellcode zu ändern.

In dieser Hinsicht bietet Node.js den Entwicklern eine Möglichkeit, die Fehlersuche zu vereinfachen, was vor allem bei komplexen Programmen vom Vorteil ist.

Zusammenfassung #

Während PHP-Code innerhalb eines HTML-Dokuments steht, ist dies bei Node.js genau umgekehrt. Bei einfachen Webseiten stellt PHP hiermit einen Vorteil dar, während es bei komplexen Webseiten genau anders herum ist, und Node.js einen Vorteil darstellt.

Node.js hat jedoch mit seiner asynchronen Funktionsweise viele Vorteile gegenüber PHP, vor allem was die Performance anbelangt, da parallele Abfragen, das Zwischenspeichern von Daten und weniger Datenbankaktivitäten zu einer geringeren Generierungszeit der Webseite führen. Zudem wird dadurch weniger Arbeitsspeicher benötigt, und das Verwenden von zeitgesteuerten Aktionen wird dadurch einfacher. Da der JavaScript-Code vor der Ausführung in Maschinencode umgewandelt wird, wirkt sich dies ebenfalls vorteilhaft auf die Performance einer Node.js-Anwendung aus.

Gleichzeitig ergibt sich daraus für Node.js der Nachteil, dass eine Anwendung erneut gestartet werden muss, damit Änderungen am Code aktiv werden. Außerdem wird die Ausführung der gesamten Anwendung angehalten, wenn ein Fehler auftritt. Bei PHP ist dies beides nicht der Fall, da Codeänderungen mit jeden darauf folgenden Scriptablauf aktiv werden, und Fehler immer nur den jeweiligen Aufruf betreffen und stoppen.

Dafür lassen sich Node.js-Anwendungen jedoch besser debuggen, als PHP-Scripte. Und es besteht die Möglichkeit, JavaScript-Code sowohl auf den Server als auch im Webbrowser zu verwenden.

Der größte Vorteil an PHP ist die hohe Verbreitung, und die dementsprechend auch große Community, sowie die große Auswahl an Webhosting-Anbietern für PHP. Vor allem für Anfänger kann dies ein Argument für PHP sein, denn Node.js ist noch nicht so weit verbreitet wie PHP.

Was wofür verwenden? #

Letztendlich lässt sich sagen, dass PHP besser für einfache Webseiten mit einfachen und nur wenigen dynamischen Funktion ist, während Node.js besser für komplexere Webseiten geeignet ist. Sobald man umfassende Webanwendungen programmieren möchte, und dafür z.B. eine Websocket-Verbindung zur Kommunikation zwischen Server und Client verwenden will, stößt PHP an seine Grenzen. Deshalb sollte man sich in diesem Fall für Node.js entscheiden, oder alternativ dazu eine Bibliothek wie Elephant.io verwenden, mit der sich PHP und Node.js im Kombination zueinander verwenden lässt.

Anfänger werden zu PHP sicherlich mehr im Internet finden, als zum noch recht neuen Node.js. Wenn man sich jedoch entscheidet, entweder mit PHP oder mit Node.js anzufangen, so hängt die Entscheidung sicherlich auch davon ab, was genau man damit erreichen möchte. Will man eine HTML-Seite nur mit ein paar dynamischen Funktionen „aufpeppen“, so kann man dafür PHP verwenden. Will man hingegen mehr in die Richtung der Webanwendungen gehen, so macht es mehr Sinn, sich mit Node.js zu beschäftigen.

Verwendest du PHP, Node.js, oder sogar beides? Und welche Erfahrungen hast du damit gemacht?

VN:F [1.9.22_1171]
Bewertung: 4.4/5 (65 Bewertungen)
PHP oder Node.js? – Vorteile und Nachteile, 4.4 out of 5 based on 65 ratings
Regelmäßige Beiträge über Node.js

nodecodeAbonniere den kostenlosen NodeCode-Newsletter, und bleibe auf dem laufenden über neue Beiträge zum Thema Node.js. Darunter:

  • Informationen und Neuigkeiten rund um Node.js und zugehörigen Modulen
  • Vorstellung von interessanten Frameworks und Bibliotheken
  • Anleitungen und Tutorials zu Node.js und weiterführenden Technologien
  • Sowie vieles mehr...

schon 62 Kommentare gehe zum kommentieren

  1. Pingback: NodeJS kurz und knapp vorgestellt – Responsive Webdesigner aus Halle Saale – WordPress – Performance /

  2. Pingback: Anonymous /

  3. Anonymous /

    Es waer gut, wenn du PHP genau so fair vertreten wuerdest, wie du NodeJS vertrittst. Man merkt – ich mein, die Seite heisst nodecode.de – dass du wirklich wenig bis gar nichts von PHP weisst. Dann eine Gegenueberstellung zu machen ist schon ziemlich unfair. Deine Punkte bei NodeJS stimmen zwar so weit ich darueber Ahnung habe, aber du redest echt viel, viel Quatsch.

    Bei deinen Punkten „Vorteile von PHP“ und „Wofuer PHP verwenden?“ stehen wirklich nur die aller aller aller minimalistischen Funktionen da, waehrend du bei NodeJS alles raushaust was geht.

    Woher nimmst du denn die Annahme, dass NodeJS gut fuer grosse Websiten ist? Fast jeder der ein bisschen Ahung hat, wird dir sagen, dass NodeJS total schlecht skaliert.

    https://news.ycombinator.com/item?id=4495101

    So, manche Seiten nutzen aber NodeJS und laufen trotzdem schnell: Trello z.b. Was lernen wir daraus? Sowohl NodeJS als auch PHP kann performant sein, wenn man es richtig macht.

    PHP ist also besser fuer Anfaenger mit wenig Programmier-Erfahrung als JS/NodeJS? Das stimmt vielleicht was den Einstieg angeht, aber um es wirklich professionell zu machen haben beide die gleichen Anforderungen.

    Einen guten Programmierer macht es ausserdem aus, dass ihm die Sprache egal ist und er sich trotzdem zurecht findet, weil er weiss wonach er suchen muss und wie er arbeiten muss um seinen Wunsch zu erfuellen.

    Punkt Webhosting:
    Man sollte sich – wenn man es profesionell macht – sowieso einen eigenen Server holen statt einen Webspace.

    Punkt Code:
    PHP ist also eine Scriptsprache. Diese Aussage klingt wie die von den Leuten, die vor 10 Jahren das letzte Mal PHP gesehen haben und denken es sein keine Programmiersprache. Oder denkst du, weil es keinen Compiler hat? Egal. Bei beiden Punkten kann ich dir nur das hier empfehlen

    http://stackoverflow.com/questions/3222316/what-is-a-real-programming-language

    Punkt Synchron vs. Asynchron:
    PHP ist also nur synchron? Stimmt nicht. Einfach mal nach „php async task“ googlen und schon findest du 1000 Ergebnisse. Also wirkich, du schreibst einen Artikel und hast da Behauptungen drin, die du mit 5 Sekunden googlen widerlegen haettest koennen.

    Punkt Server & Datenbank:
    Keine Ahnung ob ich dir hier richtig verstehe, aber bei PHP nutzt du fuer Datenbank-Verbindungen doch eh das Singleton-Pattern, sodass du nur eine DB-Verbindung aufbaust und dann das nicht mehr tun musst.

    Punkt Timing & Cronjobs
    Komisch, wenn NodeJS Code hat, der umstaendlicher ist, ist es ok, weil’s ja NodeJS ist. Wenn bei PHP etwas aufwwaendiger ist, dann hat NodeJS “ eine deutlich elegantere Lösung.“

    Fehler & Debugging:
    Ui, mal ein Negativ-Punkt fuer NodeJS?

    Debugging-Konsole:
    Einfach Xdebug nehmen? Du schreibst doch immerhin selbst „Oft will man das Rad nicht neu erfinden“. Wieso willst du dann immer, dass man Vanilla PHP nutzt?

    Was wofür verwenden?
    Letztendlich lässt sich sagen, dass PHP besser für einfache Webseiten
    LOL

    —–

    Rest ist ok, oder habe ich keine Meinung zu, oder nicht genug Wissen um was darueber zu sagen.

    1. Anonymous /

      Ich bin es noch einmal.

      Ich habe deine anderen Kommentare hier unten gelesen. Das liest sich als ob du mehr Ahnung von PHP hast als du es in deinem Artikel zeigst. Daher frage ich dennoch: Wieso stellst du PHP so unglaublich schlecht da und zaehlst Punkte auf, die einfach nur total oberflaechlich und für Anfaenger relevant sind? Das erschliesst sich mir nicht so ganz

  4. flobee /

    guter artikel! danke!
    ich bin php’ler
    was auch immer bisher geschrieben wurde: php ist seit >15 jahren neben mir und seit dem geht asyncon schon immer 😉 ohne extras!

    vorteil speed: node.js
    vorteil klare strukturen: PHP die das ziel eine programmiersprache zu sein, vorlegen
    und wer php und html ausgabe immer noch in einen pott tut: nein, auch hier darf man seine meinung soweit modernisieren wie node jung ist :-)

    der rest ist geschmacksache in meinen augen.
    klar ist: der artikel ist von einem node liebhaber geschrieben. so bewerte ich es. das war für mich die wichtige information.
    LG

  5. Anonymous /

    Gut gemachte Gegenüberstellung.

    Da will ich mich mal mit der Sache beschäftigen 😉

  6. Pingback: PHP oder Node.js? – Vorteile und Nachteile | webstefftec /

  7. Christoph Eisenmann /

    „Dieser Artikel ist voller falscher Informationen.“

    Das kann ich überhaupt nicht bestätigen. Der Artikel ist fachlich in Ordnung.

    Was ich hinzufügen würde:

    PHP ist definitiv einfacher und besser zu strukturieren. Und damit einfacher zu lesen. Mann denke an private, protected, public, interfaces , Vererbung von Klassen, Namespaces. Im Prinzip ähnlich c#, java . Kommt man aus dieser Welt, kommt man mit php schnell zurecht. Javascript hingegen ist schwierig gut zu strukturieren. Callbacks sind nett, aber eine gute, lesbare Programmstruktur ist schwierig damit zu machen.

    Events. Klar node.js , asynchron kann man mit php vergessen. Auch mit Bibliotheken wie react. Klar kann man mit react einen webserver bauen, aber was ist wenn man zusätzlich einen websocket server braucht (wie ich), dann geht das einfach nicht.
    Shared Memory, RPC oder was? Pthreads welches nicht einmal Arrays in den Griff bekommt?

    Memorymanagement. Klar node.js Anfrageübergreifendes Speichermanagement viel besser in node.js.

    In PHP gibt es viel mehr freien Source:
    Ja, In php gibt es unentlich viele Frameworks. Bei näheren hinsehen sind aber fast alle Schrott. Selbst gepriesene Frameworks wie Symphony oder Typo3 Flow fallen nach meiner Meinung darunter. Sie sind veraltert oder schlicht Schrottware wie z.B. doctrine. (Ich verwende doctrine jeden tag, ich weiss von was ich rede: „select fromdate from calendar“ produziert „select from date from calendar“). Ein Joke keine klaren Fehlermeldungen zu sqls zu bekommen. Nein, nicht alles was frei ist, ist auch brauchbar.
    Ich glaube, das man auf dolche Sachen schwerlich zurückgreifen sollte. Will man heutzutage eine webbasierte Applikation schreiben, dann ist man trotz den Fefiziten der Sprache javascript mit node.js auf der besseren Seite. Lieber weniger aber dafür bessere Module. Obwohl es bei node.js inzwischen auch Schrottware gibt.

    Oder mann verwendet halt c# , java. Auch OK für größere Anwendungen

    1. adrian /

      Tipp: Verallgemeinerungen machen keinen Sinn. Schau dir yii2 an, das ist eindeutig kein Schrott.

  8. Ohjeohje /

    Dieser Artikel ist voller falscher Informationen.

    1. NodeCode / Beitrags-Autor

      Hallo,
      Was genau soll denn deiner Meinung nach an dem Artikel inhaltlich falsch sein? Es wäre gut wenn du uns dies mitteilen würdest, ansonsten können wir den Artikel in Zweifelsfall auch nicht ausbessern.

      Grüße,
      NodeCode

      1. mschnide /

        PHP besitzt zum Beispiel einen integrierten Web-Server !
        php [options] -S : [-t docroot]

        1. NodeCode / Beitrags-Autor

          Stimmt, das Kommandzeilen-Programm php bringt einen einfachen integrierten Webserver für Entwicklungs- und Testzwecke mit sich, mit dem es möglich ist, PHP-Scripte auszuführen.

          Ich nehme mal an du beziehst dich auf den Abschnitt „Hallo Welt“. Mit PHP ist hierbei die Skriptsprache bzw. Ausführungsumgebung selbst gemeint, nicht das zugehörige Kommandzeilen-Programm, wie es aus dem Zusammenhang (insbesondere mit den jeweiligen Code-Beispielen) ersichtlich sein sollte. Gleiches gilt übrigens auch für das „Betreiben einer Website“, hiermit ist der produktive Einsatz gemeint, keine Entwicklungs-, Test- oder Demonstrationszwecke.

      2. Timo Linde /

        „Da ein PHP-Script hingegen bei jedem Aufruf extra gestartet, und somit nicht dauerhaft aktiv ist, ist eine solche Vorgehensweise mit PHP nicht möglich.“

        Das ist schlicht und einfach inhaltlich falsch 😀

        1. NodeCode / Beitrags-Autor

          Was genau soll an dieser Aussage inhaltlich falsch sein?

          Falls du Erweiterungen bzw. Bibliotheken wie PECL Ev oder React meinst: Er Artikel behandelt ausschließlich PHP an sich, keine Erweiterungen und ähnliches. Siehe dazu auch meinen Kommentar vom 16. Juni 2015 um 21:49.

      3. Timo Linde /

        „Ein Produktivsystem für Node.js sollte deshalb dafür sorgen, dass die entsprechende Anwendung beim Auftreten eines Fehlers erneut gestartet wird. Dazu verwendet man z.B. das Programm forever, welches neben dem automatischem Neustart auch dafür sorgt, dass – wie soeben beschrieben – die Ausgabe der Konsole in eine Log-Datei geschrieben wird.“

        Ich habe scheiße programmiert, also starte ich den Server bei jedem Fehler einfach neu 😀 😀 😀

        1. NodeCode / Beitrags-Autor

          Was genau möchtest du damit sagen?

          Ein Fehler muss nicht immer zwangsläufig durch schlechte Programmierung auftreten. Auch wenn z.B. die Datenbank im Augenblick nicht erreichbar wäre, würde ein Fehler zurückgegeben werden, der je nach Behandlung einen Abbruch des Programms veranlassen würde. In diesem Fall soll natürlich dafür gesorgt werden, dass der Server wieder erreichbar ist, sobald die Datenbank dies ebenfalls ist.

          Auch wenn man gut programmiert kann man reine Codefehler übrigens niemals zu 100% ausschließen, vor allem nicht wenn man auch auf externe Module (Bibliotheken, Frameworks, etc.) zurückgreift, was man bei großen Projekten wahrscheinlich immer macht.

          1. tim /

            tatsächlich macht das den Ansatz eigentlich nur noch peinlicher. Hat man bei einer größeren und komplexeren Anwendung (und diese werden ständig als besonders geeignet gepriesen) eine Kleinigkeit nicht beachtet – schwupp steht ständig die gesamte Anwendung still. Im Zweifel verlieren Nutzer Daten und weitere Seiteneffekte treten auf.
            Wenn ich 10.000 Nutzer habe, die meintewegen Echtzeitdaten abrufen, dann ist Neustart als Lösung lächerlich. -> Eher ein fundamentaler Konzeptfehler -> gerade im Bereich der Skriptsprachen sollte man solch einen Ansatz tunlichst vermeiden.
            Die Empfehlung man müsse einfach nur korrekt implementieren ist sicher nicht falsch, aber in größeren Projekten dieser Art einfach nicht vollständig zu gewährleisten (es sei denn man tritt gern auf der Stelle).

            1. NodeCode / Beitrags-Autor

              Hat man bei einer größeren und komplexeren Anwendung (und diese werden ständig als besonders geeignet gepriesen) eine Kleinigkeit nicht beachtet – schwupp steht ständig die gesamte Anwendung still. Im Zweifel verlieren Nutzer Daten und weitere Seiteneffekte treten auf.

              Dies muss nicht sein, da es möglich ist, Fehler bei einer Webanwendung z.B. auf Anfragen-Level abzufangen, sodass lediglich die jeweilige Anfrage einen Fehler zurück gibt, nicht jedoch die gesamte Node.js-Anwendung. Das Webframework Express (welches auch die Grundlage von Sails.js bildet) macht dies beispielsweise von Haus aus.

  9. Anonymous /

    Ich muss was dazu schreiben…

    Wirst ja verrückt, das so viele Fehlerhaften Informationen in einem Artikel mit Kommentaren noch Existiert und bei Google zu finden ist.

    Objektorientierung ist sehr wohl in beiden Sprachen möglich und hat nichts damit zu tun, ob es protected, public und private in der Sprache gibt.
    Wichtig an einem Objekt ist nur, dass ihm bestimmte Attribute und Methoden zugeordnet werden können. Alles andere ist „nice to have“…

    PHP ist sehr wohl asynchron zu betreiben und auch nicht unbedingt, auf einem CPU Kern begrenzt….

    Wäre super wenn Du dir den Artikel noch mal vornimmst und Dir selber, der Frage stellst:

    Habe ICH wirklich genug Erfahrung und Wissen, das für Einsteiger korrekt zu beantworten?

    1. NodeCode / Beitrags-Autor

      Um keinen Kritikpunkt unerwähnt stehen zu lassen beantworte ich deinen Kommentar hiermit auch noch.

      Wirst ja verrückt, das so viele Fehlerhaften Informationen in einem Artikel mit Kommentaren noch Existiert und bei Google zu finden ist.

      Objektorientierung ist sehr wohl in beiden Sprachen möglich und hat nichts damit zu tun, ob es protected, public und private in der Sprache gibt.
      Wichtig an einem Objekt ist nur, dass ihm bestimmte Attribute und Methoden zugeordnet werden können. Alles andere ist „nice to have“…

      Da ich in dem Artikel das Wort Objektorientierung nicht erwähne, gehe ich mal davon aus dass sich dieser Punkt auf die Kommentare von anderen Besuchern bezieht. Bitte also nicht bei mir beschweren 😉

      PHP ist sehr wohl asynchron zu betreiben […]

      Wegen dem asynchronen PHP bitte meine Antwort auf den nächsten Kommentar von Andreas lesen, da habe ich das bereits umfassend beantwortet.

      […] und auch nicht unbedingt, auf einem CPU Kern begrenzt….

      Hier beziehst du dich wahrscheinlich auf den Kommentar von „soso“ bzw. auf meine Antwort darauf, oder? In dem Artikel erwähne ich nämlich nichts von CPU-Kernen.

      Ein einzelner Scriptablauf wird in PHP soweit ich weiß auf einem einzigen CPU-Kern ausgeführt, zumindest was die originale PHP-Implementierung angeht. Man kann aber natürlich wie ich in der eben genannten Antwort bereits geschrieben habe einen weiteren Scriptablauf aus einer Anfrage heraus starten, der den ggf. parallel dazu auf einem separaten CPU-Kern ausgeführt wird.

      Ich hoffe dass ich hiermit alle Unklarheiten beantworten konnte.

      Grüße,
      NodeCode

  10. Andreas /

    Mir ist aufgefallen das du unerwähnt lässt, das man auch in PHP eine eventloop haben kann, was dann fast alle Vorteile, die du Node.js zuschreibst auch auf PHP zutreffen müsste.
    Unerwähnt bleiben auch viel zu oft die Nachteile, es ist z.b. sehr praktisch wenn ich nicht bei jeden Request die DB wieder belästigen muss, bedeutet aber auch ich muss mir mehr Gedanken machen, wie lange ich meine Objekte am leben lasse (Garbage Collection)

    1. NodeCode / Beitrags-Autor

      Stimmt, es gibt auch Erweiterungen wie z.B. PECL Ev die eine PHP-basierte Ereignisschleife bereitstellen. Mit React existiert sogar eine PHP-Bibliothek, die eine ähnliche Webanwendungs-Entwicklung wie Node.js ermöglicht.

      Allerdings haben sich eventbasierte PHP-Anwendungen wohl aus folgenden drei Gründen noch nicht durchgesetzt:

      1. Sämtliche I/O-Operationen müssen gemäß der evenbasierten Architektur asynchon ausgeführt werden, damit sie nicht die komplette Anwendung blockieren. Für eine normalerweise synchon ablaufende Programmiersprache wie PHP bedeutet das, dass herkömmliche an I/O-Operationen gebundene Bibliotheken und Frameworks nicht ohne weiteres mit der eventbasierten Architektur verwendet werden können, und es eine spezielle Implementierung hierfür bedarf. Das schließt die Auswahl an Bibliotheken und Frameworks stark ein.

        Gleiches ist übrigens auch bei asynchronen Python-Frameworks wie Tornado der Fall, wobei die Auswahl an speziell dafür entwickelten Bibliotheken dort größer zu sein scheint als bei React. Von Node.js sind beide Lösungen aber immens weit entfernt.

      2. Damit eventbasierte PHP-Anwendungen laufen, muss eine solche Erweiterungen auf dem Server installiert sein. Genau das ist meines Wissens nach aber bei nahezu keinem Webhoster der Fall, oder? Somit muss man dann, wie auch bei Node.js, einen eigenen Server betreiben oder einen speziellen Webhosting-Anbieter finden, der genau das unterstützt.

        Der Vorteil der hohen Verbreitung von PHP ist damit dann de-facto hinfällig, da alles von der Unterstützung der Erweiterung abhängt, und die Verbreitung davon geringer zu sein scheint als die von Node.js.

      3. Laut diversen Benchmarks ist die Rechen-Performance von PHP im Vergleich zu Node.js deutlich schlechter, was sich somit auch negativ auf die Performance der letztendlichen Anwendung auswirken würde, vor allem wenn diese intensiveren Einsatz davon macht.

        Die von Facebook entwickelte alternative PHP-Implementierung HHVM schafft hier Abhilfe und kommt deutlich näher an die Performance von Node.js heran, vorausgesetzt sie ist ebenfalls auf dem Server installiert. PHP 7 soll die Rechengeschwindigkeit in Zukunft ebenfalls beschleunigen.

      Letztendlich sehe ich zum aktuellen Zeitpunkt also keine deutlichen Vorteile von eventbasiertem PHP gegenüber Node.js. Da würde ich persönlich eher zu Go oder Tornado greifen, bevor eventbasiertes PHP für mich in Frage kommt.

      Asynchrones PHP wird im Artikel selbst übrigens deshalb nicht behandelt, da wie bereits geschrieben der Fokus auf PHP und Node.js selbst liegt, und somit nicht alle darauf aufbauenden Projekte bzw. Erweiterungen behandelt werden. Andernfalls würde dies den Rahmen des Artikels einfach sprengen.

      Zurück zu deinem zweiten Kritikpunkt:

      Unerwähnt bleiben auch viel zu oft die Nachteile, es ist z.b. sehr praktisch wenn ich nicht bei jeden Request die DB wieder belästigen muss, bedeutet aber auch ich muss mir mehr Gedanken machen, wie lange ich meine Objekte am leben lasse (Garbage Collection)

      Node.js ermöglicht es gegenüber synchonen PHP zwar Objekte anfragenübergreufend als Variable zwischenzuspeichern, man hat jedoch die freie Wahl ob man zu dieser Methode greift oder nicht. Der Vorteil von Node.js ist hier, dass man diese Möglichkeit hat. Ob es jedoch in einem konkreten technischen Fall auch sinnvoll ist, zu dieser Möglichkeit zu greifen, kann je nach Anwendung variieren und ist eine andere Frage um die es in diesem Artikel nicht geht.

      Mehr Möglichkeiten bedeuten aber in der Tat dass sich der Entwickler mehr Gedanken zur technischen Umsetzung machen muss, da gebe ich dir Recht, weshalb ich wie im Artikel beschrieben für „Anfänger mit wenig Programmier-Erfahrung“ auch (synchones) PHP empfehle.

      Grüße,
      NodeCode

  11. Daniel /

    Lieber Artikelverfasser,

    erstmal natürlich meine Gratulation zu dem sehr ausführlichen Artikel – das hat bestimmt einige Mühe gekostet! Dennoch will ich es nicht unerwähnt lassen, dass einige von Dir geschilderten Vor- und Nachteile doch eine erhebliche Subjektivität durchscheinen lassen. Besser wäre es hier vielleicht etwaige Aussagen kritischer zu hinterfragen. Wobei ich zugestehen muss, dass das natürlich von einer Fanseite von NodeJS nicht zwingend erwartet wird. Dennoch kann es passieren, dass sich der ein oder andere Leser hier hin verirrt ohne sofort zu durchschauen, dass das eine NodeJS Fanseite ist.

    Also Anregung für Dich zum Beispiel mal die folgenden Fragen wo ich Dir anraten würde diese kritisch selbst zu beleuchten:
    Verwendungszweck von PHP laut Deiner Aussage für folgende Webseiten: „einfache Webseiten mit wenigen dynamischen Funktionen“ – Frage an Dich – wie vereinbarst Du das mit folgenden Portalen: „Facebook“, „Wikipedia“, „YouTube“?
    Dein Hinweis auf MVC bzw. die Aussage mit PHP Code direkt in HTML Templates ist auch nicht richtig recherchiert. Die Trennung von PHP und HTML über Templates ist nicht erst durch Nutzung von Frameworks möglich – das kann man selbst programmieren. (also wenn man es kann)

    JavaScript und Objektorientierung ist so eine Sache – das es irgendwie geht mag sein – aber auf keinen Fall geil. PHP hatte insbesondere in der Version 4 ordentliche Defizite bei der Objektorientierung – inzwischen ist das besser. Noch lang nicht so gut wie beispielsweise in C# oder Java. Dennoch ist PHP was Objektorientierung betrifft bei weitem besser als JavaScript. Nicht? Na dann erzähl mir mal wie das mit Vererbung läuft und der Sichtbarkeit von Attributen. (Zugriffsmodifikatoren – Stichwort protected, public und private) – Aber auch die Implementierung von Interfaces? Auch nicht so gell? Das sind aber alles sehr wichtige und moderne Konzepte in der Objektorientierten Softwareentwicklung um einen sauberen, lesbaren und wartbaren Code zu haben.

    Wie gesagt – ich verstehe Deinen Enthusiasmus durchaus und es gibt definitiv Anwendungsgebiete wo NodeJS Punkten kann – aber bei manchen Aussagen wäre ich vorsichtig.

    Herzliche Grüße
    Daniel

    1. NodeCode / Beitrags-Autor

      Verwendungszweck von PHP laut Deiner Aussage für folgende Webseiten: “einfache Webseiten mit wenigen dynamischen Funktionen” – Frage an Dich – wie vereinbarst Du das mit folgenden Portalen: “Facebook”, “Wikipedia”, “YouTube”?

      Ich denke da liegt ein Missverständnis vor. Ich sage nicht, dass komplexe Websites mit PHP nicht möglich wären. Nur, dass Node.js im Vergleich zu PHP von der technischen Seite her dazu besser geeignet ist.

      Dein Hinweis auf MVC bzw. die Aussage mit PHP Code direkt in HTML Templates ist auch nicht richtig recherchiert. Die Trennung von PHP und HTML über Templates ist nicht erst durch Nutzung von Frameworks möglich – das kann man selbst programmieren. (also wenn man es kann)

      Hier liegt die Frage einfach nur in der Definition des Wortes „Frameworks“. Wenn man sich eine solche Struktur selbst programmiert, würde ich das durchaus als selbstprogrammiertes Framework bezeichnen.

      Die Objektorientierung in JavaScript ist in der Tat eine Sache für sich. Ich konnte in einem einzigen Artikel leider nicht auf alle Einzelheiten eingehen und musste mich daher auf ein paar Aspekte beschränken, da der Artikel sonst noch länger geworden wäre. Mein Ziel war es auch nur, einen groben Überblick mit den meiner Meinung nach wichtigsten Punkten zu geben.

      Wie bereits in einem anderen Kommentar geschrieben, bin ich aber am überlegen, evtl. eine Artikelreihe über die Unterschiede von PHP und Node.js zu starten, in der ich dann genauer auf die Details eines einzelnen Aspektes eingehen kann. Das würde sicher auch die zugehörige Diskussion übersichtlicher machen.

      Grüße,
      NodeCode

      1. tim /

        „von der technischen Seite her dazu besser geeignet ist.“

        Nö, eben nicht. Genau wegen der Mängel ist es nicht besser geeignet, weil entsprechend schnell Konflikte auftreten und auch Sicherheitslecks entstehen. Und je größer die Anwendung um so schwerer wiegen solche Probleme. Mit viel Geduld und Frickelei bekommt man das bestimmt vernünftig hin.

        Ganz nebenbei wird aus meiner Sicht außer Acht gelassen, auf welch wackeligem Fundament das Ganze steht. Google entwickelt V8 vornehmlich für Chrome und ist hier faktisch alleiniger Treiber. Wenn neue Ideen das Abschneiden alter Zöpfe erfordern wird Google nicht zögern, dies für Chrome zu tun, mit dem Ergebnis, dass node.js tot ist. Auch andere Projekte wurden schon von heut auf morgen eingestellt. Dass das Ganze Open-Source ist nützt wenig und zum Zeitpunkt des Cuts wird das Know-How fehlen.
        Aber jeder wie er möchte.

        1. NodeCode / Beitrags-Autor

          Was genau soll Node.js denn fehlen, was PHP im Vergleich dazu hat? Mittlerweile unterstützt Node.js übrigens auch von Haus aus ES6-Klassen, falls du darauf hinaus wolltest. Siehe dazu hier: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes

          Dass Node.js aufgrund von V8 von heute auf morgen tot ist, halte ich übrigens für nahezu ausgeschlossen. Diverse namenhafte Unternehmen wie z.B. PayPal, Microsoft, IBM, Intel, SAP, Yahoo oder Red Hat sind in das Projekt involviert. Microsoft hat momentan außerdem vor, die hauseigene JavaScript-Engine ChakraCore als optionale Alternative zu V8 in Node.js zu integrieren.

  12. welle /

    Ich gehöre zur Kategorie der sog. „Hobbyprogrammierer“ betreibe einen virtuellen Linux Root-Server, auch mehr zu Hobbyzwecken, schreibe PHP-Scripts seit ca. 15 Jahren und befasse mich mit Node.js seit ca. 3 Monaten.
    Eigentlich ist in diesem Artikel alles zu finden, was man wissen muss um zu entscheiden, welche serverseitige Scriptsprache zu welcher Problemlösung man verwenden sollte.
    Vielen Dank dafür.
    Der Umstieg von PHP zu Node ist nicht schwer, hatte man doch schon seit Jahren mit Javascript zu tun.
    Was im Artikel fehlt ist die Erwähnung des Linux-Paketmanager ähnlichem genialen Paketsystems NPM zur Modulverwaltung in Nodejs.
    Sowas gibts bei PHP leider nicht, was für mich auch ein Grund zum Umsteigen war.

    1. Malte /

      Doch, eine Art Paketmanager gibt es auch bei PHP:

      https://getcomposer.org/

  13. Stefan /

    Wirklich sehr gut geschrieben und recherchiert. Die hier gelegentlich vorgeworfene fehlende Objektivität kann ich so nicht bestätigen. Ich meine, dass Vor- und Nachteile beider Systeme anschaulich und auf das Mindestmaß reduziert dargestellt wurden. Nebenbei bemerkt arbeite ich am liebsten mit Java, falls mir hier wer Subjektivität unterstellen möchte … 😉

  14. michael mueller /

    grosses lob an den autor, dass er so ausführlich und fachlich auf die jeweiligen posts antwortet! 5*!

    michael

  15. Anonymous /

    Mal umformuliert:

    Anfänger werden zu JavaScript sicherlich mehr im Internet finden, als zum noch recht neuen Zend Framework 3. Wenn man sich jedoch entscheidet, entweder mit JavaScript oder mit Zend Framework 3 anzufangen, so hängt die Entscheidung sicherlich auch davon ab, was genau man damit erreichen möchte. Will man eine HTML-Seite nur mit ein paar dynamischen Funktionen “aufpeppen”, so kann man dafür JavaScript verwenden. Will man hingegen mehr in die Richtung der Webanwendungen gehen, so macht es mehr Sinn, sich mit Zend Framework 3 zu beschäftigen.

    1. NodeCode / Beitrags-Autor

      Was möchtest du uns damit sagen?

      1. Dominique /

        Ich stimme Anonymous dort voll und ganz zu.

        Der Author hat sich sicher Mühe gegeben und die Essenz ist verständlich und nicht falsch.
        Aber:
        Ich sehe auch einiges an Subjektivität durchscheinen. Node.JS ist jünger und bietet einigen Anreiz diverser „Vorteile“ (Unterschiede) ggü. PHP.
        Javascript ist jedoch nicht erst seit 2009 ein Thema und Node.JS bezeichne ich nicht ohne Kontext als „Komplizierter“.

        Da ich auch lange genug auf dem ZF2 gearbeitet habe, mit Zend Server oder selbstgebastelten PHP-Extensions darf ich ganz laut schreien, wenn ich sage, dass PHP nicht zwingend leichter zu erlernen ist als Node.JS

        Ein komplexes CMS, diverse (bereits erwähnte) Social Media Plattformen o.Ä. möchte ich nicht ausschließlich auf Node.JS programmieren.
        Nicht nur wegen der fehlenden Sinnhaftigkeit, auch weil das wahrscheinlich an Folter grenzen würde…

        Beste Grüße
        Dominique

        P.S.: Ein nett gemeinter Tipp an den Author:
        Ich kann der Seite zwar nicht entnehmen woher der/die Author(en) stammen, aber in DE wird seit Längerem definitiv kein Komma mehr vor ein Und gesetzt 😉

  16. VB6er /

    Ganz, ganz herzlichen Dank für diesen Beitrag. Ich suche nach einem dauerhaften Ersatz für VB6-Anwendungen. Nach dem Lesen dieses Artikels glaube ich, die Unterschiede zwischen php (was ich schon nutze) und node.js (von dem ich mich bisher fern hielt) verstanden zu haben.

  17. Angelo /

    Sehr schöner Artikel. Als PHP Entwickler versteh ich nun was es mit dem Hype auf sich hat. Wenn ich mir das Beispiel ansehe, dann ist das aber schon nah dran an Socketprogramierung, d.h. ich kann mir noch ganz andere nicht webspezifische Anwendungen vorstellen.

  18. Anonymous /

    Welcher Praktikant hat denn diesen Text verfasst, Ich hab mich selten so vor Lachen bepisst!

    1. NodeCode / Beitrags-Autor

      Kannst du inhaltliche Fehler vorweisen oder sachlich beschreiben, was genau du an diesem Artikel kritisierst?

      1. Matthias /

        Von anonymen Kritikern, die noch dazu keine konstruktiven Kritikpunkte benennen, sondern einfach nur stänkern, würde ich mich nicht beirren lassen. Ich fand den Artikel sehr gut und hilfreich, um einen Überblick über die grundsätzlichen Unterschiede zwischen Node.js und PHP zu bekommen. Wie die beiden Technologien dann letztendlich eingesetzt werden ist ja nochmal eine ganz andere Frage und sicherlich bei jeder Firma und jedem Programmierer individuell.
        Also, danke für den tollen Überblick!

  19. Hasenpriester /

    Der größte Vorteil von PHP ist wohl die C-nahe Syntax. Gerade wenn man überwiegend objektorientiert programmiert zeigt PHP seine Stärken wohingegen dieses Prototyping in Javascript für mich immer total unübersichtlich wirkt und logische Fehler so nicht schnell genug auffallen.

    1. NodeCode / Beitrags-Autor

      Von der Syntax her sind PHP und JavaScript ungefähr gleich nahe an C gelegen. Du meintest wahrscheinlich stattdessen C++ im Bezug zur Objektorientierung, oder?

      Das Prototyping in JavaScript unterscheidet sich in der Tat von Klassen, wie man sie aus C++ oder PHP kennt. Wenn man mit Prototypen arbeitet, sollte man sich am besten vorher mit dem Konzept dahinter auseinandersetzen. Prototypen sollten nämlich nicht unbedingt so verwendet werden wie typische Klassen, und wenn man es trotzdem macht, dann entsteht meist nur Verwirrung.

      Die nächste JavaScript-Version (ES6) führt übrigens zusätzlich zum Prototyping auch richtige Klassen ein, die ähnlich wie in C oder PHP verwendet werden können. Das wird dich sicherlich erleichtern, falls du mit Prototypen wirklich gar nicht zurecht kommst 😉

  20. george /

    websockets sind schon lange in php verfügbar
    SOCKET_CREATE gibt es schon seit php4

    http://www.sanwebe.com/2013/05/chat-using-websocket-php-socket

  21. soso /

    Aeh, also sry aber deine Gegenüberstellung PHP vs. node.js widerspricht in einigen Punkten klar einer prof. Herangehensweise an Web-Entwicklung:

    1. Natürlich ist es unterste Schublade, HTML und PHP-Code zu mischen, Spaghetti essen wir nur beim Italiener – heute sollte dringenst nach MV(V)C entwickelt werden und am besten mit einer Templating Engine der PHP-Code vom HTML-Code getrennt werden. Views müssen imho z.b. vom Typ HTML sein und im w3c validieren, alles andere ist amateurhaft.

    2. Während eines PHP-Prozesses können sehr wohl Sub-Requests gestartet und asynchron ausgeführt werden, alternativ kann ein Job/Queue-Modell eingerichtet werden. Ein gravierender Nachteil von node.js ist übrigens, dass der Mutter-thread immer nur einen CPU-Kern aufrufen kann, hier ist ein CPU-Loadbalancing eben NICHT möglich (war ja auch ein Grund für die Entwicklung und Verbreitung von PHP)

    3. PHP nur für einfache Webseiten zu empfehlen ist geradezu absurd. Schon mal daran gedacht, auf was Facebook läuft ? PHP mit HHVM, aber eben doch PHP. Rapid Prototyping und schnelle entwicklungszyklen sind gerade mit PHP möglich, auch weil nicht jedes Mal der Server neu gestartet werden muss wie bei node.js…

    Trotzdem wird node.js sicher ein ganzes Stück vom PHP-Kuchen abbeißen, allein wegen des „Hypes“

    1. NodeCode / Beitrags-Autor

      Ich kann nicht nachvollziehen, warum einige Punkte dieses Artikels eindeutig der „profesionellen Herangehensweise an Web-Entwicklung“ widersprechen sollen. Ich denke eher, dass du die entsprechenden Punkte einfach nicht so aufgefasst hast, wie ich das beim schreiben des Artikels ansichtig habe. Um genauer auf die drei von dir genanten Punkte einzugehen:

      1. Natürlich ist es unterste Schublade, HTML und PHP-Code zu mischen, Spaghetti essen wir nur beim Italiener – heute sollte dringenst nach MV(V)C entwickelt werden und am besten mit einer Templating Engine der PHP-Code vom HTML-Code getrennt werden. Views müssen imho z.b. vom Typ HTML sein und im w3c validieren, alles andere ist amateurhaft.

      Ich kann dir darin nur zustimmen, dass man bei der professionellen Webentwicklung mit PHP die Logik von den Views trennen sollte, beispielsweise mit einer Template-Engine oder gleich einem gesamten MVC-Webframework. Allerdings geht in diesem Artikel in erster Linie um den direkten Vergleich von PHP mit Node.js, und nicht um zugehörige Frameworks, die einige Gegebenheiten von PHP verbessern sollten. Auf die Möglichkeit der Verwendung eines Frameworks, um diesen Nachteil auszubügeln, weise ich im Artikel jedoch trotzdem kurz hin:

      […] Hierbei [Node.js] würde man HTML-Code zur Übersicht in eine weitere Datei auslagern, welche dann in die Anwendung geladen wird. Node.js ist also von Grund auf so etwas, wie man es bei PHP erst durch die Verwendung eines Frameworks kennt, mit dem man PHP-Code von den HTML-Templates trennt.

      2. Während eines PHP-Prozesses können sehr wohl Sub-Requests gestartet und asynchron ausgeführt werden, alternativ kann ein Job/Queue-Modell eingerichtet werden.

      Beziehst du dich hierbei auf den Abschnitt „synchron vs. asynchron“? Darin geht es um die Funktionsweise eines einzelnen Programmablaufes. Natürlich gibt es immer die Möglichkeit, einen weiteren Programmablauf zu starten, ansonsten würden die Besucher einer PHP-Website ja solange keine Antwort vom Server erhalten, bis die jeweils vorherige Anfrage zu Ende bearbeitet wurde und wieder Platz für den nächsten ist. Ein einzelner Programmablauf für sich arbeitet bei PHP jedoch asynchon, was z.B. bei datenbanklastigen Webanwendungen vom Nachteil sein kann, da so eine Datenbank-Abfrage alle anderen blockiert.

      Ein gravierender Nachteil von node.js ist übrigens, dass der Mutter-thread immer nur einen CPU-Kern aufrufen kann, hier ist ein CPU-Loadbalancing eben NICHT möglich (war ja auch ein Grund für die Entwicklung und Verbreitung von PHP)

      Ein einziger Mutter-Thread von Node.js kann in der Tat nur einen CPU-Kern nutzen, allerdings ist es durchaus möglich, die Last auf mehrere Kerne zu verteilen, z.B. durch einen Cluster oder durch Child Process. Dabei handelt es sich dann jedoch um einen getrennten Scriptablauf.

      Soweit ich weiß ist das bei PHP nicht anders, auch hier kann ein einzelner Scriptablauf doch ebenfalls nur einen CPU-Kern nutzen, oder? Die Verteilung der Seitenaufrufe auf mehrere CPU-Kerne käme dann allein dadurch zustande, dass bei jedem Seitenaufruf ein eigener Scriptablauf erzeugt wird, und genau eine solche Verteilung auf mehrere Scriptabläufe wäre auch bei Node.js möglich. Hier würde man allerdings in der Regel nicht für jeden einzelnen Aufruf gleich einen eigenen Scriptablauf erzeugen, sondern stattdessen genau so viele Scriptablaufe bereitstellen, wie Prozessor-Kerne zur Verfügung stehen. Das ist nämlich um einiges performanter, als jedes mal erst alle benötigten Zustände zu initialisieren, bevor mit der eigentlichen Generierung der Webseite begonnen werden kann (wie auch im Abschnitt „Frameworks & Bibliotheken“ beschrieben).

      Fall PHP pro Scriptablauf als tatsächlich auch nur einen CPU-Kern nutzen kann, so sehe ich hier keinen Nachteil von Node.js gegenüber PHP. Anderenfalls hätte PHP genau is als Vorteil, während Node.js hingegen dadurch punktet, dass initiale Zustände nicht vor jedem Seitenaufruf erneut hergestellt werden müssen. Die entscheidende Frage wäre dann, welcher dieser beiden Vorteile sich für das jeweilige Szenario besser macht.

      Nicht zu vergessen ist hier übrigens noch JXcore, womit sich Node.js-Programme auch ohne spezielle Anpassungen am Code auf mehrere Prozessorkerne verteilen lassen.

      3. PHP nur für einfache Webseiten zu empfehlen ist geradezu absurd.

      Hier interpretierst du den Artikel im Detail falsch. Ich habe nicht geschrieben, dass PHP „nur“ für einfache Websites geeignet ist, sondern lediglich, dass PHP für einfache Webseiten prinzipiell besser geeignet ist als Node.js. Genau lesen 😉

      Beispiel: Angenommen jemand möchte eine Website programmieren, deren einzige dynamische Funktion darin besteht, die aktuelle Uhrzeit im Header, und das aktuelle Datum beim Copyright im Footer auszugeben. Dann wäre es ganz einfach unsinnig, eine komplette Node.js-Umgebung aufzubauen, bei der man die Daten in ein Template einfügt, oder genauso dafür ein PHP-MVC-Webframework zu verwenden. Stattdessen könnte man dies mit PHP viel schneller realisieren, indem man einfach an die beiden Stellen den PHP-Bereich öffnet, und die entsprechenden Daten ausgibt. Node.js sowie sämtliche PHP-MVC-Frameworks machen eben erst ab einer gewissen Komplexität der Anwendung Sinn, die über typische „Hallo Welt“-Beispiele & Co. hinausgeht.
      Anmerkung: Dieses Beispiel könnte man tatsächlich als Wiederspruch zur „profesionellen Herangehensweise an Web-Entwicklung“ auslegen 😉

      Hinzu kommen noch die unzähligen unzähligen Unterschiede zwischen Node.js und PHP, zu denen ich im Artikel schon genug geschrieben habe. Vor allem die Tatsche der Programmcode einer Node.js-Anwendung die ganze Zeit im Hintergrund aktiv ist kann bei kleinen und einfachen Websites vom Nachteil sein, da so der Arbeitsspeicher des Servers blockiert wird, auch wenn die Website z.B. nur alle 60 Minuten aufgerufen wird. Bei Webseiten mit starken Traffic verhält es sich hingegen genau anders herum, hier kann genau das vom Vorteil sein, da der Code so nicht 100x erneut geladen und initialisiert werden muss, wenn 100 Besucher die Website gleichzeitig aufrufen.

      Schon mal daran gedacht, auf was Facebook läuft ? PHP mit HHVM, aber eben doch PHP.

      Natürlich kann man auch mit PHP komplexe Websites umsetzen. Ich würde allerdings auch bei Facebook behaupten, dass man die Webanwendung mit Node.js um einiges schneller komplett neu programmieren könnte, als das bei einer Neuprogrammierung mit PHP der Fall wäre. Aber beweisen kann ich das natürlich nicht. ;D

      Rapid Prototyping und schnelle entwicklungszyklen sind gerade mit PHP möglich, auch weil nicht jedes Mal der Server neu gestartet werden muss wie bei node.js…

      Das ist tatsächlich ein nennenswerter Nachteil von Node.js gegenüber PHP, den ich im Artikel auch geschildert habe (siehe im Abschnitt Performance vs. Neustart). Vor Allem bei stark frequentierten Websites könnte das möglicherweise ein entscheidender Grund gegen Node.js sein, allerdings gibt es eine relativ einfache Lösung für dieses Problem: Man startet ein neues Node.js-Programm mit dem geänderten Code, hält jedoch das vorherige Programm so lange offen, bis das das neue bereit ist die Anfragen entgegenzunehmen. Anschließend schaltet man die eingehenden Anfragen auf das neue Programm um, und beendet das alte. So hat man eine Downtime von (nahezu?) 0 Sekunden.

      Ein Beispiel für den Einsatz dieses Lösungsansatzes ist die Foren-Software NodeBB, die dieses Prinzip ab der Version 0.5.1 implementiert. Ein lesenswerter Artikel dazu in dem unter Anderem um dieses Prinzip geht findet sich im offiziellen Blog.

      1. Anonymous /

        Da der Artikel ohne Betrachtung der MVC-Frameworks auskommen möchte und auch Tipps für Serverneustarts in „stark frequentierten“ Produktivsystemen gegeben werden, ist die Zielgruppe: klar der Einstieg in die Hoppyprogrammierung. Dafür finde ich Ihn auch gut gelungen.

        1. NodeCode / Beitrags-Autor

          Ich bin absichtlich nicht auf (MVC-)Frameworks eingegangen, da es mir bei diesem Artikel darum geht, PHP an sich mit Node.js zu vergleichen, und nicht ein ausgewähltes PHP-Webframework mit einem ausgewählten Node.js-Webframework. Es ging mir nur um den grundlegenden Aufbau der beiden Technologien, auf mehr zielt der Artikel nicht ab.

          In sofern könnte man durchaus sagen, dass die Zielgruppe Anfänger (oder wie du sie nennst „Hobbyprogrammierer“) in mindestens einer der beiden Technologien sind, die sich einen groben Überblick über die grundlegenden Unterschiede verschaffen wollen. Was aber nicht bedeuten muss, dass es auch bei diesem grundlegenden Wissen bleibt.

          Für den professionellen Einsatz sollte man natürlich wie schon erwähnt sowohl bei PHP, als auch bei Node.js in der Regel ein (MVC-)Webramework verwenden, da stimme ich dir vollkommen zu.

          Ich überlege mir momentan, ob ich vielleicht einen Artikelreihe mit dem Unterschieden zwischen PHP und Node.js starte. Hierbei könnte ich mich dann pro Artikel auf ein bestimmten Aspekt konzentrieren, und somit auch auf weiterführende Details eingehen. Ein Vergleich zwischen einem PHP-Framework und einem Node.js-Webframework wie Express wäre dann sicherlich auch ein Thema.

          1. Wombat /

            MVC ist ein Programmier-Paradigma und hat NICHTS mit PHP, node.js oder irgendwelchen Frameworks zu tun!
            MVC sollte bei JEDER modernen Programmierung Anwendung finden, weil es sich als moderne „Programmierweise“ durchgesetzt hat, völlig gleich, welcher Programmiersprache man sich bedient oder in welcher Umgebung man arbeitet! Dafür braucht man auch keine Frameworks, weder in PHP, noch irgendwo anders. MVC beschreibt lediglich die Art und Weise und die Struktur, eine Programmierung umzusetzen.
            Hier wird immer so getan, als ob PHP ohne zusätzliche Frameworks kein MVC „könne“, das ist natürlich totaler Quatsch. Existierende Frameworks machen die Arbeit vielleicht etwas einfacher, weil sie die Grundstruktur schonmal vorgeben, aber – nochmal – MVC hat nichts mit der Programmiersprache zu tun! Jeder kann seine Projekte – auch ohne Framework! – nach MVC-Masstäben strukturieren! In jeder Programmiersprache.
            Auch in der Anwendungsentwicklung mit C++, iOS, Android oder wo auch immer halten sich professionelle Entwickler immer an die MVC-Paradigmen. Und solche Aussagen, dass „PHP-Code immer im HTML-Code steht“ ist Käse und zeigen, dass das Grundprinzip von MVC mal überhaupt nicht verstanden wurde.

            1. NodeCode / Beitrags-Autor

              Hier wird immer so getan, als ob PHP ohne zusätzliche Frameworks kein MVC “könne”, das ist natürlich totaler Quatsch. Existierende Frameworks machen die Arbeit vielleicht etwas einfacher, weil sie die Grundstruktur schonmal vorgeben, aber – nochmal – MVC hat nichts mit der Programmiersprache zu tun! Jeder kann seine Projekte – auch ohne Framework! – nach MVC-Masstäben strukturieren! In jeder Programmiersprache.

              Hier interpretierst du wahrscheinlich etwas hinein, was so gar nicht gesagt wurde. Ich sprach in meinem letzten Kommentar explizit von (MVC-)Frameworks, nicht vom MVC-Entwurfmuster allgemein.

              Und solche Aussagen, dass “PHP-Code immer im HTML-Code steht” ist Käse und zeigen, dass das Grundprinzip von MVC mal überhaupt nicht verstanden wurde.

              Dass “PHP-Code immer im HTML-Code steht”, habe ich ebenfalls nirgendwo geschrieben. Im Code-Abschnitt (auf den du dich wahrscheinlich beziehst) ging es mir nur um den grundlegenden Aufbau, nicht darum, wie man PHP in einem professionellen Projekt nach dem MVC-Muster verwenden würde. Aber ja, dieser Absatz ist etwas missverständlich formuliert.

              1. Timo Linde /

                Du weißt schon das ein MVC-Framework eine implementierung des MVC-Musters ist?

                1. NodeCode / Beitrags-Autor

                  Ja, und?

      2. Timo Linde /

        „Hier interpretierst du den Artikel im Detail falsch. Ich habe nicht geschrieben, dass PHP „nur“ für einfache Websites geeignet ist, sondern lediglich, dass PHP für einfache Webseiten prinzipiell besser geeignet ist als Node.js. Genau lesen 😉“

        Er hat nicht geschrieben „geeignet“ sondern „empfohlen“. Bitte genau lesen 😀

        1. NodeCode / Beitrags-Autor

          Das Wort „geeignet“ ist in diesem Zusammenhang schon richtig, da es dem Schreiber des Kommentars scheinbar darum ging, aufzuzeigen, dass auch große Websites mit PHP (bzw. einer Reimplementierung von PHP) laufen.

          Die gesamte Aussage dieses Punktes lautete:

          3. PHP nur für einfache Webseiten zu empfehlen ist geradezu absurd. Schon mal daran gedacht, auf was Facebook läuft ? PHP mit HHVM, aber eben doch PHP. Rapid Prototyping und schnelle entwicklungszyklen sind gerade mit PHP möglich, auch weil nicht jedes Mal der Server neu gestartet werden muss wie bei node.js…

      3. tim /

        Das Uhrzeit Beispiel ist unpassend, denn bevor man PHP installiert würde man hierfür JavaScript nutzen, das dies diese Anforderung auch Clientseitig erledigen könnte. Hier reicht uralt-javascript

        1. NodeCode / Beitrags-Autor

          Stimmt, mit clientseitigem JavaScript ließe sich das mit Sicherheit noch schneller realisieren, wenn man den Installationsprozess von PHP mit in die Rechnung aufnimmt, und sich mit der Uhrzeit des jeweiligen Besuchers (also nicht der Serverzeit) zufrieden gibt.

    2. Nico /

      Die Seite hier nennt sich nodecode.de. Hast Du ne 100% objektiven Vergleicht erwartet? 😉 Ich nicht.

  22. Anonymous /

    V8 verwendet einen Just In Time Compiler, der ECMA Script direkt in Maschinencode umsetzt, und nicht wie hier beschrieben C als Zwischenstufe verwendet.

    1. NodeCode / Beitrags-Autor

      Danke für den Hinweis, ich haben den entsprechenden Absatz soeben geändert.

  23. Ddd /

    Gute einfuehrung,
    Allerdings kenne ich noch keine nodejs-basierte webseite, die es zb mit facebook oder einer komplexen TYPO3-Seite aufnehmen kann. Hier waere mal ein Applikationsvergleich wichtig.

    1. NodeCode / Beitrags-Autor

      Von PayPal weiß ich, dass die Konten-Übersichtsseite mit Node.js umgesetzt wurde. Da sich PayPal noch unsicher in der Verwendung von Node.js war, wurde zur Sicherheit auch zeitgleich eine auf Java basierende Anwendung entwickelt.

      Aus der gleichzeitigen Entwicklung ergaben sich interessante Vergleichsdaten, wie Harrell ausführt. Zwei Node.js-Entwickler benötigten einige Monate, um die erforderliche Software zu erstellen – und damit nur gut die halbe Zeit, die ein Fünf-Mann-Team mit Java brauchte. Die Node.js-App war mit 33 Prozent weniger Codezeilen zu schreiben und erforderte 40 Prozent weniger Dateien. Darüber hinaus brauchte es aber einige Monate Arbeit für den einmaligen Aufbau der Infrastruktur, um Node.js zu Paypal kompatibel zu machen.

      Belastungstests ergaben, dass die Node.js-Anwendung auf Anfragen durchschnittlich um 35 Prozent schneller reagierte als die Java-Alternative. Eine Seite konnte damit um 200 Millisekunden schneller ausgeliefert werden – “etwas, was die Nutzer sicherlich bemerken werden”.

      Quelle: http://www.zdnet.de/88177519/paypal-ersetzt-java-durch-javascript/

      PayPal hat auch angekündigt, sämtliche Webanwendungen die sich an die Nutzer richten, zukünftig mit Node.js zu realisieren.

      1. Ronny /

        Und was beweist das nun?

        Es wurde hier im Wesentlichen ein „Webservice“ von Java nach Node.js umgesetzte. Und für solche Anwendungen ist Node.js auch wirklich gut geeignet. Das man auch größere Anwendungen so realisieren kann steht außer Frage.

        Ich habe schon vor mehr als 10 Jahren Java basierte Webanwendungen nach PHP umgesetzt. Das Ergebnis war immer schnellere Reaktionszeiten und einfacherer/weniger Code.

  24. Carsten /

    Sehr interessanter Artikel, auch der vorherige.

    Ich bin zwar totaler Anfänger in JavaScript und habe vergleichsweise mehr Erfahrung mit PHP. Dafür will ich mich in Richtung Webapps orientieren und sowieso auf JavaScript spezialisieren. Node.js ist da nur ein logischer Schritt.

    Tolle Seite (und die vielleicht erste gute, deutschsprachige Informationsquelle für Node.js?), super lehrreiche Artikel für mich. Weiter so!

  25. Anonymous /

    Guter Überblick! Danke!

hinterlasse einen Kommentar