Look at that nightmare of a rendering code and tell me you'll still want to touch that when the time comes to go back and modify it in a few months.
I had the displeasure of working with Jade on a recent project. Not only was it more difficult for humans to parse than the HTML it produced, it was also slow to execute and generally cumbersome to modify. The main purpose of its existence might just be so programmers can lie to themselves about separating code from templates, and making those templates look really sophisticated at the expense of productivity.
The battle cry "nobody should write literal HTML anymore" is not a good enough reason to do this - in fact it's not even a reason at all to begin with.
The example code in the article, well, I'm sorry to say that it's unreadable, convoluted, and huge for what it actually does. Both versions are terrible in their own way, only the JavaScript one is also deliberately sabotaged in order to really stand out as an abomination.
That being said, if there are people looking at this going "my, that does look mighty pleasant" - all the more power to you. A huge part of programming is finding technologies that map well to your brain. It just doesn't work for me at all (I needed to vent that just now, thanks for bearing with me) and I kind of hope I'm not alone.
If you don't like jade, I can respect that, and most of the time I use html for work because of factors that I can't control and it's no problem.
But you need to come to terms with the fact that your dislike of the language is caused entirely by your (I'm guessing) long experience with html, which has made you unwilling to gain proficiency in something new. Jade is objectively simpler than straight html.
the templating is subjective. i for instance prefer writing my template in the same language as it's logic.
I hope this is the case, otherwise someone somewhere thought this was the best JS code to solve the problem:
for (i = _i = _ref = this.length - 1; _ref <= 1 ? _i <= 1 : _i >= 1; i = _ref <= 1 ? ++_i : --_i) {
Well, the JavaScript is harder to read because of the colour choices and the fact that at least in part it looks to have been compiled from CoffeeScript (or something else).
Conversely, the ClojureScript is probably quite hard to read if you don't know what "peek", "reify", or "did-mount" mean.
* reify is the creation of an anonymous type instance, implementing 1..n protocols (not entirely dissimilar to an anonymous class in java). This could also have been done with a deftype (no difference in efficiency, but Om's creator seems to prefer reify):
(deftype Widget [data owner]
om/IRender
(render [this]
; render code here
)
om/IDidMount
(did-mount [this node]
; mount code here
)
[0] http://facebook.github.io/react/docs/component-specs.html#mo...
[1] https://github.com/swannodette/om/wiki/Documentation#wiki-id...
I recently converted a React project to Om and found it to be a very enjoyable exercise. However, contrary to most tweets/blog posts, my Om code ran slower than the JavaScript version, which ultimately caused me to abandon the conversion. Full disclosure, the port was a naive implementation of a single page React component which probably wasn't the best use-case for Om ( (om/transact! ...) was causing a full page re-render to the VDOM).
Om/cljs is very beautiful and concise compared to JS ... immutability rocks! If I could achieve performance comparable to JS I'd switch in a heartbeat.
The immutability of Om/cljs means that the code for determining re-renders (shouldUpdate lifecycle method) is (always?) faster than React.
By presenting Coffee's not-quite-idiomatic JS output as the counterpoint, the otherwise well made argument for Om's pleasantness is weakened.
Might be only a problem on a device like mine (S3 or Nexus 7), but it completely breaks the whole page.
1) the author tried to make it ugly. 2) the JavaScript was generated by a compiler.
Or, I suspect, both.