ECMAScript 6
rauchg.com
rauchg.com
I am already thinking ahead, ES7 is definitely going to be the pinnacle of the language I think. The implementation of a native Object.observe() means we will not have to worry about poor implementations in SPA frameworks like Angular that currently use dirty checking and other hacks to make up for the lack of native object observing. Lets hope the yearly release cycle proposed for Javascript specifications means ES7 happens sooner rather than later.
We have classes in ES6 (which is great), but they are currently nothing more than syntactic sugar over the old tried and tested prototypical inheritance. There are plans to add statics, private/public variables and classes to further extend them beyond just eye candy which they currently are. Plus Async/Await, Typed Objects, etc. There are also plans to better supported multithreading without the need to use WebWorkers which are pretty limited in their use.
Get excited. ES6 is only the beginning of a great suite of changes coming to Javascript. We'll eventually weed out the hacks and non-pretty parts of Javascript one specification at a time.
A good example is Facebook's Hack language that improve PHP in a sensible way and adds optional typing - something that would be great for ES6/7.
Necessary? No. But look around at Javascript projects, and see how many "reinventions" of simple inheritance you see. Often poorly done and/or buggy. Even more often they're hopelessly inconsistent.
What a lot of the ES6 changes does is codify ways of doing what "everyone" has been doing in mutually inconsistent ways.
I think it was. Using the class syntax gives a semantic meaning to the code that propotype wasn't. And if you think it was, then what was the point of typing again and again MyClass.prototype.<> ?
Refactoring Javascript code was a pain, and an excessive identifier redundancy was part of it.
Yes. Now your editor/IDE knows that that thing is supposed to be a class. The doc generator also knows that it's a class. Furthermore, this makes things more compatible since framework A and library B use the same kind of classes.
Finally, it means that you won't have to waste time with evaluating a dozen semi-popular options to handle classes/inheritance.
It does of course also make your code a lot easier to read and it makes it easier for new developers who used some other language with classes before.
> Hopefully ES7 doesn't get the verbose syntax of Java/C#.
I recommend to take a look at TypeScript and Dart. Optional types aren't verbose. You just add some types to the surface area, which, compared to JSDoc, is drastically less verbose. Inside functions, you can generally omit the types.
A good example is Facebook's Hack language that improve PHP in a sensible way and adds optional typing - something that would be great for ES6/7.
In comparision the Java/C# type is static at compile time. Newer C# version have like e.g. Visual Basic 6 a variant type that is a tradeoff (as wasteful as a "union struct" in C).
The class syntax in ES6 is just syntactic sugar. JS IDEs like WebStorm/PHPStorm/IDEA already can parse "classes" with JS5 syntax .
But what about the arrow syntax:
var odds = evens.map(v => v + 1);
interface Iterable {
[Symbol.iterator](): Iterator
} .attr('transform', function(d) { return "translate(" + (d.x + 1) + " 0)"; })
.attr('transform', d => `translate(${d.x + 1} 0)`)
.attr({x:x, y:y, width:width, height:height})
.attr({x, y, width, height})In context, we were commenting on this:
.attr('transform', d => `translate(${d.x + 1} 0)`)
.attr 'transform', (d) -> "translate(#{d.x + 1} 0)"
Careful though: Libraries like jQuery and D3 can and/or do rebind `this` and that can be a gotcha in both TypeScript and straight ES6. You can end up having to mix both declaration styles, which is gross.
While transpilation was possible with Traceur before - babel has made it really easy and the fact issues are addressed within a day and the author is an overall great guy really helps.
I've never been able to fully switch to Traceur - but ever since babel (used to be 6to5) came along I've made the switch and never looked back.
I came across the difficulty of using jspm on the server and client for an isomorphic React app I am building for an online community I run, and I was advised to just use npm (& naturally Babel). Integrating browserify with babelify into the build process was a far easier task.
I do not use the Flux pattern currently, but I am only in the beginning stages of building out this app & am inexperienced with React, and I have to coordinate getting others in this community involved too (two beginner/junior developers & a mid-level/senior developer, and 2-3 artists/designers, none with web designing experience). I have not evaluated how I want to handle state changes yet - I may just go with the Flux pattern for practicality for the beginner/junior developers' benefit career-wise.
This app is being built on io.js with Sails.js, isomorphic React, and ES6 (server and client) - I went with React because of its ability to do client-side and server-side rendering for SEO purposes. I have a working isomorphic React foundation, and working testing solution for the React code, but I still have to get a server-side testing solution up, integrating optional Steam authentication via OpenID, and figuring out build & deploy tooling into separate environments. This is on top of gathering requirements from the community & organizing it into a nice functional spec for developers to consume...it is almost like creating a startup except that it will never be for money, only for the love of the community I created ~7 years ago as a part of a larger one.
For the models with Sails, I haven't touched that yet - the plus side for me is that there is no schema yet, so I am still free to set everything up in the database as I wish. If you need to configure relations, there are details listed here: http://sailsjs.org/#!/documentation/concepts/ORM/Association... (check the types of associations listed in the sidebar on the left)
It uses a serviceworker in the background to transpile es6-js requests into es5 transparently.
Is the assumption now that browsers largely auto-update that it won't be so long before that happens? Why are breaking syntax changes not a big deal, whereas "use strict" was done as a string so older browsers would ignore it?
Edit: backwards compatibility -> forwards
For browsers, yes, compatibility means we have to transpile. But the day you need not isn't necessarily so far-flung. Like you say, browsers largely auto-update and, after a slow start, they are implementing ES6 features at a good pace. The ES6 compatibility table[1] shows the progress already made. Only WebKit is really lagging. IE.next/Spartan is actually leading the pack, and coupled with Microsoft's plan to give away Windows 10 free to Windows 7 and 8 users, it gives good hope for the future.
Also, transpilation can be a gradual strategy for converting code. The Babel (née 6to5) authors have stated their intention to keep supporting new JS features as they are added to future versions of the EcmaScript standard. I think we'll soon see Babel able to be used like Autoprefixer, which selectively adds vendor prefixes to CSS based on browser support statistics and a developer-specified target configuration like "last 2 versions" or "> 5%".
New syntax, on the other hand, can be added without breaking existing code. These new constructs would have been syntax errors beforehand.
With an object, I can use a console log or a debug break point and immediately see the key value pairs (hopefully well-named) without having to check the function implementation or docs to see in which order the authors decided to return (or yield, etc.) values.
Can we just agree now not to use array destructuring as an excuse for returning multiple disparate values in an array? Or at least in only some idiomatic form? [error, value] would actually make sense to me, as it follows popular Node conventions.
The solution is the same: named return values, with object restructuring.
const {error, value} = (function(){
return {value, error};
})();I've seen many an ES6 blogger decide to use arrays in their examples. It's not quite so grievous in the context of a throwaway example, but for real world usage, it might be more costly to figure out a month or two down the road.
Otherwise, we fall into exactly the "boolean trap" that the author links away to. [1]
[1] http://ariya.ofilabs.com/2011/08/hall-of-api-shame-boolean-t...
I'm saying that functions should return either primitives or objects that have properties (or keys, since in JS all objects are just hashmaps) that uphold some appropriate abstraction, completely separate from whatever the variables might have been called inside the function body.
For example, the return object from some function `getDate()` might have a .year property, or .toUnix method, etc.
If all I'm given is an array of arbitrarily typed values, I have solely the array indexes and values (or to go to the docs or implementation) to clue me into the semantic meaning of what was returned.
What's happening is that this expresion:
const { error, value } = obj;
You could name your locals something else if you wanted, of course:
const { error: myError, value: myValue } = obj;
const { error: error, value: value } = obj;
(defun foo () (values 1 :quux))
(+ (foo) (foo)) => 2
(multiple-value-bind (x y) (foo) (print y)) => :foo
If you are returning an explicit aggregation like an array then it's not true multiple value return in my opinion.
var {foo, bar} = getSomeObject();
The web needs increased consistency and cohesion in the HTML/CSS/JS triumvirate.
ES6 seems like a grab-bag of neat and fun new features that end up doing a whole lot of nothing for large projects that have to care about more tangible concerns than nicer ways to create anonymous objects.
Some of the new features of ES6 - Symbols, proxies, Object.observe, et cetera - seem to make it downright easier to write even more confusing code. Instead of increased rigor and tools for building better software, we get stuff like this:
let obj = {
["h"+"ello"]() {
return "hi";
}
};
obj.hello();
However, I can't help but wonder if that's due to a mild case of Stockholm Syndrome setting in.
Actually, they're things that actual users of javascript have been asking for (and implementing hacked-up solutions for) for a long time. There's a reason Coffeescript is often referred to as "a better javascript" and Typescript is considered its own thing.
Javascript is a dynamic language, and will never make the transition to a static one. Its users don't want a static language - the people who want a static language are using things like TypeScript.
Never say never. Typed structures are a proposal, and what make you think that we'll never see flow types in the standard someday ? Javascript will always give the upper hand to dynamic typing, but I can see it becoming a kind of hybrid language, where both dynamic and static codes can coexist.
1 - http://kangax.github.io/compat-table/es6/ (Note: Opera, Safari, and iOS8)
This is pretty much what happened with ES5, right?
And what happens with browsers on older mobile phones that cant be upgraded ? you let your scripts stop working ?
If you think you can switch to ES6 in 6 month without any kind of transpilation, while keeping a good browser compatibility good luck ...
> This is pretty much what happened with ES5, right?
No,5 years after the launch of ES5 some browsers like Safari still didn't support some ES5 features. And some browsers on handsets will never support ES6.
> And what happens with browsers on older mobile phones that cant be upgraded ? you let your scripts stop working ?
If I was absolutely worried about browser support on older mobile phones, I'd be still writing vanilla JavaScript with no features that aren't in Ecmascript 3. You'll have to drop support eventually. Plus, it's very likely a good chunk of the ES6 I'll be writing will only ever be intended for running in browsers that support other cutting-edge features like WebGL, Web Workers and WebRTC, or on a fairly up to date environment like iojs or node.js.
> No,5 years after the launch of ES5 some browsers like Safari still didn't support some ES5 features.
I'm not sure which features Safari is missing that you're referring to. Safari on both iOS and OS X are missing a lot of Javascript APIs, but both have fully supported ES5 since at least 2011 [0], and my old Macbook with Safari 5.1 has no problems running modern websites.
> If you think you can switch to ES6 in 6 month without any kind of transpilation, while keeping a good browser compatibility good luck ...
A lot of ES6 features are already being polyfilled (Typed Arrays have been polyfilled for years), plus you can use try/catch to support new syntax whilst also supplying some sort of fallback.
socket.destroy()You don't really have to be a designer to see that it's an awful choice of color.
...or use a better language.