3 ms·

You are simply wrong. I've been a full time NodeJS programmer for fourteen years. Module isn't some pure theoretical concept. It is a file that exports somethi

You are simply wrong. I've been a full time NodeJS programmer for fourteen years. Module isn't some pure theoretical concept. It is a file that exports something in Node. There's a ton of 'maybe I need this file' in the world. For example, I have things that are polymorphic by instance. I grab a config entry to decide which of several modules are going to be used. The others are completely unnecessary. You might say, just add a build step that chooses the right ones. To which I would say, Are you nuts? Why would I screw up a perfectly working paradigm? To get "an approximation of conditionally loading".

zarathustreal 2y ago
As a matter of fact _module_ is a pure theoretical concept. The fact that we’re discussing at least two different implementations of modules alone proves that it’s at least more abstract than _file_. It’s certainly not strictly related to Node, plenty of languages (and their associated runtimes, if applicable) have modules. Further, it wouldn’t matter what a specific implementation of modules within Node is, nor would 14 years of experience with Node. You’re missing the point entirely, perhaps intentionally? If you’re using modules you’re already using a “build step” - code that runs before your actual code. Your “perfectly working paradigm” is only such if you intentionally disregard the core reason for modules: modularity.
- efilife 2y ago
  > code that runs before your actual code But this is not a build step. A build step would transform the code beforehand
  - tqwhite 2y ago
    For good measure, it is an operation that executes by the runtime for every execution, not as a redeployment. Turns out that the ESM purists struggle to find reasons to condemn those of us who don’t have the need or resources to the chase bleeding edge of purity.
- tqwhite 2y ago
  Your point is that modules has a conceptual underpinning. My point is that the actual world in not the same as that concept. I use modules for all the reasons. Your assertion that require() or importSync() represents a willful misunderstanding is silly and arrogant.
  - zarathustreal 2y ago
    My assertion is that, having been made aware of the pitfalls of effectful imports, continuing to argue for using them requires a willful misunderstanding. People outside the context of this discussion could simply be uninformed, they don’t need to be willfully misunderstanding.
    - tqwhite 2y ago
      No. It is a result of a practical, engineering perspective. I love theory. It's necessary for moving the world forward. I also love getting things to work. Three quarters of NPM packages are CJS. Several of them are ones I wrote. The reason they are not ESM is that the theoretically pure folks had control and I voted with my fingers because everything I do has to fit in my a substantial amount of existing CJS code. Arguing for practical solutions that accommodate an imperfect world is absolutely correct.

zarathustreal 2y ago

As a matter of fact _module_ is a pure theoretical concept. The fact that we’re discussing at least two different implementations of modules alone proves that it’s at least more abstract than _file_. It’s certainly not strictly related to Node, plenty of languages (and their associated runtimes, if applicable) have modules. Further, it wouldn’t matter what a specific implementation of modules within Node is, nor would 14 years of experience with Node. You’re missing the point entirely, perhaps intentionally? If you’re using modules you’re already using a “build step” - code that runs before your actual code. Your “perfectly working paradigm” is only such if you intentionally disregard the core reason for modules: modularity.

efilife 2y ago
> code that runs before your actual code But this is not a build step. A build step would transform the code beforehand
- tqwhite 2y ago
  For good measure, it is an operation that executes by the runtime for every execution, not as a redeployment. Turns out that the ESM purists struggle to find reasons to condemn those of us who don’t have the need or resources to the chase bleeding edge of purity.
tqwhite 2y ago
Your point is that modules has a conceptual underpinning. My point is that the actual world in not the same as that concept. I use modules for all the reasons. Your assertion that require() or importSync() represents a willful misunderstanding is silly and arrogant.
- zarathustreal 2y ago
  My assertion is that, having been made aware of the pitfalls of effectful imports, continuing to argue for using them requires a willful misunderstanding. People outside the context of this discussion could simply be uninformed, they don’t need to be willfully misunderstanding.
  - tqwhite 2y ago
    No. It is a result of a practical, engineering perspective. I love theory. It's necessary for moving the world forward. I also love getting things to work. Three quarters of NPM packages are CJS. Several of them are ones I wrote. The reason they are not ESM is that the theoretically pure folks had control and I voted with my fingers because everything I do has to fit in my a substantial amount of existing CJS code. Arguing for practical solutions that accommodate an imperfect world is absolutely correct.