Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A summary of ECMAScript 6 features

github.com

Post reply on HN
Print view View original

41–50 of 54 posts

Re: A summary of ECMAScript 6 features

#41

Post by __david__ »

shittyanalogy wrote: post #10

ECMAScript 6 is a mess Now there's a completely new function syntax that doesn't use parens and has different scope rules var odds = evens.map(v => v + 1); Enhanced object literals: // Computed (dynamic) property names [ 'prop_' + (() => 42)() ]: 42 what?? So it uses parens if there are no params, but not otherwise? Template Strings: `In JavaScript this is not legal.` Seriously another String delimiter? `Hello ${name…

  > Splats (spreads?)

  >    f(...[1,2,3]) == 6

  > ... means destructure?
No, it means something very close to "apply" or "concat", depending on the usage. That example is the same as:

  f.apply(this, [1,2,3])
But it's cleaner syntax. The interesting part is that you can mix them in anywhere:

  function f(x, y, z) {
    return x + y + z;
  }
  a = [1,2];
  b = [3];

  [...a, ...b] == [].concat(a,b) == [1,2,3]
  [0, ...a, 4, 5, ...b, 6] == [].concat([0],a,[4,5],b,[6]) == [0,1,2,4,5,3,6]
  f(...a, ...b) == 6
  f(1, 2, ...b) == 6
  f(...a, 3) == 6
  f(...b, 0, ...b) == 6
> ES6 is a mess. Javascript just got harder.

Want some cheese with that whine? It got more complicated, yes. But I'm liking most of the changes, personally. A lot. Most of them are long overdue.

BTW, if you open Firefox's console, you can try out many examples. Firefox already supports tons of ES6.

Re: A summary of ECMAScript 6 features

#42

Post by z3t4 »

This is some scary shit!

JavaScript is a mainstream language. That means average people like myself can be very productive with it. It is easy to learn and it's easy to find people who can maintain JS code.

But it seems you need to be an academic in programming languages just to figure out what these new features do, and why they are needed. I'm afraid that the rapid development will make it harder to learn the language. And will introduce a lot of pitfalls and edge cases.

Or maybe I'm just afraid of change!?

Re: A summary of ECMAScript 6 features

#43

Post by acjohnson55 »

shittyanalogy wrote: post #10

ECMAScript 6 is a mess Now there's a completely new function syntax that doesn't use parens and has different scope rules var odds = evens.map(v => v + 1); Enhanced object literals: // Computed (dynamic) property names [ 'prop_' + (() => 42)() ]: 42 what?? So it uses parens if there are no params, but not otherwise? Template Strings: `In JavaScript this is not legal.` Seriously another String delimiter? `Hello ${name…

Sure, you abuse the new syntax to make unreadable code, but most people will probably use it to abbreviate much of the syntax noise that plagues Javascript today.

Re: A summary of ECMAScript 6 features

#44

Post by acjohnson55 »

z3t4 wrote: post #42

This is some scary shit! JavaScript is a mainstream language. That means average people like myself can be very productive with it. It is easy to learn and it's easy to find people who can maintain JS code. But it seems you need to be an academic in programming languages just to figure out what these new features do, and why they are needed. I'm afraid that the rapid development will make it harder to learn the langu…

It honestly blows my mind that there is backlash against ES6. The new features solve so many pain points I've experienced in MVC and library development:

- ridiculously verbose syntax for anonymous functions

- lack of a module system

- no string interpolation (seriously!)

- no block scoping - super annoying

- lack of language level support for immutability

- clumsy 'this' management

- clumsy variadic functions

- competing promise implementations

- competing and poorly interoperating class implementations

... And so on. This is a huge step forward and it should help redefine Javascript coding style in a much better way. My only complaint is that they didn't deprecate poorly designed features of the past.

Re: A summary of ECMAScript 6 features

#45

Post by netcraft »

z3t4 wrote: post #42

This is some scary shit! JavaScript is a mainstream language. That means average people like myself can be very productive with it. It is easy to learn and it's easy to find people who can maintain JS code. But it seems you need to be an academic in programming languages just to figure out what these new features do, and why they are needed. I'm afraid that the rapid development will make it harder to learn the langu…

this is an interesting perspective that I don't really understand and hope you will expand on. Which parts of the es6 changes do you feel you need to be an academic to understand? The es5 spec is 6 years old at this point and it feels to me like es6 is taking forever to be implemented. Most of the changes are there to make things more consistent and reduce pitfalls and edge cases - let and const to solve the problems with var, fat arrows make functions cleaner and solve the this binding problem, classes and modules formalize what everyone has been trying to do in JS for years just in different ways. No doubt there's some learning to do, but on the whole it seems like a very conservative and solid list of enhancements.

Re: A summary of ECMAScript 6 features

#46

Post by z3t4 »

acjohnson55 wrote: post #44
z3t4 wrote: post #42

This is some scary shit! JavaScript is a mainstream language. That means average people like myself can be very productive with it. It is easy to learn and it's easy to find people who can maintain JS code. But it seems you need to be an academic in programming languages just to figure out what these new features do, and why they are needed. I'm afraid that the rapid development will make it harder to learn the langu…

It honestly blows my mind that there is backlash against ES6. The new features solve so many pain points I've experienced in MVC and library development: - ridiculously verbose syntax for anonymous functions - lack of a module system - no string interpolation (seriously!) - no block scoping - super annoying - lack of language level support for immutability - clumsy 'this' management - clumsy variadic functions - comp…

I've never read any programming books or taken any classes, I've just read a lot of code written by others and also written some myself. Here's my advice after 15 years of reading both brilliant and shitty JS code:

a) Don't use anonymous functions ... You want your program to be easy to understand, so come up with a name for the function and put it as a sub-function at the bottom of the current function.

b) I love the Nodejs implementation of modules and I would say it's the main reason behind Nodejs success. But it doesn't make sense in the HTTP world. Imagine having to download 100 dependency files each time you visit a webpage.

c) I have a keyboard macro for " + + ". So if you don't save an extra keystroke, what's the deal? It might be useful if you have nasty habits like building HTML or SQL by concatenating strings though. (don't do that).

d) Just declare your variables at the top of the function and stop worrying about scope, (while listening to Bobby McFerrin.)

e) I can somewhat agree here. But where it's really needed you should make a copy or clone function. And if it's not really needed you shouldn't. Makes you write less complicated code because of laziness.

f) Give it a name!

  function Car() {var car = this;}
Or if you don't want people to understand your code:

  var that = this;
g) You are probably trying to make your function do too much! If you Do want to have one function to rule them all, pass an object to it.

h) It's possible to make async code intuitive. Stop using anonymous functions will help a lot! But it's not That easy. Promises is just another (ineffective; it just threats the symptoms) paradigm to reason with async code.

i) We don't need classes. The prototype already work great. It might be hard to learn but once you understand it's brilliant! (I don't blame you if you never will, it's hard to learn an old dog to sit).

I encourage you to use the paradigms you believe in, and also to try different solutions, and think outside the box. But don't force certain paradigms by changing the language itself. One exception being Node.js where you are forced into making modules. (but some people are stubborn and use Browserify to circumvent it).

Re: A summary of ECMAScript 6 features

#47

Post by z3t4 »

netcraft wrote: post #45
z3t4 wrote: post #42

This is some scary shit! JavaScript is a mainstream language. That means average people like myself can be very productive with it. It is easy to learn and it's easy to find people who can maintain JS code. But it seems you need to be an academic in programming languages just to figure out what these new features do, and why they are needed. I'm afraid that the rapid development will make it harder to learn the langu…

this is an interesting perspective that I don't really understand and hope you will expand on. Which parts of the es6 changes do you feel you need to be an academic to understand? The es5 spec is 6 years old at this point and it feels to me like es6 is taking forever to be implemented. Most of the changes are there to make things more consistent and reduce pitfalls and edge cases - let and const to solve the problems…

JS is like that Indian wonder kid who wanted to come up with a cure for cancer.

Then he was invited to London. Where he met C, C++ and Java, who made him become ECMAScript.

http://youtu.be/BSQf7SUxJVw

Re: A summary of ECMAScript 6 features

#48

Post by acjohnson55 »

z3t4 wrote: post #46
acjohnson55 wrote: post #44

Earlier quoted context omitted.

It honestly blows my mind that there is backlash against ES6. The new features solve so many pain points I've experienced in MVC and library development: - ridiculously verbose syntax for anonymous functions - lack of a module system - no string interpolation (seriously!) - no block scoping - super annoying - lack of language level support for immutability - clumsy 'this' management - clumsy variadic functions - comp…

I've never read any programming books or taken any classes, I've just read a lot of code written by others and also written some myself. Here's my advice after 15 years of reading both brilliant and shitty JS code: a) Don't use anonymous functions ... You want your program to be easy to understand, so come up with a name for the function and put it as a sub-function at the bottom of the current function. b) I love th…

I'm aware there are workarounds for all of these things, but they all result in a ridiculous amount of boilerplate and syntactic noise. To me, naming a simple function that's an argument to, say, `.map(...)` and putting it at the bottom of a function is pretty heavyweight.

Many of your suggestions are just optimizing for the current state of JS instead of thinking about how to best leverage the many brilliant syntactic advances from throughout the industry. I guess there's no point in arguing. Change is coming, and people can keep writing super verbose JS if they like; I'll be writing code that more directly reflects the actual important logic.

Re: A summary of ECMAScript 6 features

#49

Post by z3t4 »

acjohnson55 wrote: post #48
z3t4 wrote: post #46

Earlier quoted context omitted.

I've never read any programming books or taken any classes, I've just read a lot of code written by others and also written some myself. Here's my advice after 15 years of reading both brilliant and shitty JS code: a) Don't use anonymous functions ... You want your program to be easy to understand, so come up with a name for the function and put it as a sub-function at the bottom of the current function. b) I love th…

I'm aware there are workarounds for all of these things, but they all result in a ridiculous amount of boilerplate and syntactic noise. To me, naming a simple function that's an argument to, say, `.map(...)` and putting it at the bottom of a function is pretty heavyweight. Many of your suggestions are just optimizing for the current state of JS instead of thinking about how to best leverage the many brilliant syntact…

I can't come up with a real world use for the .map function, but then I only use Arrays when I do evil things like writing optimized code. If I however would end up in a situation where I wanted to do:

  var odds = evens.map(v => v + 1);
I would write this instead:

  var odds = increment(evens, n);
But it's never as simple as this, evens would probably be some sort of async object and you probably want to call another function once the "incrementation" has completed.

The only thing => does is to make the syntax more complex (and ugly) by saving a few keystrokes. And even worse, it's a treatment for a symptom from anonymous functions, that you shouldn't even use in the first place. And will be used everywhere, because we are lazy. But the time saved, will have to be used for mind juggling, to figure out what goes where in the syntax.

That said, I don't think all new stuff is useless. For example Object.defineProperty (ES5) that actually Adds to the language, and makes it possible to do things you couldn't do before. Like defining a set function.

Re: A summary of ECMAScript 6 features

#50

Post by jarcane »

z3t4 wrote: post #49
acjohnson55 wrote: post #48

Earlier quoted context omitted.

I'm aware there are workarounds for all of these things, but they all result in a ridiculous amount of boilerplate and syntactic noise. To me, naming a simple function that's an argument to, say, `.map(...)` and putting it at the bottom of a function is pretty heavyweight. Many of your suggestions are just optimizing for the current state of JS instead of thinking about how to best leverage the many brilliant syntact…

I can't come up with a real world use for the .map function, but then I only use Arrays when I do evil things like writing optimized code. If I however would end up in a situation where I wanted to do: var odds = evens.map(v => v + 1); I would write this instead: var odds = increment(evens, n); But it's never as simple as this, evens would probably be some sort of async object and you probably want to call another fu…

That is a loaded example that deliberately leaves out the implementation details to disguise the productivity gains. If you really can't see the productivity difference between writing this:

  const vals = ['#hp','#mp','#gp'].map(x => $(x).val());
And this:

  var elems = ['#hp','#mp','#gp'];
  var getVal = function (x) { return $(x).val() };
  var mtVals = [];
  
  for (var x = 0; x
... then maybe you should actually go read some of those programming books you're so dismissive of.
Post reply on HN