With Vue.js you can use Coffeescript (alongside others) as well as SCSS, Pug, etc in single file components using lang="coffee" attribute in the script (or style or template for the others) tag. Need to add a couple more dependencies to your package.json but it works like a charm.

https://vuejs.org/v2/guide/single-file-components.html

I loved CoffeeScript, but I felt it was a double edged sword.

I would still use it though, if there were JSX style xml/html tags. But React changed everything for me and as a full stack dev, I can use only few frameworks on one level.

Edit: Ok, JSX is now supported. http://coffeescript.org/v2/#jsx

And I'm glad they broke the different behaviour of =>. It might need a fix in a lot of code bases, but this price is cheaper than having the mental burden of it.

I personally can't stand jsx, and coffeescript makes it so much nicer to avoid when using React. It's almost like haml / slim / jade / pug if you know what I mean.

I wrote a comparison about it a couple years ago: http://rapin.com/blog/2015/02/03/reactjs-with-coffeescript/

I'm not doing much react these days (cough elm), but I think it's still mostly relevant.

Elm... And not to forget PureScript... and to a lesser extend ReasonML (by which you can still use React and JSX)... and Haskell/GHCJS. There are quite a lot of ways to seek refuge from both type scarcity and the "semicolon" line noise that was mentioned.

Here some benchmarks for several of the FWs that are popular in these languages (Elm has the FW built-in, ReasonML-React is missing but should be close to React.js).

https://medium.com/@saurabhnanda/benchmarks-fp-languages-lib...

Yeah, Elm is the bomb! Had to grin when I saw your comment. I am really happy with this refactor of Coffeescript but Elm is what I do.

I'm not a big fan of the new =>, it means the arguments variable will have parent scope in => but not in ->, it kind of erodes into coffeescript's elegance/consistency imho, unless I'm missing something ?

I never used => but when JavaScript introduced the fat arrow and made it different from the fat arrow in CoffeeScript, this introduced a mental barrier for me. By definition, the JavaScript fat arrow is the important one to know.

You can always add an splat to use instead of arguments:

    (args...) =>

Sure, but there used to be a strong performance advantage when using the arguments variable with function.apply, also editing arguments' values affected named parameters' values (not sure that's desirable, but you know, semantics)

i also don't use CoffeeScript because of any 'feature' it has over standard JS but instead because of its concise but expressive syntax. it's less about what it does have/do, and more about what it doesn't have/do.

some small aspects of CS i forgo because they (in my opinion) are a little too concise such that they sacrifice readability, but all in all it has my favorite syntax of any language.

Exactly.

I personally think calling .map() on an array is more readable than an array comprehension. But since CS is "just JavaScript" you are free to use the native JS array methods (and even more elegantly, at that).

list comprehensions was exactly what i was talking about :) however i replace them with lodash and ramda, which benefit enormously from CS's lambda syntax

I wish this line of thinking was more common. So many people feel forced to use parts of a language when you don't have to.

CS breaks the ternary ?: operator which is a big headache for me.

Everything is an expression. Including if statements. There is no need of such syntax abominations.

Bingo. Remember when you first first learned the ternary operator syntax? I recall thinking something along the lines of, "Wow, that's cryptic!"

    result = if condition then success else failure

Sure, but other coffee operations like x||=5 are also abominations. Brevity and purity are often at odds and the choices made by a language can be arbitrary.

I felt the same way when I switched from CoffeeScript to TypeScript but the type checking was worth all the braces, returns and lack of existential operator. If CoffeeScript added an (optional) type system I'd switch back in an instant.

It’s not elegant, but there is a way to do type checking in CoffeeScript: http://coffeescript.org/#type-annotations

This is cool! That being said, it would be very nice to have (optional) syntactically more beautiful type annotation. I assume Flow must be compatible with regular javascript, but CoffeeScript could take more flexible approach. I have no idea what the actual syntax could be, though.

Thanks for the link. :)

But wow, "not elegant" is an understatement.

> If CoffeeScript added an (optional) type system I'd switch back in an instant.

The home page talks a little about achieving this by using Flow annotations in Coffeescript source and then having the build system pass the Javascript output to Flow: http://coffeescript.org/#type-annotations

That would be really nice, but CoffeeScript will probably not be adding types unless they start adding them to JavaScript.

It is a dilemma, but so far I have gotten by without type-checking.

Well, guess it's time for someone to build yet another layer of abstraction by writing a typed superset that compiles-to-CoffeeScript then!

(I'm joking, but actually.. why not?)

call it ToffeeScript - a dialect of CoffeeScript that transpiles to TypeScript?

I'm afraid you're a few years too late!

https://github.com/jiangmiao/toffee-script

You might like LightScript: http://lightscript.org

Good interop with Flow isn't quite there yet, though.

> cannot imagine going back to semicolons

Actually, Javascript does not require semicolons to be present. If you skip them, the only edge-case is when you try to start your line with `[` or `(`. In that case, you can prefix the line with `;`.

I like consistency. And I am paranoid. When I write JS, I always include semicolons. When I write CS, it is a non-issue.

> And I am paranoid

You should write tests when building a project in a dynamically typed language to alleviate some paranoia anyway. As long as you have decent test coverage and use a decent linter/formatter such as StandardJS[0] or prettier[1], you'll be fine.

[0]https://standardjs.com/ [1]https://github.com/prettier/prettier

Yeah, if your linter/build tool can't handle Javascript that doesn't have semicolons, it should be considered fundamentally broken and/or incomplete.

So the question to me becomes, if the build tool doesn't correctly parse the JS that's lacking semicolons, should you really trust that build tool with the rest of your code? You already know at that point that it doesn't handle your otherwise-valid semicolonless JS correctly.

It must be said though that CS has its own headscratchers in terms of parsing, if you choose to leave off all optional punctuation.

I agree. With great power comes great responsibility. Just because you can leave out all punctuation with CoffeeScript, it doesn't mean you should.

I consistently don't use semicolons in JS. It's just noise.

Omitting semicolons breaks the "delete a line in isolation" rule, unless you begin the line with a semicolon instead. Which is even noiser than just having them at the end of the line, where they are unconsciously glossed over by anyone who's ever worked in a language with C-derived syntax.

I hear this a lot, but in ~4 years writing JavaScript without semicolons, I've had to do this maybe two or three times. I just don't feel like starting a line with [ or ( is very common, to the point that it's a complete non-issue to me.

In the majority of cases you can't "delete a line in isolation", because it's part of a program. You have to look around and understand what the impact of deleting that line will be -- and modify nearby lines as necessary.

I have my VSC set up to automatically format and insert semicolons when I save. Saves a lot of hassle.

And with Typescript (or a linter, I guess) you would get a nice red line on that 1 out of a million line where a ; is needed.

; are eyesores to an already fairly technical debt heavy/bloated language.

There is a nasty edge case if you concatenate scripts and use an IIFE in a script

There's more than just those edge-cases, but the others are rare in practice. They include +, -, `, < (JSX), ::, / (regex) and maybe a few others.

There's also some odd ASI issues within class bodies.

https://github.com/prettier/prettier/pull/1129 can be a useful reference (and tool!)

also `{` after a return without value

I feel very much the same. My first language is Ruby and CS just clicked.

I continue using it in my Vue projects and it's a pleasure.

I appreciate the work the team has put into bringing elegance and brevity to my daily life.

Might I suggest trying out JavaScript Standard Style [0]? It has editor plugins and a CLI tool for linting.

You can write JavaScript just fine without semicolons. I used to be in the same camp, but Feross eventually convinced me to try dropping em. Despite being cautious and a bit skeptical, I tried it out in a few projects by removing all semicolons with a search and replace. In every single case, I encountered zero issues.

[0] https://standardjs.com

Maybe it's just me, but I can't imagine dealing with scope without those little curly braces. They give a definitive beginning and end I can see, rather than trust my indents are correct. But maybe I just didn't give Coffeescript enough time to get used to it.

It's easier when you use something like Prettier which formats the code for you, same workflow as coffeescript except less work and possibly more readability.

I just started a new project and decided to go back to the indented Sass syntax as well. Makes a nice compliment with CoffeeScript, Halm, Slim, etc.