Programmering

Node.js vs. Java: En episk kamp om udviklerens mindshare

I computerhistorien var 1995 en skør tid. Først dukkede Java op, så tæt på hælene kom JavaScript. Navnene fik dem til at virke som sammenføjede tvillinger, der for nylig var løsrevet, men de kunne ikke være mere forskellige. En af dem er kompileret og statisk skrevet; den anden blev fortolket og dynamisk skrevet. Det er kun begyndelsen på de tekniske forskelle mellem disse to vildt forskellige sprog, der siden er skiftet til et slags kollisionskurs takket være Node.js.

Hvis du er gammel nok til at have været omkring dengang, husker du måske Java's tidlige, episke højdepunkt. Det forlod laboratorierne, og dens hype-meter blev fastgjort. Alle så det som en revolution, der ville stoppe ved intet mindre end en total overtagelse af computing. Denne forudsigelse endte med at være kun delvist korrekt. I dag dominerer Java Android-telefoner, enterprise computing og nogle indlejrede verdener som Blu-ray-diske.

På trods af al sin succes etablerede Java dog aldrig meget trækkraft på skrivebordet eller i browseren. Folk udråbt kraften fra applets og Java-baserede værktøjer, men gunk glitchede altid disse kombinationer. Servere blev Java's sweet spot.

I mellemtiden, hvad programmører oprindeligt forvekslede som den dumme tvilling er kommet til sin ret. Sikker på, JavaScript blev tagget sammen i et par år som HTML og internettet trak en Borg på verden. Men det ændrede sig med AJAX. Pludselig havde den stumme tvilling magt.

Derefter blev Node.js gydet og drejet udviklerens hoveder med sin hastighed. Ikke kun var JavaScript hurtigere på serveren, end nogen havde forventet, men det var ofte hurtigere end Java og andre muligheder. Dens faste diæt med små, hurtige, uendelige anmodninger om data har siden gjort Node.js mere almindelig, da websider er blevet mere dynamiske.

Selvom det måske har været utænkeligt for 20 år siden, er kvasi-tvillingerne nu låst i en kamp om kontrol over programmeringsverdenen. På den ene side er det dybe fundament for solid teknik og arkitektur. På den anden side er enkelhed og allestedsnærværende. Vil den old-school kompilerdrevne Java-verden holde fast, eller vil hastigheden og fleksibiliteten i Node.js hjælpe JavaScript med at fortsætte med at sluge alt, hvad der er i vejen for det?

Hvor Java vinder: Bundsolid foundation

Jeg kan høre udviklerne grine. Nogle kan endda dø af hjertesvigt. Ja, Java har fejl og fejl, men relativt set er det Gibraltar-klippen. Den samme tro på Node.js er mange års fri. Faktisk kan det gå årtier, før JavaScript-besætningen skriver næsten lige så mange regressionstest som Sun / Oracle udviklede for at teste Java Virtual Machine. Når du starter en JVM op, får du 20 års erfaring fra en solid kurator, der er fast besluttet på at dominere virksomhedsserveren.

JavaScript-verdenen indhenter hurtigt. Når meget af hele internettet afhænger af JavaScript-eksekveringsmotoren, går en bazillion-udviklertime i polering af alle kanter. Men al innovation har en ulempe, fordi de nye funktioner muligvis spreder sig hurtigere, end udviklerbasen kan absorbere dem. Old school-udviklere forveksles ofte af kode fyldt med de nyere forbedringer af ECMAScript-syntaks - og den samme nye kode vil stille nedbringe nogle ældre browsere. Den endeløse forsyning med innovative præprocessorer som CoffeeScript og JSX kan være godt for udviklere, der ønsker disse funktioner, men de gør det sværere for resten af ​​os at åbne en tilfældig fil og forstå den med det samme.

Java har sin andel af nye funktioner og muligheder, men for det meste er det en stabil platform. Det gør livet meget lettere for udviklere, der bygger noget til at holde.

Hvor Node.js vinder: Ubiquity

Takket være Node.js finder JavaScript et hjem på serveren og i browseren. Kode, du skriver til en, vil mere end sandsynligt køre på samme måde på begge. Intet er garanteret i livet, men det er så tæt som det kommer i computerbranchen. Det er meget nemmere at holde fast ved JavaScript for begge sider af klienten / serveropdelingen, end det er at skrive noget en gang i Java og igen i JavaScript, hvilket du sandsynligvis skulle gøre, hvis du besluttede at flytte forretningslogik, du skrev i Java til server til browseren. Eller måske vil chefen insistere på, at den logik, du har bygget til browseren, flyttes til serveren. I begge retninger gør Node.js og JavaScript det meget nemmere at migrere kode.

Knudepunktet i denne verden ser kun ud til at udvides. De mest sofistikerede webrammer, som React, beslutter i sidste sekund, om koden skal køres på serveren eller klienten. En dag kører det på klienten, og en anden dag kører det på serveren. Noget smart logik vil tage beslutningen i farten baseret på belastning eller ekstra RAM eller noget andet. Nogle rammer sender JavaScript til databasen som en forespørgsel, hvor den udføres. Din kode kan køre hvor som helst, og det bliver sværere at følge med, fordi den ikke sender et postkort hjem. Bare vær glad, fordi du ikke behøver at tænke på detaljerne.

Hvor Java vinder: Bedre IDE'er

Java-udviklere har Eclipse, NetBeans eller IntelliJ, tre førsteklasses værktøjer, der er godt integreret med debuggere, decompilere og servere. Hver har mange års udvikling, dedikerede brugere og solide økosystemer fyldt med plug-ins.

I mellemtiden skriver de fleste Node.js-udviklere ord i kommandolinjen og kode i deres foretrukne teksteditor. Ja, nogle af de bedste teksteditorer som Atom har omfattende samlinger af plug-ins, der gør næsten alt, men selv da føles det som om Node.js er mere old school end Eclipse. Snart erstatter vi vores mus med en Atari joystick.

Nogle udviklere bruger Eclipse eller Visual Studio, som begge understøtter Node.js. Naturligvis betyder den stigende interesse for Node.js nye værktøjer, hvoraf nogle ligesom IBMs Node-RED tilbyder spændende tilgange, men de er stadig langt fra at være så komplette eller så dominerende som Eclipse eller IntelliJ.

Det underlige er, at udviklerne ikke ser ud til at bruge disse værktøjer. Kommandolinjen skulle forsvinde for 35 år siden med Mac-ankomsten, men ingen fortalte Node.js-udviklerne. Indstillingerne er der. WebStorm er for eksempel et solidt kommercielt værktøj fra JetBrains, der indeholder mange kommandolinjeværktøjer.

Selvfølgelig, hvis du leder efter en IDE, der redigerer og jonglerer kode, er de nye værktøjer, der understøtter Node.js, gode nok. Men hvis du beder din IDE om at lade dig redigere, mens du opererer på den kørende kildekode, som en hjertekirurg skiver et bryst op, ja, Java-værktøjer er meget mere kraftfulde. Det hele er der, og det hele er lokalt.

Hvor Node.js vinder: Databaseforespørgsler

Forespørgsler til nogle af de nyere databaser, som f.eks.CouchDB og MongoDB, er skrevet i JavaScript. At blande Node.js og et opkald til databasen kræver ingen gearskift, endsige ethvert behov for at huske syntaksforskelle.

I mellemtiden bruger mange Java-udviklere SQL. Selv når de bruger Java DB - tidligere Derby, en database skrevet i Java til Java-udviklere - skriver de deres forespørgsler i SQL. Du ville tro, de ville bare kalde Java-metoder, men du ville tage fejl. Du skal skrive din databasekode i SQL og derefter lade Derby analysere SQL. SQL er et dejligt sprog, men det er helt forskelligt fra Java, og mange udviklingsteam har brug for forskellige mennesker til at skrive SQL og Java.

For at gøre tingene værre bruger mange Java-kodere omfattende biblioteker og skemaer til at konvertere data fra SQL-forespørgslen til Java-objekter, så de kan omarbejdes i skabeloner. Det er en skør proces og i sidste ende temmelig spildende.

Hvor Java vinder: Typer

Mange af de indledende programmeringskurser fortsætter med at bruge Java, fordi mange seriøse programmører har tendens til at kunne lide statisk indtastet kode både for enkelhed og sikkerhed. Koden føles bare strengere, når compileren har fanget de åbenlyse bugs.

JavaScript er dog ved at indhente, og nogle udviklere skifter til TypeScript, et statisk skrevet supersæt af JavaScript, der anvender al den typekontrolmagi, før de spytter noget, der kører i din browsers JavaScript-stak. Hvis du elsker typer, kan det være nok for dig at omfavne JavaScript. Eller du kunne bare genkende efterligningen som den oprigtigste form for smiger og holde fast ved Java, som fra begyndelsen omfavnede statisk skrivning.

Hvor Node.js vinder: Syntaktisk fleksibilitet

JavaScript plejede at være et simpelt sprog til popping up uønskede advarselsbokse og dobbeltkontrol af formularinput. Derefter oprettede udviklerfællesskabet mange forskellige versioner af sproget, der kunne sendes til noget til browseren. Der er CoffeeScript-publikummet, der tilbyder en håndfuld forskellige syntakser designet til at tilfredsstille en smag for renere tegnsætning. Der er React / Vue-publikummet, der blander HTML og JavaScript sammen, bare fordi det er renere. Der er TypeScript til typeelskere og LiveScript til de funktionelle sproghengivne.

Du finder også en enorm mængde kreativitet i Java-verdenen, men af ​​en eller anden grund udtrykkes den ikke med mange forprocessorer. Der er et antal sprog som Kotlin, Scala og Clojure, der omdannes til bytekode for JVM, men på en eller anden måde føler de sig anderledes nok til at skille sig ud som separate sprog. Alle forprocessorer gør livet sjovere for JavaScript-programmører, der elsker forskellige måder at formulere eller tegne deres kode på.

Hvor Java vinder: Enkel byggeproces

Komplicerede byggeværktøjer som Ant og Maven har revolutioneret Java-programmering. Men der er kun et problem. Du skriver specifikationen i XML, et dataformat, der ikke var designet til at understøtte programmeringslogik. Sikker på, det er relativt let at udtrykke forgrening med indlejrede tags, men der er noget irriterende ved at skifte gear fra Java til XML blot for at bygge noget. Med JavaScript er der ingen skiftende gear.

Node.js plejede at have den enklere opbygning. Du ville bare redigere koden og derefter trykke på "kør". Det var dengang. Da Node-udviklerne har "forbedret" processen, har de tilføjet præprocessorer, der tager din foretrukne underdialekt til JavaScript og gør det til noget, der kan køres. Derefter skal Node-pakkehåndtereren finde det rigtige bibliotek. Det meste af tiden virker dette bare, men nogle gange fungerer det ikke, og så bruger du tid på at finde det rigtige versionsnummer på en artefakt, som du bygger dig selv i et separat trin. Og hvis du begår en eller anden fejl i artefaktopbevaringsstedet, er det versionsnummer skudt, og du skal dreje kilometertællerhjulene igen.

Java har også en kompleks byggeproces, der minder meget om Node.js-metoden, men det føles ikke som om den er blevet mere kompleks. På en eller anden måde ser Maven og Ant ud som en del af Java-fundamentet nu. Mange af de uslebne kanter er langt væk, og bygningerne fungerer bare oftere. Hvis der var noget absolut mål for besvær, kunne de to sprog være ens, men den hurtige eksplosion af JavaScript-kompleksitet betyder, at Java vinder.

Relateret video: Node.js tip og tricks

I denne forklaringsvideo lærer du flere teknikker, der kan forbedre din Node-udviklingsoplevelse.

Hvor Node.js vinder: JSON

Når databaser spytter svar, går Java ud i detaljerede længder for at gøre resultaterne til Java-objekter. Udviklere vil diskutere i timevis om POJO-kortlægninger, dvale og andre værktøjer. Konfiguration af dem kan tage timer eller endda dage. Til sidst får Java-koden Java-objekter efter hele konverteringen. Og når det kommer til konfiguration, klamrer Java-verdenen stadig til XML og tilbyder endda to store parsere for at give udviklere flere grunde til at bekymre sig.

I dag returnerer mange webtjenester og databaser data i JSON, en naturlig del af JavaScript. JSON er nu så almindeligt og nyttigt, at mange Java-udviklere bruger formatet, og en række gode JSON-parsere er også tilgængelige som Java-biblioteker. Men JSON er en del af grundlaget for JavaScript. Du har ikke brug for biblioteker. Det hele er der og klar til at gå.

Hvor Java vinder: Fjernfejlfinding

Java kan prale med utrolige værktøjer til overvågning af klynger af maskiner. Der er dybe kroge i JVM og detaljerede profilværktøjer, der hjælper med at identificere flaskehalse og fejl. Java enterprise stack kører nogle af de mest sofistikerede servere på planeten, og de virksomheder, der bruger disse servere, har krævet det allerbedste inden for telemetri. Alle disse overvågnings- og fejlretningsværktøjer er ret modne og klar til at blive implementeret.

Hvor Node.js vinder: Desktop

Der kører muligvis nogle Java-applets derude, og jeg vedligeholder stadig nogle Java JAR-filer, som jeg kan klikke på for at køre, men for det meste er desktop-verdenen stort set Java-fri. JavaScript fortsætter på den anden side med at fange mere og mere af handlingen, da browseren spiser de fleste af rollerne til vores desktop. Da Microsoft omskrev Office til at arbejde i browseren, blev die støbt. Hvis du stadig undrer dig over, er der interessante muligheder som Electron, der tager din webkode og gør den til en enkeltstående desktop-app.

Hvor Java vinder: Håndholdte

Android-apps er ofte skrevet i Java, og 90 procent af de nye telefoner kører en version af Android. Mange mennesker bruger ikke engang desktops mere, fordi telefonerne er gode nok til alt.

Selvfølgelig er der lidt forvirring. Mange udviklere skriver Node.js webapps, der er målrettet mod mobilbrowserne på både iPhone og Androids. Hvis dette gøres godt, er præstationen ofte god nok.

$config[zx-auto] not found$config[zx-overlay] not found