Deno - Eine Alternative zu NodeJS?

    • Hilfreich

    Moin,

    heute möchte ich euch mal auf etwas neues aufmerksam machen; Deno. Da Deno vor kurzer Zeit offiziell mit der Version 1.0 released ist, denke ich ist es mal an der Zeit, dass einige Leute aufgeklärt werden, was Deno denn überhaupt ist.


    Was ist Deno?

    Deno ist wie die Webseite selber sagt eine simple, moderne und besonders sichere JavaScript Runtime. Deno ist sehr ähnlich wie NodeJS, und der Ziel von Deno ist es auch NodeJS zu ersetzen. Ähnlich wie NodeJS läuft Deno auf der V8 JavaScript Engine. Es ist aber in Rust geschrieben, NodeJS ist in C++ geschrieben.

    Deno ist von dem Entwickler Ryan Dahl, welcher auch der originale Entwickler von NodeJS ist.

    Die Besonderheiten von Deno im Vergleich zu NodeJS sind besonders der native TypeScript Support, die Sicherheitsfeatures, die mitgelieferten Tools und die dezentralisierten Packages. Aber auf diese Features, gehe ich gleich auch noch einmal genauer ein.


    Es gibt doch schon NodeJS, wofür brauch man jetzt also Deno?

    Das Ziel von Deno ist es, wie NodeJS zu sein, aber alles gute von NodeJS zu nehmen und zu verbessern und alles schlechte wegzulassen.

    Das größte Problem von NodeJS ist nämlich die Sicherheit. Jeder der schon einmal ein etwas größeres Projekt mit NodeJS umgesetzt hat, welches auf anderen Third-Party Libraries basiert, der weiß genau wie riesig der node_modules Ordner wird. Denn jede Library verwendet andere Libraries, und die verwenden auch wieder andere Libraries und es geht immer so weiter. Deswegen hat eine Library manchmal unglaublich viele Dependencies, und jede dieser Dependencies kann ein Sicherheitsproblem darstellen. Denn dieser Gedanke, dass eine Library von jemand übernommen wird der damit Schabernack treibt, ist leider schon oft Realität geworden. Du hast mit NodeJS Zugriff auf sehr viel, ohne dass man irgendwelche besondere Rechte angibt, kann NodeJS einfach Dateien löschen oder verschieben. Und genau das ist schon einige male passiert, irgendeine große Library hat eine kleine Dependency, welche von jemand übernommen wird, der dann dort irgendetwas einbaut, was man eigentlich gar nicht in seinem Code haben will.


    Dezentralisierte Packages

    Und dieses Problem will Deno beheben, denn bei Deno gibt es kein NPM.

    Das klingt erstmal natürlich schlecht, soll ich jetzt einfach alles selber schreiben oder was?! Nein. Deno lädt nämlich Packages einfach direkt von einer URL aus, und nicht aus einer lokalen Datei.

    Um beispielweise das offizielle Deno Package für einen HTTP Server zu importieren benutzt man einfach folgendes:

    JavaScript
    import server from "https://deno.land/std@0.50.0/http/server.ts";

    Diese Datei wird natürlich nicht bei jedem Start neu heruntergeladen, sonst würde das starten von einer Deno Applikation ja jedes mal unglaublich lange dauern, die Dateien werden beim ersten importieren in einem Cache gespeichert, damit es beim nächsten mal lokal geladen wird.

    Durch diesen Weg Packages zu importieren wird das ganze dezentralisiert. Denn wir haben nichtmehr einen einzigen Ort von dem wir unsere Packages beziehen (NPM), sondern jeder kann seine Packages selber dort hosten wo man will.


    Explizite Rechtevergabe

    Das nächste wichtige Feature welches Deno sehr viel sichererer als NodeJS macht ist, dass Deno nicht automatisch alle Rechte hat.

    Wenn du also ein Deno Programm welches z.B. einen HTTP Server startet einfach mit Deno startest, dann wird das nicht funktionieren. Man erhält einen Fehler dass die Berechtigungen fehlen und die Applikation beendet sich.

    Du musst also Deno immer explizit Zugriff geben auf genau die Features welche du benötigst, warum sollte meine Deno Applikation auch Zugriff auf das Dateisystem erhalten, wenn es garkeine Dateien liest oder schreibt?

    Diese Rechte sind sogar weiter konfigurierbar, z.B. dass die Applikation nur auf gewisse Ordner oder Dateien Zugriff hat. Oder dass externe Anfragen nur auf eine bestimmte URL gemacht werden können.

    Und durch diese Sicherheitsfeatures, ist es nicht möglich für einen Angreifer einfach ungewollten Code in eine externe Library zu packen, denn jeder kann es sehen wenn eine weitere Permission hinzugefügt wird, die diese Library eigentlich garnicht brauch.


    Nativer TypeScript Support

    Wie man in dem Beispielcode gesehen hat, wird eine .ts Datei importiert, wie jeder weiß endet eine JavaScript Datei aber mit .js, was ist das also? Deno unterstützt nativ TypeScript. TypeScript ist ein Superset von JavaScript, welches es ermöglicht statische Typen anzugeben, denn Variablen und ähnliches in JavaScript haben keinen festgelegten Typ, sie können eine Zahl sein, oder ein String oder ein Objekt. TypeScript ist aber nur ein Superset, das heißt also dass man TypeScript Dateien compilen muss, und zwar werden TypeScript Dateien in normale JavaScript Dateien umgewandelt, die jeder JavaScript Interpreter versteht.

    Aber um genau herauszufinden was TypeScript ist, empfehle ich einfach mal zu googlen.


    In NodeJS war es also nun immer der Fall, dass man erstmal einen TypeScript Compiler aufsetzen muss, der den geschriebenen TypeScript Code in JavaScript Code compiled, damit man dann den resultierenden Code mit NodeJS laufen lassen kann.

    Das ist in Deno nicht so, denn Deno hat einen eingebauten TypeScript Compiler, um den man sich nicht kümmern muss. Es gibt keine Configs und nichts, sondern du erstellst eine TypeScript Datei mit der .ts Endung, und startest diese mit Deno, Deno compiled diese TypeScript Datei dann automatisch für dich und läuft wie gewohnt!

    Falls man aber trotzdem seine eigene TypeScript Konfiguration verwenden will, ist das natürlich auch möglich, die muss man dann beim starten nur angeben.


    Mitgelieferte Tools

    Jede erfolgreiche NodeJS Applikation verwendet viele verschiedene Tools um den Code zu gut wie möglich zu halten, wie z.B. ein Debugger, ein Formatter, ein Bundler und ein Dependency Inspector.

    Aber bei diesen Tools gibt es keinen offiziellen Standard, z.B. gibt es zig verschiedene Formatter wie Prettier, Standard, Beautify und sehr viele mehr.

    Das heißt dass der Code zwar "schön" ist und sich an einen Standard hält, aber es gibt nicht nur einen einzigen Standard, und das ist halt eigentlich gar nicht der Sinn von so einem Standard.


    Genau deswegen liefert Deno all diese verschiedenen Tools die ein Entwickler für seine Applikation brauch einfach mit. Du brauchst einen Formatter? Einfach den mitgelieferten Formatter mit einem einzelnen Befehl ausführen, und fertig, der Code wurde "verschönert".

    Du willst deine Applikation debuggen? Kein Problem, Deno liefert einen Debugger mit.

    Und das waren natürlich noch nicht alle hilfreichen Tools die Deno mitliefert, in der Dokumentation findet man sie alle aufgelistet und wie man sie verwendet.


    Einen Standard für all diese Tools zu haben ist gut, denn dadurch ist es auch wirklich ein Standard, der von allen verwendet wird.


    Offizielle Packages

    Genauso wie NodeJS bietet Deno auch offizielle Packages an, wie z.B. für einen HTTP Server, für das verwenden des Dateisystems, zusammensetzen von Pfaden etc.

    Das sind Packages die eine besonders hohe Qualität haben und ständig verbessert und erweitert werden, da diese vom offiziellen Deno Team geschrieben sind.

    Auf diese Packages kann man sich also immer verlassen, dass diese funktionieren, keine Bugs oder Sicherheitslücken beinhalten und dass man diese immer verwenden kann.


    Fazit über Deno

    Deno ist definitiv für jeden NodeJS Entwickler ein Newcomer, welchen man genau im Auge behalten sollte.

    Ich finde Deno ist definitiv super, und ein sehr großer Schritt in die richtige Richtung. Es wird wahrscheinlich noch sehr lange weiterhin NodeJS regieren, aber vielleicht sieht man dann ja doch irgendwann dass Deno weit genug fortschreitet um den Markt zu übernehmen und den Platz von NodeJS einzunehmen.

    Definitiv sehr interessant, und ich bin gespannt wie es in der Zukunft mit Deno weiter geht.

    Die Features welche Deno bietet, besonders im Bereich der Sicherheit sind einfach etwas womit NodeJS nicht mithalten kann, aber dadurch dass Deno leider halt noch relativ unbekannt ist, wird es wohl noch einige Zeit dauern bis Deno zum Mainstream gehört.


    Ich bedanke mich bei jedem der sich die Zeit genommen hat diesen riesigen Text zu lesen, und ich hoffe dass ich vielleicht ein paar Leute neugierig gemacht habe, damit sie sich Deno mal genauer anschauen.



    Euer (endlich mal wieder einen normalen Thread verfassender) Leon,

    xoxo

  • Wenn das xoxo am Ende nicht gewesen wäre, wäre es fast ein ordentlicher Beitrag geworden.

    Spaß beiseite.

    Ich verfolg das ganze schon etwas und prinzipiell find ichs ne gute Sache. Ziel war ja all das was Ryan selbst meint bei Nodejs falsch gemacht zu haben jetzt richtig zu machen (gibt mehrere Videos auf diversen cons wo er aufzählt was er falsch gemacht hat / ändern würde).

    Nativer ts support ist ein echt gutes feature.

    Mal beobachten welche großen npm packages demnächst auch ein deno module bereitstellen.

  • Man hätte auch einfach NodeJS nach und nach verbessern können. Aber whatever.


    Hab es auch schon länger auf dem Schirm und bin gespannt wie sich das entwickelt. Hoffentlich werden die Fehler nicht erneut gemacht und dann kommt man mit "Oden" oder was auch immer um die Ecke.

  • Man hätte auch einfach NodeJS nach und nach verbessern können. Aber whatever.

    Nein, da eben viele grundlegende Designentscheidungen von NodeJS verbessert werden müssten, und das kann man nicht einfach machen wenn etwas so weit verbreitet ist und verwendet wird.

    Diese Änderungen sind halt viel mehr als nur "Breaking changes" deswegen kann man das nicht einfach so in NodeJS selber implementieren.