haack

I'm not at all surprised about the response here. We are a community of people who love function over form (the perfect emblem being the purely functional design of our beloved HN). And in all honesty, my initial reaction was the same.

But we'd do well to bear in mind that:

- Most of us are not the intended audience.

- The purpose of the site is not what most of us expect. They are not trying to create leads from this page (hence the lack of useful information and call to action).

- And tangentially, the internet isn't only about function or utility.

I sympathise with the compulsive need to pull-apart a website with >300kb javascript, scrolling to get more information and unnecessary animation when it gets in the way of you using a site that you need. But surely this is not one of those times. Instead why not treat it like you are looking at an abstract piece of art. Sure a 3 year old could have made it but that's not really the point, is it?

I already found it frustratingly ambiguous that there could be more than one Manchester in the US, then I checked and it turns out there are more than 30

It seems like this is not simply about the decision of whether to allow http by default and security of dependencies.

I'm not familiar with the surrounding politics and don't particularly want to be involved, but I appreciate the explanation.

> Should you review the code of all imported modules? This is virtually impossible.

I wouldn't be surprised if this was exactly the direction that Deno was trying to move towards. Fewer direct dependencies with some amount of transitive trust.

I.e. "[Deno] has a set of reviewed (audited) standard modules"

> Windows CP without SP 2 and Internet explorer bellow 6

I get the point you're trying to make with this hyperbole but browsers still let you view http pages (by default).

> Deno must disable http by defaulkt and provide a flag to re-enable it. This is factually a security issue in Deno.

Again I agree with your idea about disabling by default but there is another perspective (and I think Ryan deserves some empathy).

> 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.

Would you say linux is insecure because a user can download an arbitrary shell script and run it?

I know it's not an identical problem, but it does demonstrate that we probably agree that the onus is on the user to assess the risk of any arbitrary code they run on their machine, including the risk associated with the transport they use to obtain that code.

Funnily enough I actually agree with you that I would prefer to prevent http imports by default. However doing so won't make importing a library secure, and conversely allowing it doesn't mean it is insecure.

As an aside, I noticed you have posted the same one line message about the risk of a MITM attack with http imports 4 times in this thread. You might find it more helpful to contribute to the discussion by explaining why you think that.