Jag vet inte om du är uppdaterad med nyheterna, men Deno är den nya stjärnan på Javascript-ekosystem - vissa säger till och med att det kommer att döda Node. Nu när Deno släpps är det dags att ta reda på om det kan vara en värdig tävling för Node. Nyfiken? Låt oss börja!
I det här inlägget kommer vi att ta en titt på Deno mot Node och jämföra dem för att förstå vad de har gemensamt, och vad som skiljer dem åt när det gäller:
Jag hoppas att vi kan hjälpa dig att ha en klar uppfattning om vad som är bäst för dig.
Vid Imaginärt moln, vi har använt Node för att bygga API:er, betjäna frontend och för att bygga mikrotjänstarkitekturer, bland andra.
Node en JavaScript-miljö på serversidan baserad på Googles V8 JavasScript-motor, skapad av Ryan Dahl 2009 och var starkt fokuserad på händelsedrivna HTTP-servrar. Det förde JavaScript på serversidan till mainstream och det var detta JavaScript överallt paradigm som möjliggjorde utveckling av webbapplikationer med ett enda programmeringsspråk.
Snabbspola fram till 2018 höll Ryan Dahl ett föredrag i JSconf EU med titeln Designfel i Node - även känd som ”10 saker jag ångrar om Node.js ”. I sitt föredrag beskriver han sina ånger angående några av de val som gjordes i utvecklingen av Node. Som han påpekar, när Node började utvecklas, var JavaScript ett mycket annorlunda språk, och det saknade några av de mest moderna funktionerna:
Med tanke på att många av de designfel som nämns vid föredraget inte kunde åtgärdas utan att skriva om kärnan i Node och därmed avsluta stödet för äldre applikationer, bestämde Ryan sig för att introducera Deno.
Först och främst är det inte en fork av Node - det är en ny implementering baserad på moderna funktioner i JavaScript-språket, även om namnet är ett anagram av Node. Deno är en säker körtid för JavaScript och TypeScript baserat på Googles V8 och dess kärna är inbyggd i Rust (Nodes implementering är i C ++). Den använder Tokio för sin händelselinga, som också är skriven i Rust.
För andra installationsmetoder, kontrollera officiell dokumentation.
(När jag skriver detta är den tillgängliga Deno-versionen 1.46.3).
Deno levereras som en enda körbar fil utan beroenden och levereras med några inbyggda verktyg för att göra utvecklarupplevelsen enklare:
Alla dessa verktyg är standardiserade för Deno, så du är säker på att de kommer att ha fullt stöd.
Eftersom Deno är en enda körbar kan Deno uppdatera sig själv via: deno uppgradering eller deno uppgradering --version <new_version>.
Detta hämtar den angivna versionen (eller senaste om den inte specificeras) och ersätter din nuvarande körbara med den.
Det är möjligt att ha flera versioner installerade, med hjälp av versionshanterare.
För Node ansvarar versionshanterare också för att uppdatera/installera nya versioner, t.ex. nvm.
Deno är baserat på TypeScript, så det stöder det direkt utan att behöva installera eller konfigurera verktyg, som att lägga till en tsconfig.json konfigurationsfil i Node. Även om den levereras med en standardkonfigurationsfil är det möjligt att lägga till din egen deno kör -c tsconfig.json [fil-till-kör.ts].
Eftersom TypeScript bara är en superset av JavaScript kan Deno också köra det.
För att köra ett skript kan du skapa ett hello-world.ts fil med kodavsnittet ovan och kör det genom att köra: deno kör hello-world.ts. Detta kommer att använda Microsofts TypeScript-kompilator för att kontrollera typer och producera JavaScript och sedan köra skriptet.
Just nu antar Denos team att tiden det tar V8 att analysera TypeScript jämfört med JavaScript är mycket högre och det är en pågående uppgift för att portera TypeScript Compiler till Rust.
Ett av huvudfokuserna är säkerhet. Deno är säkrad som standard och koden körs i en säker sandlåda, vilket replikerar samma behörighetsmodell som webbläsaren implementerar. Om det inte anges har den ingen tillgång till filsystemet, nätverket eller miljövariablerna, och åtkomstbehörigheter måste uttryckligen skickas till Deno-processen på kommandoraden.
Om du försöker köra föregående kodavsnitt:
För att undvika felet måste du lägga till --tillåt—env flagga för att kunna få tillgång till miljövariablerna:
Det finns ett alternativ för att tillåta all åtkomst --tillåt alla eller -EN, men detta rekommenderas inte.
På olika sätt är Node mycket tillåtande, du har full tillgång till i stort sett allt:
Deno använder ES Modules, det officiella standardformatet för att paketera JavaScript-kod, introducerat i ES6/ES2015:
När Node skapades hade JavaScript inte sitt eget modulsystem, så det använde CommonJS-standarden:
Just nu har Node bara experimentellt stöd för ES-moduler och du måste göra några konfigurationer/ändringar av befintliga filer.
Jag kommer inte att gå in i detalj om skillnaderna, men om du vill ha en djupgående titt på båda modulsystemen rekommenderar jag att du läser detta.
Även om det i allmänhet inte är kompatibelt med Node-paket, tillhandahåller Deno ett Node Compatibility Library, som gör att vi kan använda vissa NPM-paket som inte använder icke-polyfyllda Node API: er.
En av de största fördelarna är att det använder ett vanligt webbläsarkompatibelt protokoll för att ladda moduler, så att du kan importera moduler direkt via webbadresser, vilket har en enorm inverkan på hur vi hanterar moduler.
Med tanke på att Deno använder webbadresser för att ladda moduler, tar det uttryckligen rollen som både runtime och pakethanterare. Det är inte beroende av en centraliserad server för distribution av moduler. Det betyder att det kräver fullt kvalificerade modulnamn, inklusive tillägget (eller en server som tillhandahåller rätt mediatyp).
Du kan importera moduler direkt och använda beroenden som kod:
För att köra föregående utdrag kan du bara köra: deno kör --allow-net http-server.ts. Det finns ingen installation att göra i förväg eftersom Deno laddar ner och cachar en modul i en global katalog första gången dess URL påträffas i ett skript. Modulens cache har två huvudmål:
—ladda om flagga om du vill återställa cacheminnet manuellt.
Alla moduler och filer som laddas från fjärr-webbadresser, förutom att de är cachbara, är också avsedda att vara oföränderliga.
Som du säkert märkte kräver import helt kvalificerade modulnamn, inklusive tillägget. Dessutom har Deno ingen ”magisk” modulupplösning. Istället anges importerade moduler som filer (inklusive tillägg) eller fullständigt kvalificerade URL-import.
Nod använder npm som pakethanterare för att installera och hantera paket från tredje part som anges i NPM-registret. Detta gör länkning till externa bibliotek fundamentalt centraliserad genom NPM-registret. När du installerar ett paket i ditt projekt med NPM/Yarn, a paket.json fil används för att ange paketnamn och accepterade versioner, och paketen laddas ner till en node_modules mapp i ditt projekt. Som ett resultat, node_moduler mappar blir enorma, eftersom moduler kräver specifika versioner av andra moduler, och de kommer att replikeras i varje enskild projektkatalog det kräver.
Deno använder inte NPM för beroendehantering, så nejpaket.jsonoch nejnode_moduler
Deno tillhandahåller kuraterade standardmoduler av hjälpare och verktyg för vanliga uppgifter som granskas av Deno Core-teamet.
Dessa moduler kommer att märkas i enlighet med Deno-utgåvor. Om du inte anger en tagg länkas automatiskt till huvudgrenen, så det rekommenderas att du länkar till taggade versioner för att undvika oavsiktliga uppdateringar och oönskade ändringar.
Om du vill låsa en specifik modulversion kan du använda en lås.json fil, för att kontrollera modulintegritet.
Deno tillhandahåller en värdtjänstens integritet för Deno-skript. Den cachar utgåvor av open source-moduler lagrade på GitHub och serverar dem på en domän som är lätt att komma ihåg.
Till exempel, om du letar efter ett datumverktyg kan du använda https://deno.land/x sökfunktion som hjälper dig att hitta moduler. När du har hittat den modul du vill ha, i det här fallet date-fns, kan du bara importera rätt URL i filen du använder den i:
För alla andra NPM-paket, om de inte är kompatibla med esmodule-import, kan du använda en tjänst som JSPM som kommer att lösa tredjepartsmodulerna och kompilera CommonJS-modulerna för att fungera som ES-moduler import.
Deno använder löften hela vägen ner - alla asynkrona metoder returnerar löften:
Från föregående utdrag kan du se att Deno stöder toppnivå väntar. Detta gör att vi kan använda väntesyntaxen i det globala omfånget utan att behöva lägga in den i async-funktionen. Nyligen lade Node Node också till stöd för att vänta på toppnivå.
Långt före Promises eller async/wait utformades Node's API för asynkrona operationer för att använda återuppringningar och följa felåteruppringningskonventionen:
Även om Node-utvecklare nu har tillgång till Promises och syntaxen async/wait, förväntar sig Nodes API fortfarande att återuppringningar upprätthåller bakåtkompatibilitet.
Förmodligen är en stor skillnad att Deno alltid dör omedelbart på ohanterade löften, där Node för närvarande hanterar avslag genom att avge en avståndsvarning till stderr. Just nu kör Node en undersökning för att bättre förstå hur användarna hanterar detta.
Utvecklingsteamet bestämde sig också för att använda webbläsar-API:er där det är praktiskt att göra det. På samma sätt tillhandahåller Deno en global fönster objekt och API: er som AddEventListener, ladda, ladda ner och hämta.
Deno tillhandahåller en globalfönsterobjekt och API: er somAddEventListener,ladda,ladda nerochhämta.
Detta innebär att Deno-program skrivna helt i JavaScript som inte använder det globala Deno-namnutrymmet (eller funktionstestet för det), borde vara isomorfa, vilket innebär att de kommer att kunna köras i en modern webbläsare utan någon förändring:
Även om fönsterobjektet inte är tillgängligt i Node kan du använda hämta om du polyfyller detta eller använder ett tredjepartsbibliotek.
Vilket är bäst: Deno eller Node? Deno är säkert som standard och stöder TypeScript utan att behöva en kompilator, men har ett mindre ekosystem. Node.js har ett stort biblioteksekosystem och används ofta, men har historiska säkerhetssårbarheter. Det ”bästa” valet beror på dina specifika behov och förtrogenhet.
Så målet med Deno är inte att ersätta Node, utan att erbjuda ett alternativ.
Node har varit under utveckling i över ett decennium, vilket gör den mer stabil och stridstestad, vilket gör den till de facto-standarden för JavaScript på serversidan. Deno har bara varit under utveckling i bara två år och fortsätter att förbättras. Bland annat är Deno en utmärkt ersättning för verktygsskript som vanligtvis skrivs med bash eller python.
Det beror på kraven, men för de flesta Node-applikationer kanske Deno inte passar just nu. Ett av de viktigaste hindren att ta itu med är skapande/konvertering av NPM-moduler som ska användas med Deno och detta kommer förmodligen att förändras i framtiden när stöd för Node ES Modules kommer att bli mer standard.
Jag tror dock att vi gradvis kommer att se Deno adopteras mer och mer på grund av dess förstklassiga TypeScript-stöd och moderna standardbibliotek. Nodprogrammerare bör hålla ett öga på Deno och kanske försöka använda det för vissa sidoprojekt.
En sak är säker, Denos nuvarande utveckling driver JS-serverns ekosystem framåt och det är bra.
Hittade den här artikeln användbar? Du kanske gillar dessa också!
Senior utvecklare på Imaginärt moln, specialiserat på att skapa innovativa mjukvarulösningar, brinner för teknik och kodningsexpertis.
Människor som läste det här inlägget tyckte också att dessa var intressanta:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
