4 ms·

I'm going to read that gist ( https://gist.github.com/joepie91/bca2fda868c1e8b2c2caf76af7dfcad3 https://gist.github.com/joepie91/bca2fda868c1e8b2c2caf76af7d...

by ble 3y ago

I'm going to read that gist ( https://gist.github.com/joepie91/bca2fda868c1e8b2c2caf76af7dfcad3 https://gist.github.com/joepie91/bca2fda868c1e8b2c2caf76af7d... ), but what do you dislike or hate about ES modules? From my own experience, they are extremely frustrating when tooling doesn't work well or at all with them. Given that I don't do JavaScript or front-end for work, I mostly run into these things in hobby programming. Given that this is programming for fun, I can voluntarily cut myself off from all the libraries that use other module systems. In this happy little bubble, over time, ES module support has gotten better and I've selected tools / found ways to use tools that work with modules and I rather like it. Perhaps because I'm less invested in the tools, I evaluate the situation of "tool X doesn't support ES modules" more like "tool X isn't great" and less like "ES modules are bad". Perhaps it all stems from being a person who genuinely likes JavaScript, has a high affinity for standards, and a relatively low opinion (yes, I'm a snob) of the Node ecosystem?

Py_ 3y ago
You can already do encapsulation without them by using TypeScript namespaces. It's sad that namespaces didn't become part of JavaScript. I really dislike having to include every last identifier that exists in other files. Yes I know that IDEs will sometimes do this for you I guess the main thing is that they result in your needing a bunch of additional infrastructure (webpack, rollup, bun.js, HMR solutions, etc) just to get your app to run, when TypeScript can already do all this.
- throwitaway1123 3y ago
  > I really dislike having to include every last identifier that exists in other files. How do you feel about esm's namespace import feature [1]? For example: import * as React from 'react' > I guess the main thing is that they result in your needing a bunch of additional infrastructure (webpack, rollup, bun.js, HMR solutions, etc) just to get your app to run, when TypeScript can already do all this. You can obviously use es modules directly in the browser without additional infrastructure. Bundlers simply combine (bundle) all your dependencies into a single file to prevent multiple http requests (although this is less relevant today with HTTP2). HMR solves a completely different problem — replacing individual modules in the browser during development when they change instead of reloading the entire page. HMR isn't something that es modules necessitate. You're free to reload your entire page every time you make a change in development. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#namespace_import https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
  - whstl 3y ago
    Off topic and unrelated to the discussion proper, but: I really wish React had gone with "component factories" instead of `import ... from 'react'`. This would not only allow for framework-agnostic components (so they could also work in Preact, Mithril, Inferno, etc, etc), it would also make the hooks implementation not dependent on global state. For example: export default const Component = ({ createElement, useState }) => () => { ... } Then you would only have to import from React from the entry point.
- whstl 3y ago
  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. I'm a big fan of "global" components in Vue.js, which are "dependency injected" into all your components but in a totally transparent way. You can "just use them" in templates, with zero boilerplate. You also don't have to mock imports in unit tests, you just inject them on an as-needed basis. To me this is 100x cleaner and simpler, there's no room for accidentally running a unit test that actually tests multiple components. The "irony" is that people avoid them because of the name, but the ones called "global" are actually definitely not global :/ React could also benefit from something like that. The `import { createComponent }` part (which is hidden but must be added by Babel plugins) is the worst part of the framework, and is an obstacle to having cross-framework components that work in React/Preact/Mithril/Inferno/etc.
  - throwitaway1123 3y ago
    > 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 3y ago
      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).

by ble 3y ago

Py_ 3y ago

You can already do encapsulation without them by using TypeScript namespaces. It's sad that namespaces didn't become part of JavaScript. I really dislike having to include every last identifier that exists in other files. Yes I know that IDEs will sometimes do this for you I guess the main thing is that they result in your needing a bunch of additional infrastructure (webpack, rollup, bun.js, HMR solutions, etc) just to get your app to run, when TypeScript can already do all this.

throwitaway1123 3y ago
> I really dislike having to include every last identifier that exists in other files. How do you feel about esm's namespace import feature [1]? For example: import * as React from 'react' > I guess the main thing is that they result in your needing a bunch of additional infrastructure (webpack, rollup, bun.js, HMR solutions, etc) just to get your app to run, when TypeScript can already do all this. You can obviously use es modules directly in the browser without additional infrastructure. Bundlers simply combine (bundle) all your dependencies into a single file to prevent multiple http requests (although this is less relevant today with HTTP2). HMR solves a completely different problem — replacing individual modules in the browser during development when they change instead of reloading the entire page. HMR isn't something that es modules necessitate. You're free to reload your entire page every time you make a change in development. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#namespace_import https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- whstl 3y ago
  Off topic and unrelated to the discussion proper, but: I really wish React had gone with "component factories" instead of `import ... from 'react'`. This would not only allow for framework-agnostic components (so they could also work in Preact, Mithril, Inferno, etc, etc), it would also make the hooks implementation not dependent on global state. For example: export default const Component = ({ createElement, useState }) => () => { ... } Then you would only have to import from React from the entry point.
whstl 3y ago
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. I'm a big fan of "global" components in Vue.js, which are "dependency injected" into all your components but in a totally transparent way. You can "just use them" in templates, with zero boilerplate. You also don't have to mock imports in unit tests, you just inject them on an as-needed basis. To me this is 100x cleaner and simpler, there's no room for accidentally running a unit test that actually tests multiple components. The "irony" is that people avoid them because of the name, but the ones called "global" are actually definitely not global :/ React could also benefit from something like that. The `import { createComponent }` part (which is hidden but must be added by Babel plugins) is the worst part of the framework, and is an obstacle to having cross-framework components that work in React/Preact/Mithril/Inferno/etc.
- throwitaway1123 3y ago
  > 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 3y ago
    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).