4 ms·

Yeah, it definitely feels like ES6/7/Next is packed with features that theoretically make it a little faster to write code while making it monstrously slower an

Yeah, it definitely feels like ES6/7/Next is packed with features that theoretically make it a little faster to write code while making it monstrously slower and harder to read for at least 80% of practitioners... (destructuring comes to mind, with a syntax that is bafflingly similar to literal decs, that used to be the "good part") Seems like they made that choice every time. I was reserving my thoughts about ES6 until I worked with it for a while, but now that I have, I have to say for those reasons you cited I don't like it as much as ES5.

feanaro 8y ago
Can you give an example of the aspect of restructuring you consider confusing?
- zbentley 8y ago
  I'm not GP, but I believe they were referring to the fact that the syntax for destructuring is visually very similar to the syntax for object literals, which makes it easier to make mistakes while reading code in a hurry or as a newcomer to the language.
- dccoolgai 8y ago
  "Confusing" is perhaps too harsh (although destructuring over several levels can be terribly confounding). By "hard to read" I mean primarily the fact that when you are "scanning" code, destructuring statements are syntactically way too similar to literal declarations. It severely degrades, IMHO, the speed with which you can effectively "scan" code in JS. It's not really that you _can't_ understand it when you slow down and analyze - it's that you _have to_ slow down to see the difference between "let a = [0,1]" and "let [,a] = [0,1]". Whereas in ES5, whenever you saw the brackets you could know without reading into the code there was an object or array being declared. That's not to say that I think destructuring is all bad - it certainly saves lines of code - but aftet working with it for a few years, I would gladly trade it back for more scannable code, easier syntax for beginners, etc.

feanaro 8y ago

Can you give an example of the aspect of restructuring you consider confusing?

zbentley 8y ago
I'm not GP, but I believe they were referring to the fact that the syntax for destructuring is visually very similar to the syntax for object literals, which makes it easier to make mistakes while reading code in a hurry or as a newcomer to the language.
dccoolgai 8y ago
"Confusing" is perhaps too harsh (although destructuring over several levels can be terribly confounding). By "hard to read" I mean primarily the fact that when you are "scanning" code, destructuring statements are syntactically way too similar to literal declarations. It severely degrades, IMHO, the speed with which you can effectively "scan" code in JS. It's not really that you _can't_ understand it when you slow down and analyze - it's that you _have to_ slow down to see the difference between "let a = [0,1]" and "let [,a] = [0,1]". Whereas in ES5, whenever you saw the brackets you could know without reading into the code there was an object or array being declared. That's not to say that I think destructuring is all bad - it certainly saves lines of code - but aftet working with it for a few years, I would gladly trade it back for more scannable code, easier syntax for beginners, etc.