HACKER Q&A
📣 no_wizard

Was ES6 a Bust?


I been doing a lot of code reading in the front end land the last few weeks and I’ve noticed that much of not nearly all of the features of ES2016/ES2015 are hardly used.

From what I’ve seen, even in big code bases like react, I only notice the the following:

- Classes

- Class Properties

- Promises

- A few object methods (entries, values, keys)

- Arrow functions

- async functions

I see very little code, even in new projects, big or small, where any of the newer features are leveraged. Even things like Map and Set have sparse usage, despite their efficiency on modern JS engines. For instance I still quite commonly see code that is meant as value stores implemented as objects instead of a Map, even though Map has better performance in high deletion/write scenarios (if I recall correctly due to not touching the prototype chain)

My favorite example being something like the redux state tree, which could be much more efficiently implemented with combo of Proxy + Map rather than a single mutated object.

Proxy, Reflect, WeakMap and Weakset are non existent even more . The JS community definitely didn’t embrace custom iterators or generators, and symbol never seemed to have taken off as a way to provide library specific code extensions or properties

I know Vue 3 leverages Proxies now but it’s not something I see much of in the wild otherwise

Seems the advanced programming concepts and promises of ES6 are languishing. It’s still all objects and arrays and mostly still coded like in the ES5 era while leveraging mostly syntactic sugar rather than new features outright despite higher efficiencies

I will say the limited Set API is rather annoying (you either have to convey it to an array or iterate over it to get a value out), other than that I don’t think the design of the newer features is harder to adopt, in a lot of cases I have found it’s easier

Has this been anyone else’s experience?

Edit: I speaking of new code or code that is generally being significantly re-written, or code being refactored that could benefit here. What I’m looking at is code written after ES6 was widely known and available


  👤 GianFabien Accepted Answer ✓
I can only speak for my experience. I never re-implement working code using new features just because I can. I have enough on my plate to just use the most convenient features initially. Over time, especially if I have a performance or code complexity issue will I take the time to read up on and understand new features.

My philosophy is: Don't fix what isn't broken. I suspect that might also be the case for most large code bases.


👤 taf2
I think it takes time. I work on a 10+ year old code base (young IMO) and instead of rewriting and probably breaking things unnecessarily we are slowly upgrading things. If you see a var and it’s constant change it to const. if you can fix a bug here change it to async await flattening it out making it easier to read. If you realize this is an object refactor this section to use a class... slow and steady improvements... not sexy just effective

👤 schwartzworld
My team uses es6 features every day, and I can't imagine going back to writing es5 flavored JS.

Generators/iterators are just waiting for a use case. They aren't that useful in React-land, but I actually think there is a lot of potential there.

But also the features you said you see used most often are amazing. Not a day goes by at work when I don't use all of them except classes, but I use them more at home.

You should judge those features by the code that you aren't seeing written. Async / await is do clean and simple to write compared to endless callbacks. Arrow functions save lots of code to handle inconsistent `this` behavior. These are major fixes to a language that is often described as broken.

The one big downside is compatability with older browsers. The Redux team may be hesitant to use new features that require transpiling or polyfills, but I'll wager most code that consumes redux is written using those features.


👤 henning
Strange, I use arrow functions and const to make variables immutable all the time.

Classes are widely used in React although with the arrival of hooks they aren't as necessary.

I use async functions and generators extensively with redux-saga. I use object methods when I need them. Sometimes I use promises.


👤 nojvek
ES6 is the thing that made JS worth it. Async await is awesome. Generators are awesome. Proxy is dark magic which should only be used with extreme care. Maps and Sets are awesome (and fast)

It really depends where you look. A lot of JS devs aren’t computer science folks. They probably learnt web dev via self learning or some lambda like school.

Js codebase quality varies a lot.


👤 the__alchemist
It sound like you're discounting the portion of features you mention as being used.

Anecdote: I regularly use async/Promises in the form of fetch, Map, Set, classes, arrow functions, and destructuring. My code style would have to change significantly to use an on older version of JS. Does this mean ES6 is a bust for me? Or do `Map` and `Set` make the difference?


👤 runawaybottle
Eh. Import/export, Const/let, arrow functions, async, and destructuring are the only really mainstays of the spec. The framework dependent development now days has left the current developer pool weak on constructing their own Class organization (but this might be a React specific problem). I don’t even really see scoped styles taking on the form of Class A extends B, we do weird stuff with hooks. The shift to hooks really put a damper on leveraging things developers already know how to reason about.

React not coming with a built in global store that’s easy to hit up really fucked with everyone’s natural ability to simply structure their code with stuff like Class, so it’s hard to just blame the es6 spec, the ecosystem is driving people in different directions. I was appalled how a simple API wrapper Class turned out to be the monstrous Redux action/dispatch fiasco for example. Our most widely used frameworks don’t implement obvious stuff in obvious ways, so what can you expect from the rest of the community.

Async, again, another weird syntactic jury rig with try/catch. Promise.then().fail() is so clear, but to each their own.