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.
undefined
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: undefined eller undefined.
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. undefined.
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 undefined konfigurationsfil i Node. Även om den levereras med en standardkonfigurationsfil är det möjligt att lägga till din egen undefined.
Eftersom TypeScript bara är en superset av JavaScript kan Deno också köra det.
undefined
För att köra ett skript kan du skapa ett undefined fil med kodavsnittet ovan och kör det genom att köra: undefined. 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.
undefined
Om du försöker köra föregående kodavsnitt:
undefined
För att undvika felet måste du lägga till undefined flagga för att kunna få tillgång till miljövariablerna:
undefined
Det finns ett alternativ för att tillåta all åtkomst undefined eller undefined, men detta rekommenderas inte.
På olika sätt är Node mycket tillåtande, du har full tillgång till i stort sett allt:
undefined
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.
Ä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:
undefined
För att köra föregående utdrag kan du bara köra: undefined. 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:
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 undefined 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 undefined 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, undefined 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å nej undefined och nej undefined
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 undefined 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:
undefined
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:
undefined
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:
undefined
Ä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 undefined objekt och API: er som undefined, undefined, undefined och undefined.
Deno tillhandahåller en global undefined objekt och API: er som undefined, undefined, undefined och undefined.
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:
undefined
Även om fönsterobjektet inte är tillgängligt i Node kan du använda undefined 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.
People who read this post, also found these interesting:
.webp)
