CoffeeKup is markup as CoffeeScript(coffeekup.org)
coffeekup.org
CoffeeKup is markup as CoffeeScript
http://coffeekup.org/
17 comments
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.
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:
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"
body ->
defer ->
div ->
p -> "some text here"
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.
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.
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.
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.
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.
Next step should be a ruby DSL to generate CoffeeKup markup!
Is this serious?
I don't see why not. What's wrong with it?
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.
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.
I agree with you if you need a template for a blog or sales pages or some other light markup. But if you have very complex HTML that renders controls, graphs, crud - dense complex things which are less HTML and more of rendering commands in form of stacked divs. Then this wins out.
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?
Is there any speed gains in terms of page weight or loading times?
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.
It feels faster because there is no interface between you and the template language - because there is no language its just coffee script.
As a backend developer, I'd love to know how this is better than HAML.
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
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.
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.
It's like a less elegant version of Jade.
Jade is still a language. This is just near plain coffescript.
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.)
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.)
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.
I recommend taking a look at DryKup: https://github.com/mark-hahn/drykup Its basically a better CoffeeKup.
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.
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.
- 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.
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.
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.
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.
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.
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.
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.
[deleted]
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
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
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.
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.
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
* Readability
* Portability
* Assists with avoiding common errors in formatting
* Generally easy to learn, with thin abstraction layers
* Enforce DOM hierarchy with formatting
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.
* 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.
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.
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.
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 :)
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-apibecause more languages are better ...
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.
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.
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 ;)
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 ;)
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.
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.
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.
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.
That's caused by CoffeeScript's object syntax (foo: "bar"). If you use quotes for your case, it should work ("data-bind":"baz").