3 ms·

Obviously this is true, but I kind of agree with him. So far I don't use the overwhelming majority of new features and it does sort of seem like JavaScript is

Obviously this is true, but I kind of agree with him. So far I don't use the overwhelming majority of new features and it does sort of seem like JavaScript is in some kind of race with itself to implement every paradigm and idea that anyone latches on to. There is beauty in simplicity and commonality in code. I don't think there would be anything wrong with taking a more conservative approach to adding new language constructs. JavaScript needed a class syntax. It needed block-scoped variables. It needed better parameter syntax and object loops. Generators are great. I'm not sure how much else of what is being added is strictly necessary as opposed to a technological debt for the future that must be supported for compatibility.

likeclockwork 10y ago
> JavaScript needed a class syntax. Did it? Or is that just a paradigm you've latched on to?
- mkohlmyr 10y ago
  You got me.. Although the multitude of awful shims people invented would tend to support my assessment that a singular way of doing things was needed. Oh, and all the blog posts explaining "this" and prototype inheritance.. I take it back, you didn't get me. JavaScript needed a coherent common syntax for doing what everyone was trying to do anyway.
ufmace 10y ago
As far as using the new features, how many people actually can/are? I can agree that they're needed, and I'm glad that they're coming, but support in browsers is variable at best, meaning you can't really use it in the front-end for anything in production without a transpiler, which IMHO mostly defeats the purpose. When you try to actually debug something, you have to deal with the mental translation of going back and forth between the translated/compiled stuff that's actually running and the source code. Could be different for stuff running in Node on the server, but then according to this, Node native support for ES6 features varies between bare-bones and not very tested to nonexistent. So we're back to transpilers again, not quite as much of a pain on the server, but still not great.
tracker1 10y ago
Did it really need class syntax? I mean, there are a lot of us following functional patterns as much as possible, and I feel that I rarely need class syntax... I mean it's kind of nice for a react component, but even then, not something that couldn't easily be represented with static objects. I rarely use classes, or for that matter constructor functions... a lot of the code is far easier to follow and reason that way. As to block-scoped variables, understanding that variables were scoped to the function they are declared in wasn't a huge hinderance, and is part of the reason why the new stuff runs slower... creating that scope has overhead. I'll add that destructured assignment and string templates are huge... taking generators the next step to async functions with await is very nice as well, not that co didn't work. Fat-arrow syntax cuts quite a bit of typing out with a default return. Each piece is valuable to some, and collectively not everything is valuable to some... Just because you don't see the value, doesn't mean that nobody does. I, for example, will probably not use the WeakMap/Map/Symbol in practice... But I see how someone can find those valuable additions.

likeclockwork 10y ago

> JavaScript needed a class syntax. Did it? Or is that just a paradigm you've latched on to?

mkohlmyr 10y ago
You got me.. Although the multitude of awful shims people invented would tend to support my assessment that a singular way of doing things was needed. Oh, and all the blog posts explaining "this" and prototype inheritance.. I take it back, you didn't get me. JavaScript needed a coherent common syntax for doing what everyone was trying to do anyway.

ufmace 10y ago

As far as using the new features, how many people actually can/are? I can agree that they're needed, and I'm glad that they're coming, but support in browsers is variable at best, meaning you can't really use it in the front-end for anything in production without a transpiler, which IMHO mostly defeats the purpose. When you try to actually debug something, you have to deal with the mental translation of going back and forth between the translated/compiled stuff that's actually running and the source code. Could be different for stuff running in Node on the server, but then according to this, Node native support for ES6 features varies between bare-bones and not very tested to nonexistent. So we're back to transpilers again, not quite as much of a pain on the server, but still not great.

tracker1 10y ago

Did it really need class syntax? I mean, there are a lot of us following functional patterns as much as possible, and I feel that I rarely need class syntax... I mean it's kind of nice for a react component, but even then, not something that couldn't easily be represented with static objects. I rarely use classes, or for that matter constructor functions... a lot of the code is far easier to follow and reason that way. As to block-scoped variables, understanding that variables were scoped to the function they are declared in wasn't a huge hinderance, and is part of the reason why the new stuff runs slower... creating that scope has overhead. I'll add that destructured assignment and string templates are huge... taking generators the next step to async functions with await is very nice as well, not that co didn't work. Fat-arrow syntax cuts quite a bit of typing out with a default return. Each piece is valuable to some, and collectively not everything is valuable to some... Just because you don't see the value, doesn't mean that nobody does. I, for example, will probably not use the WeakMap/Map/Symbol in practice... But I see how someone can find those valuable additions.