Warum ist ein Mann in der Java-Welt ein leidenschaftlicher Unterstützer von Node.js und JavaScript geworden?

David Harron, der Autor des Materials, das wir heute veröffentlichen, stellte die folgende Frage: „Sollte eine Person, die mehr als 10 Jahre bei Sun Microsystems im Java SE-Team gearbeitet hat, bis zum letzten Atemzug nur an Java-Bytecode denken und Instanzen abstrakter Schnittstellen erstellen? ". Er stellte diese Frage in Bezug auf sich selbst, und für ihn erwies sich die Node.js-Plattform nach Java als ein Hauch frischer Luft. David sagt, als er im Januar 2009 (kurz vor der Übernahme dieses Oracle-Unternehmens) von Sun entlassen wurde, habe er von Node.js erfahren. Diese Technologie hat ihn begeistert. Was bedeutet es "süchtig"? Seit 2010 hat er viel über das Programmieren für Node.js geschrieben. Er schrieb nämlich mehrere Bücher, darunter Node.js Web Development, dessen vierte Ausgabe dieses Jahr veröffentlicht wurde. Er hat viele kleine Materialien über Node.js vorbereitet, die im Internet veröffentlicht wurden. Tatsächlich verbrachte er viel Zeit und Mühe damit, über die Node.js-Plattform und die JavaScript-Funktionen zu sprechen. Warum haben sich diejenigen, die zuvor ausschließlich in Java gearbeitet haben, so für Node.js und JavaScript interessiert?

Über die Java-Welt

Während meiner Arbeit bei Sun habe ich an Java-Technologie geglaubt. Ich hielt Präsentationen in JavaONE, nahm an der Entwicklung der Klasse java.awt.Robot teil, organisierte die Veranstaltung Mustang Regressions Contest (ein Wettbewerb zur Suche nach Fehlern in Java 1.6) und half beim Start des Projekts Distributions License for Java, das als Antwort diente auf die Frage nach Linux JDK-Distributionen vor dem Aufkommen von OpenJDK. Später spielte ich eine Rolle beim Start des OpenJDK-Projekts. Unterwegs habe ich ungefähr 6 Jahre lang Blog-Material auf java.net veröffentlicht (jetzt ist diese Seite geschlossen). Dies waren 1-2 Artikel pro Woche, die wichtigen Ereignissen im Java-Ökosystem gewidmet waren. Eine wichtige Rolle in meiner Arbeit spielte der Schutz von Java vor denen, die eine düstere Zukunft für diese Technologie vorhersagten.


Diese Auszeichnung, der Duke Award, wurde an die angesehensten Mitarbeiter von Sun vergeben. Ich habe es bekommen, nachdem ich den Mustang Regressions Contest organisiert habe

Was ist mit der Person passiert, die so viel mit allem zu tun hat, was mit Java zu tun hat? Eigentlich möchte ich hier darüber sprechen, wie ich mich von einem Java-Anhänger zu einem leidenschaftlichen Unterstützer von Node.js und JavaScript entwickelt habe.

Ich muss sagen, dass das, was mir passiert ist, nicht als völlige Aufgabe von Java bezeichnet werden kann. In den letzten 3 Jahren habe ich ziemlich viel Java-Code geschrieben und Spring und Hibernate verwendet. Obwohl mir das, was ich jetzt in diesem Bereich mache, wirklich gefällt (ich arbeite in der Solarbranche, mache das, was ich gerne mache - ich schreibe Anfragen für die Arbeit mit Daten aus dem Energiesektor), ist Java-Programmierung jetzt in meinen Augen verlor seine frühere Pracht.

Durch die zweijährige Entwicklung mit Spring konnte ich eines klarstellen: Ein Versuch, komplexe Mechanismen zu verbergen, führt nicht zu Einfachheit, sondern nur zum Auftreten noch komplexerer Strukturen.

Hier sind kurz die wichtigsten Ideen, die ich in diesem Material ansprechen werde:

• Java-Programme sind voll von Code, der die Absichten des Programmierers verbirgt.
• Die Arbeit mit Spring und Spring Boot hat mir eine gute Lektion erteilt: Der Versuch, komplexe Mechanismen zu verbergen, führt zu noch komplexeren Konstrukten.
• Die Java EE-Plattform war ein Projekt, das sozusagen durch „gemeinsame Anstrengungen“ erstellt wurde und absolut alle Anforderungen der Entwicklung von Unternehmensanwendungen abdeckt. Infolgedessen hat sich die Java EE-Plattform als unerschwinglich erwiesen.
• Sich mit dem Frühling zu entwickeln ist bis zu einem gewissen Punkt eine angenehme Erfahrung. Diese Illusion verschwindet an dem Tag, an dem eine Ausnahme, die völlig unverständlich ist, aus den Tiefen eines Subsystems kommt, von dem Sie noch nie gehört haben, und es dauert mindestens drei Tage, um herauszufinden, wo das Problem liegt.
• Welche Hilfsmechanismen, die das System übermäßig belasten, benötigen Sie ein Framework, das Code für Programmierer "schreiben" kann?
• Obwohl IDEs wie Eclipse leistungsstarke Anwendungen sind, sind sie ein Indikator für die Komplexität des Java-Ökosystems.
• Die Node.js-Plattform entstand aufgrund der Bemühungen einer Person, ihre Vision einer leichten ereignisgesteuerten Architektur zu verbessern.
• Die JavaScript-Community scheint begeistert davon zu sein, Boilerplate-Code loszuwerden, der es Programmierern ermöglicht, ihre Absichten so klar wie möglich auszudrücken.
• Async / await ist eine Lösung für das Problem der JS-Rückrufhölle, das ein Beispiel für die Ablehnung von Vorlagencode darstellt und zur Klarheit des Ausdrucks von Programmiererabsichten beiträgt.
• Das Programmieren für Node.js ist ein echtes Vergnügen.
• In JavaScript gibt es keine Java-spezifische Typisierung. Dies ist der Segen und Fluch der Zunge. Dies erleichtert das Schreiben von Code, aber um die Richtigkeit zu überprüfen, müssen Sie mehr Zeit für das Testen aufwenden.
• Das von npm / yarn eingeführte Paketverwaltungssystem ist einfach und macht Spaß. Sie kann nicht mit Maven verglichen werden.
• Sowohl Java als auch Node.js bieten eine hervorragende Leistung. Dies widerspricht dem Mythos, dass JavaScript eine langsame Sprache ist, deren Verwendung zu einer schlechten Leistung der Node.js-Plattform führt.
• Leistung Node.js baut auf den Bemühungen von Google auf, V8 zu verbessern, die Engine, die sich auf die Geschwindigkeit des Chrome-Browsers auswirkt.
• Der harte Wettbewerb zwischen Herstellern von browserbasierten JS-Engines trägt zur Entwicklung von JavaScript bei, was für Node.js sehr vorteilhaft ist.

Informationen zu Java-Entwicklungsproblemen

Einige Werkzeuge oder Objekte sind das Ergebnis langjähriger Bemühungen der Ingenieure, sie zu verbessern. Programmierer probieren verschiedene Ideen aus, entfernen unnötige Attribute und erhalten dadurch Entitäten, in denen ausschließlich das vorhanden ist, was zur Lösung eines bestimmten Problems erforderlich ist. Oft haben solche Technologien eine sehr attraktive Einfachheit, die leistungsstarke Funktionen verbirgt. Dies gilt nicht für Java.

Spring ist ein beliebtes Framework für die Entwicklung von Java-basierten Webanwendungen.

Das Hauptziel von Spring und insbesondere von Spring Boot besteht darin, die Verwendung des vorkonfigurierten Java EE-Stacks bereitzustellen. Der Programmierer, der Spring verwendet, sollte sich nicht um Servlets, persistente Speichersysteme, Anwendungsserver und Unbekanntes kümmern, um ein vorgefertigtes System zu erstellen. All diese Bedenken werden an Spring weitergegeben, und der Programmierer schreibt Code, der die Logik der Anwendung implementiert. Beispielsweise sind JPARepository-Mechanismen für die Generierung von Datenbankabfragen für Methoden verantwortlich, deren Namen wie findUserByFirstName aussehen. Der Programmierer muss den Code für solche Methoden nicht schreiben. Es reicht aus, die Beschreibung der Methode an das System zu übergeben, und Spring erledigt den Rest.

Es klingt alles sehr gut, es ist schön, in diesem Stil zu arbeiten, aber - bis etwas Unerwartetes passiert.

Ich meine eine Situation, in der zum Beispiel eine Hibernate PersistentObjectException ausgelöst wird, bei der die von der Nachricht detached entity passed to persist . Was könnte es bedeuten? Es dauerte mehrere Tage, um es herauszufinden. Wenn Sie alles sehr vereinfacht beschreiben, bedeutet dies, dass die am REST-Endpunkt empfangenen JSON-Daten ID-Felder mit einigen Werten enthalten. Wenn Sie nicht auf Details eingehen, versucht der Ruhezustand erneut, die ID-Werte zu steuern, und löst daher die obige undurchsichtige Ausnahme aus. Es gibt Tausende solcher Fehlermeldungen, die verwirrend und schwer zu lesen sind. Wenn man bedenkt, dass es im Frühjahr ganze Kaskaden von Subsystemen gibt, die aufeinander basieren, sieht der Spring-Stapel wie ein vereidigter Feind eines Programmierers aus, der ihn beobachtet und darauf wartet, dass der Programmierer den geringsten Fehler macht, und in diesem Fall Ausnahmen auslöst, die nicht mit ihm kompatibel sind normaler Betrieb der Anwendung.

Außerdem können Sie hier die längsten Stapelspuren abrufen. Sie repräsentieren mehrere Bildschirme mit allen möglichen abstrakten Methoden. Spring erstellt offensichtlich die Konfiguration, die erforderlich ist, um das zu implementieren, was im Code ausgedrückt wird. Eine solche Abstraktionsebene erfordert zweifellos eine beträchtliche Menge an Hilfslogik, die darauf abzielt, alles zu entdecken, was zum Funktionieren des Codes erforderlich ist, um beispielsweise Anforderungen zu erfüllen. Und lange Stapelspuren sind nicht unbedingt schlecht. Solche Dinge sind eher ein Symptom, das zu der Frage führt, welche Art von Belastung des Systems durch Hilfsmechanismen erzeugt wird.

Wie wird die findUserByFirstName Methode findUserByFirstName , da der Programmierer den Code für eine solche Methode nicht geschrieben hat? Das Framework muss den Methodennamen analysieren, die Absicht des Programmierers verstehen, so etwas wie einen abstrakten Syntaxbaum erstellen, eine Art SQL-Code generieren und so weiter. Wie lädt das alles das System? Und das alles nur, damit der Programmierer keinen Code schreiben muss?

Nachdem Sie einige zehn Mal nach der Bedeutung des oben genannten Fehlers gesucht haben und wochenlang versucht haben, Geheimnisse zu entschlüsseln, die Sie im Großen und Ganzen nicht enträtseln sollten, können Sie zu dem gleichen Schluss kommen, zu dem ich gekommen bin . Seine Bedeutung ist, dass der Versuch, komplexe Mechanismen zu verbergen, nicht zur Einfachheit führt, sondern nur zum Auftreten noch komplexerer Strukturen. Die Node.js-Plattform ist viel einfacher.

Der Slogan „Compatibility Matters“ verbarg eine wunderbare Idee, wonach Abwärtskompatibilität das wichtigste Merkmal der Java-Plattform war. Wir haben das ernst genommen und Bilder auf T-Shirts wie das unten gezeigte angebracht.


Abwärtskompatibilität ist sehr wichtig.

Natürlich kann dieses Maß an Aufmerksamkeit für die Abwärtskompatibilität eine Quelle ständiger Angst sein, und von Zeit zu Zeit ist es nützlich, sich von alten Mechanismen zu entfernen, die nicht mehr davon profitieren.

Java und Node.js.

Spring und Java EE sind zu kompliziert. Die Node.js-Plattform vor ihrem Hintergrund wird als ein Hauch frischer Luft wahrgenommen. Das erste, was Sie bemerken, wenn Sie Node.js kennenlernen, ist der Ansatz von Ryan Dahl bei der Entwicklung des Plattformkerns. Seine Erfahrung zeigte ihm, dass Plattformen, die Streams verwenden, benötigt werden, um komplexe, schwere Systeme zu erstellen. Er suchte nach etwas anderem und verbrachte einige Jahre damit, die in Node.js enthaltenen grundlegenden Mechanismen zu verbessern. Als Ergebnis erhielt er ein leichtes System, das sich durch einen einzelnen Ausführungsthread, die erfinderische Verwendung anonymer JavaScript-Funktionen als asynchrone Rückrufe und eine Laufzeitbibliothek auszeichnet, die ursprünglich asynchrone Mechanismen implementiert. Die erste Nachricht beim Erstellen eines solchen Systems war, eine leistungsstarke Ereignisverarbeitung mit der Übermittlung dieser Ereignisse in einer Rückruffunktion bereitzustellen.

Als nächstes ist eine wichtige Funktion von Node.js die Verwendung von JavaScript. Es besteht das Gefühl, dass diejenigen, die in JS schreiben, dazu neigen, Vorlagencode loszuwerden, wodurch sie die Absichten des Programmierers klar beschreiben können.

Betrachten Sie als Beispiel für den Unterschied zwischen Java und JavaScript die Implementierung von Listener-Funktionen (Beobachter). In Java müssen Sie für die Arbeit mit Listenern eine bestimmte Instanz der abstrakten Schnittstelle erstellen. Dies beinhaltet die Verwendung sperriger Sprachkonstrukte, die die Essenz des Geschehens verbergen. Wie kann man die Absicht eines Programmierers erkennen, die unter dem Deckmantel des Boilerplate-Codes verborgen ist?

JavaScript verwendet stattdessen einfache anonyme Funktionen. Bei der Implementierung eines Listeners müssen Sie nicht nach einer geeigneten abstrakten Schnittstelle suchen. Es reicht aus, ohne die Notwendigkeit einer Vielzahl von Hilfstexten zu verwenden, den erforderlichen Code zu schreiben.

Hier ist eine wichtige Idee, die aus der Analyse der oben genannten Mechanismen abgeleitet werden kann: Die meisten Programmiersprachen verbergen die Absichten des Programmierers, was dazu führt, dass der Code schwer zu verstehen ist.

Die Entscheidung bezüglich der Verwendung von Rückruffunktionen, die Node.js anbietet, sieht sehr attraktiv aus. Aber es ist nicht ohne Probleme.

Problemlösung und Problemlösung

In JavaScript gibt es seit langem zwei Probleme bei der asynchronen Programmierung. Das erste nennt Node.js die Rückrufhölle. Dieses Problem liegt in der Tatsache, dass es während der Entwicklung leicht ist, in eine Falle zu geraten, die aus tief verschachtelten Rückruffunktionen besteht, bei denen jede Verschachtelungsebene das Programm kompliziert und die Ergebnisse von Code und Fehlern verarbeitet. Im Zusammenhang damit gab es ein weiteres Problem, dessen Kern darin bestand, dass die JavaScript-Sprachmechanismen dem Programmierer nicht dabei halfen, Ideen zur asynchronen Codeausführung richtig auszudrücken.

Es wurden mehrere Bibliotheken entwickelt, um die asynchrone Entwicklung unter JS zu vereinfachen. Dies ist jedoch ein weiteres Beispiel für den Versuch, komplexe Mechanismen zu verbergen, was nur zum Auftreten noch komplexerer Strukturen führt.

Betrachten Sie ein Beispiel:

 const async = require('async'); const fs = require('fs'); const cat = function(filez, fini) { async.eachSeries(filez, function(filenm, next) {   fs.readFile(filenm, 'utf8', function(err, data) {     if (err) return next(err);     process.stdout.write(data, 'utf8', function(err) {       if (err) next(err);       else next();     });   }); }, function(err) {   if (err) fini(err);   else fini(); }); }; cat(process.argv.slice(2), function(err) { if (err) console.error(err.stack); }); 

Dies ist eine unscheinbare Nachahmung des Unix- cat . Die asynchrone Bibliothek vereinfacht asynchrone Aufrufsequenzen. Für die Verwendung ist jedoch eine große Menge an Code erforderlich, der die Absicht des Programmierers verbirgt.

Im Wesentlichen enthält dieser Code eine Schleife. Es wird nicht als regulärer Zyklus geschrieben, es werden keine natürlichen Konstruktionen der Beschreibung von Zyklen verwendet. Darüber hinaus gelangen die Ergebnisse der Codeausführung und die von ihnen erzeugten Fehler nicht dahin, wo sie richtig gewesen wären. Sie sind in Rückrufen gesperrt, was unpraktisch ist. Vor der Implementierung der ES2015 / 2016-Standards in Node.js konnte jedoch nichts Besseres getan werden.

Wenn wir diesen Code unter Berücksichtigung neuer Funktionen umschreiben, die insbesondere in Node.js 10.x verfügbar sind, erhalten wir Folgendes:

 const fs = require('fs').promises; async function cat(filenmz) { for (var filenm of filenmz) {   let data = await fs.readFile(filenm, 'utf8');   await new Promise((resolve, reject) => {     process.stdout.write(data, 'utf8', (err) => {       if (err) reject(err);       else resolve();     });   }); } } cat(process.argv.slice(2)).catch(err => {   console.error(err.stack); }); 

In diesem Beispiel haben wir das Konstrukt async/await verwendet. Hier werden die gleichen asynchronen Mechanismen wie im vorherigen Beispiel dargestellt, aber hier werden die üblichen Strukturen verwendet, die beim Organisieren von Schleifen verwendet werden. Das Arbeiten mit Ergebnissen und Fehlern sieht ganz normal aus. Ein solcher Code ist leichter zu lesen und zu schreiben. Dieser Ansatz macht es leicht, die Absicht des Programmierers zu verstehen.

Der einzige Nachteil ist, dass process.stdout.write keine Promise-Schnittstelle hat. Daher kann dieser Mechanismus nicht in asynchronen Funktionen verwendet werden, ohne ihn in ein Versprechen einzuschließen.

Jetzt können wir daraus schließen, dass das Problem der Rückrufhölle in JavaScript auf eine Weise gelöst wurde, die sich von dem Versuch unterscheidet, komplexe Mechanismen zu verbergen. Stattdessen wurden Änderungen an der Sprache vorgenommen, die das Problem selbst lösten und uns vor den Unannehmlichkeiten bewahrten, die durch die Notwendigkeit verursacht wurden, große Mengen an Vorlagencode in einer temporären Lösung zu verwenden. Darüber hinaus wurde der Code durch die Verwendung des Async / Wait-Mechanismus einfach schöner.

Wir haben diesen Abschnitt mit einer Diskussion über den Fehler von Node.js begonnen, aber eine hervorragende Lösung für die Hölle eines Rückrufs hat dazu geführt, dass aus Gerüchten über Fehler die Stärken von Node.js und JavaScript wurden.

Starke Eingabe, Schnittstellen und imaginäre Codeklarheit

In jenen Tagen, als ich Java vor allen möglichen Angriffen schützte, betonte ich, dass Sie durch strikte Eingabe große Anwendungen schreiben können. In jenen Tagen wurde die Entwicklung monolithischer Systeme verwendet (es gab keine Mikrodienste, es gab keinen Docker und dergleichen). Da Java eine stark typisierte Sprache ist, hilft der Java-Compiler dem Programmierer, viele Probleme zu vermeiden, indem er verhindert, dass er den falschen Code kompiliert.

JavaScript ist im Gegensatz zu Java nicht stark typisiert. Daraus können wir den offensichtlichen Schluss ziehen, dass der Programmierer nicht genau weiß, mit welchen Objekten er arbeiten muss. Wie kann ein Programmierer wissen, was er beispielsweise mit einem bestimmten Objekt tun soll, das von irgendwoher empfangen wurde?

Die Kehrseite der starken Java-Typisierung ist, dass Sie ständig Boilerplate-Aktionen ausführen müssen. Der Programmierer wirft ständig oder überprüft, ob alles genau wie erwartet ist. Der Entwickler verbringt viel Zeit damit, Code zu schreiben, macht dies mit außergewöhnlicher Genauigkeit, verwendet beträchtliche Mengen an Vorlagendesigns und hofft, dass all dies ihm hilft, Zeit durch frühzeitiges Erkennen und Korrigieren von Fehlern zu sparen.

Das Problem der Programmierung in einer stark typisierten Sprache ist so groß, dass ein Programmierer, der fast keine Optionen hat, eine große, komplexe IDE verwenden muss. Ein einfacher Code-Editor reicht hier nicht aus. Die einzige Möglichkeit, den Java-Programmierer in einem angemessenen Zustand zu halten (mit Ausnahme von Pizza), besteht darin, ihm ständig Dropdown-Listen mit verfügbaren Objektfeldern oder Beschreibungen von Methodenparametern anzuzeigen. Dieser und andere unterstützende Mechanismen von IDEs wie Eclipse, NetBeans oder IntelliJ helfen beim Erstellen von Klassen, erleichtern das Refactoring und andere Aufgaben.

Und ... ich werde nicht über Maven sprechen. Dies ist nur ein Albtraum-Tool.

In JavaScript werden Variablentypen nicht angegeben, wenn sie deklariert werden, Typumwandlung wird normalerweise nicht verwendet usw. Dadurch ist der Code leichter zu lesen, aber dieser Zustand birgt auch das Risiko von Programmierfehlern, die schwer zu erkennen sind.

Ob sich das Vorstehende auf die Pluspunkte von Java oder auf die Minuspunkte bezieht, hängt von der Sichtweise ab.

Vor zehn Jahren glaubte ich, dass all diese Schwierigkeiten sich rechtfertigen, indem sie dem Programmierer mehr Vertrauen in den Code geben, den er schreibt. Heute glaube ich, dass starkes Tippen die Arbeitsbelastung des Programmierers erhöht und es viel einfacher ist, Projekte zu entwickeln, als dies in JavaScript der Fall ist.

Bekämpfen Sie Fehler mit kleinen Modulen, die einfach zu testen sind

Node.js drängt den Programmierer, seine Projekte in kleine Fragmente, sogenannte Module, zu zerlegen. Sie mögen diese Tatsache als unbedeutend empfinden, aber sie löst teilweise das gerade erwähnte Problem.

Hier sind die Hauptmerkmale des Moduls:

• Unabhängigkeit Das Modul kombiniert miteinander verbundenen Code zu einer einzigen Entität.
• Klare Grenzen. Der Code im Modul ist durch externe Mechanismen vor Störungen geschützt.
• Expliziter Export. Standardmäßig werden Code- und Moduldaten nicht exportiert. Der Entwickler entscheidet unabhängig, welche Funktionen und Daten öffentlich zugänglich gemacht werden sollen.
• Expliziter Import. Bei der Entwicklung eines Moduls entscheidet der Programmierer selbst, von welchen Modulen er abhängig ist.
• Mögliche Unabhängigkeit. Module können im weitesten Sinne des Wortes öffentlich zugänglich gemacht werden, indem sie in npm veröffentlicht werden oder, wenn sie für die internen Anforderungen des Unternehmens bestimmt sind, in geschlossenen Repositories veröffentlicht werden. Dies macht es einfach, dieselben Module in verschiedenen Anwendungen zu verwenden.
• Einfach zu verstehender Code. Die Tatsache, dass die Module klein sind, das Lesen und Verstehen ihres Codes vereinfacht, eröffnet die Möglichkeit einer freien Diskussion über sie.
• Erleichtern Sie das Testen. Ein kleines Modul kann bei korrekter Implementierung problemlos einem Unit-Test unterzogen werden.

All dies macht Node.js Modulentitäten zu klar definierten Grenzen, deren Code leicht zu schreiben, zu lesen und zu testen ist.

Die Sorge um die Arbeit mit JavaScript ist jedoch die Tatsache, dass das Fehlen einer starken Eingabe leicht dazu führen kann, dass Code etwas falsch macht. In einem kleinen Modul, das darauf abzielt, ein enges Problem mit klaren Grenzen zu lösen, kann „etwas stimmt nicht“ nur den Code des Moduls selbst beeinflussen. Dies führt dazu, dass die Probleme, die das Fehlen einer strengen Eingabe verursachen können, innerhalb des Moduls gesperrt sind.

Eine andere Lösung für das Problem der dynamischen Eingabe in JavaScript besteht darin, den Code gründlich zu testen.

Der Entwickler muss das Testen ernst nehmen, was einen Teil der Vorteile beeinträchtigt, die sich aus der Einfachheit des JS-Entwicklungsprozesses ergeben. Testsysteme, die von einem JS-Programmierer erstellt wurden, sollten die Fehler finden, die der Compiler automatisch finden könnte, wenn er von ihm in etwas wie Java entwickelt wird. Schreiben Sie Tests für Ihre JS-Anwendungen?

Für diejenigen, die ein statisches Typisierungssystem in JavaScript benötigen, kann es hilfreich sein, sich TypeScript anzusehen. Ich benutze diese Sprache nicht, aber ich habe viele gute Dinge darüber gehört. Es ist mit JavaScript kompatibel und erweitert die Sprache um ein Typsteuerungssystem und andere nützliche Funktionen.

Am Ende können wir sagen, dass die Verwendung eines modularen Entwicklungsansatzes die Stärke von Node.js und JavaScript ist.

Paketverwaltung

Ich fühle mich schlecht bei dem bloßen Gedanken an Maven, daher kann ich nicht einmal normal darüber schreiben. Und so wie ich es verstehe, wird Maven ohne Kompromisse entweder geliebt oder gehasst.

Das Problem hierbei ist, dass es in der Java-Umgebung kein ganzheitliches System zum Verwalten von Paketen gibt. Maven-Pakete existieren, Sie können normal mit ihnen arbeiten, sie werden von Gradle unterstützt. Die Art und Weise, wie die Arbeit mit ihnen organisiert ist, ähnelt jedoch nicht den Annehmlichkeiten, die das Paketverwaltungssystem für Node.js dem Entwickler bietet.

In der Welt von Node.js gibt es zwei großartige Paketmanager, die eng zusammenarbeiten. Das einzige derartige Tool war zunächst das npm-Repository und das gleichnamige Befehlszeilentool.

Dank npm haben wir ein hervorragendes Schema zur Beschreibung von Paketabhängigkeiten. Abhängigkeiten können streng sein (es wird angegeben, dass nur Version 1.2.3 eines bestimmten Pakets benötigt wird) oder mit mehreren Freiheitsgraden angegeben werden - bis zu * , was bedeutet, dass die neueste Version eines bestimmten Pakets verwendet wird.

Die Node.js-Community hat Hunderttausende von Paketen im npm-Repository veröffentlicht. Gleichzeitig ist die Verwendung von Paketen, die nicht in npm enthalten sind, so einfach wie die Verwendung von Paketen ab npm.

Das npm-System erwies sich als so erfolgreich, dass nicht nur Entwickler von Serverprodukten auf Node.js es verwenden, sondern auch Front-End-Programmierer. Bisher wurden Tools wie Bower zum Verwalten von Paketen verwendet. Bower war veraltet, und jetzt können Sie feststellen, dass alle JS-Bibliotheken für die Frontend-Entwicklung als npm-Pakete vorhanden sind. Viele Support-Tools für die Client-Entwicklung, wie die Vue.js-CLI und das Webpack, sind als Node.js-Anwendungen geschrieben.

Ein anderes Paketverwaltungssystem für Node.js, Garn, lädt Pakete aus dem npm-Repository herunter und verwendet dieselben Konfigurationsdateien. Der Hauptvorteil von Garn gegenüber dem npm-Paketmanager ist seine höhere Geschwindigkeit.

Das npm-Repository, egal ob mit dem npm-Paketmanager oder dem Garnpaketmanager, ist eine leistungsstarke Grundlage dafür, was die Entwicklung für Node.js so einfach und unterhaltsam macht.


Einmal, nachdem ich bei der Entwicklung von java.awt.Robot mitgeholfen hatte, wurde ich inspiriert, dieses Ding zu kreieren. Während das offizielle Duke-Bild aus Kurven besteht, besteht RoboDuke aus geraden Linien. Nur die Ellbogengelenke dieses Roboters sind rund

Leistung

Java, JavaScript . -, , . , , - .

Java, JavaScript . Java Node.js, . JavaScript . -.

JDK Sun/Oracle HotSpot — , -. , , , , , . HotSpot — , .

JavaScript, , JS-, , , - . , JavaScript . , , . , , Google Docs, . JS .

Node.js , V8 Google Chrome.

, Google, V8, . , V8 Crankshaft Turbofan.

— , , R Python. , , . JavaScript, , , JavaScript.

JavaScript , TensorFlow.js. API API TensorFlow Python, . , , , .

IBM, Node.js, , , Docker/Kubernetes. , Node.js Spring Boot. -, . , Node.js , , , V8.

, Node.js . . - , Node.js , . , «Node.js Web Development», , :

• — .
• , Node.js .
• .

JavaScript , Node.js. — Node.js-. Node.js- node-gyp , . , Rust- Node.js.

WebAssembly , , JavaScript, . WebAssembly , JavaScript-. WebAssembly Node.js.

-

- (Rich Internet Applications, RIA) . , , ( ) JS-, .

, 20 . Sun Netscape Java- Netscape Navigator. JavaScript , , Java-. , Java-, — Java-. , . .

JavaScript , . RIA, , - Java -.

, RIA . Node.js , , , . JavaScript.

Hier einige Beispiele:

• Google Docs ( ), , .
• , React, Angular Vue.js, , HTML, CSS JavaScript.
• Electron — Node.js Chromium. - . , Visual Studio Code, Atom, GitKraken, Postman.
• Electron/NW.js , -, , React, Angular, Vue, .

Java, , - -, JavaScript. , , - Sun Microsystems. Sun , . . Java- , Java Java Web Start. Java- Webstart-.

Java, , , IDE NetBeans Eclipse . Java , , Java.

JavaFX.

JavaFX, 10 , Sun iPhone. , Java, , , . Flash iOS. . JavaFX , , . - React, Vue.js .

JavaScript Node Java.

Java, - JavaONE. Java . , , , .


Java

Zusammenfassung

. «P-» (Perl, PHP, Python) Java, Node.js, Ruby, Haskell, Go, Rust, . .

, , , Java, Node.js, , , Node.js-. Java , Node.js . , , , Java, .

. , , Node.js - , - . . , XBRL-. XBRL Python, , , Python. , , , .

Liebe Leser! , , JavaScript - , - Node.js, .