The code I write in ES2015 makes very heavy use of arrow functions, destructuring parameters, the ellipsis syntax for extending arrays and objects, and the syntax for evaluated object literal keys.

Random example:

    DRAFT_LOADED: ({
      state: { drafts },
      payload: { draft }
    }) => ({
      drafts: {
        ...drafts,
        [draft.id]: draft
      }
    })

In classic JavaScript, I'd have to write something like:

    RESULTS_LOADED: function(state, payload) {
      return {
        drafts: Object.assign(
          {}, state.drafts,
          keyValue(payload.draft.id, payload.draft)
        )
      }
    }

The new syntax rules combine to significantly improve the clarity of this kind of transformation function.

hmm. Looks like some sort of exploit. Tried to run it in node and got some weird error I haven't seen before. Did you just pwn me?

haha, no... I haven't tried it in pure Node, I'm using Babel for transpiling.

I don’t find the arrow function version of (1) cleaner than the anonymous function version. Is it cleaner because you can fit it on one line?

I don’t find the import version of (2) cleaner than the require() version. Having a boring old function that’s consistent with the rest of the language actually seems better than dedicated syntax, especially when that dedicated syntax is unnecessarily verbose. Copying Python’s might have been okay:

  // I have to repeat “fs” =(
  var fs = require('fs');

  // Wait, I still have to repeat “fs” *and* it’s longer
  // *and* it looks more confusing? There’s no precedent
  // for this use of * in JavaScript.
  import * as fs from 'fs';

  // Nice.
  import fs;

I don’t find the `export default` version of (3) cleaner or more streamlined than the one that assigns to `module.exports`. It just seems like another waste of dedicated syntax.

how about...

    return myArray.map(item => `I am ${item}, yo!`);

vs

    return myArray.map(function(item){
      return 'I am ' + item + ', yo!';
    });

There are a lot of one liners that are much more composable in the fat-arrow syntax. The default returns takes a lot of it out, and makes it simpler the simpler it starts.

Beyond this, the above also uses templates, which you can even create custom processors for templates...

    var result = await sql`
        SELECT *
        FROM
          a
        WHERE
          a.foo = ${bar}
    `

You can create an sql processor that turns that query as a template into a parameterized query for the database, that returns a promise, which inside an async function can be awaited directly... I wrote a few libraries that did just that to make using sql, bigtable (azure tables), queues and other pieces really easy to use... With that I was able to write data migration scripts with ease... it was really awesome to see.

Your second example is only if there's no default export... the local name doesn't have to match the name of the module, also modules can be `foo.bar` or `foo_bar` or `foo-bar` which can't be a single value within the script... so it creates a disconnect there, requiring the localized in-script name.

> There are a lot of one liners that are much more composable in the fat-arrow syntax. The default returns takes a lot of it out, and makes it simpler the simpler it starts.

They’re not more composable… they’re slightly shorter, and anything non-trivial doesn’t fit on one line. Template literals are nice, sure.

> the local name doesn't have to match the name of the module,

But when it does, everything is a lot more obvious. It works fine for all the Python modules, too.

Try the following without fat-arrow syntax off of an object

    {
      foo: (a,b) => doFoo(this, a, b, 'fixed-value')
    }

I find the fat-arrow syntax allows for much more dynamic flows that are easy to understand, more so than bind, and like the above, where bind wouldn't work.

There's a lot of oneliner possibilities when you get rid of 12+ characters `function(){ return ` ... Also, I find the fat-arrow syntax looks better in a lot of cases, where you might use bind.