But for the folks who still do — or have existing codebases — this update is for you.
I hope that this release (and hopefully future releases) will help to keep CS alive. Thanks to all contributors!
To parent post, why should we settle for "good enough"?
Because it's an actual standard and benefits from wider mindshare and support.
If anyone wants to take a look it's at tmzt.github.io/isymtope and github.com/tmzt/isymtope
The #cleanup-symbols branch is much further along and has a mostly working TodoMvc.
i understand the problems these tools are trying to solve, but i don't like that you have to learn two (or more) grammars and syntaxes, and the quirky interactions between them, to get those benefits (because you can't debug one without debugging the other). it's a lot more cognitive overhead for what amounts to a little syntactic sugar.
standard es-whatever javascript needs to be "good enough", and, despite my disdain for using coffeescript, the improvements that coffeescript induced in javascript are heartily welcomed.
This isn't really accurate with respect to meta languages like SCSS that add new features not present in the underlying language, like variables.
You really are missing out on a lot by not using the meta languages.
Well, this is how a lot of JS (if not most) is done today anyway.
These days we have typescript as another option, and I feel like there's more gains from that than the syntactic niceness of coffeescript.
Before anyone tells me, yes I know the semantics are slightly different, but muddling the semantics with arcane syntax is not an optimal solution.
As for () =>, it can make a big difference in scenarios like `myArray.map(a => a.foo)` versus `myArray.map(function(a) { return a.foo })`
I can't think of any other examples. Closures get used heavily in JS and arrow functions do make their use quicker and more concise, as well as fixing `this`. Compared to other languages like Scala, OCaml, Elm and Haskell, with symbols for functional combination and pipelining, pattern matching, and whatever you call the thing where you can miss out parameters and use underscores in function bodies in Scala ... JS is relatively light on symbols.
All these things are irrelevant today.
1/ Most of CS features are supported by javascript
2/ ECMASCRIPT spec is big and complex. Learning another syntax on top of something every front end developer should know is a wasted effort in my opinion.
And for loops (which double as list comprehensions). And the existential operator. And "this." shorthand. Among other reasons. To my team it's also more clean-looking than Python (which used to be my favourite language), esp. when using a good syntax highlighter like Atom's (or at least that differentiates function calls, like Github's).
Yes, there's not much difference now from ES6 regarding features, but for some of us it's still worth it.
It really is a matter of taste, but the large majority of us didn't like it. It is pretty, but I felt like fighting against the language all the time (implicitly returning an bracketless object is not something that's easily readable)
In my experience it has only been a problem when porting existing code bases. We only had to be a bit careful putting a return after a for loop at the end of a function so it doesn't build a list unnecessarily (otherwise implicit returns of unused random values don't hurt). For clarity, one of the few rules we have is to use return explicitly when a function is more than a single expression.
> objects without brackets
The language allows it but it doesn't mean you must use them. We have a loose style guide where we forbid a few confusing uses (like bracket-less one liners or returned objects). So loose it's shorter than this comment.
> no spread operator
It always had a spread operator (except for the first month of life). It's just called splat instead of spread, like in Python. Now it also allows ES6 syntax which is very similar (...foo vs. foo...).
> significant whitespace
That's not a bug, it's a feature ;)
> no variable declaration keyword
In the last year or two, that only bite us once. If it's more frequent than that your functions are way too long.
But as you say, it's a matter of taste.
however i like to point that our entire codebase, CS, JS, TS, Python, Java, Swift, 100% of it already has significant whitespace.
...it's just that the JS/TS/Java also have curly brackets.
The end result (or arguably, driving force) is that even in languages where whitespace isn't significant, people read the whitespace, not the curly braces. So the curly braces are basically redundant noise.
I agree about { } being mostly noise but I think they are the lesser evil. I'm making most of my money with Python and I still believe significant whitespace is a very bad idea. The Ruby alternative of using end is better even if not super elegant (and Ruby is my language of choice). It's on par with curly braces. After 30+ years of programming I still have to find a satisfying solution to the problem.
This could easily be fixed by adding a -!> operator that disables implicit returns, but no, they are so opinionated that a change like that will ruin their perfect little universe. I know that there are forks that add this sort of functionality among fixing some of my other gripes with CS but my point still stands: I'm not going to invest my time into a cult.
The old joke was that Perl is a write-only language, and CoffeeScript et al are essentially thought experiments for how deep into the write-only abyss people are willing to plunge as a non-joke. It's no mystery that CS primarily attracts people who heavily discount the importance of long-term maintainability.
The core issue seems to be that some people have conflated prescience with elegance. We must stop deluding ourselves into pretending there are languages that can read our minds. Put your intent in the code, avoid ambiguity. If the answer is not obvious and consistent, do not rely on either the computer or the human to extract your intent from the ether.
It's not that ES6 is good enough; it's that CoffeeScript is actually "bad".