-
This happens because you don't include the .js extension. I am 100% serious. TejasKumar_/1488527340279930885
-
…in reply to @rockerest
Let me explain. In '09, CommonJS proposed a standardized module format - now colloquially called uh... CommonJS - ALSO in '09 (FEBRUARY!), the TC39 Committee started conversations about including a Module system into ECMAScript. archives.ecma-international.org/2009/TC39/tc39-2009-011.pdf archives.ecma-international.org/2009/TC39/tc39-2009-012.pdf
-
…in reply to @rockerest
On page 23, you will see almost exactly what we have today as their "sugared" version. In this document they refer to the require/exports stuff as all we need, but the sugared stuff as how real developers want to use it. They say "this is not how most people program".
-
…in reply to @rockerest
Quick aside here: it is _incredible_ how like the original (?) proposal our current version is. These people are SMART.
-
…in reply to @rockerest
Responsible standards bodies would have seen what the TC39 committee was discussing, and shifted to target the same end goal. I'm not sure why they chose to use the unsugared version, but maybe they expected CommonJS to compete with ECMAScript? (credit: xkcd.com/927/)
-
…in reply to @rockerest
The strange part is that CommonJS was _aware_ of the TC39 proposals, but just chose to implement only the unsugared version and - more disastrously - not follow along as the proposal advanced to what we have today. wiki.commonjs.org/wiki/Modules/1.0
-
…in reply to @rockerest
Perhaps more importantly, CommonJS chose to ignore the part on Module Identifiers (page 8), which - if you ignore the Java-influenced (and what is that, Python?) options 🤮 - all declare a FULL path because we're dealing with a web language and ambiguity is antithetical.
-
…in reply to @rockerest
Anyway, CommonJS biffs it, Node adopts CommonJS, and then Node starts taking off. Let's stop here for a moment. CommonJS COULD HAVE seen what TC39 was talking about and stayed in sync. Node COULD HAVE seen what TC39 was doing and used polyfills to target the same result.
-
…in reply to @rockerest
Could have.
-
…in reply to @rockerest
They didn't, so a module format that didn't work anywhere except on your local computer took off. Right away, you can't ship any code with CommonJS to the web. Specifications for a historically web language that don't work on the web? Strange.
-
…in reply to @rockerest
So you need transpilation. You need some code that can read your code on storage somewhere, pull together all your ambiguity that you baked into the system for some reason, and spit out something it Frankensteined together that will run on the web.
-
…in reply to @rockerest
There's probably some pithy quote I could put here, but I can't find one, so here's mine: "The farther you abstract your processes from your audience, the more out of touch you will be." It seems obvious, but apparently it needs to be written down.
-
…in reply to @rockerest
Once you're transpiling, it's a short trip to including logic and constructs that can't run on the web either, if they can be down-compiled to an older version. You've created a system that cannot run on your target platform, and depends on bundling and transpiling.
-
…in reply to @rockerest
It outputs literally megabytes of code, most of it to fill in all the things that you're using that don't actually exist on your target platform. "The purpose of a system is what it does." - Stafford Beer
-
…in reply to @rockerest
If your system allows you to write unreadable code, that doesn't adhere to a specification and also doesn't run on the target platform, all while offloading any careful thought to your consumer to bear with network and CPU time, that IS its purpose.
-
…in reply to @rockerest
So anyway, while you're here transpiling and compiling and bundling, why not give yourself a hand? It's really confusing in this codebase! Instead of addressing why the codebase is confusing, why not build aliases into your bundler? webpack.js.org/configuration/resolve/#resolvealias
-
…in reply to @rockerest
Why type
../../../../../../otherDir/long/path/components/modulewhen you could just type~/module? Easy peasy. -
…in reply to @rockerest
Except now - only now, 13 years later - people are starting to realize that adhering to specifications is helpful actually? So let's get rid of all that non-standard stuff and use the platform in all of its bare-metal glory.
-
…in reply to @rockerest
We don't actually need all those esoteric whispered commands to make a bundle, and we don't need all those strange configuration options to make modules work. So let's get rid of all this entrenched cruft that never should have happened in the first place.
-
…in reply to @rockerest
A poorly advised module specification required abstraction from the target platform, which opened the door for "out-of-sight, out-of-mind" patches over ugly programming sins. When any part of that broken system begins to be removed, you have to deal with every one of the sins.
-
…in reply to @rockerest
And that's why not writing
.jsat the end of your imports led to mentally and physically exhausting relative import paths.
