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.
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.
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)
Easy: In Javascript the if statement only fails if the condition is “falsy” (i.e. a literal boolean false, but it can also be undefined or an empty string, for example)
get(company, 'images.logo', '/images/default-logo') will either return the value from company.images.logo (which will be “truthy”) or it will return /images/default-logo which is also “truthy”.
Which means that the statements inside the if-statement will always be executed.
es5-shim is something you should include if you support IE8 as IE8’s support of ES5 is horrendous.
For linting, I use webstorm so I can’t speak to other linting tools, except to say that I’ve heard of babel-eslint being really helpful for people with atom or sublime (both excellent editors).
This points to a general issue in JS, there’s usually multiple ways to accomplish the same thing, unlike python.
As far as lodash, the main concern of using non-native methods is bundle size (web performance)? Seems like lodash/fp fixes this? Also webpack 2 has tree shaking, which I think solves the same issue, removes unused code in lodash.
I think we as a community should simply write a babel plugin for nicer null-checking syntax, it’s probably simple enough. I asked about it on babel forum, but no answer on the complexity of this. Why wait around until the committees get around to it?
