Yes, it comes with batteries included, but a big node project already has setups handling things like testing, linting, formatting, and dependencies. Moving to Deno for any of those might actually be easy, but migrations in the JS ecosystem never end up being easy, so people who could sway the company to change tools don’t have the appetite to tell leadership about migration projects with minimal upside and unknown duration. And under a startup with an unknown future.
NodeJS succeeded at undermining existing server toolchains, because web devs were easily sold on writing JS for their servers, so tons of successful startups built with Node, and when Node got pretty well established, it was easier to adopt for greenfield projects in the enterprise.
Deno is Node, but better. So it’s not giving a whole market of devs access to a tool that is way easier to write for. It’s marginally easier to manage and you could maybe drop some other toolchain dependencies. But again, those toolchain things are automated/hidden away from developers directly… like they don’t care we use eslint, they just care CI catches problems before they hit prod and that the linter throws an error early in the process. It’s already easy for them to run locally. So it’s not like Deno lint changes anything about the dev user experience, it just changes what DevOps/platform teams have to manage.
We inherited a 10+ year old production system with node and react; it made by a succesful company that made it with vc money in a short time and then got acquired; the system has grown to 100s of 1000s of lines of js (no ts). It runs on a cluster of VPSs on ancient versions of everything.
It took me 3 days to rewrite it to typescript and deno with zero vulns by prompting cerebras glm 4.7 with basically 'port this to modern ts, drizzle and deno' and then opus in claude code to make it work and fix it. It uses playwright mcp to test all flows; it runs production now instead of the old version; no issues so far.
Also, the 3rd day was only on writing REST and Playwright tests on both versions so we could compare if everything works the same.
LLMs seem likely to kill or at least vastly weaken the support model.
And essentially one of the reasonings behind it was that people weren't taking support or buying templates etc. from tailwind because they were getting essentially both of these from LLM's.
And you really have to believe in open source and have the discipline to keep investing in it, otherwise the temptation is ever present to throw more and more effort and resources into the proprietary parts.
> I'm pretty confident that neither bun nor uv will stop existing anytime soon, and the makers got paydays out of it.
If OpenAI stocks let's say IPO and then fall 70% (because hey a business is well, a business at the end of the day), do you suppose they will still keep the folks at uv?
Sure, its good for the makers who get paydays but they are quite far and few and this doesn't feel like a strategy much to me to rely on.
If Open source needs to thrive, we might need a better strategy long term perhaps.