I thought it wasn’t even called ES6 anymore, but ES2015. Though maybe that’s a whole different discussion.
A lot of the new syntax does seem like unnecessary shorthand, like the spread operator, which I think can be written in code that may be a little more verbose but easier to reason about when read later or by someone else.
What should really be fixed are real problems like imprecise floating point arithmetic.
I think I see what’s driving obscure ES6 grammer now. With single-page js apps, the initial page load can be megabytes. So ES6 is pushing concise syntax in an effort to reduce those megabytes – even at the expense of learnability, readability, and in some cases ease of coding and maintenance.
Since most browsers don’t yet support ES6, those benefits are not yet available. Instead we have ES6 to ES5 transpilers, giving us the worst of both worlds – the difficulties of ES6 without the benefits.
If you ask me, we don’t need ES6 to ES5 transpilers – which is what we have now. We need (once ES6 is supported in browsers) ES5 to ES6 transpilers, so that we have the ease of coding of ES5, and the reduced page load of ES6.
That said, I must add that I understand that there are some fantastic benefits in ES6 that are a lot harder to do in ES5, e.g. promises, etc.
Your thoughts?
Lebab (Babel spelled backwards) is an ES5 to ES6/7 transpiler. I can’t speak to how good it is, but I do know that some of the people involved are amongst the ECMAScript elite.
I can speak to the likelihood of it being “great”. That is near zero. I’ve been in the business long enough to see tools like this come again and again and again. The first I remember was one used to convert the software for an aircraft computer from 8085 assembly language to PLM/85 (an Intel language with similarities to Pascal and C). I’ve seen serious, multi-million dollar government projects bite into them. In the vast majority of cases, it would have been easier to start over.
“Good”, however, is possible here because it isn’t converting apples to oranges - just apples to better apples.
As to the idea that a concise grammar makes a difference in download size, I doubt it. I’ve made the mistake of spending time reducing file size by concentrating on characters too many times in the past. You almost always end up with a near zero change after compression.
This is because the download size is only marginally related to the size of things on disk. Patterns are patterns and, when they go through compression for transmission across the wire, they tend to come out similar in size if they produce the same functionality, even when the number of characters implementing them is different.
The biggest problem with download size today is library bloat. Many sites are downloading a lot of functionality that they don’t need because of unused functionality - code that is different from other code that you need. It is the stuff that is both different and doesn’t contribute that has the biggest impact on download size.
We will eventually see a bit of a gain because some things moved into the core. The core is already on the machine. i.e. if promises are already implemented, there is no reason to download a promise library.
I think ES6/7 changes are more about making things simpler for newbies and increasing code reuse. For example, the biggest advantage of the arrow function syntax is the difference in the handling of “this”. It makes more sense to those of us who aren’t JS experts.
And code reuse is improved when common functionality is moved into the core. When I search for a library to perform a function, it is easier if I don’t have to find one that is using the same promise library and modularization system as the other libraries I’m using.
imo TypeScript is much more interesting…
Which is clearer ?
arr.map(function(a){
return a * a;
}).reduce(function(a, b){
return a + b;
});
or
arr.map(a => (a * a)).reduce((a, b) => (a + b))
I cannot resist to post this link https://github.com/you-dont-need/You-Dont-Know-Lodash-Underscore which shows that native forEach is 89% SLOWER than lodash each and that native map is 94% SLOWER than lodash map.
Which show that “ALWAYS” are true, only when they are not false. 
As ironic as this is going to sound, I have to ask nevertheless… Is there an ES6 legibility “translator”? Like babel but for making code more human readable?
PHP is the worst langauge. Yuk. It’s horrible.
const result = myarray.map(callback)
There is your “array_walk”. Learn Ruby then ES6 and you’ll never willingly code in PHP again.
I’ll actually be sticking to Coffeescript for some time. Pretty much anything you can get from ES6 you already have in CoffeeScript. It also transpiles automatically to something like ECMA 3.5 so no need for Babel. Also, really, really like meaningful whitespace.
CoffeeScript the language is wonderful IMHO.
BUT, the debugging support is quasi inexistent with the never corrected and/or ever creeping back bugs all over the place with source maps handling in the best IDE: WebStorm and VSCode.
Do these seemingly never solved source maps issues also plague programming with ES6?
Since us coffee addicts are a tiny minority among the {(var); (function);}; fetishist majority, coffee friendly tooling seems to be an elusive dream, cursed to always be lacking and behind.
Reading CoffeeScript is very productive for a Python lover like me and thinking in CoffeeScript is also very natural to someone coming from Lisp. But debugging with console.logs and debugger statements to then look at uber verbose Meteor generated app.js files in plain vanilla JS is not. 
BTW: did any coffee addict meteorite out there figured out how to set up a VSCode launch.json file so that the VSCode node and chrome debuggers do find the right source map paths for CoffeeScript files and stop at breakpoints put in the source .coffee file?
coffee script tooling is behind because anyone who has been burned by coffee script specifically won’t go back. Meanwhile ES6 is standard and therefore tools made for it automatically have a growing audience, while coffeescripts audience is more static. Just look at MDG, they continue to support coffeescript because they once did, but they’ve all switched to using ES6. ES6 is a very clean and very readable way to write good javascript without needing to understand coffee script.
Cofeescript wouldn’t even be so bad if it didn’t have multiple points where the syntax is indeterminate. Javascript has indeterminate libraries, but coffeescript has indeterminate syntax, the result of certain syntactical elements being different if the target is a function or a standard variable. That is just unacceptable from a dynamic language. I get why it’s liked, that syntax is very clean looking, but there’s nothing wrong with the c-style syntax of javascript by itself.
Does Meteor use Babel to generate the server/app.js and web.broswer/app.js files in ES5 so that they can run today on all browsers and on Node 4 that still do not support much of ES6?
Is ES6 correctly supported by WebStorm or VSCode in terms of stopping at breakpoints in the ES6 source file through correct source maps mapping in spite of the very complex code generation process of a Meteor build? Can ES6 syntax be used in watch expressions in these tools?
Or are the most advanced debugging tools still only support ES5 syntax and thus by choosing ES6 today those of us who are not fans of the syntatic noise inherited from C (a language designed to be more reabable and concise than … assembly) get the worse of both worlds, i.e., the lack of proper debugging support of a transpiled language and the noisy syntax standard?
Almost all the new concepts of ES6 were taken from CoffeeScript, so an ES5 programmer has to learn them anyway to adopt ES6. As for clean and readable, I guess to those who learned programming in C, C++, C#, Java or PHP (i.e., most programmers) redundant delimiters and typeless variable declarations somehow help readibility.
More interesting is: [quote=“lassombra, post:31, topic:30167”]
but coffeescript has indeterminate syntax, the result of certain syntactical elements being different if the target is a function or a standard variable
[/quote]
Can you give examples of this? and of the “burning cases” associated with it?
Isnt’t the case that by using using CoffeeLint you can just determine one CoffeeScript syntax style and just stick to it?
Why?
You sound like a ex-CoffeeScripter who learned better, so thanks in advance to share your “burning” experience with the coffee.
Yes. WebStorm does a great job of working with breakpoints in Meteor ES6 code.
I think he’s just referring to how you could write:
some_obj.some_func
And it would not execute, as you wanted, but rather return a function as an object. So, you would have to write
some_obj.some_func()
I would also like to know about an actual “burning” scenario. What was just mentioned doesn’t really qualify, in my opinion.
As for breakpoints, I do TDD, so I rarely need them, if ever.
That’s pretty close to what I’m referring to, I remember a few other similar cases, but it is weird. Of course, to be entirely fair, ASI is weird too and changes the need for a line ending semicolon depending on what comes next in many cases.
The biggest issue I’ve run into for coffeescript regularly is when I want to grab a reference to a function, not execute the function. In many cases in coffeescript you end up accidentally executing the function instead, which can lead to hard to find bugs.
Javascript is weird yes, and has some bad cases, yes, but the rules are very well defined. The idea of some syntax being undefined or unpredictable at a glance is something that doesn’t exist.
In regards to the original ideas in this thread, ES6 does not needlessly obfuscate code. ES6 provides an option to write better more elegant code that is simpler and clearer. The obfuscation comes because for right now there is still a need for ES5 and rather than serve two different versions depending on the browser, babel is an effective way to move forward, while dragging the IE8s of the world kicking and screaming along.
Long story short, ES6 and Coffeescript are both transpilers currently but one is made to improve the language while having almost no learning curve, the other is made because some ruby developers didn’t want a c-like syntax in javascript while using Ruby/Haml/Slim/Whatever everywhere else. One will go away in 10 years because there is no more need for the transpilation step, the other will hold onto that build step for all eternity. Ruby is also the reason why SASS exists, Ruby developers wanted their css to look like Ruby. Basically, we invented an entire set of tools just to pander to a batch of developers who never learned c-like syntax. Why? At least SCSS (the css like syntax of SASS) is truly just a pre-processor for CSS, emitting CSS that is very predictable from the pre-processor code.
Meanwhile, ES6 still hasn’t added some very simple syntax for null-checking. Why:
if (company && company.images && company.images.logo)
? wouldn’t it be nicer:
if (company?.images?.logo)
Agreed! x100.
One thing i’ve done is accept that lo-dash is pretty much a std-lib for browser based JS. They have a function that you can call that will essentially nerf the nested property and optionally fallback to a default value (perhaps a string to prevent the code from blowing up).
eg.
import {get} from 'lodash'
// before
if (company && company.images && company.images.logo)
// after
if (get(company, 'images.logo'))
// returns undefined
and then you can also use a default like this so if it returns undefined :
if (get(company, 'images.logo', '/images/default-logo'))
100% the standard library is lacking and there are some real nice shorthands out there. Strictly speaking though, I’ve never found the number of characters involved in a test to have a significant impact on how fast I can write code.
lodash or underscore are critical I think to modern javascript and it’s sad to me that they remain two separate projects as they both offer so much but it creates its own little holy war when there are two libraries so similar.
Are there a few syntactical sugar pieces that coffescript has that javascript doesn’t? Yes. Are there some that are missing? Yes. Did Coffeescript collide with ES6? Yes. And to me that last point is the biggest reason not to use languages such as coffeescript. When the time came for the underlying language to get some pretty important features, coffeescript was wholly incompatible with many of them (especially class properties which is a very nice feature)
Though your last example makes the if a bit superfluous since the condition will always be true 