> Those speedbumps used to also not be there—they were put in recently

> having read through your comment

It doesn't sound like you've read my comment at all: 3 of the problems I listed are not new at all. The one that is - modules - is a result of two colliding independently standardised implementations from one language (commonjs vs ecma).

> The module fiasco is 100% a consequence of really, really bad decisions on the part of the NodeJS folks.

I'd genuinely like to hear an elaboration on this. You may be right but just stating doesn't make it so (your two referenced articles are just people who dislike JS railing against it for its own sake, nothing really constructive)

> It doesn't sound like you've read my comment at all

Well, I did.

> I'd genuinely like to hear an elaboration on this.

You already alluded to it. NodeJS's take on modules (which are not CommonJS[1]) were never a good idea, and they were never standard, least of all in any sense that matters.

Too many people treat the NodeJS project and its associated silliness like it's the be-all and end-all of "JS". It's not. It's a single, standards-incompatible runtime packed with proprietary features leading to obvious pain points (like the module fiasco) that are foreseeable from a mile away.

Previously: <https://news.ycombinator.com/item?id=31331358>

> your two referenced articles are just people who dislike JS railing against it for its own sake

Wrong. I happen to like JS. It's why a spent a huge chunk of my time (before NodeJS was even a thing) making sure that there were high quality JS docs available on developer.mozilla.org, and it's why I wrote that post diagnosing the problems with the NodeJS culture that can (and should) be fixed to repair the JS onramp to be friction-free the way that it was before (and repair JS's image from the damage done by the NodeJS project, cf OP).

But it doesn't sound like you've read them at all (nor does it sound like you're able to meaningfully separate JS from NodeJS yourself).

1. Isaac S: the best thing for me, and for node, and for npm, was just to go off the reservation and focus on the things that I knew mattered. Ryan basically always gave zero fucks about CommonJS anyway. One evening at Joyent, when I mentioned being a bit frustrated some ludicrous request for a feature that I knew to be a terrible idea, he said to me, "Forget CommonJS. It's dead. We are server side JavaScript."[...] we went pretty far off the reservation in v0.4, with the whole node_modules folder thing, and loading packages via their "main" field. Maybe we should remove those features, I'm sure that Node users would appreciate us being more spec-compliant!

In terms of early days serverside JS, I was mainly a Flusspferd user (outside of earlier Rhino & lots and lots of awkward XULRunnering), so I do get where you're coming from. Node was absolutely the mainstream enemy in the early days, and for me strongly represented the antithesis of what the ecosystem should become, including CommonJS.

But that battle was lost and at this stage Node realising late is so so much better than Node never realising at all.

It's also such a familiar story across ecosystems. Node gets all the flack because it's the browser-similar language platform and browsers have been where it's at for a long time (and will continue to be). That's neither a flaw nor an asset though - other ecosystems deal with very large (different) problems despite not having as many challenges to overcome as JS does.

> I do get where you're coming from

Given how little "getting" there's evidence for in your previous comments and how quickly you resorted to the most convenient strawman at the time (that I'm just some "people who dislike JS railing against it for its own sake"), this is doubtful.

I can't say I get where you're coming from—too difficult to locate the logical throughline in your comment and how it relates to (a) the specific issues raised in the original article, and (b) your original mischaracterization of it.