Hacker News Reader

Comment by matthewmacleod | Hacker News Reader

Mixed feelings about CoffeeScript, as ever.

ES6 obviously deals with some of the issues that CoffeeScript was intended do. That's awesome. Unfortunately, it's still difficult to go back to what seems like the relatively baroque syntax of Javascript afterwards, as someone who has a bit of a vendetta against over-syntax. SO MANY BRACKETS.

In particular, there was CJSX - JSX with CoffeeScript. Writing React components using it was an absolute joy in comparison, and helped eliminate a lot of noise – making it much more obvious what a component was doing.

But yeah, it's been hard to convince others that it's worth the investment, when honestly it's really just a personal preference at this stage.

View on HN

> SO MANY BRACKETS.

Whatever do you mean?

Didn't ES6 promise ;) to solve this?

This is true only insofar as libraries use promises, and your code uses promises. They're still pretty annoying in my experience.

There are still some other cases where the mess of brackets is overkill, other than callback hell.

> This is true only insofar as libraries use promises, and your code uses promises. They're still pretty annoying in my experience.

Promisify, or (as I prefer to) just "return new Promise((resolve, reject) => { nonPromisedStuff(...) })"?

> There are still some other cases where the mess of brackets is overkill, other than callback hell.

Like bad coding style?

I'm awaiting ES7 :D for the true solution to this problem. It'll eliminate the boilerplate of .then(function() {})` entirely. Less brackets, less ceremony.

ES7 was finalized a year ago. Everything except IE 11 supports all of it.

You meant ES2017.

HTH

And all current browsers save IE11 support ES2017 async functions.

Isn't ES6 `.then(()=>{})` ?

Or even without curly braces:

`.then(x => doSomethingWith(x));`

Promises returning promises (or async/await which is just sugar-coating for promises) solves this very cleanly in my experience

I agree. Promises have solved most our team's nesting issues.

It's incredibly clear, allows clean and concise error handling, and is easy to use.

It takes time to get those brackets right; time that adds up. That's one of the many ways CoffeeScript contributed to my own productivity over the years

Only if you're editing text with a potatoe.

Assuming you have an editor which auto wraps pararenthesis then with Coffeescript you are basically exchanging brackets for spacing with zero productivity gain, besides some features such as list comprehension and easier handling of that = this.

Additionally every JS file has to be preprocessed making debugging slightly harder and set up more involved. Every person contributing to the project has to become familiar with CS. Plus mixing both CS and non-CS files always ends up happening in my experience.

As a former CS fan, I really don't see the utility of using CS like I used to.

If you're using ES6, you're already likely doing a compilation step anyway. So I'm not too sure there's much loss.

True, I've been using Babel for ES6 when not working on chrome extensions or sites limited to early adopters which I look forward to not having to depend on. For Node you don't need Babel to use ES6 besides support for import instead of require.

I still find having to use Babel annoying.

So we're assuming that everyone only ever writes new code in a situation where auto insertion of parentheses would kick in and contribute. Don't you people have to edit existing code? Callback hell anyone?

the text editors/ides I use today have bracket matching and with eslint it's been easier to track missing/extra bracket bugs, the example you have is heavily exaggerated, nesting like that is bad code with or without brackets

It is still confusing. Look at how clear python files are for example.

My editor's colorscheme makes brackets dark gray and I don't use semicolons in JS because it's optional. It's really not that ugly. I What IS ugly is inspecting machine generated Coffeescript source code in Chrome dev tools and debugging it.

So is having to set up preprocessors whenever you want to use Coffeescript. Which is easy in Rails but a challenge in many other scenarios such as simple static sites.

Not to mention the number of projects I've joined which has a random mix of both .js and .coffee files.

I'd prefer spacing over bracket if it was natively supported in the language as it is in my favourite languages Erlang, Elixir, and Haskell. But that's not the case here.

CoffeeScript 2 will compile classes to ES6 classes, among other changes. So the output should be more readable than it was previously.

Exactly, which sort of mutes the effectiveness of this tool. Coffeesctipt 2 is already a coffee to es6 transpiler

Python would be even worse in this situation, IMO. At least brackets are visible; having to line up a bunch of indentation for that kind of nesting depth is the sort of thing that gives me nightmares at night.

Who writes JS like this?

This is something I'm left wondering. I've written a lot of JS, some of it in complex applications. I've never had this issue of mass nesting that would cause all of these brackets people here seem to be complaining about. I'd suggest that coffeescript isn't solving issues with javascript syntax, but instead is allowing the kind of code that should be refactored out to stay around for longer as it doesn't look so ugly. That's not really a good thing. Perhaps it's a good thing if the community lets it die.

You might not feel like you wrote too many brackets, but good luck convincing someone who uses none (except for hashes) that they should start. Coffeescript code is not sloppier, its more terse.

People who have not yet discovered named functions.

I built LightScript because of this; you might give it a try.

It's a rough superset of ES7+JSX+Flow, built on Babel. Integrates pretty well with a bunch of tools like ESLint, should be much more future-proof than coffeescript.

Would love your thoughts if you'd like to give it a try - http://lightscript.org

That actually looks lovely I'll check it out!

Thanks! Happy to help in the gitter chat if you have any questions - gitter.im/LightScript/Lobby

I really appreciate the thin arrow syntax.

I've work for over a year on a CS codebase and, while brackets are ugly, but I'll take visible ones over invisible ones any day.

100%. I think CoffeeScript put the cart before the horse by promising some nearly-magical block detection and then they were stuck trying to implement it. I find that CS code is very temperamental and difficult to maintain over the long term.

"No brackets, it's so pretty!" is fine, but other languages don't make what feel like random guesses as to where your delimiters are, they use a different syntax to mark the blocks.

Personally I prefer to just mark the blocks myself rather than hope that the compiler infers it correctly, whether that's done with indentation as in Python, keywords like "begin" and "end", or with C-style bracketing. I even find comparatively mild things like Ruby's inferred parentheses grating.

There's no reason not to put an opening and closing mark. You're already thinking in delimited terms when you're writing the code, there is no real extra cost to throwing in the indicators, and it makes it so much easier to figure out what's going on when you go back to debug, when you try to read the code after months, or when your text editor is trying to help you out with folding and the like.

Whether or not bracket free code is more readible might be a personal opinion. I think for people who understand Coffeesctipt well, its easier because theres less visual noise. There are many languages with optional parens, and whether or not you want to stretch the ability of the parser is up to you. Coffeescript proves that they are not necessary in order to write javascript.

> I even find comparatively mild things like Ruby's inferred parentheses grating.

I agree with everything you've written and I'd like to note that even Ruby has degenerate cases where you're forced to use parenthesis around things because the parser can't figure out what you mean.

I have an instant dislike for any language that tries hard to make code 'pretty' by removing such indicators.

And to be clear, there's a difference between a concise version of a syntax, such as C#'s lambda syntax, and creating inconsistencies in your language by trying to remove syntax that cannot be universally removed without creating ambiguities.

The former is welcome, the latter is not. Even Ruby has such degenerate cases.

And I like Ruby, but I dislike that design decision.

> I have an instant dislike for any language that tries hard to make code 'pretty' by removing such indicators.

Ah, you see, I don't, or didn't :)

I thought bracketless code would be magical, until I had to wander through nested callbacks with implicit returns.

Yeah, I think that people jump on that bandwagon just assuming that it will work magically. It is better to explicit about it if the cost is minimal. Python also strove to eliminate unsightly bracketing, but it did so by replacing the characters with a more readable delimiter, not removing them entirely.

To be fair to Ruby, most of the time when I've come across a situation where the call became ambiguous due to lack of parenthesis, the failure was obvious and easy to fix. I still think introducing that type of ambiguity into the language is an antifeature, but compared to CoffeeScript, where the automatic delimiting is non-intuitive enough that you often have to compile it down to JS to check that it's rolling everything into the right place, it's no contest.

On our CoffeeScript project, the compiled blocks would change layout even with very minor changes to spacing or code arrangement. It would've been much easier just to throw in a () and tell it what we meant!

I'm not saying it's insurmountable, but the gain just isn't worth the cost imo.

So, what you are saying is that you don't like language that have operator precedence rules so that you can omit some uses of grouping parentheses in expressions? Because that's the same level of inconsistency due to non-universal removing of markers as Ruby's permitting function-call parens to be removed when unambiguous.

What I'm saying is that anyone who's judgement is so poor as to try and argue operator precedence in this discussion isn't worth bothering with.

I've found that writing React render methods in plain CoffeeScript is actually pretty pleasant, too. I gave it a try not long ago and it came out looking pretty similar to Elm.

Yeah, I can see that. There are a few things that make it nice, like the `@` sign in place of `this, and implicit returns (which remove a bunch of boilerplate and brackets).

> just a personal preference

How does one objectively measure this? I strongly prefer to read less code, to make fewer mistakes (I.e. closing brackets).

Reply on news.ycombinator.com