Node FINALLY Supports TypeScript

73,050
0
Published 2024-07-28

All Comments (21)
  • @jacoL8
    Bun’s biggest achievement is getting all the other run times to actually comply and make things devs want
  • @rapzid3536
    I trust they gave that 617 line blob a good security review.
  • @samuelgunter
    i've been able to type "script" my entire life, why do I need this change?
  • @BobFrTube
    I much prefer the term "type annotation" rather than "strong types". Also "transpiler" rather than "compiler".
  • @n30v4
    1. NodeJS supports TypeScript 2. Browser supports TypeScript natively 3. Microsofts new Update TypeScript .NET 4. NodeJS Supports TypeScript .NET 5. TypeScript can be transpiled to C# 6. "Why you should write C# instead of TypeScript" blogs appears 7. Microsofts final plan to own the whole web ecosystem is finally archived
  • @SG_01
    Curiously, there is another ECMAScript language that supported type annotations way before TypeScript came along, and that is ActionScript, used by Adobe Flash. I wonder if you can now use some ActionScript as well.
  • @Mekelaina
    Im not a web dev, and ive not done much with web stuff. So take this for what it is. Why did JavaScript not have static types in the first place? It seems like every dynamic/flexible typed language reinvents static types eventually
  • @O._.O._.O
    The JavaScript ecosystem is aging into the very thing they despised: Java and PHP.
  • @corvoswag
    It works nicely imo in Python that use similar type annotation.
  • @ovflowd
    FYI, Theo, you can run the latest version of `master` of node with `npx node-nightly`
  • @re.liable
    Thoughts on the tsx package? Not the file type. It's like ts-node but better (in my limited experience) My Node flow currently consists of - tsx for running Typescript - tsconfig.json made from Matt Pocock's cheatsheet - `pnpm tsc` and `pnpm eslint src` for typechecking and linting
  • @gomesbruno201
    serious question here: are you guys using bun in production? I'm looking for some reason to not do it
  • @user-fed-yum
    $ node helloworld.ts Unintelligible error messages $ npx tsx helloworld.ts # problem solved
  • @keenoogodlike
    Browsers should support TypeScript for the sake of humanity.
  • @MobiusCoin
    Do the video on the .ts thing! I remember the Fireship video on it and I just did not understand it.
  • @akam9919
    My only concern is how this will affect typescript's development and ability to add new features and syntax. As far as I'm concerned, browser and node should be doing their own seperate things than defining where and how TS/flow/the-language-that-"one day"-replaces-TS describes its types and syntax. Of course, they could use their own build tools and such, but depending on how this spec is done, anyone with a new idea and syntax that doesn't play well with most transpilers will be effectively forced to create their own compiler which could slow adoption. Meaning the only way for their stuff to work would require typescript to add support and consequentially force venders to update their transpilation process...assuming they will even try.
  • I believe the reason for using WASM over native was actually due to tool chain complexity (I recall this was commented on the PR if anyone wants to fact check). Node already supports WASM, but they don’t support Rust in their toolchain. Therefore, it’s easier to ship WASM than Rust. I don’t think binary size reduction was cited or is the main reason. Yes SWC core platform binaries are bigger, but node only needs to ship one of them. Also, to my knowledge, there’s no native equivalent to SWC WASM typescript at present. However, comparing like for like, the full native and WASM versions are on the same order of magnitude, so I think it would be possible to ship an SWC native typescript binary which is similar in size to the WASM binary.