CoffeeKup is markup as CoffeeScript

http://coffeekup.org/

by jonny_eh • 14 years ago

66 41 14 years ago

coffeekup.org

ehutch792• 14 years ago

Is this serious?

Posibyte• 14 years ago

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

ehutch792• 14 years ago

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.

codewright• 14 years ago

https://github.com/weavejester/hiccup

hoov• 14 years ago

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

treeform5• 14 years ago

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

jeswin2• 14 years ago

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.

alexcabrera• 14 years ago

It's like a less elegant version of Jade.

treeform5• 14 years ago

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

webjprgm2• 14 years ago

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.)

aroman• 14 years ago

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.

treeform5• 14 years ago

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

solox3• 14 years ago

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.

laurent123456• 14 years ago

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.

pooriaazimi2• 14 years ago

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• 14 years ago

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.

hayksaakian• 14 years ago

Honestly I prefer embedded ruby and rails helpers plus JavaScript and HTML where appropriate.

To me ruby's terseness makes sense as its an independent language, but something like coffeescript as well as haml and the OP's thing just feel like extra baggage and an arbitrary abstraction.

jeswin2• 14 years ago

1, 2 & 4: You could _probably_ write all of CoffeeKup in a couple of days. The concept isn't complicated enough to have so many bugs.

3: CoffeeScript- After using it as my primary programming language for more than a year, I have come across exactly ZERO compiler bugs. It is pretty popular on GitHub, and there are enough eyes looking at it to be called a safe, mainstream language.

pooriaazimi2• 14 years ago

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

spankalee2• 14 years ago

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• 14 years ago

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

spankalee2• 14 years ago

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.

klibertp• 14 years ago

I disagree completely, or in large part at least.

There are places where using any DSL designed for building HTML is not that great of an idea, for example when using external template files or writing large chunks of simple HTML.

However, there are necessarily places where you need small snippets of HTML embedded inside your JS/CS code and where it's not worth creating external file for it. Then you have two choices - either have your snippet as a long string (with ugly manual concatenation if it spans multiple lines in JS), which introduces another language inside your JS file or, on the other hand, to use programmatic builders of DOM. In a context of small script this would have only advantages were it not for extremely verbose default DOM API, but this particular problem was solved many times now, for example in MochiKit[1] quite a few years ago - and now in CoffeeKup.

I use both types of generating markup - if it has more layout elements than embedded data I use external template files, however if it contains many more logic specific elements, like variables and class or id names I tend to generate it programmatically. Terseness of such approach makes modifying it easier and faster and being able to use a full blown programming language instead of constrained templating one makes it much more efficient to write in the first place.

Also, I'd like to point everyone to Nagare[2] and it's DSL for creating HTML[3] - it's pythonic equivalent of coffeekup and it's cute :)

    [1] http://mochi.github.com/mochikit/doc/html/MochiKit/DOM.html
    [2] http://www.nagare.org/
    [3] http://www.nagare.org/trac/wiki/PresentationTier#imperative-dom-building-api

lucian303• 14 years ago

because more languages are better ...

djbender• 14 years ago

I can't recommend the slim template engine enough.

http://slim-lang.com

pbiggar2• 14 years ago

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.

mntmn5• 14 years ago

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 ;)

mntmn5• 14 years ago

After digging through the discussion and links and this comparison, and if I had to choose something for a new project today, I might take a really serious look at Jade, though. No arrows, no percents, and very thorough discussion of the features (and the compiled output) on its github page.

pbiggar2• 14 years ago

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.

neebz• 14 years ago

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.

mntmn5• 14 years ago

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

mntmn5• 14 years ago

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.

tzaman• 14 years ago

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.

mntmn5• 14 years ago

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.

IsaacL• 14 years ago

I agree - don't get me wrong, I can see the value of stuff like HAML, but my experience of using it is that a lot of the time it saves is outweighed by the extra time spent trying to debug the extra abstraction layer.

chsonnu• 14 years ago

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

sgentle• 14 years ago

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.

CoffeeKup is markup as CoffeeScript

Related Stories