---
Node kept doing its thing when Bun, Deno, etc. was all the rage. And I do respect Node team for trying to improve little by little. It's not an ideal runtime but, it is _trying_... and that's a positive story.
> This restriction is philosophical rather than technical. I get it though. TypeScript is a Microsoft product. Opening that floodgate would pollute the entire ecosystem. Nobody wants more Microsoft.
I've done a small amount of work with Node (with JavaScript), and many libraries appear to have TypeScript bindings. It "felt" like there was pressure on me to move to TypeScript. (And, my conclusion at the end of my work with Node was that the next time I do anything significant with it, I would start with TypeScript first.)
That being said. I don't think anyone in my team considers us a "Bun" team in regards to Typescript, all our internal packages are Node packages as an example.
I don't personally have an opinion on it being owned by Anthropic. It was part of our risk assessment, but it obviously passed.
Bun has the same permissive trust model as Node
You'd think unit testing would be the most already-solved problem in the world: just copy what Jest, Mocha, Vitest, etc. do ... and you're done.
Instead they left out major features and implemented other features in really strange "why are you reinventing the wheel" ways :(
But one thing that stood out was .only(). In every major testing framework IT'S ASSUMED the dev is going to want to run one test at a time (sometimes). They make it super simple: you throw a ".only()" on the test, and the test runner only runs it.
In Node, you instead need to pass some special command line flag or add .only to every describe above the test ... which just makes a basic operation (run one test) much harder than it needs to be ... for zero benefit whatsoever (again, just do it the way every other test runner does it).
Not sure if the runtime should be responsible for linting of type checking.
Bad news (well not news, this happened a while ago): https://www.cnbc.com/amp/2020/03/16/microsoft-github-agrees-...
That is.....not the way anyone I know would describe Microsoft's history with the open source movement historically.....
Name one other company that would do that.
And your comment about LLMs is even sillier. Not only did they buy it 5 years before LLMs became relevant, but there's nothing stopping anyone other than Microsoft from downloading all of GitHub. Look at grep.app for example.
This only matters if you don't know what you are doing. LLMs can work with any tool. I'm working with a very unconventional stack and the LLM seems right at home.
That’s also probably why bun, supabase and netlify have been seeing so many new users, because (at least in my case and unless instructed otherwise), vibe coded projects had a tendency to push me in that direction.
The industry defaults are trash but it is what it is.
However, the truth is that writing isomorphic javascript programs in the age of agentic coding is much less important to me than it was a few years ago.
Please excuse my language, but that's only the case if you're a complete imbecile and can't write a for loop to save your life.
An LLM doesn't "reach" for anything, because you tell it what to do. You go "use this tool, to do that thing, in this way, here's a bunch of written guidance on how exactly to do that, and if you run into issues ask me". Any other use is glorified copy-paste slop code and will end up with a worse codebase than if you let an egomaniac run amok on a single codebase for 20 years.
If I say, "start a C++ package skeleton" I'm getting CMake, not waf, make, bjam, or whatever. If I state the build system, then I'm still getting some package layout drawn from the training distribution. If I specify that, I'm still getting snake_case or CamelCase or whatever naming convention, drawn from the training distribution. If I specify that, etc etc.
It is distribution sampling all the way down.
So, yes, literally LLMs ARE reaching for "it".
Well, in my case I suddenly had deno installed, while letting run fable in auto mode, even node was already there and I had to look up what deno was. "Ah, that node replacement."
There are valid reasons to choose both, valid reasons to be concerned about the direction of both, but most of the criticism here doesn't seem worthy of a blog post, let alone making it onto the front page of HN.
this is not fair. given the amount of work going into cell-d which will make an open source self host-able workers platform.
cz at the moment there's nothing comparable to Cloudflare workers.
> My interest in the Bun JavaScript runtime evaporated when I was informed of Jarred Sumner’s connection to Peter Thiel.
Ok, he doesn't really explain it in your link, but there's another link in that text ... surely that explains it:
>Anyway, I was recently made aware of Sumner’s connection to/fandom of Peter Thiel.
WHAT CONNECTION!?!?!? Did Peter Thiel help him murder someone? Invest $100k in his project? Is he friends with his uncle?
Look I think Thiel is a toxic human being too, but he's a major Siliocn Valley figure: you can't ostracize any project with any association with him, so if you're going to avoid using an entire technology, at least have the decency to say what this giant terrible connection is!
>In 2014, Peter Thiel's Thiel Foundation awarded a 19-year-old Jarred Sumner $100,000 along with mentorship.
So Thiel gave Summer, as a young starting entrepeneur, a $100k prize ... can you really fault him for liking Thiel a little after that? Apparently the OP does, and will refuse to use a technology Summer created simply because of it.
... but that doesn't justify boycotting the young dev and everything he ever makes in the future.
For example, Linux — how fascist, communist, or monarchist is it? I'd also be interested to know which NVIDIA drivers are more supportive of the LGBT community—the open-source ones or the proprietary ones?
I had never even thought about this until your comment.
i'm very interested in RISC-V and would love to read anything you can provide.
Thanks!
Ive just gone all in, no more mega bash scripts that constantly bug out on the silliest problems whenever you try to do anything complex involving a list data type.
It just feels like its something you can pretty much always bend towards what you need without needing to breakout into another language and I'm keen to see some of the new performance stuff their continuing to work on.
If you’re trashing Deno, it would be nice to give some examples of where node surpasses it and has not just caught up.
The Internet loves to adopt a new shiny thing, try to convince everybody else it's the right decision because it's the decision they made, and then get quiet about it. (i.e. they went back.)
All of the drama around Node was just that...drama. It works great, anecdotally keeps getting better, and while it definitely has shortcomings compared to Deno/Bun, I can at least trust that it isn't going away or mere months away from a pivot to curry favor.
I look at Deno/Bun as more supplemental, as-needed tools. I think the best Deno application I saw was on Bunny CDN's custom edge scripting. It was really nice to just hack together a script and know that it was going to pull and cache deps without me having to manage a dev environment. It also just worked out of the box.
Rambling, but I dunno. I kind of wish Ryan Dahl would move back to Node, bringing the wisdom and lessons from his Deno work.
WHAT ENGINEER WORTH THEIR SALT DOES NOT WANT TO COMMENT THE CENTRAL CONFIGURATION FILE OF THEIR ENTIRE PROJECT?
I'm not quite sure I've seen a runtime, JavaScript or otherwise, that has the same network-level gating that deno enforces. Making an allowlist of addresses the default seems like it needs to be table stakes in the agentic era.
The thing with being around for a while is the ability to seat on the porch, watching the adventurers' caravans pass by, once upon a traveller in one of those, now only the ones that actually make the way back into town matter to actually have a second look and talk to the strangers.
When comparing Bun and Node.js for my tasks, I keep finding more advantages in Bun’s optimizations. I'll handle GPU processes through BFFI. Node.js is also prone to unstable memory behavior with native processes, so it doesn’t make sense to use it as an extra layer.
For those looking for stability, Node.js is definitely the better choice.
Why would just switching the binary version in path be something deep enough to have a preference?
Honest question, I'm trying to think how can the experience be good or bad in a command that's just "use 3.2". Isn't the whole thing a switch, a state variable and maybe handling the download if there required version isn't available?
(That's one of the things I appreciate about Deno is the "let's just auto-install point upgrades" evergreen mentality and its suggestion that side-by-side versioning is maybe a mistake in the JS world.)
One thing I've learned about tech is that you can never assume something is too boring for opinions.
Bun seems popular too, what would be reasons to choose it?
I reported it, watched robobun write an unhinged +300 -0 patch which quickly got LGTM'd and merged.
I hope now that we've moved past AGI and into the ASI era things are better.
Ps to the original poster. I screw things like this up in my 2nd language all the time.
"more" and "-er" are sort of redundant. You could say
More light (but this is just awkward - you'd just say lighter).
Much lighter gives an extra degree of lightness than lighter.
Much much lighter even moreso. There's nothing wrong with saying it like this in an informal context like this, but it would generally be better to use words like significantly, vastly, enormously, slightly, a bit, considerably etc to modify the degree of "lighter"
Any LLM could explain the nuances of all of this in much much more detail (this actually makes sense, because detail is not -er).
English is difficult, but dont let that stop you - it is easy to communicate effectively with even a low degree of proficiency, when the other person is acting in good faith.
> This restriction is philosophical rather than technical. I get it though. TypeScript is a Microsoft product. Opening that floodgate would pollute the entire ecosystem. Nobody wants more Microsoft.
The reason Node disallows this has nothing to do with TypeScript being owned by Microsoft, it's because there's no guarantee the TSConfig settings used in the library you're pulling in match the ones in your project. A mismatch would mean you would get type errors inside the library code (assuming you're doing some form of type-checking in your application, otherwise what's the point of even using TypeScript).
> No TypeScript packages mean I need to find the latest churnware slop to bundle my stuff.
The TypeScript compiler itself comes with everything you need for this. See: https://www.typescriptlang.org/tsconfig/#declaration
There are other advantages to bundling, but it's not strictly necessary if all you care about is publishing TS on NPM. Declaration files solve the problem by supplying the resolved types of the publicly exposed identifiers. Also has the added advantage of not locking out plain JS consumers.
OP doesn't want the types to be checked, they want the types to be stripped. Type stripping ignores tsconfig.json files and any of its features, see: https://nodejs.org/api/typescript.html#type-stripping
TypeScript has different semantics depending on settings in tsconfig e.g. useDefineForClassFields
> Node.js ignores tsconfig.json files and therefore features that depend on settings within tsconfig.json, such as paths or converting newer JavaScript syntax to older standards, are intentionally unsupported.
Of course import aliases and such features would break.
OP is talking about type stripping nonetheless, and I'd put type stripping into the same ballpark as reading ambient declarations, performance wise.
... but then again, I haven't even really used the term "leet" much (let alone spelling it with numbers) since high school.
Alarms started ringing for me when they went for backwards support and focused heavily on that, when Bun was already on that route.
Sad but true.
That's what Deno does too, tho. Typescript is designed to work that way.
Now just deno install everything and even desktop works amazingly well.
Not needing to have opinions about the details has been one of the most freeing things when working on a project, even if it now means having a slight opinion about not wanting to use npm anywhere that I don't have to.
I realize at this point Bun offers a lot of overlapping "Node-like but with lots of extra niceties." But I happen to like that this one is actively trying to contribute stuff back to the core ecosystem -- the stdlib, initiatives like WinterCG, infrastructure like JSR (which is open source and at least a little bit more resistant to consolidation relative to npm)... Instead of just trying to extend it with a kitchen sink full of first-party features.
Like others here said, I don't think it's just one thing.
- Deno uses a system-wide module cache instead of endless nested node_modules folders. Especially on Windows where symlinks work but software, including npm, tends to avoid them by default, the space savings can be quite large.
- I kind of like Deno Deploy, even despite the messy transitions and generally "half-finished" feeling, but mostly because its free tier has been generous for the hobby projects I've been building on it.
- It's a strange sort of benefit but Dependabot doesn't police deno.lock files in the same way that npm package lock files get reported on, and even if it did it's a lot easier to keep development/scripting-only dependencies entirely out of the deno.lock file (by using http dependencies or full version qualified imports like "npm:package-name@v1.2.3" only for small scripts and dev time things). I've had some frustration lately with Dependabot pings on "completed" repos for dev dependencies that don't affect runtime. Especially in the deep dependency trees of eslint.
- packages in workspaces can be used as dependencies without compilation (node's type stripping doesn't support this)
- a good permissions model for limiting access to system fs, net, etc.
- native WebGPU support (including building a windowed app without a web view)
- desktop gui builds that allow using Chromium embedded or WebView
- built-in linter, benchmark, coverage, etc.
Node does support this! Although it may depend on exactly you link the packages within a workspace — I use `pnpm` and it Just Works™. Because NodeJS looks at the resolved symlink to decide whether a project is in `node_modules` or not, if the symlink resolves to a package in the workspace, then NodeJS will do type stripping as normal.
In fairness, the documentation is very unspecific about this, so I just had to try it out and see what happens, but it does work.
I think NodeJS also has coverage these days, although I could be wrong there.
Glad if it's working now regardless though, I also see some experimental support for coverage in the docs now.
... a way to document/comment the central project config file (ie. package.json).
Even if I pick modern tooling, say Biome for linting and formatting, Vite for bundling and handling the build, Vitest for unit testing, and finally TypeScript.
Once that's done, it's then remembering the right values needed in package.json and tsconfig.json to do the right thing and Just Work TM. It's 2026 and all this slop still assumes I don't want ES modules.
I could spend a whole morning on this bullshit. With Deno, I don't have to.
I always contrast that with my preferred languages, like C#/.NET. Project setup takes literally a few minutes. Deno and .NET have that in common, there is a single CLI for it.
The Deno JSR/STD thing also has a whole collection of libraries and data structures I'd otherwise need to get from NPM.
There are better, much better, choices.
A poster child for popularity!= quality
LMAO okay bro.
With Deno I get TypeScript by default, security, a package manager that isn't riddled with nonsense and a dated UI, and I can compile my APIs to a single executable. No way am I going back to Node but then again, this ain't my blog post.
But now that people seldom even look at the code, does it even matter? Our shared language now is English - across tests, frontend, backend, product briefs and design systems.
I have written a crap ton of node code before, because I liked it, but now I do everything in specialized stacks where each tech is chosen to best fit its environment. Backend - use Go, frontend - react/svelte/custom ,game simulation code - C#.
I just debate what would be best fit with an agent, do a few pilots to prove it and just go. Languages I’ve never coded in are super fast to execute - just insist on following best practice, modern conventions and do some spot checks against o(n) problems, architecture and parallelism - and it works, and vibe coded codebase with strict linting rules vastly outperforms fine tuned code in a shared language (node).
I honestly don’t see a bright future for them, and tbh I was surprised at Claude’s migration _to_ bun - why not just make the jump to something like ocamel that would let their agents have even more performance, context and linting tools, but I guess if they did it once the will do it again when they feel like it.
Although I was keen to get involved in Deno in the beginning and I'm a fan of Ryan Dahl, I just couldn't shake my preference for vanilla JavaScript; it was already the case before LLMs took over, but now even more so after LLMs. But I like that Deno is an option which users of my open source projects can use.
That said, Deno deserves the credit for making TypeScript as painless as possible. Juggling different Node.js and tsc versions and tsconfig versions was a major pain in the neck. I like how Deno forces a specific TypeScript version. None of that nonsense.
All the LLM issues I face are related to incorrect priorities, choosing the wrong tradeoffs, UX and UI flaws or incorrect assumption about requirements.
Why would I want to fill up my context window with useless type annotations and waste tokens generating them? Just like I don't want to be distracted thinking about types when I code, I don't want my LLM to be distracted by them either. Also, I don't want to waste time waiting for the transpiler to build. I don't use bundling nowadays - Not necessary if I use plain JS; instead I preload all my frontend libraries and distribute them individually; better for caching and they still download in parallel. I don't have to invalidate the entire bundle cache just because I updated one script.
Also, I don't want my LLM to generate over-engineered enterprise code. My priority is to get stuff done, not achieve job security.
I was under the impression that TypeScript is only statically typed, not strongly typed, too. Am I mistaken?
get with the program and be awesome with mise
Bun was promising, but as long as they don't fix their http GET implementation to accept the request body, its broken for me.
Note: Many real world tools like Elasticsearch's GET /_search with a JSON query DSL is one example. It breaks Axios. Many custom infrastructure tools expect it.
Advertising as node compatible and having this breaking change is undesirable. Hope it gets fixed soon.
Hint: Elasticsearch, GraphQL, Axios, etc..
And it was rather controversial that some listed a body as necessary for a GET request, and doing my research I came to find out that a "request body" was often quite undesirable and perhaps contrary to the RFC standards, and sending a "body" in a GET could result in undefined or unpredictable behavior. But it's all in good fun.
Perhaps the broken thing might be how you expect existing softwares to break so that your expectation can be satisfied. You should look at GET more closely.
There is a reason curl allows to send GET requests with a body. There is a reason node allows to receive GET requests with a body.
I understand why you'd want it, and that's why RFC10008 introduces QUERY as a GET-with-body alternative.
Sticking to RFC is one thing. Advertising as node compatible is completely different altogether. Many people cannot see the difference.
Atleast a flag would suffice as that would ensure existing infrastructure tooling doesn't break while keeping the RFC spec folks happy.
https://github.com/graphql/graphql-over-http/blob/main/spec/...
The QUERY method is a step in the right direction but it came too late.
> Why? Just strip the types bro, I know you can!
Since when is it acceptable to make everyone else un-pollute his code?
Had to run "dbus-launch" to send this comment.
In my opinion TypeScript is not a feature. Why? 90% of the benefit of TypeScript can be obtained by using `foo({duck, clock})` pattern. And at 90% of the cost and time. TypeScript, like Java, is beneficial in situations where an error is catastrophic. That is not my situation nor the situation of what 90% of programmers?
So to the bro who wrote the otherwise interesting article I say "Just strip the types bro". You can do it!! You like it? You do it!
[Rant of course, but if you had wasted as much of your life writing types in Java you would probably rant as well. Recipe thinking sigh.]
sick burn. can't say i disagree though.
https://x.com/rough__sea/status/2105853283617440032
https://youtu.be/G-v1hkQ8Sf8
https://github.com/stars/patcon/lists/awesome-celld
I get the sense that they'd just been brewing things around durable objects, and I'm excited for it coming to fruition
It is much more of a side-quest and it doesn't answer the question: where is deno going?
1. https://github.com/denoland/celld