5 ms·

ES6 is Over-Engineering JavaScript

5 points by akamaozu 11y ago

hoodoof 11y ago
>> I really hope I’m wrong I have good news - you are wrong. ES2015 at last makes JavaScript into a consistent, sane way to program JavaScript. Providing a consistent mechanism for imports and modules alone justifies its existence apart from the many other fixes, tweaks and features. In many ways ES2015 is starting to look alot like other modern programming languages - that's a good thing. One of the great things about ES2015 is that it provides an agreed upon standard for solving many of the common problems with JavaScript that were previously solved in myriad ways. When there is a consistent way of doing something in a programming language then alot of the noise and confusion associated with the many old solutions disappears. JavaScript needed to grow up. ES2015 does alot of the needed growing.
- qewrffewqwfqew 11y ago
  > In many ways ES2015 is starting to look alot like other modern programming languages - that's a good thing. That depends on how you view Javascript. If you consider it a programming language, the growing-up is a good thing. Making developers more productive and all that jazz. Of course, core WATs in JS are at a deep enough level that they're going nowhere (backward compatibility folks!), and anyone who's not already invested in JS should have the sense to look elsewhere. If you consider it a runtime for delivering applications to the browser, it's really not so clearly a positive. A more complex language means more lock-in to existing runtimes, more room for bugs, more wasted engineering effort supporting the moving standard, less opportunity for lighter abstractions or more declarative assets amenable to static analysis ...
  - hoodoof 11y ago
    >> A more complex language means more lock-in to existing runtimes, more room for bugs, more wasted engineering effort supporting the moving standard, less opportunity for lighter abstractions or more declarative assets amenable to static analysis ... Sorry you've lost me on this one - I'm sure "complex" is the wrong word and how the rest of your conclusions follow mystifies me.
  - tracker1 11y ago
    So, you don't use any features added to any of the languages you use in the past 20 years?
- angersock 11y ago
  Did it need to grow up, truly? The module system needed to be sorted out, sure. Some of the rough edges around Number and Array, sure. But let's not kid ourselves...everything else being added is basically just gravy, and it's gravy that sometimes comes at the expense of readability. Just because it's not "a modern language" doesn't mean it isn't quite good at what it did--we still use C for that same reason.
  - akamaozu 11y ago
    Exactly my sentiments. The module system is definitely needed. For better or worse, npm's already become the defacto JavaScript package manager. It works automatically with every environment outside the browser and we're fine using whatever module system that is compatible with it in the browser. (I use Browserify) These tricks aren't really new. We had them in ES5. The syntax may be easier to parse for experts .. people with multiple languages under their belts ... but these changes aren't really newbie friendly. Is the new syntax worth it?
    - tracker1 11y ago
      What languages do you use that have not added features to the language for 20 years that you happen to use regularly?
      - akamaozu 11y ago
        It's not about refusing to use new language features. It's that these aren't new features; they're old features with new syntax. That's why Babel can transpile it. It's a case of old feature new syntax.
        iliaznk 11y ago
        Exactly why I'm not taking any efforts to use Babel. I got no problems with .bind(this) and webpack. I don't need another task running just for some syntactic sugar.
    - 11y ago
tracker1 11y ago
Certain features like generators, lambdas, spread, rest, and more cannot be done via npm modules. The expressions themselves improve the language. Really don't agree with TFA at all.
- akamaozu 11y ago
  I'm certain generators can be packaged up as modules. I believe there's a functional programming package that includes lambdas. I've seen spread used by co-workers. Point is .. even if not 100% of these are functionality you can package and distribute, a good number of them are.
  - tracker1 11y ago
    Doing generators, or async functions without the modern syntax is relatively painful.. same goes for spread/rest, and a lot of other bits.

5 points by akamaozu 11y ago

>> I really hope I’m wrong I have good news - you are wrong. ES2015 at last makes JavaScript into a consistent, sane way to program JavaScript. Providing a consistent mechanism for imports and modules alone justifies its existence apart from the many other fixes, tweaks and features. In many ways ES2015 is starting to look alot like other modern programming languages - that's a good thing. One of the great things about ES2015 is that it provides an agreed upon standard for solving many of the common problems with JavaScript that were previously solved in myriad ways. When there is a consistent way of doing something in a programming language then alot of the noise and confusion associated with the many old solutions disappears. JavaScript needed to grow up. ES2015 does alot of the needed growing.

qewrffewqwfqew 11y ago
> In many ways ES2015 is starting to look alot like other modern programming languages - that's a good thing. That depends on how you view Javascript. If you consider it a programming language, the growing-up is a good thing. Making developers more productive and all that jazz. Of course, core WATs in JS are at a deep enough level that they're going nowhere (backward compatibility folks!), and anyone who's not already invested in JS should have the sense to look elsewhere. If you consider it a runtime for delivering applications to the browser, it's really not so clearly a positive. A more complex language means more lock-in to existing runtimes, more room for bugs, more wasted engineering effort supporting the moving standard, less opportunity for lighter abstractions or more declarative assets amenable to static analysis ...
- hoodoof 11y ago
  >> A more complex language means more lock-in to existing runtimes, more room for bugs, more wasted engineering effort supporting the moving standard, less opportunity for lighter abstractions or more declarative assets amenable to static analysis ... Sorry you've lost me on this one - I'm sure "complex" is the wrong word and how the rest of your conclusions follow mystifies me.
- tracker1 11y ago
  So, you don't use any features added to any of the languages you use in the past 20 years?
angersock 11y ago
Did it need to grow up, truly? The module system needed to be sorted out, sure. Some of the rough edges around Number and Array, sure. But let's not kid ourselves...everything else being added is basically just gravy, and it's gravy that sometimes comes at the expense of readability. Just because it's not "a modern language" doesn't mean it isn't quite good at what it did--we still use C for that same reason.
- akamaozu 11y ago
  Exactly my sentiments. The module system is definitely needed. For better or worse, npm's already become the defacto JavaScript package manager. It works automatically with every environment outside the browser and we're fine using whatever module system that is compatible with it in the browser. (I use Browserify) These tricks aren't really new. We had them in ES5. The syntax may be easier to parse for experts .. people with multiple languages under their belts ... but these changes aren't really newbie friendly. Is the new syntax worth it?
  - tracker1 11y ago
    What languages do you use that have not added features to the language for 20 years that you happen to use regularly?
    - akamaozu 11y ago
      It's not about refusing to use new language features. It's that these aren't new features; they're old features with new syntax. That's why Babel can transpile it. It's a case of old feature new syntax.
      - iliaznk 11y ago
        Exactly why I'm not taking any efforts to use Babel. I got no problems with .bind(this) and webpack. I don't need another task running just for some syntactic sugar.
  - 11y ago

tracker1 11y ago

Certain features like generators, lambdas, spread, rest, and more cannot be done via npm modules. The expressions themselves improve the language. Really don't agree with TFA at all.

akamaozu 11y ago
I'm certain generators can be packaged up as modules. I believe there's a functional programming package that includes lambdas. I've seen spread used by co-workers. Point is .. even if not 100% of these are functionality you can package and distribute, a good number of them are.
- tracker1 11y ago
  Doing generators, or async functions without the modern syntax is relatively painful.. same goes for spread/rest, and a lot of other bits.