Hacker News Reader

Comment by lghh | Hacker News Reader

And now, he'll make a whole different set of good and bad choices to potentially regret later.

such is the curse of having the audacity to develop software :)

Not necessarily. I prefer trying to improve what we have verses making a new thing every time we have a relatively minor disagreement, even if that disagreement is with our past self.

EDIT: I'd like to add that clearly he is able to spend his time as he wishes.

I generally agree. Although, some of these are pretty "opinionated" breaking changes (promises all the way down, package manager changes). It would be hard to convince the whole node community that these upgrades are worth the risk forking in a python 2/3-esque way.

Forcing TS is a change node could adopt in the next major version if everybody agreed, but the node community might be too big and diverse at this point, to make such an opinionated switch.

afaik modifying node doesn't make sense here – it'd be so incompatible that it'd effectively be "a new thing" anyway

Sure, but there's a tendency to start over when the development gets hard to maintain or support instead of just fixing the mistakes.

This really feels like the fundamental response in the js world and why we see much churn.

But isn't this an inherent problem in software development that is really super hard to not do?

Let's say you are deciding how to make node when it was first conceived and how it would work. You've made decisions about how the thing fundamentally works. Then after using it and developing for it many years and after having millions of critical software projects dependant on it, you slowly start to see the shortcomings of the software that you could only see at this stage. The problem is that these shortcomings come from a false assumption or solution to the fundamental problems you had to solve when making node. Now, the only way to fix node is to change how it fundamentally works. But if you do that, millions of users' code will break. So, do you require everyone now to fix their broken code and potentially piss everyone off? Or do you give people a choice? Stick with node if you aren't noticing any of those fundamental problems you found, or switch to the new thing on your own time? It's a question of how to affect the least number of people in the least negative way.

I think the answer is a break in backwards compatibility on a major version release.

People in JS/frontend world are willing to drop the world for the latest new thing, I see this as less jarring than, say, Python 2 -> Python 3.

> People in JS/frontend world are willing to drop the world for the latest new thing

Except there aren't any breaking changes in JavaScript, are there? Even in Node if anything is deprecated that is done over time in many years.

I find it amusing that you use the example of Python 2 -> Python 3, a breaking change in a widely used language, that has famously been very difficult and long for organisations to deal with.

Compare that with javascript which has never had a breaking change. On top of that Typescript is a backwards compatible superset of javascript.

More to the point, Ryan has a humble explanation of what regrets he has about Node.js[1], why they exist and in some cases why there isn't an easy fix.

The point that I assume you're making, that sometimes it is better to spend significant energy to fix something, rather than throwing the baby out with the bath water, is a good one. However I'd suggest this is not one of those cases.

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

> I find it amusing that you use the example of Python 2 -> Python 3, a breaking change in a widely used language, that has famously been very difficult and long for organisations to deal with.

Why is that amusing? I specifically chose that example for that exact reason. I was highlighting the difference in the audience and use case.

> However I'd suggest this is not one of those cases.

I don't see the argument that supports that, either in the post or your reply.

The thing is, I can see Beepboo 1.0 being announced in 2025 to address the things that went wrong with deno. Because there will be design mistakes. And at what point do you say 'oh too many people rely on this software to fix this, I have to start over'?

Couple this with a very real trend-chasing and resume pushing in frontend dev and I'm starting to understand why people are so cynical about this stuff.

Typescript is something more palatable to me because it wasn't throwing the baby out with the bathwater.

> Why is that amusing? I specifically...

My apologies I misread.

> ... there's a tendency to start over when the development gets hard to maintain or support instead of just fixing the mistakes.

The thought that Node.js should have been 'fixed' instead of creating Deno is where I disagree. At a glance I can see a few reasons:

- Node.js maintainers + community may not even think there is something to be fixed (see various discussions in this thread about module resolutions)

- Politics, death by committee, inertia

- Effectively a dependency with npm registry (although not technically)

- Lack of backwards compatibility with changes (e.g. module resolution)

> The thing is, I can see Beepboo 1.0 being announced in 2025

Node.js was initially released in 2009 so it's probably fairer to suggest Beepboo 1.0 will be released in 2030. And yes, if it improved on Deno and solved inherent problems that couldn't be solved internally, I would wholeheartedly cheer it along.

I think it's also worth mentioning that Node.js is at a level of stability and maturity that people who plan to and have already built on it, aren't left abandoned.

When other people go ahead and build billion dollar companies on top of your development you can't "just fix the mistakes"

Why not? Billion dollar companies were built on flash, on asp, on Perl ...

Software changes, languages change. Billion dollar companies adapt or migrate.

Good that it’s called Deno, not Done!

Reply on news.ycombinator.com