Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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".



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.


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.


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.


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.


> code that runs before your actual code But this is not a build step. A build step would transform the code beforehand


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: