Re:The state of JavaScript modules
by hdhzy on Monday May 29, 2017 @07:05AM
(#14438510)
I meant higher level constructs. Classes are just an example. Even in Haskell you have typeclasses and modules. The point is that even though in JavaScript (and other Turing complete languages) you can emulate anything with what is available (for JS that is functions) you cannot easily build tooling around your ad hoc constructs.
[ Parent
| on HN ]
Again, maybe a concrete example would help?
Import/export statements vs require() calls?
const x = require;
const m = x('crypto');
Here I'm requiring a module but it's hard to follow for a tool that Crypto is being imported.The proliferation of class systems in JS before ES6 classes. Building a tool (IDE for example) to support all of them would be a complex problem.
See also interviews with Anders Hejlsberg (e.g. [0]) where he explicitly mentions that TypeScript type system's primary focus is allowing better tooling support for developers (like press dot and see what's there, safe refactorings).
[0]: https://devchat.tv/js-jabber/209-jsj-typescript-with-anders-...
Not sure I see what you're saying.
Requires are impossible to statically analyze in some pathological cases, which is why more rigidly defined imports made it into the ES2015 spec.
That's totally unrelated to classes vs. functions or any of the other things you've mentioned.