
No more Haml or CoffeeScript - kirillzubovsky
http://kirillzubovsky.com/no-more-haml-or-coffeescript/
======
lucisferre
So I've been having a similar discussion with people on this exact issue
(disclaimer: I actually use SLIM not HAML but same difference). From my fairly
long term experience with both I've found:

1\. Neither are particularly hard to learn, assuming you understand HTML and
Javascript reasonably well to begin with. In fact, there isn't much to these
abstractions at all. Coffeescript probably has more rough edges to be aware of
though. Which is to be expected, all programming languages have their dragons
to be sure.

2\. Both offer non-trivial gains in terms readability of the written code.

3\. Both can make future change of code non-trivially easier

4\. Both seem to offer less friction for what is a fairly trivial learning
curve.

I've never been able understand the argument that on teams using these
abstractions things makes it harder because not everyone "knows" them. I guess
my response is "what is there to know?". This may come across offensively, but
I'd be pretty dubious of anyone who struggled to "get" HAML/SLIM or
Coffeescript.

I used to hear a lot of similar arguments working in .NET for not using open-
source frameworks, things that were vastly superior or easier than the MS
ordained stuff (nHibernate, Nancy, ServiceStack, etc.). In the end that
perspective hindered the teams growth and abilities far more than it helped
them.

I also don't seem to experience this added friction people say is there. Don't
get me wrong I see the bulk of the problems that HAML/SLIM and Coffeescript
have, they're far from perfect. But I still find them more comfortable and
notably lower friction than working with HTML and Javascript directly.

~~~
coldtea
> _Both offer non-trivial gains in terms readability of the written code._

I've never seen non-trivial gains by either, either in readablity or
expressibility. A few less lines != more readable.

~~~
pjc50
Coffeescript removes the trailing `});` that stacks up when writing callback-
heavy code (such as node.js).

~~~
nawitus
Use of promises also reduces the callback "hell".

------
trustfundbaby
I hope this catches on.

I love coffeescript (not a huge fan of haml) as well, but the article is spot
on, haml has an adoption problem ... and by that I mean I could pull a guy who
can do html/css layouts off the street corner and they can figure out erb
templates in an hour or so, but with haml they're still having trouble working
with it weeks later. Thats because haml was built to solve Rails developers
problems not frontend developers problems like say less or sass was (and you
can see how those are doing).

With coffeescript, the two problems are

\- writing coffeescript is fun, coming back to make sense of what you wrote
months later is an absolute nightmare

\- debugging it is a massive PITA

Coffeescript is mostly syntactic sugar that gives you a lot of other benefits
but, again, if you want to move quickly as a dev team its one more thing for
people to learn or know when they come on line and maintaining it can be a
real hassle.

On my current team, we started out on an app that had an even split between
haml and erb templates, we stopped doing haml and only do erb now. We started
out with some coffeescript but after running into the problems mentioned
above, we don't write any new coffeescript.

That is not to say certain teams won't prosper by embracing these two
abstractions, just that in my experience the benefits aren't usually worth it.
As always YMMV

~~~
wambotron
I've found the opposite with Coffeescript as far as returning to old code.
It's clean, nicely indented, easy to follow. I don't use all of the shortcuts,
though. For example, I'd never write a plain object without including the
curly braces.

With javascript, there is SO MUCH there that it can be hard to read through.

~~~
pyrrhotech
nicely indented? Install jsbeautify plugin in sublime, on save, your codebase
will be beautiful and consistent.

Brackets, semicolons, insignificant whitespace, var keyword, and named
functions are some of Javascript's strengths. List comprehensions are nice,
but be honest, how many times per year do you use them?

I'd take JS over Coffee any day

~~~
lowboy
The lack of visual clutter like brackets, semicolons, the var keyword, and the
addition of significant whitespace are some of Coffeescript's strengths.

Some others are loop variable initialization, better hasOwnproperty checks,
destructuring assignment, null soaking on objects, string interpolation, and
array ranges.

I've never found a good case for named functions over function expressions,
other than maybe arbitrary order of source code. Even then, I usually put
functions at the top of my files before they would be used in the script's
execution. But to each their own.

I don't use list comprehensions that often.

I'd take CS over JS any day.

~~~
pyrrhotech
how about when debugging? nice to see function name in stack traces. You can
use named function expressions in JS, you can't in CS

~~~
lowboy
Yup, good point.

Apparently a future version of CS or CSRedux will have it so that this CS:

    
    
        myFn = ()->
          # function body
    

Gets compiled to this JS:

    
    
        var myFn = function myFn() {
          // function body
        }

------
bitwarrior
I've watched these precompilers come and (perhaps) go. Granted, I'm a big fan
of the likes of SASS, LESS, and tools built on those platforms such as
Autoprefixer, as those give me new tools (mixins, variables, modularization,
automatic vendor prefixes) I don't have in the "native" language they compile
into.

HAML and Coffeescript only change the syntax.

To me, this adds little value. If Javascript appears scary, spend more time
with Javascript so groking it becomes easier for your brain. Making a
tangental change to a completely different syntax seems like a wasted
investment. When debugging in the browser, you're still going to require
knowledge of JS, even with source mapping. Delving into other libraries will
still require knowledge of JS. The entire JS community is not hardened in
Coffeescript, so the pivot you make to learning Coffeescript is time _not_
spent learning JS, setting you behind when groking other source.

HAML seems to add even less. HTML is just markup, it can only ever get so
scary, and if you're in control of the source, you should strive to _not_ make
it scary. HAML seems like the worse case scenario for hand-holding.

That is to say, I'm not against precompilers that actually add something
useful. I'm in the middle of evaluating TypeScript, and depending on its 1.0
release and its community support, I may very well choose to fully adopt it.
But for me to start using your precompilation tool, you better be adding more
than just syntactical changes. If you're worried about needing tools to help
you remember to close an HTML tag, your problem isn't with the language, you
just need to become a better programmer.

~~~
tlrobinson
_" If Javascript appears scary, spend more time with Javascript so groking it
becomes easier for your brain."_

I knew JavaScript better than probably 99% of JavaScript developers. I was
skeptical of CoffeeScript until I was forced to use it for a couple weeks, and
haven't looked back since.

~~~
flywheel
You only think you knew javascript that well. Your anecdotal evidence is
unsupported by reality. You likely never really liked or used javascript as
much as a real javascript developer. Let me guess, you're "full stack".

------
kailuowang
Common, this is a vague and unconvincing article, I suspect people up voted
for it for its opinion rather than reasoning

> First, compiler languages require some learning.

Every new technology require some learning. This shouldn't be the number 1
reason not to use one.

> Second, both languages make debugging a harder process.

Haml harder to debug than html? How so? Coffeescript harder to debug
javascript? Maybe there is an extra step, but how do you weigh in the better
readability in CoffeeScript when it comes to debugging complex code?

> Lastly, there are just too many dependencies.

"Every time I touch code, I am forced to touch two levels of abstraction." I
seldom if ever need to touch the javascript file compiled from the
coffeescript. And I really don't see how come more coffeescript files is more
complex to handle than a couple of coffeescript? I can assume that you don't
manually compile them one by one right?

------
rubiquity
There's a lot of reasons to not use abstraction languages like CoffeeScript
and Haml, but the reasons the author cites are weak.

> First, compiler languages require some learning. HAML is awesome, but the
> number of people who know how to write it is small. That means every time we
> need to make a change to Scoutzie, not everyone can get tasked with updates.
> Same goes for Coffee.

I'm sorry to hear that you don't have a culture of learning and teaching other
people at your company new technologies.

> Second, both languages make debugging a harder process. When something
> breaks and I try to fix it, I can't always tell right away whether it's due
> to poorly written logic, or simply improperly written code.

Both CoffeeScript and Haml have syntax errors so you can tell whether your
error is syntax related or not.

> Lastly, there are just too many dependencies.

If you're using Rails, which it sounds like you are, the coffee-rails gem is
in your Gemfile by default. I've never had any issues with the coffee-rails or
Haml gems in 3 years of using them. I hardly notice that they are even there.

~~~
winslow
To expand on your second point. Debugging coffeescript has become pretty easy
with Chrome and Firefox supporting source maps. With livereload and coffee's
autocompile (watch & compile flags) I basically skip the build steps. For me,
coffeescript was similar in syntax to Python (our main language at work) and
it makes everything much cleaner compared to JS for big projects.

------
sergiotapia
I agree with your opinion on CoffeeScript, but HAML is so petite and small -
you can learn to use it in 15 minutes.

Granted, I don't use HAML because it's syntax is ugly; I prefer Slim. I vastly
prefer using SLIM as opposed to raw HTML with horrendous tags. Compare:

    
    
        <p><%= @user.name %></p>
    
        p= @user.name
    

We're in the future, let's use smarter tools.

~~~
tel
Is a very slight syntax change really a "smarter tool"?

~~~
sergiotapia
Yes, yes it is. Time spent on dumb things adds up specially if you do it for 8
hours a day.

~~~
tel
I think maybe it's a semantics thing. I'm not going to claim it's not a smart
choice to pick a more expressive language... I just don't know that I think of
syntactic expressivity a large enough gain to call the tool itself smart.

------
bphogan
I don't like HAML as much as I did, but one thing I do know about
preprocessors:

I can't get many HTML developers to write valid markup. A preprocessor that
won't build your HTML file until you satisfy its syntax prevents that.

And I can never accept "because learning it is hard and what we know works
fine" as a valid argument.

------
jb55
We've come to the same conclusion with coffeescript but for a different
reason. We're starting to move away from it to simplify our build process.

We have tons of little modules that are all in coffeescript that need to be
compiled to js before we run component-build. Just not having to deal with
that step would simplify everything. We're starting to value simplicity over
fancy things at scale.

Kind of made me appreciate the thesis of Go a bit more now. I was initially
unimpressed with the lack of language features in Go. Once you get to a larger
sized codebase you start caring less about fancy features and more about
agility and build times funny enough.

------
vinceguidry
A template engine for HTML is unavoidable if you're using a framework. It's
important to select the one you use carefully. I used Haml until I found Slim.
Haml syntax vagaries bit me more than Slim's did.

I love Coffeescript and use it whenever I can, for the reason that the
compiler output generated by it is better than my own Javascript. I consider
the complexity of the added layer to be worth it. 95% of the time Coffeescript
saves me time writing, and the 5% of the time spent debugging is made easier
with the tool at coffeescript.org. My javascript workflow has only been
enhanced by Coffeescript, not hurt. Then again, I don't write large, sprawling
programs in Javascript and consider it a smell when it does start getting
complex.

I can't say the same about Slim, it hasn't been an unqualified boon, but still
overall I feel it's an improvement.

------
moron4hire
Whenever I consider a language for a task, I try to ask myself what advantages
the language has towards my task. I don't try to think of the downsides of the
language at first, just the advantages.

So what does CoffeeScript _give_ me, that JavaScript does not already have? It
actually doesn't give you anything. It takes things away from JavaScript,
things like explicit variable declarations (I throw "use strict" everywhere
these days), and white-space independent syntax. It renames "function()" to
"()->". It renames "if(condition)statement;" to "statement if condition".

Regardless of whether or not you like these things, the ultimate point is that
CoffeScript, as a language, does not give me anything new, it doesn't provide
anything which which I can do things any differently than JavaScript. At least
for now, we need to know JavaScript, because there is too much in the wild to
be ignorant of it and the transpilers aren't 100% perfect yet (leaving too
many cases where you have to inspect the generated code). So why ever bother
picking up another language that is, at best, a wash in terms of productivity?

On the other hand, something like ClojureScript (which I don't use, for other,
unrelated reasons) gives me something. It gives me a Lisp-like language in
which to write client-side applications. I know people say "JavaScript is a
Lisp", but try writing good macros in raw JavaScript sometime and see how long
it takes you to blow out your brains.

Similarly, TypeScript gives me static type checking, instead of having to
hand-write all of my duck-typing checks. A much more explicit syntax for doing
object oriented programming. A module system (though I'm not very much in love
with require() style includes, I prefer namespaces).

So CoffeeScript won't likely ever be in my toolbox. Curly braces don't make my
eyes cross, and I don't understand how they could ever be such a huge
distraction to warrant brittle, white-space based syntax. You Pythonistas
confuse the hell out of me: what are you programming that _to curly brace or
not to curly brace_ is a significant concern for you?

Note that I have no experience with Haml, so I will refrain from comments.

~~~
bsder
> You Pythonistas confuse the hell out of me: what are you programming that to
> curly brace or not to curly brace is a significant concern for you?

You assume this is why people use Python instead of Jaascript. It's simply
what the ignorant latch on to as "different" when they need something to
blather about. I make just as many cut/paste errors in Python as I do in
Javascript--very few.

I use Python because I can generally count on the fact that it has what I need
"built-in". Last example I had about this was that I could open a promiscuous
socket and suck up UDP packets quite easily from Python, while doing that in
Javascript was a mess. There are lots of little examples like this.

I'm actually waiting for a replacement for all of my current "go to"
languages: C, Python, and Javascript. A language that does concurrency well
would cause me to leap from those.

~~~
moron4hire
Sorry, I didn't mean "Python instead of JavaScript", and I also didn't mean to
lump all Python users into one group. I had hoped using the term "Pythonista"
would connotate a die-hard user, one of those people who argue on message
boards at length of the great superiority of white-space syntax.

And while I don't like white-space syntax, personally, I don't get the general
debate as a whole, for the reason you mentioned: haven't made more than a
handful of copy-pasta errors in the last decade. It seems like a 6-or-one-
half-dozen issue, so if it's being used as a selling point of a particular
language (i.e. one of the more substantial differences between CoffeeScript
and JavaScript), then it's not much of a selling point at all.

Your last sentence is actually very closely to my point. Yes, the languages we
have aren't perfect, but there aren't any better alternatives yet. Give me an
alternative and I'll gladly use it. I'm actively evaluating languages as we
speak. But I need real advantage to switch from what I'm already using. A
handful of regex's in a loop over stuff I already know isn't enough.

------
mrcwinn
Happy to read this. My own gripe is open source projects that are
CoffeeScript-first. CoffeeScript is a tool. Some people like it, some people
hate it, and some people just don't get a big enough win from it to care.
JavaScript is the native language, and to expect someone to read documentation
or source code in something that might not be familiar to them is a
frightening direction or tendency.

If you are writing docs, you should be writing JavaScript.

~~~
heeton
To pose a counter-argument: should all open-source projects avoid jQuery? For
many projects, it's a huge time saver, doesn't cause issues, and plenty of
people like it. I totally agree that if you want more people to use your code,
you should consider the implications of tools like these, but often the
tradeoff is worth it.

You don't _have_ to use my code, so I'm going to use the tools that I think
give the best results.

~~~
mrcwinn
I think there's a difference between a dependency on a library, and choosing a
syntax or language. If you do not rely on jQuery, or jQuery doesn't move your
code forward, you absolutely should not depend on it. You can always spin off
a pluginized version. Of course, jQuery is as near a standard component as
JavaScript has, so I'm not surprised to see it so often as a dependency.

On the other hand, people learn JavaScript. It's the language of the web.
CoffeeScript is something some developers prefer, and others do not prefer.
Any CoffeeScript developer can read JavaScript, its native parent, but the
opposite is not true.

Therefore, I respectfully stand by my original argument. :-)

------
x3ro
First off, I do like HAML and I don't really like CoffeeScript (anymore), but
thats not the point.

What I see here is exactly what I've read in a rather old book (might've been
the mythical man month, but not sure): There'll always be those people who
don't care to wrap their heads around new ideas, because in their eyes they
don't have an advantage. E.g. in the early days, assembly developer could not
see an advantage in using a higher-level language such as C (:D), and when
FORTRAN eventually came around, C programmers didn't really want to use that
either. Why? Because if you spent time and energy on becoming proficient in
something, be it assembly or javascript, the defensive but natural position of
most people is to be skeptical of new ideas, because they diminish the value
of their knowledge. If you're an expert in writing OO-code in JavaScript, and
suddenly CoffeeScript comes around and lets everyone write "class" and be done
with it, your JavaScript OO knowledge becomes less valuable.

Bottom line, I can hardly imagine anyone who'd be able to learn CSS,
JavaScript, HTML and perhaps another backend language, including all the
quirks and weirdness associated with these technologies, and then _not_ be
able to wrap their heads around e.g. HAML, if presented with proper guidance.
The same goes for CoffeeScript, even if the learning curve might be a little
steeper than for HAML.

So are these specific technologies good ideas? I'd definitely say "yes" for
HAML, and "don't know" for CoffeeScript (TypeScript perhaps?)... For both
technologies, I agree with lucisferre:

> 2\. Both offer non-trivial gains in terms readability of the written code.

> 3\. Both can make future change of code non-trivially easier

------
vectorpush
Anyone who groups CoffeeScript and HAML into the same rhetorical category is
plainly oversimplifying and really only positing an argument against the
general use of abstractions.

HAML is so dead simple that if it takes your engineer more than a day to grok
it, you have to admit that they're probably not _yet_ cut out for anything but
a junior role. HAML has zero debugging overhead because it's not a programming
language; it's just not that hard, period. HAML does add an extra step to the
build process, but who cares? It's trivial. In a world where CI and single
command deploys are commonplace, the idea that an extra build step would
prohibit the use of any developer tool seems absurd. It reminds me of people
who argue against unit tests because "ugh, just another tool to learn", or "I
end up writing more code in tests than actual code, I just want to _ship_ ".
God forbid you actually have to learn something. While we're at it, please
avoid the use of languages that compile to machine code because who the hell
wants to deal with a linker in their build process?

Now, although I'm a huge CoffeeScript fan, CoffeeScript is an entirely
different beast, and requires a deep understanding of JavaScript to use
correctly. I can understand not wanting to devote time to teaching engineers
about the finer nuances of CoffeeScript, especially if they aren't that
experienced with JavaScript to begin with. In an ideal world, they'd pick up
CoffeeScript as quickly as HAML since in my experience, CoffeeScript creates
very readable code, especially when the script makes heavy use of anonymous
functions, sadly, it's not always that simple. However, CoffeeScript debugging
is a non-issue for an experienced JavaScript developer, CoffeeScript produces
excellent JavaScript code that is easily understood. Individuals who like to
minimize context changes can use sourcemaps.

Finally, dependencies for both tools are pretty trivial. I'm not sure how the
author has managed to introduce 100 different gems into his project in order
to support these tools, but it's certainly not a requirement.

[https://github.com/haml/haml/blob/master/Gemfile](https://github.com/haml/haml/blob/master/Gemfile)

That's like 4 gems for HAML. CoffeeScript is often distributed as a binary, so
zero gems required in that scenario. All in all, I'd say the author's case
against these tools is pretty weak.

------
mrpickles
What's worse is seeing documentation for npm modules where all the code
examples are in CoffeeScript...please make it stop.

------
ahallock
I wouldn't publish JS code in CoffeeScript, but for proprietary projects,
especially Rails, I'd use CoffeeScript, HAML, and also, indented Sass. Coming
from a different background, I was pretty resistant at first, but I think
developers need to embrace different environments fully and see what the
experience is, rather than molding it into something else or trying to force
tools that don't belong. When in Rome and all.

So, if you're going to be working in a particular environment, be committed
and embrace the experience.

------
tieTYT
The first argument is: It's easier to find people that already know how to use
a more popular language. I don't like this argument. Why not take it all the
way and drop ruby for a more popular programming language? Or, if they don't
know HTML/JS but do know ruby, why not write a ruby tool to generate HTML and
JS? Taken all the way, there's no reason to ever use a DSL.

I think that if your coworkers won't learn something new that's their problem
to fix, not yours.

------
flywheel
People have been saying this stuff since Coffeescript first started making the
rounds, but many adopted it anyway without any good reason to, and without any
critical thinking about what implications using this "made up language" would
have on their codebase and the life of their project. Coffeescript needs to
fade into obscurity, where it should have stayed to begin with.

------
badman_ting
I don't really bother with these things, for the reasons listed here. I don't
like how these concerns are brushed off, as if skepticism about these things
means you're afraid of change or new tools or whatever.

When these things work they may make your development experience slightly
nicer, but when they don't, you'll be sad about it. Just learn Javascript.

------
brandoncarl
I'm surprised that nobody seems to reference Dropbox or Github. Both companies
are well-respected, successful, good at attracting talent, and choose to use
CoffeeScript. I would wager that both generally manage programming projects
that are larger than the majority of the HN community does.

~~~
kirillzubovsky
Could you point out to evidence that they both use coffee extensively?

~~~
Spiritus
Here's the GitHub style guide:

[https://github.com/styleguide/javascript](https://github.com/styleguide/javascript)

------
olivierlacan
Haml.

