

CoffeeKup is markup as CoffeeScript - jonny_eh
http://coffeekup.org/

======
pbiggar
At Circle, we write all our front-end code in Coffeescript, and all our front-
end templates in Haml-coffee (<https://github.com/netzpirat/haml-coffee>). I
thoroughly recommend Hamlcoffee - its mature and reliable, and is basically
HAML but with coffeescript instead of Ruby.

So looking at this for how it compares to Hamlcoffee.

\- I dont like the arrows (we already have indentation, so it feels like the
arrows are wasteful)

\- I do like the `or` syntax (@title or "Untitled). THat said, I don't know if
I'd use it and I suspect there's a way in Hamlcoffee, but I've never needed
it.

\- I cant read this at all: `(li -> a href: '/', -> 'Home')`. I feel it is a
lot less readable than pure coffee, and much worse than hamlcoffee.

\- In the github page, they say coffeekup might not be great if "You use divs
and/or classes for everything". I could be mistaken, but doesn't everybody do
that? Is it just me?

\- Haml's biggest annoyance is trying to get commas and full-stops in. I don't
see discussed whether that is easy here.

~~~
mntmn
Regarding 1: Yes, that's not perfect. But in HAML you have to mark the
beginnings of your lines with %, - or = and such, so that's the tradeoff.

2: That's just a feature of CoffeeScript.

3: It is pure CoffeeScript. And I agree, it's the same as 1. But the example
is also a little odd. a href:'/', 'Home' should work fine.

4: Well, a matter of taste. There is the "semantic html" crowd who try to map
the classes of the "div" crowd to more diversified html5 tags, e.g. "section
header ul li span" instead of "div div div div" with different classes. I tend
to mix both approaches. HAML has the . syntax for the div-inclined, which is
nice.

5: No such problems here. But you have to deal with all the arrows ;)

~~~
pbiggar
1\. I quite like "%" - it nicely marks tags as what they are (and its at the
start of the line, not the end). Then there's '.', '-' and '=', which have
different semantics so you always know what you're looking at. Its much worse
at the end of the line, and 2 chars is unpleasant :)

3\. I guess its a part of coffee I steer clear of (and a part of ruby I
avoid). Once you have 2 or 3 names in a row, its awkward to decode the
function call ordering, so I just avoid it.

Actually, I think that that's what I don't like about this. In haml, its a
declarative syntax, and that's very restrictive (in a good way). In coffeekup,
its pure coffeescript, which means you have imperative semantics that can do
anything, and so need to be decoded. But maybe its not a problem in real-life,
but if that example is indicative, I'm happy where I am.

------
pooriaazimi
It hasn't been updated for over a year and Maurice is apparently "lost"[1]
(i.e., hasn't been seen online for over a year).

This fork is alive and well, though: <https://github.com/gradus/coffeecup>

Maybe a mod can change the link?

[1]: <https://github.com/mauricemach?tab=activity> and
<https://github.com/mauricemach/coffeekup/issues/110>

------
laurent123456
I fail to understand why would anyone want to use this. It's like a markup
language to generate another markup language, except that now you have to deal
with:

\- bugs in your CoffeeKup code

\- bugs in the CoffeeKup framework

\- bugs in CoffeeScript

\- bugs in the HTML output

\- Plus of course having to train the developers that will come after you to
maintain all this non-standard code.

~~~
pooriaazimi
If you're a rubyist (in heart), you'd absolutely, completely hate HTML and
something like this (a clean, beautiful syntax) is like Christmas present. And
if write your client-side scripts in CoffeeScript _anyway_ , then there's
really no learning curve.

~~~
lazerwalker
If you're looking for a templating language with clean, beautiful syntax, the
question is why you wouldn't use something like HAML or Jade. They don't have
the advantage of already being written in a familiar syntax, but they are easy
to pick up, and they're well-supported and generally accepted by the Ruby/Node
community rather than being an abandoned year-old code dump.

------
spankalee
I really, really dislike builder APIs/DSLs for HTML. HTML itself is a DSL for
documents, and now UIs in general, and since something like this doesn't
really add any capabilities or, very useful abstractions, that I can see, I
don't see the point.

I'd much rather write markup in markup, and then have a nice API, or no API
with bindings, for tying markup and code together, than to try to do my markup
in code.

Eventually all these template languages and DSLs will be supplanted by web
components and all the time spent building them can go to more useful things
like contributing to awesome, and inter-operable, widget libraries. Or so I
hope.

~~~
1qaz2wsx3edc
Because none of these points are valid:

* Readability

* Portability

* Assists with avoiding common errors in formatting

* Generally easy to learn, with thin abstraction layers

* Enforce DOM hierarchy with formatting

~~~
spankalee
Thanks for the sarcasm, but I'm not sure your points stand.

* Readability can be somewhat subjective. Neither Coffekup or any of the markup DSLs I've seen are inarguably much more readable than HTML. A few extra braces to closing tags do not immediately make something less readable to me, and the example given does not seem like a clean win to me. Better in some cases, worse in others, a wash overall.

* I do not think "portability" means what you think it does. Coffeekup appears to only run under Coffeescript. That makes it rather un-portable. Many other template languages have multiple implementations in many languages. That seems unlikely with Coffeekup.

* Reducing formatting errors would presumably be because of static syntax errors caught by a Coffeescript-aware editor, and dynamic errors caught by the Coffeescript compiler and JS runtime. The same is achieved with a HTML-aware editor and various available validators.

* I don't see how Coffeekup that generates HTML is easier to learn than just HTML.

* Or screw up the hierarchy because of whitespace errors. This is just the significant-whitespace debate brought to markup. If you want significant whitespace for your markup, I'm sure there are portable template languages with significant whitespace.

~~~
webjprgm
HTML is great, it's just a little more verbose.

I like PHP because I can wrap logic around HTML so that documents are
described in document markup and code is in code.

I like Mustache because I can write a document in document markup and then
pass in the variables like a MS Word "mail merge".

Using HTML means less things to learn, which is very good.

However, HTML is definitely not the perfect language. Things like HAML and
Slim are attempts to make a cleaner, less verbose document language. (However,
they are mixing the ideas of document markup with code, since they are trying
to solve "templating" together and not just one problem at a time.) So I
appreciate things like this, but I still choose not to use them unless I'm
forced to.

------
hoov
As a backend developer, I'd love to know how this is better than HAML.

~~~
treeform
The bast thing is that all control structures such as functions, classes,
conditionals, loops are just already in language you know - coffeescript. If
you use coffee script after a minute or two you can learn how to write very
complex coffeekup templates. Its also best suited for "more" logic in
templates approach then say HAML. I would only use this an a webapp where the
templates are very complex and require a lot of logic. You end up writing less
code and it ends up more organized. We use modified coffee kup like template
in rendering the hipmunk's UI. For example see the flight bars:
<http://www.hipmunk.com/flights/JFK-to-PDX#!dates=Jan15,Jan16>

~~~
jeswin
Makes sense, I am going to try it out.

I have found (in <http://poe3.com>, which uses backbone and handlebars) that
as template logic gets complicated, more and more html gets moved to backbone
views. And now the coffeescript classes contain a not-insignificant amount of
HTML. Maybe I can avoid some of that mess.

------
aroman
This is old news -- the github repo hasn't been updated in a year and I
haven't heard any news about it since then.

~~~
treeform
I recommend taking a look at DryKup: <https://github.com/mark-hahn/drykup> Its
basically a better CoffeeKup.

------
mntmn
At Spacedeck, we're using gradus' fork of CoffeeKup (CoffeeCup) for all of our
frontend templating, driven by Backbone. It works out very well for us, even
for a relatively complex application (~1 year development time). I personally
like the fact that it's "just" CoffeeScript and not another markup. We did a
little patch though to make it generate more meaningful errors when exceptions
occur, and I can say that the codebase is quite small and easy to understand.

------
solox3
I know it's not as flexible as Zen Coding (conditionals and such), but this is
just another layer of complexity to have my code misinterpreted and come out
wrong.

------
ehutch79
Is this serious?

~~~
Posibyte
I don't see why not. What's wrong with it?

~~~
ehutch79
Very subjective, but I feel like if you're going to write HTML, you should
just write HTML. (or possibly something like markup or restructured text)

I just feel like writing code to generate document markup doesn't really fit
the model of what it is. I can understand why coffeescript -> javascript fits
the same mental models though.

~~~
at-fates-hands
For me, its kind of redundant. Also, I've been mind melded into an MVC mindset
and can't see how this would be helpful to me.

Is there any speed gains in terms of page weight or loading times?

~~~
treeform
I dont have any numbers to back this up but: * templates get compiled to js *
there is no magic the code you write is the code that runs

It feels faster because there is no interface between you and the template
language - because there is no language its just coffee script.

------
alexcabrera
It's like a less elegant version of Jade.

~~~
treeform
Jade is still a language. This is just near plain coffescript.

~~~
webjprgm
I personally think CoffeeScript is ugly. I don't know why so much of the HN
internet seems to disagree.

Consequently I don't think being nearer to plain CoffeeScript is helpful at
all.

(CS leaves out too much and has the oddest tricks to save characters that
cause confusion, or sometimes force you to arrange your function parameters
the right way to best use the CS syntax. Too bad setTimeout has params in the
wrong order.)

------
sgentle
One advantage of this not really covered in the comments so far is that
something like CoffeeKup makes it very easy to mix custom code with html
generation.

As an example, I'm currently using CoffeeKup as part of a build system for
single-page websites. I wanted fine-grained control over things like whether
to inline or reference external scripts and be able to defer non-essential
chunks of markup until after page load.

It's nice to be able to take something like this:

    
    
      body ->
        div ->
          p -> "some text here"
    

And make it this:

    
    
      body ->
        defer ->
          div ->
            p -> "some text here"
    

I'm not sure CoffeeKup would necessarily be the best choice if you're just
looking for a generic template language, but I found it useful in my case.

------
tzaman
I must say, I'm having a hard time seeing any significant benefits on using
CoffeeCup/HAML/Whatever instead of plain old vanilla HTML. I mean, there's a
lot more to frontend development than just HTML, and getting to learn another
tool like this (especially in a team) doesn't cut it for me. If you want to
speed up, there are alternatives like ZenCoding plugins and whatnot.

I'm using SASS extensively, but I can see the benefits immediately, plus the
syntax is _almost_ the same, so there is less cognitive load to switch.

~~~
mntmn
I think it depends on what you use the HTML for. If you use it for its
original purpose, "Hypertext", then vanilla should be fine. If you're writing
a GUI-heavy application, HTML becomes more of a "rendering layer" and its
semantics tend to play a smaller role (YMMV). So you introduce helpers,
builders, abstractions for things like forms, menus and such (see Rails).

At that point, the PHP-esque mixing of HTML and code fragments becomes
inelegant (again, YMMV), and solutions might be sought for a more readable
markup. Bonus: no more closing tags.

------
neebz
I used it in one of my learning projects (<https://github.com/neebz/real-time-
notice-board>) and it was having troubles with html attributes having hyphens
(e.g. data-bind). I wonder if they have fixed that. Otherwise it was really
good.

~~~
mntmn
That's caused by CoffeeScript's object syntax (foo: "bar"). If you use quotes
for your case, it should work ("data-bind":"baz").

------
djbender
I can't recommend the slim template engine enough.

<http://slim-lang.com>

------
chsonnu
Next step should be a ruby DSL to generate CoffeeKup markup!

------
lucian303
because more languages are better ...

