Agreed about the article tone. I'm a Deno lifer over here, and will definitely not try to cover up the mistakes they've made along the way or the trouble their deploy product has had over the past few months. Ryan Dahl is obviously polarizing as a personality for many people, always has been since he decided to "hate almost all software" or even before that when he created Node.js.

I don't use Fresh. Serverless is kind of a weird offering that forces developers to do a lot of work to adjust their programs to running all over the place. I even wish Deno had never supported NPM because that ruined their differentiator.

I'm going to keep using Deno and I hope they use this opportunity to refocus on their core product offering so that I can move back to using it from this VPS that is hosting all of my Deno servers right now.

▲

KyleJune 2 days ago | parent | next [-]

I'm planning on using Deno long term too and have also made some contributions to their standard library. But I completely disagree with you on NPM support. I think that gap early on contributed to bun's success. I almost quit using it because of how difficult it was to use react with Deno. Now it's pretty easy to use react and other npm packages with Deno. Before that, a lot of the most popular packages were just forks of npm packages adapted for Deno, but not as well maintained since less people were using them. Then deduping dependencies was just harder when they were all urls. If your package had a dependency using a different version url, you'd need an import map just to remap them all to using the same version. I'm pretty happy with the current deno.json with jsr and npm compatibility.

▲

afavour 2 days ago | parent | next [-]

As someone who has mostly just tinkered with this stuff (while using Node extensively at work) I see two truths:

- Deno initially seemed like something a number of us were clamouring for: a restart of the server JS ecosystem. ES modules from the start, more sensibly thought out and browser compatible APIs, etc etc

- that restart is incompatible with the business goals of a VC funded startup. They needed NPM compatibility but that destroyed the chances of a restart happening.

I’m just sticking with Node. I know Deno and Bun are faster and have a few good features (though Node has been cribbing from them extensively as time has gone on). I just don’t trust a VC backed runtime to keep velocity in the long term.

▲

josephg a day ago | parent | next [-]

Personally I've moved to bun. Its basically identical to node out of the box - almost all nodejs projects just work. But its usually faster. And it can run typescript files directly. And it has a JS bundler & minifier built in. And it can --watch for changes.

I hope nodejs copies these features. They're great.

	▲	pas 10 hours ago \| parent [-]
		node has watch now too bun is not bad, but for me consistently slower than pnpm for dependency management, and unfortunately I hit a very strange async runtime bug with it, so ended up just going with node

▲

ameliaquining 2 days ago | parent | prev [-]

Would something else that wasn't a VC-funded startup really work better? The technical problem seems fundamental.

▲

afavour 2 days ago | parent [-]

Yes, the technical problem is fundamental. But if Deno managed to be a truly great runtime that solved a lot of people’s gripes with Node and made ES modules etc the price of admission for using it there would have been momentum to create a new module ecosystem.

But once you add that NPM compatibility layer the incentives shift, it just isn’t worth anyone’s while to create new, modern modules when the old ones work well enough.

It all feels similar to the Python 2 vs 3 dilemma. They went the other way and hey, it was a years long quagmire. But the ecosystem came out of it in a much better place in the end.

	▲	KyleJune a day ago \| parent \| next [-]
		It wasn't worth recreating packages everytime you needed something that Deno had. If you ended up needing something and there was already something on npm for it, it was easier to just switch back to using node than to adapt/maintain a fork or alternative to an npm package. I think the lack of npm compatibility earlier on led to a lot of churn. Deno would probably be dead if they never improved the npm compatibility, especially considering the rise of bun promising performance improvements like Deno, but with better node compatibility at the time.
	▲	pjmlp a day ago \| parent \| prev [-]
		The big difference is that Python 3 was still CPython going forward, there was no one left to fork CPython 2 into an incompatible direction. Or like Wayland and X.Org Server. Quite different than an alternative that comes out of nowhere, expecting users to migrate.

▲

evbogue 2 days ago | parent | prev [-]

As an early Deno purist I must invoke the 10 Mistakes talk that Ryan gave when he launched Deno: https://m.youtube.com/watch?v=M3BM9TB-8yA&t=11s&pp=ygUScnlhb...

▲

rewgs a day ago | parent | prev [-]

Holy shit, a wild Everett Bogue sighting. I read your blog way back. Hope you’re doing well!

	▲	evbogue a day ago \| parent [-]
		lol, email me! I'm still an active user. ev@evbogue.com or 773-510-8601