Hacker News Reader

Comment by can3p | Hacker News Reader

Is it considered a stable version? The amount of unnecessary breaking changes is really frightening.

I mean, why would one ever need to change standard module names or demo.json structure?

Maybe it looks a bit better, but I’m sure it invokes a lot more pain for all developers, who need to watch out carefully with every release.

I consider this a JavaScript curse to be honest. Every webpack version breaks apis in random ways, react native is notoriously hard to upgrade because of this etc

Why isn’t it considered a problem in the community?

View on HN

I think Deno feels a fire under their ass. The JS ecosystem has not really embraced Deno in terms of tooling, libraries or frameworks and the serverless ecosystem has not embraced Deno as a runtime (aws/gcp/azure functions), so they're iterating rapidly to see if they can get something to really stick. And then there's Bun.

I love Deno for system scripting but the friction with the rest of the JS ecosystem has prevented me from adopting it further.

Their main issue IMO is that they are not really bringing anything major to the table in exchange for the very high cost of breaking compatibility with nodejs. If you are going to create a competing ecosystem it has to be somewhat revolutionary for the cost of investing/migrating to a whole new ecosystem to be worth it.

I like Typescript quite well, but if I'm told I'm going to throw away my nodejs/ts code base and start from scratch, then they are many alternative with better (for many definitions of "better") langages to consider, which at least will actually be different from what I have just thrown away.

> Their main issue IMO is that they are not really bringing anything major to the table in exchange for the very high cost of breaking compatibility with nodejs.

This is why my money is on Bun, just like a safe bet in Carbon. Both are designed to be drop-in-capable in large codebases where the bean counters aren't going to budget a total rewrite that redelivers the same functionality.

In regards to C++ evolution, Circle is a much better bet than something that is a basic AST interpreter.

Agreed. The way to fix that fire, however, is focusing on giving people the closest thing to a solution -- not the tools to build the closest thing to a solution.

For deno that would be fresh (the framework). And the speed of development is just not there, compared to the competitors (but everything has trouble keeping up with next right now)

Netlify edge workers use only Deno

The standard library is separate from the Deno runtime and is currently pre-1.0 (0.185.0).

As the blog post touches on, upgrading Deno itself does not force you onto the latest version of the stdlib. You will need to change the import URLs to get it.

Deno has a very cool architecture where almost all of the standard library is imported from outside of the runtime. Which means you can pin specific versions of unstable APIs, and never get caught by surprise even as they're being iterated on rapidly. They also say in the post that eg., the deno.json file changes are backward-compatible

As far as I know, Deno 1.x runtime upgrades are always backwards-compatible

The json structure is not a breaking change. You can use the old and the new structure

Why would you ever add the complexity of having to support two different formats then?

Old one will be deprecated in a major version change afaik.

The two formats aren't that different, and the old version is now deprecated. I doubt it adds that much complexity.

Because the new format is easier for their (new) users but removing the old one would be a pita for their (existing) users.

You can't get things 100% right all the times so you have to decide what to do when you realize there is a better way. You have a few choices:

a. You don't improve the interface and instead you offset the issue by adding more documentation, helper scripts, templates/examples etc.

b. You improve the interface, possibly in a backwards compatible way.

So, (b) presents some maintenance costs, but (a) too has some costs! Some organizations tend to prefer (a) because it's easier to just make it somebody else's problem (e.g. some other team will do documentation, some other team will do the developer advocacy).

So it's a locally optimal solution and hence it's often chosen despite (b) being a globally optimal solution, since the product will be easier to use.

Reply on news.ycombinator.com