Node.js vs. Java: een epische strijd om mindshare voor ontwikkelaars

In de geschiedenis van computers was 1995 een gekke tijd. Eerst verscheen Java, daarna kwam JavaScript op de hielen. Door de namen leken ze op een pas vrijstaande Siamese tweeling, maar ze konden niet meer verschillen. Een ervan is samengesteld en statisch getypt; de andere geïnterpreteerd en dynamisch getypt. Dat is nog maar het begin van de technische verschillen tussen deze twee enorm verschillende talen die sindsdien zijn verschoven naar een soort ramkoers, dankzij Node.js.

Als je oud genoeg bent om er toen bij te zijn, herinner je je misschien de vroege, epische piek van Java. Hij verliet de laboratoria en zijn hypermeter werd vastgezet. Iedereen zag het als een revolutie die zou stoppen bij niets minder dan een totale overname van computers. Die voorspelling was uiteindelijk maar gedeeltelijk correct. Tegenwoordig domineert Java Android-telefoons, bedrijfscomputers en sommige ingebedde werelden zoals Blu-ray-schijven.

Ondanks al zijn succes heeft Java echter nooit veel grip op de desktop of in de browser. Mensen prees de kracht van applets en op Java gebaseerde tools, maar smurrie heeft deze combinaties altijd op de kop gezet. Servers werden de favoriete plek van Java.

Ondertussen is wat programmeurs aanvankelijk aanzagen als de domme tweeling, tot zijn recht gekomen. Natuurlijk, JavaScript tagde een paar jaar als HTML en het web trok een Borg over de wereld. Maar dat veranderde met AJAX. Plots had de domme tweeling macht.

Toen werd Node.js uitgezet, waardoor de ontwikkelaars met zijn snelheid de hoofden omdraaiden. JavaScript was niet alleen sneller op de server dan iemand had verwacht, maar het was ook vaak sneller dan Java en andere opties. Het gestage dieet van kleine, snelle, eindeloze verzoeken om gegevens heeft Node.js sindsdien meer gemeengoed gemaakt, omdat webpagina's dynamischer zijn geworden.

Hoewel het 20 jaar geleden misschien ondenkbaar was, zijn de quasi-tweelingen nu verwikkeld in een strijd om controle over de programmeerwereld. Aan de ene kant bevinden zich de diepe fundamenten van solide engineering en architectuur. Aan de andere kant zijn eenvoud en alomtegenwoordigheid. Zal de old-school compiler-gedreven wereld van Java stand houden, of zal de snelheid en flexibiliteit van Node.js JavaScript helpen om alles op zijn pad te blijven opslokken?

Waar Java wint: ijzersterke basis

Ik hoor de ontwikkelaars lachen. Sommigen zullen zelfs sterven aan hartfalen. Ja, Java heeft glitches en bugs, maar relatief gezien is het de Rots van Gibraltar. Hetzelfde vertrouwen in Node.js duurt nog vele jaren. Het kan zelfs tientallen jaren duren voordat de JavaScript-crew bijna evenveel regressietests schrijft als Sun / Oracle heeft ontwikkeld om de Java Virtual Machine te testen. Wanneer u een JVM opstart, krijgt u 20 jaar ervaring van een solide curator die vastbesloten is om de bedrijfsserver te domineren. 

De JavaScript-wereld is snel aan het inhalen. Wanneer een groot deel van het hele web afhankelijk is van de JavaScript-uitvoeringsengine, gaan er een baziljoen ontwikkelaaruren in het polijsten van alle randen. Maar alle innovatie heeft een keerzijde, omdat de nieuwe functies zich mogelijk sneller verspreiden dan de ontwikkelaars ze kunnen absorberen. Oldschool-ontwikkelaars worden vaak in de war gebracht door code die is gevuld met de nieuwere ECMAScript-syntaxisverbeteringen - en dezelfde nieuwe code zal stilletjes sommige oudere browsers laten crashen. Het eindeloze aanbod van innovatieve preprocessors zoals CoffeeScript en JSX is misschien geweldig voor ontwikkelaars die die functies willen, maar ze maken het voor de rest van ons moeilijker om een ​​willekeurig bestand te openen en het onmiddellijk te begrijpen.

Java heeft een aantal nieuwe functies en opties, maar voor het grootste deel is het een stabiel platform. Dat maakt het leven veel gemakkelijker voor ontwikkelaars die iets duurzaams bouwen.

Waar Node.js wint: Ubiquity

Dankzij Node.js vindt JavaScript een thuis op de server en in de browser. Code die u voor één schrijft, werkt hoogstwaarschijnlijk op beide op dezelfde manier. Niets is gegarandeerd in het leven, maar dit is zo dichtbij als in de computerwereld. Het is veel gemakkelijker om vast te houden aan JavaScript voor beide kanten van de client / server-scheiding dan om iets een keer in Java en opnieuw in JavaScript te schrijven, wat u waarschijnlijk zou moeten doen als u besluit bedrijfslogica die u in Java hebt geschreven voor de server naar de browser. Of misschien staat de baas erop dat de logica die u voor de browser hebt gebouwd, naar de server wordt verplaatst. In beide richtingen maken Node.js en JavaScript het veel gemakkelijker om code te migreren.

De voorsprong van Node in deze wereld lijkt alleen maar groter te worden. De meest geavanceerde webframeworks, zoals React, zullen op het laatste moment beslissen of de code op de server of op de client wordt uitgevoerd. De ene dag zal het op de client draaien en de andere dag zal het op de server draaien. Sommige slimme logica zullen de beslissing tijdens de vlucht nemen op basis van belasting of reserve RAM of iets anders. Sommige frameworks sturen JavaScript naar de database als een query waar het wordt uitgevoerd. Uw code kan overal worden uitgevoerd en het wordt moeilijker om bij te houden omdat er geen ansichtkaart mee naar huis wordt gestuurd. Wees gewoon blij, want u hoeft niet over de details na te denken.

Waar Java wint: betere IDE's

Java-ontwikkelaars hebben Eclipse, NetBeans of IntelliJ, drie eersteklas tools die goed zijn geïntegreerd met debuggers, decompilers en servers. Elk heeft jarenlange ontwikkeling, toegewijde gebruikers en solide ecosystemen gevuld met plug-ins.

Ondertussen typen de meeste Node.js-ontwikkelaars woorden in de opdrachtregel en coderen ze in hun favoriete teksteditor. Ja, sommige van de beste teksteditors zoals Atom hebben uitgebreide collecties plug-ins die bijna alles kunnen, maar zelfs dan voelt het alsof Node.js ouderwets is dan Eclipse. Binnenkort zullen we onze muis vervangen door een Atari joystick.

Sommige ontwikkelaars gebruiken Eclipse of Visual Studio, die beide Node.js. Natuurlijk betekent de grote belangstelling voor Node.js dat er nieuwe tools aankomen, waarvan sommige, zoals IBM's Node-RED, intrigerende benaderingen bieden, maar ze zijn nog lang niet zo compleet of dominant als Eclipse of IntelliJ.

Het rare is dat de ontwikkelaars deze tools niet lijken te gebruiken. De opdrachtregel zou 35 jaar geleden verdwijnen met de komst van de Mac, maar niemand vertelde het aan de Node.js-ontwikkelaars. De mogelijkheden zijn er. WebStorm is bijvoorbeeld een solide commerciële tool van JetBrains die veel opdrachtregelprogramma's bevat.

Als u op zoek bent naar een IDE die code bewerkt en jongleert, zijn de nieuwe tools die Node.js ondersteunen natuurlijk goed genoeg. Maar als u uw IDE vraagt ​​om u te laten bewerken terwijl u aan de lopende broncode werkt, zoals een hartchirurg een kist opensnijdt, dan zijn Java-tools veel krachtiger. Het is er allemaal, en het is allemaal lokaal.

Waar Node.js wint: databasequery's

Query's voor enkele van de nieuwere databases, zoals CouchDB en MongoDB, worden in JavaScript geschreven. Het mengen van Node.js en een oproep naar de database vereist geen schakelen, laat staan ​​dat je syntaxisverschillen moet onthouden. 

Ondertussen gebruiken veel Java-ontwikkelaars SQL. Zelfs als ze de Java DB gebruiken - voorheen Derby, een database die in Java is geschreven voor Java-ontwikkelaars - schrijven ze hun vragen in SQL. Je zou denken dat ze gewoon Java-methoden zouden noemen, maar je zou het mis hebben. U moet uw databasecode in SQL schrijven en Derby vervolgens de SQL laten parseren. SQL is een leuke taal, maar het is totaal anders dan Java, en veel ontwikkelingsteams hebben verschillende mensen nodig om SQL en Java te schrijven.

Om het nog erger te maken, gebruiken veel Java-codeerders uitgebreide bibliotheken en schema's om de gegevens van de SQL-query om te zetten in Java-objecten, zodat ze deze kunnen herschikken in sjablonen. Het is een gek proces en uiteindelijk behoorlijk verkwistend.

Waar Java wint: Types 

Veel van de inleidende programmeercursussen blijven Java gebruiken, omdat veel serieuze programmeurs statisch getypte code leuk vinden, zowel vanwege de eenvoud als de veiligheid. De code voelt alleen maar rigoureuzer aan nadat de compiler de voor de hand liggende bugs heeft ontdekt.

JavaScript is echter aan het inhalen en sommige ontwikkelaars schakelen over naar TypeScript, een statisch getypte superset van JavaScript die alle typecontrole-magie toepast voordat iets wordt uitgespuugd dat in de JavaScript-stack van uw browser wordt uitgevoerd. Als je van typen houdt, is dit misschien genoeg om JavaScript te omarmen. Of je zou de imitatie gewoon kunnen herkennen als de oprechtste vorm van vleierij en vasthouden aan Java, dat vanaf het begin statisch typen omarmde.

Waar Node.js wint: syntactische flexibiliteit

JavaScript was een eenvoudige taal om ongewenste waarschuwingsvensters te laten verschijnen en formulierinvoer dubbel te controleren. Vervolgens creëerde de ontwikkelaarsgemeenschap veel verschillende versies van de taal die in iets voor de browser konden worden omgezet. Er is de CoffeeScript-menigte die een handvol verschillende syntaxis biedt die zijn ontworpen om te voldoen aan de smaak voor schonere interpunctie. Er is de React / Vue-menigte die HTML en JavaScript door elkaar haalt, alleen maar omdat het schoner is. Er is TypeScript voor de typeliefhebbers en LiveScript voor de functionele taalliefhebbers.

Je zult ook een enorme hoeveelheid creativiteit in de Java-wereld vinden, maar om de een of andere reden komt het niet tot uiting in veel pre-processors. Er zijn een aantal talen zoals Kotlin, Scala en Clojure die worden omgezet in bytecode voor de JVM, maar op de een of andere manier voelen ze zich anders genoeg om als afzonderlijke talen op te staan. Alle preprocessors maken het leven leuker voor JavaScript-programmeurs die houden van verschillende manieren om hun code te formuleren of te accentueren.

Waar Java wint: eenvoudig bouwproces 

Ingewikkelde build-tools zoals Ant en Maven hebben een revolutie teweeggebracht in het programmeren van Java. Maar er is maar één probleem. Je schrijft de specificatie in XML, een dataformaat dat niet ontworpen is om programmeerlogica te ondersteunen. Natuurlijk is het relatief eenvoudig om vertakking uit te drukken met geneste tags, maar er is iets vervelends aan het schakelen van Java naar XML om alleen maar iets te bouwen. Met JavaScript hoeft u niet te schakelen. 

Node.js had vroeger de eenvoudigere build. U zou gewoon de code bewerken en vervolgens op 'uitvoeren' klikken. Dat was toen. Omdat de Node-ontwikkelaars het proces hebben "verbeterd", hebben ze preprocessors toegevoegd die je favoriete subdialect van JavaScript gebruiken en het in iets uitvoerbaars veranderen. Vervolgens moet de Node-pakketbeheerder de juiste bibliotheek vinden. Meestal werkt dit gewoon, maar soms niet, en dan besteed je tijd aan het zoeken naar het juiste versienummer van een artefact dat je zelf bouwt in een aparte stap. En als je een fout begaat in de artefact-repository, dan wordt dat versienummer geschoten en moet je de kilometerteller weer draaien.

Java heeft ook een complex bouwproces dat vrij gelijkaardig is aan de Node.js-methode, maar het voelt niet alsof het nog complexer is geworden. Op de een of andere manier lijken Maven en Ant nu deel uit te maken van de Java-stichting. Veel van de ruwe randen zijn allang verdwenen en de builds werken gewoon vaker. Als er enige absolute mate van bouwprobleem zou zijn, zouden de twee talen vergelijkbaar kunnen zijn, maar de snelle explosie van JavaScript-complexiteit betekent dat Java wint.

Gerelateerde video: Node.js tips en trucs

In deze uitlegvideo leert u verschillende technieken die uw Node-ontwikkelervaring kunnen verbeteren.

Waar Node.js wint: JSON

Wanneer databases antwoorden uitspugen, doet Java veel moeite om de resultaten om te zetten in Java-objecten. Ontwikkelaars zullen uren discussiëren over POJO-mappings, Hibernate en andere tools. Het configureren ervan kan uren of zelfs dagen duren. Uiteindelijk krijgt de Java-code na alle conversie Java-objecten. En als het op configuratie aankomt, klampt de Java-wereld nog steeds vast aan XML en biedt zelfs twee belangrijke parsers om ontwikkelaars meer redenen te geven om zich zorgen te maken.

Tegenwoordig retourneren veel webservices en databases gegevens in JSON, een natuurlijk onderdeel van JavaScript. JSON is nu zo gewoon en nuttig dat veel Java-ontwikkelaars het formaat gebruiken, en een aantal goede JSON-parsers zijn ook beschikbaar als Java-bibliotheken. Maar JSON maakt deel uit van de basis van JavaScript. U heeft geen bibliotheken nodig. Het is er allemaal en klaar om te gaan.

Waar Java wint: debuggen op afstand

Java biedt ongelooflijke tools voor het bewaken van clusters van machines. Er zijn diepe haken in de JVM en uitgebreide profileringstools om knelpunten en mislukkingen te helpen identificeren. De Java-enterprise-stack draait enkele van de meest geavanceerde servers ter wereld en de bedrijven die deze servers gebruiken, hebben het allerbeste op het gebied van telemetrie geëist. Al deze tools voor monitoring en foutopsporing zijn behoorlijk volwassen en klaar om door u te worden geïmplementeerd.

Waar Node.js wint: Desktop

Het kan zijn dat er enkele Java-applets op de markt zijn en ik onderhoud nog steeds enkele Java JAR-bestanden waarop ik kan klikken om ze uit te voeren, maar voor het grootste deel is de desktopwereld grotendeels Java-vrij. JavaScript daarentegen blijft steeds meer van de actie vastleggen, aangezien de browser de meeste rollen voor onze desktop opeet. Toen Microsoft Office herschreef om in de browser te werken, werd de dobbelsteen geworpen. Als je je nog steeds afvraagt, zijn er interessante opties zoals Electron die je webcode gebruiken en deze in een zelfstandige desktop-app veranderen.

Waar Java wint: Handhelds

Android-apps zijn vaak in Java geschreven en 90 procent van de nieuwe telefoons heeft een versie van Android. Veel mensen gebruiken zelfs geen desktops meer omdat de telefoons overal goed genoeg zijn.

Er is natuurlijk een beetje verwarring. Veel ontwikkelaars schrijven Node.js-webapps die zich richten op de mobiele browsers op zowel de iPhone als de Android-apparaten. Als dit goed wordt gedaan, is de prestatie vaak goed genoeg.