[throwitaway1123]

> I don't personally have a problem with ES Modules per se, but I do agree with the "I really dislike having to include every last identifier that exists in other files" part.

Isn't this exactly the problem that esm's namespace import feature solves?

[whstl]

Not really. I elaborated more in the rest of the message.

IMO the language is fine, and imports are fine too, but the way they're used in popular frameworks isn't good programming. Again, IMO.

My problem is with the excess of transitive dependencies in JS files as a programming style, even though the language supports other more modern idioms just fine. It's the classic Banana-gorilla-jungle problem, to quote Joe Armstrong. One component depends directly via imports on dozens of others, and it can't be separated. This specific style needs lots of compilation trickery to mocking imports in unit tests, for example. It's like Java or C++ in the 90s: zero independency and maximum coupling of everything, killing all portability and reusability.

Every React component directly depends on React, for example. This was a design decision, and is not strictly necessary, from first principles. This is IMO bit of a regression in terms of framework design. Like I said, with injection this would be unnecessary.

IMO one doesn't need "dependency injection everywhere" or "interfaces everywhere" (like 2010s Java, which is also not good), but when you have such a good and simple abstraction like "components" in React or Vue, it is a bit of a waste IMO to not use them and just use the imports-everywhere strategy.

Vue got it right, IMO, with "global" components for example. But this is also shunned by the community (even though it is used a lot by the authors of Vue and authors of libraries).

[throwitaway1123]

You're editing your comment very frequently, so I'll reply to it as it appears to me right now.

> IMO the language is fine, and imports are fine too, but the way they're used in frameworks isn't the best.

Ok so I think we're talking about two different things. The RawJS author was saying that he doesn't like es modules as a language feature because he has to separately import each identifier from a package. I was pointing out that you don't have to import each identifier separately, you can simply use the 'import * as identifier from "package"' syntax (es module namespace imports).

You seem to be talking about a separate issue (dependency injection).

[whstl]

Yes, I edited it as I went to make it more clear.

> The RawJS author was saying that he doesn't like es modules as a language feature [...] You seem to be talking about a separate issue (dependency injection).

Yes, that's why I said "I don't personally have a problem with ES Modules per se". Because I don't. But I dislike the abuse of the feature, and frameworks that force its use.

[throwitaway1123]

> Yes, that's why I said "I don't personally have a problem with ES Modules per se". Because I don't.

But you also quoted a criticism of ES Modules and explicitly said "I do agree". That's the part that threw me off. The commenter you were quoting (and agreeing with) wasn't talking about dependency injection. Earlier in the thread he said "I admittedly have a visceral hatred for ES modules", and this was him listing his grievances. Dependency injection and ES Modules are completely orthogonal.

I think your other comment where you admit that this is off topic was a more straightforward statement of your position, because you didn't quote (or purport to agree with) an unrelated argument [1].

[1] https://news.ycombinator.com/item?id=38865550

[whstl]

Well, sorry for throwing you off, then. That's why I was verbose with my edits: to ensure there was no misunderstanding. Hope all is clear now.