Ich bin sicher, viele von euch achten sowieso auf Deno, das Next-Gen-JavaScript-on-the-Server-Projekt vom Node-Erfinder Ryan Dahl, besonders nachdem er all diese aufrichtigen Reuebekundungen darüber fallen gelassen hat, was bei Node passiert ist. Aber vielleicht achtet ihr jetzt mehr darauf, da Deno etwas Startkapital erhalten hat und sich selbst in ein Unternehmen verwandelt, während es Open-Source bleibt.
Damit Deno wachsen und maximal nützlich sein kann, muss es permissiv frei bleiben. Wir glauben nicht, dass das „Open Core“-Geschäftsmodell für eine Programmierplattform wie Deno richtig ist. Wir wollen uns nicht in der unglücklichen Lage wiederfinden, entscheiden zu müssen, ob bestimmte Funktionen nur für zahlende Kunden bestimmt sind. Wenn ihr euch unsere Konferenzvorträge anseht, werdet ihr feststellen, dass wir seit Jahren auf kommerzielle Anwendungen dieser Infrastruktur hindeuten. Wir sind von dem technologischen Stack, den wir aufgebaut haben, begeistert und beabsichtigen, diese kommerziellen Anwendungen selbst zu verfolgen. Unser Geschäft wird auf dem Open-Source-Projekt aufbauen und nicht versuchen, es direkt zu monetarisieren.
Ich bin begeistert davon, weil es auch andere in gewissem Maße sind. Ich weiß, dass die „standardmäßig sichere“ Natur es für meinen extrem sicherheitsbewussten Mitbegründer Alex begeistert.
Ich finde Funktionen wie „TypeScript out of the box“ interessant. Obwohl ich selbst kein TypeScript benutze, finde ich es bemerkenswert, welch große Bedeutung es hat. Als ich vor ein paar Jahren mit Laurie Voss sprach, erfuhr ich, dass fast zwei Drittel der Entwickler es benutzten, und es scheint nicht an Dynamik verloren zu haben. Und ihr habt Scott Tolinski, der hier schwärmt, wie GraphQL komplett typisiert ist und man diesen traumhaften, vollständig typisierten Stack bekommt, wenn TypeScript Teil des Mixes ist.
Es gibt bereits einen Bundler (buchstäblich, Bundler) für Deno, der TypeScript out of the box unterstützt, zusammen mit JSX. Ratet mal, was noch? Die großen Build-Tools der nächsten Generation, Snowpack, Vite und wmr.
Deno ist auch in Rust geschrieben, was ein interessanter Aspekt bei all dem ist, teilweise wegen der Geschwindigkeit (es ist schnell). Snowpack und Vite verwenden beide esbuild im Hintergrund, das in Go geschrieben ist (auch schnell). Ich habe kein gutes Gefühl dafür, ob Go oder Rust für diese Art von Arbeit schneller ist, aber sie sind beide ein großer Sprung nach vorne gegenüber den meisten Bundlern und Task-Runnern, die wir heute verwenden. Man kann esbuild sogar direkt verwenden, oder mit leichten Abstraktionen darüber, wie Estrella. Wieder mit TypeScript-Unterstützung.
Das lässt mich an Babel denken. Wenn man TypeScript nicht damit durchlaufen lässt, und es nicht für JSX benötigt, und es nicht benötigt, um grundlegende ES6/7-Sachen wegzukompilieren, da die Unterstützung jetzt so weit verbreitet ist, wie lange wird es bestehen bleiben? Eine lange Zeit, ist natürlich die Antwort. Ein Projekt, das so groß ist wie Babel, verschwindet nicht einfach. Ich nehme an, es braucht nur ein exotisches und begehrenswertes neues JavaScript-Feature, das in eine bestehende Syntax kompiliert werden kann, und jeder wird es wieder in seine Pipelines einbauen.
Ich denke, Babel (früher 6to5) hat erkannt, dass es immer einen Bedarf/Wunsch geben wird, neue Features zu testen. Deshalb haben sie den Namen „es6 to es5“ fallengelassen. Aber ich stimme zu, dass viele Projekte derzeit keine Transpilierung benötigen. Vielleicht werden ES10 oder ES12 Änderungen haben, die für ein Feature-Flag in Node oder Deno zu radikal sind, aber mit etwas wie Babel ist das kein großes Problem.