3 ms·
Some things I like about ES6 1. Arrow functions are really handy: ["the", "red", "fox"].map(word => console.log(word)) is much cleaner than ["the", "red
by terda12 10y ago
Some things I like about ES6
1. Arrow functions are really handy:
["the", "red", "fox"].map(word => console.log(word))
is much cleaner than
["the", "red", "fox"].map(function(word) {
console.log(word)
})
2. Imports, while more ambiguous than `require`, look quite nice:
import React, { Component } from 'react';
import Block from './Block';
vs
var React = require('react');
var Block = require('./Block');
3. Exports are cleaner and streamlined
export default myFunction()
vs
module.exports = myFunction()
So while ES6 is more ambiguous than ES5 and has a higher learning curve, I think it's much cleaner and looks more like a proper programming language. ES5 feels like a homegrown hacky language in comparison.
- mbrock 10y agoThe 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.
- minitech 10y agoI 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.
- tracker1 10y agohow 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.
- minitech 10y ago> 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.