Comment by gen2brain
10 hours ago
I have no idea anymore what is happening, and none of the blogposts seem to explain that either. So, if I am to start a new JS or TypeScript project or whatever, what should I choose and why? One runtime used a lot of tokens to rewrite Zig project, one was already Rust, one bought, one rewritten in Go, what is going on?
> what should I choose and why?
You should choose Node.js unless you have a good reason to use something else. This is what everyone uses, and it is used widely enough that it's in the same position as Java, i.e. it will be supported forever.
Also the other runtimes only offer incremental improvements.
Regarding the blogposts, you don't read a lot about Node.js because it is mature software and there isn't a lot of drama or new things to talk about.
One was not rewritten in Go. Typescript rewrote its compiler in Go, but that doesn't affect which runtime you use for the resulting Javascript code. Moreover this isn't producing a fork in Typescript as it is a replacement for the previous compiler, at least once they're done with it. The JS runtime forks and churn are not related to Typescript per se.
Yeah, after I posted I realized that Go remark was not correct, but again, I am confused how do you combine all that. JS I can read and understand (well, understand), I have seen it already, TS, I compile TS to JS right, and then I can choose any of the current available runtimes to run that code, correct? And final fat binary that is deployed has what, whatever runtime I choose to be? Huh, I think I guessed that right, I do use such apps, but never bothered to understand how they are actually packed.
> Typescript rewrote its compiler in Go, but that doesn't affect which runtime you use for the resulting Javascript code.
It unfortunately has other implications, ts-loader (used by webpack) for example is not compatible with the new Go crap so you need to do weird pinning down to v6 to get your builds working again [1].
[1] https://github.com/TypeStrong/ts-loader/issues/1671
Yes, everything I have is pinned that way too. That's why I said "when it is done", even in my limited experience and contact with TS it is not currently a suitable replacement, and I'm not a particularly hard user of the tool chain. (I am having a hard time phrasing this in a way that I'm completely sure can't be potentially read as snarky or short-tempered, so I guess I'll just go with the clumsy direct statement that I'm agreeing with you and continuing the thought from my own experience, not trying to disagree.)
As near as I can see, it isn't anything fundamental to the rewrite, it's just a transitional phase, though.
Well, that "Go crap" needs some explanation. The reason I am not involved in JS is because I mostly use Go for backend, and I am happy I have no relation with frontend at all. And even that is just small part of my job and what I do daily (Radius, Diameter, etc.). But, I never heard about Go crap (in that context maybe), or experienced any crap there, it is just nice and simple. What are the issues?
1 reply →
There's basically no reason not to just go with Node as 99% of projects out there do
Isn’t the whole node npm ecosystem now with AI a greater risk as before?
"which runtime" is a separate discussion from "which package manager"; there's nothing in Node requiring you to use npm (or to rely on external dependencies at all)
I don't choose TS/JS for new projects anymore unless they're browser based. If you need to be in JS land for whatever reason, deploy with Node but do local package management/testing with Bun, because it's way faster for those and you can migrate off without too much pain if it ever becomes problematic.
More or less the same but I dropped Bun after Anthropic acquisition so I now default to PNPM and Vitest, which is ok.
While it may as well be the same thing, the Anthropic acquisition isn't what turned me off of Bun, it was the vibe-coded Rust refactor. As soon as that happened I dropped Bun. Deno was what I ended up more interested in (Deno Fresh seemed really cool too), but I guess it's just back to Node/PNPM for me now as well. What is going on anymore...
There's just one worthy of using for fresh project: Bun.
Deno was never going to be a thing anyways.
Bun's being a part of Anthropic is just as concerning, if not more so. At least Cloudflare is being honest here that they have no idea continuing Deno support long term. Anthropic's first role in Bun was treating it as a playground to migrate from Zig to Rust using as many LLM tokens as they wished in the process. That's not exactly the sign of a steward with long term maintenance in mind.
Bun's rewrite has been a massive success, unprecedented even.
The amount of new features they are coming up with, the speed of development has been even faster than before.
We have not seen any indications so far Anthropic messing with Bun's direction. It was always Jarred deciding what to do and it is still the same. So far Anthropic has left Bun alone and they are just reaping benefits of bun getting faster and faster.
I see that as a long term benefit. Not a negative.
Bun is dead. It's a skin-walker wearing the appearance of its former self. They screwed the community when they got acquired.
Deno has been successful, technically better and a respectably run project. I expect it may survive in the form of modular runtime and associated features.
Screwed who actually? How? Dead? lol.
Every company that is using Bun is getting so much more perf benefits — faster and less memory used; also less crashes/bugs. New features are dropping rapidly. All those naysayers about rust port will be littered with bugs and unmaintainable crap are already proven wrong. So now you just call it dead. nice.
Just use Node. Community led and supported by the Linux Foundation.
Why not the standard NodeJS? Well supported and not heavily influenced by acquisition or trends like bun is?
If Deno and Bun were not kicking NodeJS's behind, we'd not see any of the improvements in the ecosystem in last few years. Node has been stagnant for a long time.
> So, if I am to start a new JS or TypeScript project or whatever, what should I choose and why?
NodeJS for the runtime if it's not in a browser, webpack for bundling. For the frontend stack, either React if you're in for a full application or, fuck it, good old jQuery if you don't want to do type document.queryXXX all the time. You'll find a ton of developers and coding bootcamp graduates to deal with all of that, and the AI agents should all be trained well enough on them.
Everything else is just a recipe for getting rug-pulled or being the bananaware customer responsible for the ripening.
I'd throw out webpack and start with unbundled ESM today. Vendor bundle and spot bundle with esbuild or rollup or something else designed for native ESM bundling and just ESM bundling, and only where you see actual performance bottlenecks (visible request waterfalls). Use any friction you see as an excuse to replace/drop old CommonJS dependencies entirely.
Webpack had its day, but today its kitchen sink and incredibly baroque configurations are as much a liability as a helpful place to start on a project. Start fresh with ESM and without a bundler and things are surprisingly nice in development experience.
I'd just go with Node, it supports TS natively now.
NodeJS just strips TS types and prays that it runs as JS. It's not a native support by any means.
For example it doesn't support enums.
Bun and Deno do the real thing.
"deno run" also just strips the types. The type checker is 'opt-in' now.
Don't know what Bun does though.
> prays that it runs
If you want to use TS stripping for your own project the typescript ecosystem makes it very easy to avoid using the wrong features. Just set erasableSyntaxOnly and verbatimModuleSyntax to true in your tsconfig.json and you will be warned when you're doing something node would not be able to handle. These days I find more code is being written to be stripping friendly than not, the incompatible stuff is of little importance besides enum for which you could resort to an as const object or a string union. I consider the presence of such things a smell, the TS dev team considers things like enums to have been a mistake, the goal of TS is to remain minimally divergent with JS outside of the type annotations.
Oh for real? I thought the latest versions ran actual typescript.
1 reply →