Suche

Schluss mit Java – es lebe Node.js: Liegt PayPal wirklich richtig?

Hartmut Schlosser
©Shutterstock/DVARG

PayPal wechselt von Java nach Node.js. Das bestätigt PayPal-Entwickler Jeff Harrell in einem Blogpost, in dem er auch die Gründe beschreibt, warum PayPal-Webanwendungen fortan in JavaScript und Node.js umgeschrieben werden. Alles nur die halbe Wahrheit – kommentiert indes Andy McKay von Mozilla.

Schauen wir uns zunächst die PayPal-Variante der Geschichte an:

Ursprünglich war das PayPal-Team in eine Browser- und ein Applikationslayer-Abteilung aufgeteilt, so wie man das sicherlich in vielen realen Unternehmensprojekten finden wird: Browser-seitig HTML, CSS, JavaScript – auf dem Server Java. Dieses Modell greift laut Jeff Harrell bei PayPal nicht mehr, da „Full-Stack“-Ingenieure ins Team gekommen sind, die beides können: gute User Interfaces programmieren, danach die Applikationslogik dahinter bauen.

Und das tun diese „Einhörner“, wie Harrell sie nennt, mittels Node.js auf dem Server. So sei nur noch ein Team nötig, das jederzeit an beliebigen Stellen des Technologie-Stacks eingreifen könne, um die Anwendung an die Bedürfnisse der User anzupassen.

Weitere, für Java unrühmliche Fakten kommen hinzu:

Bei PayPal wurde zunächst die Account-Übersichtsseite mit Node.js gebaut – also eine wichtige High-Traffic-Page. Um das Risiko zu minimieren, wurde parallel an einer neuen Java-Variante dieser Account-Seite gearbeitet. Dies ermöglicht Harrell nun allerlei Vergleiche, mit dem folgenden Ergebnis: Das Node.js Team war kleiner und begann zwei Monate später, schloss aber zur selben Zeit wie das Java-Team ab. Die Node.js-Version sei also in der Entwicklung effektiver gewesen, enthalte 33% weniger Zeilen Code, 40% weniger Dateien, und zeige darüber hinaus eine bessere Performance. Schluss daher mit Java – es lebe Node.js.

Ein vehemente Reaktion provoziert Harrell mit dieser Argumentation bei Mozilla-Entwickler Andy McKay. Denn hier werden seiner Meinung nach Technologien vorgeschoben, um organisatorische Probleme zu verschleiern.

Könnte es nicht sein, dass die schlechte Kommunikation bzw. Zusammenarbeit zwischen „Backend“- und „Frontend“-Entwicklern bei PayPal das eigentliche Problem war bzw. ist? Denn erstens können sich Java-Entwickler problemlos an der UI-Entwicklung mit anderen Technologien beteiligen – schließlich ist man heutzutage polyglott und lernt niemals aus. Zweitens wurde nichts über die im Java-Team verwendeten Werkzeuge und Freamworks gesagt, die ja maßgeblich sind für produktives Arbeiten – war man da bei PayPal wirklich auf der Höhe der Zeit?

Und drittens müsse es in expandierenden Unternehmen ohnehin ständig zur Zusammenarbeit zwischen Teams kommen – über Technologie- und Fachgrenzen hinweg. Wenn das bei PayPal schon früher das Problem war, werde dieses mit einem Technologie-Wechsel nicht einfach über Nacht verschwinden.

Jedenfalls könne man eine Schlussfolgerung, mit Node.js sei man in jedem Fall besser bedient als mit Java, nicht gelten lassen. Wenn PayPal Prozessprobleme in der IT-Abteilung habe, dann sitze es möglicherweise in ein paar Jahren auf seiner Node.js-Insel im gleichen Dilemma und frage sich wieder: Mit welcher anderen Technologie kommen wir hier raus?

Wie auch immer – PayPal setzt auf Einhörner und Node.js. Jeff Harrell kündigt an, dass in Kürze ein eigenes Framework namens kraken.js Open Souce zur Verfügung gestellt werden soll: eine Applikationsschicht auf Basis des Node.js-Routers express, die auf Skalierbarkeit in großem Unternehmensmaßstab ausgelegt ist.

Aufmacherbild: Raster version. Running blue fire unicorn on black background von Shutterstock / Urheberrecht: DVARG

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Hartmut Schlosser ist Redakteur und Online-Koordinator bei Software & Support Media. Seine Spezialgebiete liegen bei Java-Enterprise-Technologien, JavaFX, Eclipse und DevOps. Vor seiner Tätigkeit bei S & S Media studierte er Musik, Informatik, französische Philologie und Ethnologie.
Kommentare
  1. Another Voice2013-12-03 07:10:28

    Die Argumentationskette funktoniert nicht: Der Webstack besteht aus HTML + Javascript und einem Backend und (optional) einer Datenbank.

    Ohne Javascript wird es nirgendwo funktionieren. Das ist ein essentieller Teil des Stacks. Java ist das nicht.

    "Wenn PayPal Prozessprobleme in der IT-Abteilung habe" ..

    Das Problem sind Java-EE Entwickler, die in Wirklichkeit Webentwickler sind und "nicht mit dem HTML Mist" zu Tun haben wollen und leider kein Teil der Lösung sind sondern ein Teil des Problems.

    Es gibt abgesehen davon noch genügend technische Gründe.

    1. Pffft2013-12-03 15:47:48

      "Der Webstack besteht aus HTML + Javascript und einem Backend und (optional) einer Datenbank."

      Wenn man sich den Stack so aufbaut, dann hast du natürlich absolut Recht. Am Ende ist es aber so, dass die Client Seite aus HTML besteht. Punkt. Man kann beliebige Webseiten auch ohne JavaScript entwickeln. Das war über Jahrzehnte Standard. Schon zieht dein Argument nicht mehr, denn JavaScript ist in deinem Stack nirgends vorhanden.

      Versteh mich nicht falsch, ich habe nichts gegen JavaScript und erst recht nicht gegen Node.js, aber ich habe etwas gegen Pseudoargumente.

      "Das Problem sind Java-EE Entwickler, die in Wirklichkeit Webentwickler sind und "nicht mit dem HTML Mist" zu Tun haben wollen ... "
      Ich bin seit etwa einem Jahrzehnt Java/JEE Entwickler und habe viel Zeit in internationalen Großprojekten verbracht. Ich habe kein Problem damit HTML/CSS/JavaScript zu schreiben. Ich weiß nur dass ich langsamer sein werde als ein Webdesigner und dass mein Output u.U. nicht so gut aussehen wird. Manchmal muss man die Hintergründe beleuchten, wieso ein Entwickler bestimmte Aufgaben gern abgibt ...

      Diese Vorurteile und dein Schubladendenken sind die Hauptprobleme für die organisatorischen Probleme, die im Artikel angesprochen werden. Sie erzeugen nämlich Gräben, über die niemand gern springt ...

  2. hansPeter2013-12-03 10:39:21

    Wie konnte es kommen, dass Paypal für Ihr System verschiedene technologische Stacks hat (JSP, Grails, Ruby)? Kann es sein, dass man nun diese Technologievielfalt wieder "einfangen" will und nun den kleinsten gemeinsamen Nenner sucht???
    Das hat dann aber erst einmal nichts mit Java als Technologie an sich zu tun, sondern mit einem missglücktem Architektur-Management.

  3. Tolga2014-01-14 11:44:45

    Paypal hat neben NodeJS parallel in Java die gleiche Anwendung geschrieben. Und da die Anwendung zuvor mit der Java EE Spezifikation erfolgreich implementiert und gewartet wurde, kann ich mir eine schlechte Kommunikation zwischen dem Front- und Backend-Team nicht wirklich vorstellen.

    Dieser Benchmark ist definitiv kritisch zu sehen und wurde wahrscheinlich verschönert, aber man sollte da keine Mutmaßungen treffen, dass der Grund zum Wechsel durch schlechte Kommunikation bedingt ist. Auch andere Firmen wie bspw. Groupon haben ihre Anwendung auf Nodejs umgestellt.

  4. Phred2014-01-16 10:08:53

    Man kann nicht ein Entwicklerteam mit einem anderen Entwicklerteam vergleichen, welches auch noch eine andere Technologie einsetzt. Aus so einem Vergleich gezogene Schlussfolgerungen sind nicht belastbar.

    Teams unterscheiden sich prinzipiell stark aufgrund der unterschiedlichen personellen Zusammensetzung. Kennwerte wie Codequalität, Codeumfang und Projektdauer werden maßgeblich beeinflusst von Erfahrung und Fachkompetenz sowie auch der sozialen Kompetenz der Teammitglieder.

  5. Eugene2014-02-17 15:37:46

    Ohje, da fühlt sich jemand von einem "Einhorn" auf den Fuß getreten. Tut mir leid.

    Eine Runde Mitleid bitte :-)

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.