3 ms·

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 i

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.

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.