I would never use most of the exotic new stuff and I would probably never use any of the red stuff.
I'm not saying it shouldn't be in there. I love that JS can be a fit for everybody. I just wonder how much we're gonna be adding and when it's enough...
Are we talking 'does not use many jQuery plugins these days' or 'regular contributor to ${framework}' here?
1. Arrow functions are really handy:
["the", "red", "fox"].map(word => console.log(word))
["the", "red", "fox"].map(function(word) {
console.log(word)
})
import React, { Component } from 'react';
import Block from './Block';
var React = require('react');
var Block = require('./Block');
export default myFunction()
module.exports = myFunction()
Random example:
DRAFT_LOADED: ({
state: { drafts },
payload: { draft }
}) => ({
drafts: {
...drafts,
[draft.id]: draft
}
})
RESULTS_LOADED: function(state, payload) {
return {
drafts: Object.assign(
{}, state.drafts,
keyValue(payload.draft.id, payload.draft)
)
}
}
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;
return myArray.map(item => `I am ${item}, yo!`);
return myArray.map(function(item){
return 'I am ' + item + ', yo!';
});
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}
`
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.
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.
{
foo: (a,b) => doFoo(this, a, b, 'fixed-value')
}
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.
For me most of my work in node needs to work over multiple versions and most of my browser work also needs to work over multiple browsers. Transpiling with Babel means I can't debug the code I actually wrote (even mappings won't work in all browsers or older ones) and I don't need extra, unnecessary complexity added to my build and development.
I like many of ES6's features but I value simplicity over almost everything so I can only hope to use it at some point in the future.
> I feel save saying this and claiming this
Is `this` some kind of pun? When I was learning JS I never felt safe around this:)
Nevertheless if I see people has just replaced `class` with `jQuery.extend` or with some other helper tool it would be a downside. Also we are talking about lodash vs native implementation.
That's one of the reasons I stopped working with coffeescript.
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.
Did it? Or is that just a paradigm you've latched on to?
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.
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.
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.