Node.js + TypeScript: Nie wieder JavaScript! // deutsch

JavaScript ist in den vergangenen 20 Jahren nach und nach auch im Enterprise-Bereich salonfähig geworden. Aus kaum einem zeitgemäßen Web- oder Cloud-Projekt ist die Sprache noch wegzudenken.

Doch das heißt noch lange nicht, dass Entwicklerinnen und Entwickler JavaScript gerne einsetzen. Nicht umsonst gibt es TypeScript, quasi ein verbessertes JavaScript, das ein optionales statisches Typsystem und einen sehr verlässlichen Compiler bietet.

Doch TypeScript einzurichten, ist immer noch zeitaufwändig und umständlich, wenn auch das ganze Tooling TypeScript unterstützen soll: Vom Formatting über das Linting bis hin zum Testrunner.

Und übrigens: Wenn Du und Dein Team Unterstützung bei der Konzeption, dem Entwurf und der Entwicklung von Web- und Cloud-basierten Anwendungen benötigt, dann meldet Euch gerne bei uns:

────────────────────

Willst Du wissen, welche Videos es noch von uns gibt oder suchst Du eines zu einem bestimmten Thema? Hier findest Du die perfekte Übersicht über alle unsere Videos:

────────────────────

Möchtest Du demnächst den Job wechseln, hast aber Angst vor den technischen Fragen im Bewerbungsgespräch? Wir können Dir helfen! Werde Mitglied in unserem Coding-Circle und erhalte jede Woche exklusive Videos:

────────────────────

Hast Du Fragen zu diesem Video oder willst Du Dich mit Gleichgesinnten aus der Community austauschen? Dann komm auf unseren Discord-Server:

────────────────────

00:00 – Einleitung
01:09 – TypeScript als Workaround
03:24 – Die große Überraschung 🎉
03:35 – Der aktuelle Stand der Dinge
04:56 – Was geht, was geht nicht
05:40 – Wie funktioniert Type-Stripping?
06:26 – Einschränkungen der ersten Version
08:42 – Performance und neue Features
09:30 – Vorsichtiger Optimismus

────────────────────

[carstenholtkamp]

Immer schön frisch und ehrlich.

„One does not simply configure TS“ :-)

Wobei Rust auch viel variablen payload mitbringt, wann auch nicht vergleichbar mit Node-Modules.

[-Jakob-]

2:52 Für Typescript gibt es ja keine Laufzeitumgebung, ist ja nur ein Transpiler. Node funktioniert so gut, weil grosse Firmen Unmengen an Geld investiert haben, um eine extrem effiziente (zumindest in Sachen Performance) Javascript-Laufzeitumgebung zu schaffen --- für Browser, daher mit JIT-Compiler etc. - was wiederum ein Ressourcenfresser par excellence ist. Node hat diese Technologie ja nur für Server recyclet, was suboptimal ist. Man vergleiche mal den Ressourcenbedarf von Go- oder Rust-Apps mit NodeJS-Apps.

[Sourcerr]

Endlich mal eine "native" Lösung. 🎉
Da kann man nur hoffen dass das Interesse nicht zu schnell abflaut.

[schnudderi]

Für seriöse Software-Entwicklung ist schwache Typisierung einfach Mist.
Für schnell einen Hack zu schreiben ist es praktisch

[marinaegner]

Endlich 😅 Wurde wirklich Mal langsam Zeit.

[rupertbogensperger]

Krass das es erst jetzt kommt. Schon Jahre überfällig ^^

[mzhomie]

Diese ganzen Konfiguration innerhalb von Node / TypeScript Projekten machen einen manchmal echt fertig. Hier eine config dort eine config, dann zich Werte, die man dort setzen kann aber vielleicht nicht muss. Manche können in die package.json manche nicht... gelockt wird man mit einer index.js und einer package.json. Dann oh eine typescript.config wäre gut und dann bricht der Damm für Formater, Linter, zich Frameworks 😂

[deleonio]

Ich verstehe die Notwendigkeit nicht, wenn es doch wieder pro Projekt entkoppelt funktionieren soll. Was sind die konkreten Vorteile gegenüber dem aktuellen Setup? Und ja, ich habe Prettier und Co gehört, aber kein Wort, wieso das mit Node.ts plötzlich obsolet wäre.

[DJTechnostyler]

Wenn jetzt noch die Browser TypeScript unterstützen würden, würde ich tatsächlich auch wieder zurück nach TypeScript wechseln. Momentan hab ich wegen der Toolchain die Schnauze voll von TypeScript und verwende stattdessen JSDoc

[raumkosmetiker]

Kann ich nicht einfach mit Go, Rust oder von mir aus auch mit Java entwickeln? 😀 Sofern es passt vom Projekt. Verursacht alles weniger Kopfschmerzen.

[emhome]

Bun ist schon nice und flott, müsste aber noch etwas länger testen.

[Leon-cmuk]

Ich frage mich oft, was bringt es eine bestimmte Technologie zu hypen und für sich als den heiligen Gral zu ernennen? Ich sehe diese Tendenz bei vielen Entwicklern. Sollte man nicht technologieoffen sein, um relevante Trends nicht zu verpassen und so seine Anwendung best möglich zu bauen?
Das heißt nicht, dass man auf jeden Zug aufspringen muss, aber zumindestens mal experimentell testet, was so womit umzusetzen geht.

[longingbydesign]

Typescript macht auch jede Menge falsch. Eine sehr nervige Last beim Entwickeln von z.B. nativen Komponentenbibliotheken. Ich bin so froh dass ich da mit JSDoc dasselbe Ziel erreichen kann, ohne dass ich deswegen eine andere Sprache nutzen muss. Ist das dann eine experimentelle Implementierung des mehr als fragwürdigen Proposals von Microsoft?

[mzhomie]

Ich habe mir letztens das Bun Alpine Dockerfile angeschaut und war traurig darüber, dass die Alpine eigenen Pakete nicht ausreichen um Bun zum laufen zu bringen, denn da werden aktuell noch Pakete von einem anderen Repo gezogen. Bei Deno brauch man das nicht und bei Node erst garnicht. Allein diese Frickelei ist wieder was mich nervt. Ich habe großen Respekt vor den Devs, die das alles bereitstellen und an dem Ökosystem arbeiten, aber es macht einen schon nachdenklich. Was ich auch nicht verstehe, warum die Dockerfiles alle so unterschiedlich aussehen.
Es ist doch genug Zeit ins Land gegangen, dass sich eine Best Practice mit genau den selben Schritten durchsetzen könnte. Beziehen, Benutzer erstellen, Rechte setzen und am Schluss einen Einstiegspunkt. Dass es dafür noch kein Blueprint gibt...

[helw]

Solange TypeScript nicht nativ ist, interessiert es mich gar nicht.

[tsukinoko_kun]

TS und JS ist doch dasselbe. Es hat dieselben Probleme. npm Pakete sind fast immer in JS geschrieben. Ich kann mich nicht auf die Typen verlassen. Es gibt immer noch keine int und float Typen, obwohl es diese intern gibt und nur hinter number versteckt sind. Ich denke, dass die Browser TS unterstützen und die dort stehenden Typen auch zur Laufzeit sicherstellen müssten. Viel lieber wären mir aber mehr Zugriffe von WASM auf die DOM APIs.