Please Keep JavaScript Dumb(hyperorg.com)
hyperorg.com
Please Keep JavaScript Dumb
http://www.hyperorg.com/blogger/2019/03/08/keep-javascript-dumb/
13 comments
This article loses some credibility when citing arrow functions as a complex and “professional” feature. In reality, arrow functions are simple - smoothing over the weirdness and complexity of normal js functions.
This may be an unpopular opinion, but I disagree. Arrow functions are unnecessary syntactic sugar, and, like much of ES6, feel like the language adding opinionation.
Enterprise codebases I work on are locked to ES5 and scale to 100k+ lines. These codebases cannot afford to layer on every new JS "innovation" and hope to remain consistent across 7+ years (the average lifespan of an enterprise app) and multiple developers.
To assume that this is just because of developer laziness or inability to learn is to ignore the realities of apps built and deployed behind the firewalls of Fortune 500 companies.
Enterprise codebases I work on are locked to ES5 and scale to 100k+ lines. These codebases cannot afford to layer on every new JS "innovation" and hope to remain consistent across 7+ years (the average lifespan of an enterprise app) and multiple developers.
To assume that this is just because of developer laziness or inability to learn is to ignore the realities of apps built and deployed behind the firewalls of Fortune 500 companies.
It’s pretty well accepted by this point that normal functions in JS get a lot wrong. Inconsistent creation styles, weird hoisting rules - and lets not forget the fact that they don’t bind this, which itself is probably one of the top ways to cause a bug in vanilla JS. Each of these are great ways to trip up developers in JS, both amateur and expert. Arrow functions fix them all.
I’m not saying that your 100k loc code bases can’t be built without them. Obviously, once a language is turing complete, then everything is possible. But certain language features tend themselves to create bugs at a higher rate than others because they confound the expectations of even the most experienced developers. Functions are such a feature.
I’m sure your 100k code bass works fine now - but I wonder, if you look through the commit logs, just how many bugs were caused by some of the inconsistencies and strangeness I mentioned above, and I wonder how much of that time and those bugs could have been obviated had you moved. Probably a decent amount.
I’m not saying that your 100k loc code bases can’t be built without them. Obviously, once a language is turing complete, then everything is possible. But certain language features tend themselves to create bugs at a higher rate than others because they confound the expectations of even the most experienced developers. Functions are such a feature.
I’m sure your 100k code bass works fine now - but I wonder, if you look through the commit logs, just how many bugs were caused by some of the inconsistencies and strangeness I mentioned above, and I wonder how much of that time and those bugs could have been obviated had you moved. Probably a decent amount.
> Arrow functions are unnecessary syntactic sugar
Unnecessary is a matter of taste. Most don't like having to bring out `.bind()` or inside of the function using `let that = this`.
Unnecessary is a matter of taste. Most don't like having to bring out `.bind()` or inside of the function using `let that = this`.
Whoever thinks it's easier to understand the this scope because they have to explicitly declare it must just like to not learn better methods to program.
const that = this;
const that = this;
tinus_hn(1)
IT is brutal. You either evolve or you die.
If JS didn't introduce new features, it would be just replaced with the "next big thing" that introduces things.
Arrow functions, classes and promises don't make things more complicated. They are added to make things more readable
I sympathize and resonate with the author.
While for me, the JS language features are still manageable. What has outgrown me are the layers upon layers of abstractions used in modern JS app, like React/Redux/... We no longer have a straightforward, plain JS app. To understand the code, we have to 'see through' the thick layers of frameworkds/middleware.
Modern JS app is becoming as ugly as J2EE last time used to be.
While for me, the JS language features are still manageable. What has outgrown me are the layers upon layers of abstractions used in modern JS app, like React/Redux/... We no longer have a straightforward, plain JS app. To understand the code, we have to 'see through' the thick layers of frameworkds/middleware.
Modern JS app is becoming as ugly as J2EE last time used to be.
This really reads like it was written by someone who does not know how React and Redux are used. Both of those libraries are incredibly straightforward and minimal in their functionality — orders of magnitude less complex and multifaceted than something like Hibernate or Spring. When you compare a React app with something written with what JS “used” to be (vanilla JS with browser hacks, jQuery, Backbone) the number of hacks or workarounds per line of code in the React app is much lower in my experience.
Well the prototypal inheritance stuff is newish for Java people, so I can see a desire for class based, and then there is that closure private variable thing when it is nicer to just have a private keyword. (I think they use let now?) Still adding features can make things to become bloated. I think one of the targets of language design is balancing everything.
I'm not an expert though.
I'm not an expert though.
Folks,
Understand all of you. But what can I say is to wait, keep calm, let all the fancy new comer like Angular, React and Vue going ahead. Wait and it will be sure, in 2 years, everybody, everybody write all their stuff in their known language and only compile it down to native, web-assembly.
Gheers.