4 ms·
Well, in ancient ES3 times all we had was functions and so we used functions for everything and that was good as they are extremely versatile. But now a differe
by hdhzy 9y ago
Well, in ancient ES3 times all we had was functions and so we used functions for everything and that was good as they are extremely versatile. But now a different problem appeared: it's hard to statically analyze function-based constructs for various purposes (tree shaking, refactoring, etc.) so new syntax was invented to capture what was convention inside the language itself. If you look at classes they are "just" syntactic sugar that works just like good ol' prototype system. But the one key difference is that this is now easier to statically analyze.
The same happens with modules although having written several require.js like loaders I find the ES system a little bit lacking.
> I swear, it's like the language reinvents itself every year. Give me some sort of promise when you'll leave the standard alone, then I'll wait for the community to form best practices / libraries to catch up. After the dust settles, I'll invest time reading up on the standard.
Sorry to disappoint you but this will never happen, especially not in JavaScript. Actually the standard is released every year that's why we have ES2015, ES2016... But that's just the way things work in IT: people keep changing things and we are supposed to follow.
> ... seems like a moving target.
Yes, exactly. But that seems to be "by design" rather than "by accident", see Fire and Motion [0].
[0]: https://www.joelonsoftware.com/2002/01/06/fire-and-motion/ https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
- bcherny 9y agoCan you give some examples (or better, a writeup) about how static analysis is hard without classes? It seems like Haskell gets along fine without it.
- hdhzy 9y agoI 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.
- bcherny 9y agoAgain, maybe a concrete example would help?
- hdhzy 9y agoImport/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-hejlsberg https://devchat.tv/js-jabber/209-jsj-typescript-with-anders-...
- bcherny 9y agoNot 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.