4 ms·
JS fatigue is not a fake problem, it's real and different from other forms of fatigue. The metaphor used in the article i.e. 'learning another language every 6
by edblarney 10y ago
JS fatigue is not a fake problem, it's real and different from other forms of fatigue.
The metaphor used in the article i.e. 'learning another language every 6 months' is not apt - because those are not 'new languages' and they are not 'new and critical parts of the landscape' for any specific vertical.
If any one of those languages were to have the same degree of evolution as JS ... then 'fatigue' would also be an issue.
JS has a pernicious problem for a few reasons:
1) The language is quirky, fragmented, there are still no 'agreed upon' approaches to do many things even outside the context of libraries. There are really no analogues to 'prototype' based languages, which possibly makes it great for some things, but it's not great for those wanting to use more classical ways of thinking about information organization.
2) Runtimes, particularly browser - are highly fragmented, and there's scant documentation. Safari docs for Mac/iOS are literally empty in some spots.
3) JS doesn't come with a lot of things 'baked in' to the language that most others support, so discovering those 'standard libs' has been a painful process.
4) Due to the limitations of the browser, we see a lot of churn in frameworks.
Though there is some advantage to 'community participation' - the pernicious problem is most of the churn is not fully forward. It's 3 steps forward, 2 steps back, and a step sideways.
There's a lot of time and investment in learning something new that won't exist in the future - that's costly.
Learning Lambda's for Java 8 is probably worth investing in for Java programmers ... because Java 9 will surely use them as well.
Taken as a whole - there is an enormous amount of inherent 'reducible complexity' in the JS ecosystem, which any JS developer intuitively senses.
If someone were to have made up their mind about JS right from the start, and had come up with some good standard libs ... and the evolution of the language were to have been more 'version' and less 'pick and chose' (Es6 means something different in each environment) ... then the complaint would be valid.
It is what it is ... but JS fatigue is a real thing.
- z3t4 10y agoone reason why JS is so popular is because there are no standard lib. There would be no nodejs etc.
- cocktailpeanuts 10y agonode.js was built from scratch, in C, to resemble javascript syntax intentionally.
- ryanolsonx 10y agoNo, it was not. It uses Chrome's JavaScript Engine, V8. From nodejs.org: > Node.js® is a JavaScript runtime built on Chrome's V8 JavaScript engine.
- bobbytherobot 10y agoWhat? The engine is written in C, but all JavaScript engines are written in another language (C being the most popular) because it is an interpreted language. The engine isn't written from scratch because it is the V8 engine from Google. Of course the system binding and package system is written specifically for Node.
- paulddraper 10y agoC++, actually.
- jnbiche 10y agonode.js doesn't just resemble JavaScript, it is JavaScript. Like ES5 standard JavaScript, and (very soon) ES6 standard JS as well. It uses the V8 JS engine. The only non-standard features of Node.js has been the module system (CommonJS), but even that will be ECMA standard as of next version. (also, Node.js was built in C++ and JS)
- dcherman 10y agoThe module standard that is present in ES6 is a very different beast than CommonJS
- jnbiche 10y agoAgreed. I use ES6 modules regularly (via Babel compiled to CommonJS, and also Rollup). Unlike CommonJS, ES6 modules have the advantage (and disadvantage) of being statically resolved, which permits tree-shaking (but denies dynamic resolution of imports like CommonJS). The "that" in my sentence refers to "module system", not "CommonJS", but I agree my sentence was unclear.
- ryanolsonx 10y agoYou have a lot of great points but one area where I disagree is in this statement: > Es6 means something different in each environment Ecmascript 6 (or Ecmascript 2015) by definition is a specification that browsers (and others, such as nodejs) adhere to in order to support that version of JavaScript. The api and functionality are designed to be the same. So Es6 means the same thing no matter the environment. However, there places where they haven't finished implemented ES2015 quite yet. Most modern browsers have 99% of Ecmascript 2015 all implemented. [0] And for those that don't, there's always transpilers like Babel or TypeScript. [0]: https://kangax.github.io/compat-table/es6/ https://kangax.github.io/compat-table/es6/