Replace CoffeeScript with ES6

Ex-Coffeescript ,now Javascript with lot's of Python experience guy here.

The "I understand CS code much quicker" argument is a valid one theoretically, but In my opinion, it does not hold up practically that well.

CS got one thing wrong that Python got right: There are many ways to do things.

When writing CS, I understood MY CS just fine... but it always took me longer to understand the CS of other people. Sometimes even longer than JS. This is such a huge drawback, and even if there is coffeelint, for teams, this is deadly.

A lot of devs need to read a fair amount of foreign code. Even worse a lot of coffeescript writers also need to read and understand a lot of JS code.

Understanding and reading YOUR code slightly faster gets mitigated by having longer to understand foreign code.

While some JS purists fail to see that Coffeescript has some benefits, CS people also underestimate how "quickly" you can understand JS code, if you're experienced. It's all about what your brain is trained to do.

In my opinion, with ES6, I would argue for most people (ceteris paribus) it just makes sense to read and write JS exlusively, if you want to maximize output-productivity of a full, practical project.

Shaving off a couple of seconds "understand-time" of your personal, well written CS vs well written JS will just not compensate other things that will take you longer to do with CS.

> Never, ever debug on live. If you can't recreate the problem locally, you don't understand the problem yet.

I am guessing you have not been exposed to highly complex live environments. What you say is largely true but you state it as an absolute fact, which is a bit naive. Live environments tend to be far more complex than test or local environments and sometimes that complexity is what creates the bug. Sometimes the only solution is to debug live, but of course that is a last resort.

Significant indentation is enough for me to avoid Python. It just doesn't have enough to offer vs. the available alternatives without significant indentation.

It's much easier to read indentation than unindented/badly indented pairs of brackets, but you're setting up a strawman - it's not either or - and then you tear down the strawman yourself by pointing out we match the indentation anyway.

My code generally is properly indented and has start/end markers (though I mostly write Ruby, so rarely brackets), but what makes me stay away from significant indentation is that in the 30+ years I've been coding, I've never gone long without coming across situations where indentation has broken "in transit" e.g. with cut and paste between systems in annoying ways, or someone loading the code into an editor that butchers the indentation with tabs using "non-standard" tab settings.

When that happens, I'd rather "get the wrong impression" than have the code be broken.

That's one reason I want redundancy. My tools can trivially and automatically fix the result of breaking indentation when the indentation can be derived from the code.

Additionally, I want the visual redundancy, much like I find it far more comfortable to read syntax highlighted code even though it conveys no additional information.

Sometimes your problem turns out to be a problem with production hardware or wiring, or depending on interaction with external partners who may not be able to replicate their interactions accurately for your dev/test environment, or otherwise impossible for you to replicate in dev/testing without already having figured out what the problem is.

While I agree with your overall sentiment, in any kind of remotely complex environment you sooner or later come across problems that you have no sensible way of reproducing in dev, and which will require you to debug on a production environment without it saying anything about the quality of your development process.

> "With CS, it's indent and be done with it"

As others have said, it's all fun and games until two people edit the same source file, one of whom has the dangerously incorrect opinion that tabs are better than spaces :-)

I use a lot of semantic whitespace languages (CS, Haskell, Python), and it's a tradeoff: you gain in terms of redundancy, true, but there's an additional human overhead of making sure everyone's got their editors set up correctly. The larger the team, and a fortiori the number of teams, the bigger that overhead is. Smacking people about the head with PEP8 goes quite close to solving the problem in the Python world, but CS's Rubyish commitment to TIMTOWTDI militates against that.

"It's like SASS vs. SCSS. Or Haml vs. ERB. I can't, for the life of me figure out why anyone would prefer more to less."

Because HTML and CSS, despite their verbosity, are linguae francae. A CSS file is valid SCSS by definition - a less technical prototyper person can give you their code (perhaps even generated code from some wysiwig monstrosity) and you can refactor over it to remove redundancy, enforce conventions etc using the special SASS sauce. The SASS syntax does not.

A HTML file, likewise, is already an ERB file. HAML is 'backwards compatible' with ERB/plain HTML, so far as I recall, but mixing the two syntaxes is very, very ugly and a dreadful idea, and I'm not sure if it's possible to mix the two in similar template languages (Jade etc).

Point is: there is a human factor involved in picking shinier toys. I like HAML/Jade type templates, and Coffeescript for that matter, but I am far more comfortable using them on small teams or solo projects.