Comment by lolinder | Hacker News Reader

Comment by lolinder | Hacker News Reader

Parent Full thread

Yep. Honestly, the pivot to Node/NPM compatibility was the moment I lost interest in Deno. I know why they did it, and as you say from a financial perspective it makes complete sense, but they had the chance to be a fresh start to the whole ecosystem and they gave that up.

I really like coding in TypeScript and think that most of people's irritation with JavaScript isn't actually related to the language so much as the ecosystem of NPM. The exponentially growing web of dependencies and the constant churn of deprecations are exhausting, detracting from a core language that is now pretty solid.

Deno set out to change that and be something new, but they squandered that chance because it was too risky for their investors. And again, that's totally fair—resetting an ecosystem is risky and probably wouldn't have yielded the return they needed! But giving up on that was giving up on what made Deno different and interesting. If I'm going to use NPM anyway why not stick with Node while I'm at it?

They basically said they were taking a risk (node/npm incompatible) for a big long-term benefit. They gave up on that forever, for some short-term growth. How many more times would they back-pedal on any risk they announced taking?

They did say something like that, but I don’t remember what the big long-term benefit was supposed to be. What specifically did they give up? Maybe it wasn’t that important after all.

Their original announcement post covers it pretty well:

https://deno.com/blog/v1

IMO their logic still holds up. Dahl had a whole talk about the mistakes made with Node:

https://www.youtube.com/watch?v=M3BM9TB-8yA

I haven’t done all that much network programming in Deno, but I think it’s still fairly easy to get “promises all the way down” by sticking with Deno API’s? What’s your experience with this?

My complaint is not with Deno APIs. From what I’ve seen they’re great. My problem arrives the moment you install a dependency, because it isn’t using Deno APIs. And digging into exactly what any dependency is doing is often an odyssey through transpiled-to-ES3 JavaScript, outdated APIs and so on.

The original promise of Deno was a consistent ecosystem. Absent that it doesn’t matter to me all that much how great Deno is within itself, the case for using it simply isn’t compelling enough. These days the newer, standards-compliant Node APIs are pretty good too!

Surely you can choose to only install "Deno native" dependencies?

It may sometimes be difficult to find such an option, but that was always going to be the case without Node compatibility.

Now, in theory at least, you have the option of sticking with Deno native dependencies, and an escape hatch when none are available.

That seems like the most pragmatic solution to the ideology vs adoption dilemma.

They gave up on a quality Deno ecosystem. And being relevant.

> Deno set out to change that and be something new, but they squandered that chance because it was too risky for their investors

Maybe it was too risky for users? The people with the most appetite for a new start and a new way of doing things are people who are suffering from their existing investment in Node. Making a halfway jump to a new platform with no path to completing the migration would leave their customers running on two platforms indefinitely. It's the worst-case outcome for a migration, going halfway and getting stuck with your feet in two canoes.

By supporting Node, Deno lets customers switch to something new and better and bring their legacy baggage along as well.

It was always going to be too risky for a subset of users, from the moment they announced it. That would not have stopped a project that was not VC funded—a smaller project with less at stake could easily have stuck to their guns and just appealed to the people who were actually interested in pioneering a new ecosystem.

Yeah. JavaScript is fine if you’re dealing with the DOM and vendor libraries, or if you’re using it in some scripting environment like GNOME. Node were ok too, but failed to develop a standard library like Go or Python. Addressing that failure would go a long way towards a better JS ecosystem.

Deno’s standard libraries [1] seem pretty nice, but to be honest I never used them much, because lots of stuff on MDN works fine in Deno.

[1] https://jsr.io/@std

I stumbled upon Deno when I needed to spin up a simple API to add to/update a CSV file, and really the only thing I found was deno-csv library, and it worked great. I was pleased with how easy it was with Deno, had it going in under an hour.

Reply on news.ycombinator.com