Ask HN: Was ES6 a Bust? | Hacker News Reader

Ask HN: Was ES6 a Bust?

9 pointsno_wizard13 comments

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

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.

For clarification, as I should have mentioned: I am speaking only to code that has one of the following characteristics:

1. It’s new code

2. It’s a significant re-write

3. It’s a substantial refactoring of existing code or a refactor where using one of the newer apis would be trivial (e.g Reflect.apply vs Function.prototype.apply)

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

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.

In React land, generators are the basis of Redux sagas. I'm still on the fence about when sagas become worth the weight, but a lot of people are using them. (In the recommended style, a simple fetch call with sagas requires more than a dozen lines of code spread over several files. Which is a pain, but it integrates nicely with the Redux framework if you're using it.)

Generators are also really nice for writing parsers and other tree-walking operations. Rather than passing in visitors or producing an entire tree, it's very easy to yield an intermediate result and then keep going. I don't see it used all that much (I believe in part because people don't write all that many parsers), but they're actually a pretty good way to get a handle on generator writing.

I didn't know that about sagas. I'm not a redux guy, so I don't really know any of the patterns.

If you're curious:

https://github.com/redux-saga/redux-saga

As I said, I'm on the fence. Redux itself is for programs that get large enough, and interconnected enough, that you want a central place to manage global state. You add in sagas when you want to grow that to include all side effects.

It is really cool to use its debugger and look at every message that got passed, and how that changes the global state. But adding in the message passing system is really heavy: you have to connect the component to it, AND create an action for both the request AND the response, AND put the code in a separate "reducer", AND then the whole saga middleware magic, AND several other things.

So... keep it in the back of your mind. If nothing else, it's pretty cool to use generators for something.

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.

OP is talking about less common features like Map, Set, proxies

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.

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?

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.

fwiw async/await also solves issues with chained promises in the .then portion. I’ve found this to be really helpful and a lot cleaner at times

Reply on news.ycombinator.com