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.
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 ;)
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.
This fork is alive and well, though: https://github.com/gradus/coffeecup
Maybe a mod can change the link?
: https://github.com/mauricemach?tab=activity and https://github.com/mauricemach/coffeekup/issues/110
- 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.
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.
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.
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.
* Assists with avoiding common errors in formatting
* Generally easy to learn, with thin abstraction layers
* Enforce DOM hierarchy with formatting
* 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.
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.
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 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 and it's DSL for creating HTML - it's pythonic equivalent of coffeekup and it's cute :)
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.
Is there any speed gains in terms of page weight or loading times?
It feels faster because there is no interface between you and the template language - because there is no language its just coffee script.
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.)
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:
p -> "some text here"
p -> "some text here"
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.
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.