Ryan Dahl, twórca Node.js tj. środowiska uruchomieniowego, obudowanego wokół silnika JavaScript V8, pracuje nad kolejnym tego typu rozwiązaniem. Nosi ono nazwę Deno, co jest anagramem Node. W zamierzeniu Deno powinno być odpowiedzią na pewne ograniczenia Node.js i obok JavaScriptu będzie też kompilować TypeScript, prócz tego jest pisane w duchu zmian jakie nastąpiły w samym JavaScriptcie od 2009 roku (czas w którym Ryan Dahl rozpoczął implementację Node.js), ponadto ma dostarczyć bezpieczniejsze wykonywanie kodu. Należy mieć na uwadze, że JavaScript nie jest językiem wyłącznie kompilowanym, jest to zależne od przeglądarki WWW, bywa on też interpretowany, niemniej w przypadku V8 następuje bezpośrednia kompilacja do kodu maszynowego. Silnik V8 jest kompilatorem i niczym więcej, ponadto nie występuje w nim etap bytecodu, gdy w odmiennych rozwiązaniach kompilator jest dodatkiem do silnika

Główne różnice między Deno a Node.js:

Author: Deno.land | CC: MIT

1. Zastosowanie ES Module zamiast CommonJS, jako domyślnego systemu modułów.
2. Użycie adresów URL do lokalnego lub zdalnego ładowania zależności, analogicznie do przeglądarek WWW.
3. Zawiera wbudowany menedżer pakietów, jaki pobiera zasoby (resource fetching), toteż nie istnieje potrzeba używania NPM.
4. Domyślnie wspiera TypeScript i posiada jego kompilator z obsługą migawek (snapshots) i mechanizmem buforowania (caching).
5. Deno zostało zaprojektowane w celu osiągnięcia szerszej kompatybilności z przeglądarkami WWW i większym zakresem Web API.
6. Umożliwia kontrolę dostępu do systemu plików i sieci, w celu uruchomienia kodu w trybie piaskownicy.
7. Przeprojektowanie API w celu użycia Promises i funkcji znanych z ECMAScript 6 i TypeScriptu.
8. Zminimalizowanie rozmiaru API przy jednoczesnym dostarczeniu biblioteki standardowej, jaka nie posiada zewnętrznych zależności.
9. Użycie kanałów przekazywania wiadomości (message passing) w celu przywołania uprzywilejowanych, systemowych, API przy użyciu bindingów.

Niemniej Node.js i Deno korzystają z tego samego silnika V8, używanego w Google Chrome. Ponadto oba dostarczają tekstowy interfejs w celu wykonania skryptów i wewnętrznie działają w oparciu o pętlę zdarzeń (event loop). Pierwotnie Deno było pisane przy użyciu Go, jednakże zostało ono zastąpione Rust, m.in. z powodu obaw o narzut odśmiecania pamięci.

Zobacz też: Rust zyskał silnego sprzymierzeńca. Amazon zainwestuje w rozwój języka Mozilli

Przeczytaj również: Zdalne debugowanie w Chrome za pomocą DevTools

Bezpieczeństwo

Deno domyślnie nie zezwala programom na dostęp do systemu plików, sieci, podprocesów i zmiennych środowiskowych. Jeżeli zajdzie tego typu potrzeba to Deno umożliwia szczegółową kontrolę z poziomu linii komend, przy użyciu dodatkowych opcji:

--allow-read=/tmp lub --allow-net=google.com

Ponadto Deno ma przerwać swoje działanie, gdy natrafi na uncaught errors, kiedy Node.js wykonywałoby dalej kod, nawet jeśli rezultat mógłby być nieprzewidziany.

Moduły Deno

W Node.js moduły ładowano za pomocą słowa kluczowego require, a one wszystkie pochodziły z npmjs.com. W Deno moduły ES przywołuje się słowem kluczowym import, podając przy tym adres URL. Moduły w Deno mogą być przechowywane gdziekolwiek, nie ma tutaj scentralizowanego repozytorium. Oprócz tego są one przechowywane i kompilowane lokalnie i nie zostaną uaktualnione, jeśli odświeżenie nie zostanie świadomie wywołane. Standardowe moduły Deno są „luźnym” portem analogicznej biblioteki standardowej Go.

Podsumowanie

Deno, kiedy osiągnie wersję 1.0, może być wartościową alternatywą dla Node.js, o tyle ciekawą, że napisaną w nowoczesnym języku Rust, przy użyciu biblioteki Tokio w celu zaimplementowania pętli zdarzeń (event loop). Przede wszystkim może wyzwolić to ekosystem JavaScriptu z wymogu korzystania z centralnego repozytorium, jakim jest npm. Póki co Deno wydaje się przyjemne do eksperymentowania z budowaniem małych i prywatnych skryptów.