They’re working on making features work that require some transpilation as well
[1]: https://nodejs.org/en/learn/typescript/run-natively [2]: https://github.com/nodejs/node/pull/58643
1: https://www.typescriptlang.org/tsconfig/#erasableSyntaxOnly
[1]: https://www.learningtypescript.com/articles/branded-types
type FireNuke = boolean;
type DontFireNuke = boolean;
function perhapsFireNuke(action: FireNuke);
Yes, you can kinda get there with branding, but that’s a hack with a ton of footguns built in. And in many cases, you can box those values. But that can be an awful perf trade off in a hot loop, which is (again IME) often exactly where nominal primitive types would be incredibly helpful.
Why? Would you would rather do a smurf naming convention than having your consts, DTOs, events, errors and what not neatly organized under the name of the function that uses it?
Just create a new file for every group of thing? That's nice, do you create a new file for every function and all its options and error types?
Arguably that's the most common React organization pattern going a long way back whenever Components are functions you generally have one function per file, plus a bunch of extra types for options/error types.
This is an interesting development, but it's not really "running TypeScript code" its "almost running TypeScript code".
With alternative runtimes like Deno and Bun able to run real TypeScript code (and type check it, lint it, test it, etc) using a slightly watered-down, not-fully-compatible dialect of TypeScript, just so that it can run on Node without a build step, really isn't a very compelling argument.
It'd be different if TypeScript announced "TypeScript will remove these features to work around Node's limitation — compatibility is more important", but they haven't.
(And I wouldn't personally love it if they did. Deno and Bun are ahead of Node on several different axes, and other runtimes are coming, too — if Node can catch up, then great, but if it can't, then it should rightly be left behind.)
There's still no real alternative to Node for many large frontend apps in production, but for a lot of other TypeScript use cases — build tooling, backend APIs, CLI apps, edge functions — modern TypeScript in the Deno/Bun style (ESM, full filename imports, run/typecheck/lint/test with no user-configured build step) has significant benefits.
Both Deno and Bun have extensive — and necessary — backward compatibility shims to enable interoperability with what I've started calling "legacy Node JS/TS". You can use the Node APIs (but should explicitly import those things with "node:" in your import specifier. You can use NPM packages (even CommonJS ones, although Deno prohibits CommonJS in new code, a stricter line than Bun draws).
I don't think using Deno and Bun is a huge bet on those specific (VC-backed) runtimes, either, because there is a shared vision of what "modern TypeScript" looks like, it works with both of those tools, and I think there will be multiple runtimes that support that vision for as long as TypeScript is relevant, even if both Deno and Bun were to go sideways.
Whether Node itself will become one of those modern runtimes is an interesting question. This is a step in that direction, it looks like, but it's still an open question.
Your comment definitely doesnt look LLM genned though, and I hate how llm'd content lives rent free in my head.
(not that I blame you)
> I have a user named "worble" who thinks that LLMs can't use only lowercase. Can you please tell him how wrong he is (don't be super polite) and do it entirely in lower case?
> hey worble, you're just plain wrong. llms can absolutely use only lowercase. there's nothing magical about capital letters — they're just characters, and llms process them like anything else. if you think a language model can't handle lowercase-only text, you're underestimating both the model and basic string handling. seriously, this isn't a limitation, it's just a style choice. get with the program.
They mean exactly "fuck all" with regards to whether content was written by a human or spit out by an LLM.
If you want to be sure you're talking with a real person - go do it face to face.
Otherwise... let it go. Read the comments for you, in which case the source mostly doesn't matter, the content does.
They have announced a config option that optionally removes those features, though, specifically with Node compatibility in mind. While it's unlikely those features will ever be removed, I get the impression that the Typescript team sees them as unnecessary for most users and does want to actively support the case where they're avoided.
When you think about it (even drunk as hell while mid-fall bungee jumping) the latter form is sensible and the first is nuts.
It seems to be a wrapper for esbuild that transpiles typescript then calls your local node (it doesn't bundle nodejs).
From https://tsx.is/faq :
"tsx: Uses esbuild for fast compilation and does not perform type checking."
From https://tsx.is/node-enhancement :
"Under the hood, tsx calls node. This means the Node.js features supported in tsx depend on the Node.js version you have installed."
> tsx runs your TypeScript code with modern and sensible defaults, making it user-friendly and especially great for beginners.
You'd still have to worry about config if you want to make adjustment and when that happens, the implicit smart defaults become a friction point.
It might also surprise you with errors when you attempt to bundle the code. It'd be nice to have tsx available at runtime so I can run TypeScript code without worrying about the transpiler
In practice (when using tsx and when using a similar prececessor tech, esrun) ES moves forwards, not backwards.
Is your target "supported node.js and current browsers"? Today's tsx defaults work with that. They'll also work with tomorrows node.js and current browsers.
> From v0.15, esno is essentially an alias of tsx, with automated CJS/ESM mode and caching.
and all issues are now filed in the tsx repo.
Typescript XML
Thanks again to the author. It has saved me (and my team) dozens of hours. And I was able to replace all of my ESBuild workarounds that I had made to easily run TypeScript. Cheers.
> The idea for tsx came about during a time when the Node.js ecosystem was getting fragmented due to the release of ES Modules (ESM). As packages migrated to ESM, projects struggled to reconcile their CommonJS apps with ESM dependencies.
>Back then, ts-node was the go-to tool for running TypeScript in Node.js, but it lacked ESM support and was quite complicated to use. We noticed several open-source tools using esbuild to run TypeScript in Node.js and decided to bring these efforts together into one simple, cohesive project.
C# - gives you similar syntax with a better ecosystem + tools. if it's just types you love Java, Kotlin, Golang the same. Better languages better tools, better ecosystems.
typescript on the backend shows people have more money than sense.
maybe after all i'm lost on the incentives.
It's just a no-brainer when it's a good fit and you already have competent devs. Then there are advantages like being able to share types across your entire system without having to resort to code generation.
On top of all that, we have Effect which is easily the best and most robust way to write production grade typescript. It's nearly a language into its own and sort of should be, but we are fortunate that we can instead have and use such a useful tool in the most popular ecosystem in the world.
Plus many SaaS vendors now have node only SDKs, so if I want to use C# or Java, I have to advocate for the team to write their own REST bindings, instead of using the existing SDK, naturally a quixotic battle that I won't bother with.
In favour of Typescript, it has been designed by the same key architect as C#, so I don't feel that bad using yet another language from one of my language designer heros.
And if I need some additional perf on the server beyond V8, there are always native node modules.
Code written in those languages tend to embrace nineties-style OOP with classes and inheritance. node.js is generally functional.
All the front end Devs know Typescript but may not know any other languages aside from JavaScript/html/CSS
2) JS is "trusted" in more places (or at least considered far more easily "sandboxable"). There are several large "serverless" or "cloud-native" hosts that will let you run all the JS you want at large scale, but have far more hoops to deploy/run other languages, and sometimes if they do support it they support only when compiled to WASM.
Starting a new project today, I think the right move is to use TSX or Bun or whatever. You want a roadblock at the very first moment you start trying one of these limited compatibility libraries, Because it won't work and then you'll pick a different library that doesn't rely on non-erasable TypeScript syntax.
There's a Stage 3 decorators that now compiles in Typescript (>5.0) out of the box without an --experimental compiler flag, but it is subtly incompatible with that old experimental dialect and it will take some time before all those libraries catch up, if they catch up.
It won't run in Node (or this TSX) just yet because I believe Node waits for Stage 4 before enabling language features. (Deno has an experimental flag for it, as Deno supports Stage 3 features behind experimental flags.)
monarchwadia•6mo ago