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

Рет қаралды 9,277

Күн бұрын

Пікірлер: 41

@thenativeweb 5 ай бұрын

Du möchtest das Video an jemanden weiterleiten, die oder der aber lieber liest? Dann findest Du den passenden Artikel zum Video bei Heise Developer: www.heise.de/blog/Node-js-TypeScript-Nie-wieder-JavaScript-9826686.html

@-Jakob- 5 ай бұрын

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.

@carstenholtkamp1444 5 ай бұрын

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.

@thenativeweb 5 ай бұрын

Danke für Deinen Kommentar 😊

@Sourcer3r 5 ай бұрын

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

@thenativeweb 5 ай бұрын

Ja, das hoffe ich auch … warten wir es ab 😊

@schnudderi 5 ай бұрын

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

@thenativeweb 5 ай бұрын

Das finde ich an TypeScript so gelungen: Das Typsystem ist optional. Man kann, man muss aber nicht.

@Hofer2304 5 ай бұрын

@@thenativewebLässt sich in TypeScript die Verwendung des Typsystems erzwingen?

@kernel0verflow919 5 ай бұрын

@@Hofer2304 Ja, in der tsconfig gibt es die Option 'strict' mode zu aktivieren.

@Hofer2304 5 ай бұрын

@@kernel0verflow919 Leider wird tsconfig.json ignoriert, wenn man die Eingabedateien auf der Kommadozeile angibt. Kann der Chef sichere Optionen erzwingen? Die Entwickler dürfen diese sicheren Optionen nicht ausschalten können, nur weil es bequemer ist.

@nonlinearsound-001 4 ай бұрын

Ich habe zu Anfang der HTML5 Ära mehrere Informations-Presentations-Systeme und Vertriebs-Unterstützungssysteme für das iPad im Browser unter Verwendung von knockout und halt JavaScript geschrieben, die alle im Kontext eines großen Industrieunternehmens liefen und aktiv verwendet wurden. Es gab nie Probleme. Wir verwendeten sogar WebGL, bauten die Szenen in der Unity Engine und steuerten die über eben den JS Code. Ich kann sagen, dass recht große und komplexe Frontend-Systeme durchaus mit JavaScript gebaut werden können. Es erfordert halt Disziplin und ein gutes Wissen der Sprache sowie eisenhartes Testing. Asynchrones handling der UI states wurde, wie gesagt per knockout und signals erledigt. Das Ganze hat immer gut funktioniert.

@deleonio 5 ай бұрын

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.

@mehmetcetinkaya7984 5 ай бұрын

🎉🎉🎉 wird langsam Zeit

@thenativeweb 5 ай бұрын

In der 22.6.0 ist es inzwischen auch außerhalb der Nightlies drin (aber immer noch experimentell) 😊

@raumkosmetiker 5 ай бұрын

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

@Leon-cm4uk 5 ай бұрын

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.

@marinaegner 5 ай бұрын

Endlich 😅 Wurde wirklich Mal langsam Zeit.

@thenativeweb 5 ай бұрын

In der 22.6.0 ist es inzwischen auch außerhalb der Nightlies drin (aber immer noch experimentell) 😊

@marinaegner 5 ай бұрын

@@thenativeweb gut zu wissen 😊

@mzhomie8880 5 ай бұрын

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 😂

@thenativeweb 5 ай бұрын

Ja, genau das … leider.

@qui-gonkenobi4574 5 ай бұрын

Oh ja die Erfahrung habe ich auch gemacht, dachte nur, ich hab es einfach nicht richtig verstanden. Wäre echt mal super, wenn es mal richtig aufgeräumt wird.

@jerrybodensky9679 5 ай бұрын

Déjà-vu !

@djchrisi 5 ай бұрын

Aber was ist die alternative? eine mega aufgeblähte package.json ist es meiner Meinung nach nicht.

@mzhomie8880 5 ай бұрын

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...

@rupertbogensperger2376 5 ай бұрын

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

@tsukinoko_kun 5 ай бұрын

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.

@emhome924 5 ай бұрын

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

@hermanheinz33 5 ай бұрын

Super Video!

@thenativeweb 5 ай бұрын

Danke schön 😊

@helw7 5 ай бұрын

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

@Leon-cm4uk 5 ай бұрын

Naja, wie er ab Minute 03:43 vorstellt, geht es schon in eben deine gewünschte Richtung. Außerdem, was hindert dich daran eine Sprache, wie typescript auszuprobieren? Ist es nicht besser anderen Sprachen gegenüber offen unterwegs zu sein, anstatt immer in seinem Ökosystem zu bleiben und die Welt an sich vorbei ziehen zu lassen? Das heißt ja nicht, dass man jede erdenkliche Sprache ausprobieren muss, aber offen ist sich anzugucken, was für die Use Cases in unterschiedlichen Projekten an Technologie sinnvoll einsetzbar ist und ältere Technologien ablösen kann.

@helw7 5 ай бұрын

@@Leon-cm4uk alles was nicht nativ ist, ist automatisch anfälliger für Fehler, Probleme und eventuell auch Einstellung der Entwicklung. Ich mag mich mit diesen Dingen einfach nicht rumschlagen. Ich verstehe natürlich, dass viele Leute gerne das Neueste ausprobieren wollen. Das ist auch völlig in Ordnung und muss ja auch irgendwer machen. Für mich persönlich brauch ich aber nicht immer das Allerneueste. Mir reicht es völlig aus, die Dinge erst dann zu nutzen, wenn sie native neu sind. Es gibt ja ohnehin auch nativ immer wieder Neues über das man sich freuen kann. Dazulernen muss man also sowieso immer. Wenn ich das aber auf die nativen Dinge beschränke, verschwende ich nicht meine Zeit mit Dingen die eventuell nur ein paar Jahre da sind und währenddessen auch noch meine Arbeitsumgebung komplizierter und damit Fehleranfälliger machen 😏 Ich will ja einfach vernünftig arbeiten können. Und mit JavaScript kann man ohnehin alles umsetzen was man mit TypeScript umsetzen kann. Und es ist übrigens nicht meine gewünschte Richtung, dass TypeScript nativ unterstützt wird. Mir ist es völlig egal ob es unterstützt wird oder nicht. Aber solange es nicht nativ ist, schaue ich es mir halt nicht an, weil ich keinen guten Grund habe, der diese Verkomplizierung der Arbeitsumgebung rechtfertigt. Ich bin komplett offen anderen Sprachen gegenüber, ich mag mich nur nicht mit Dingen beschäftigen, die eventuell nach ein paar Jahren schon wieder Schnee von gestern sind 😉

@derEULER 5 ай бұрын

Was meinst du mit nativ?

@helw7 5 ай бұрын

@@derEULER native Unterstützung in Node und/oder Browser

@DJTechnostyler 5 ай бұрын

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

@longingbydesign 5 ай бұрын

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?