6 ms·

The pleasantness of Om

63 points by danielszm 13y ago

bshimmin 13y ago
> Is it a rhetorical question were I to ask which of the two versions, Om + Clojurescript vs vanilla JavaScript, looks more pleasant? 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.
- masklinn 13y ago
  * did-mount is a mapping to React's componentDidMount[0] lifecycle method (and, in Om, part of the IDidMount protocol[1]) * 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 ) * peek's a bit more complex because it requires knowledge of interesting features (?) of Clojure collections: all clojure collections are immutable, and often built with conj(oin). conj "adds an item to a collection", but where it does so depends on the collection (and its efficiency profile): (conj '(1 2 3) 0) -> '(0 1 2 3) but (conj [1 2 3] 0) -> [1 2 3 0] (lists can be efficiently extended from the head, vectors from the tail). `peek` essentially returns the last conj'd item, so on lists it's equivalent to `first`, on vectors it's equivalent to `last` (but faster) [0] http://facebook.github.io/react/docs/component-specs.html#mounting-componentdidmount http://facebook.github.io/react/docs/component-specs.html#mo... [1] https://github.com/swannodette/om/wiki/Documentation#wiki-ididmount https://github.com/swannodette/om/wiki/Documentation#wiki-id...
Udo 13y ago
I know the use of object-to-HTML-mappers is only going to grow from here on out, but I really don't see the appeal in most cases where pure HTML would have been a perfectly readable and lightweight choice. We're becoming so scared of angle brackets that we seek refuge behind object-like constructs that are nothing but yet another impoverished and leaky abstraction layer above an already abstract markup language. 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.
- benaiah 13y ago
  It actually looks much more pleasant than HTML. The syntax is almost identical, except that HTML is much more verbose and difficult to read. This is a very different beast from Jade - Lisps translate to HTML very easily and transparently.
  - mercurial 13y ago
    I'm not the world's foremost Lisp advocate, but you're absolutely right. It's even better than HTML in the sense that you don't have the "sometimes close the tag, sometimes not close the tag" inconsistency issue.
- paulwithap 13y ago
  Weird. I've come back to our Jade templates months later, thankful I decided to use to Jade. My only beef with it at the time was the lack of documentation, but that seems to have improved since.
- dustingetz 13y ago
  The difference is that a traditional approach requires you write code that updates your templates (the function `update` in his javascript example). The React version has no analogous logic. So you end up writing less code, and the code you do need to write is simpler.
- catshirt 13y ago
  "nobody should write literal HTML anymore" isn't really relevant. React actually goes out of it's way to enable HTML syntax with JSX. the templating is subjective. i for instance prefer writing my template in the same language as it's logic.
- IanCal 13y ago
  > only the JavaScript one is also deliberately sabotaged in order to really stand out as an abomination. 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) {
deleted 13y ago
[deleted]
brandonbloom 13y ago
I'm a huge proponent of both ClojureScript and Facebook's React. However, this is a severely broken comparison.
- jbeja 13y ago
  Its give me sympathetic shame.
stevejohnson 13y ago
Your post content keeps moving up and down when the ticker changes size. Makes the post unreadable.
Cless 13y ago
That JavaScript code is ugly because either: 1) the author tried to make it ugly. 2) the JavaScript was generated by a compiler. Or, I suspect, both.
nickfargo 13y ago
The "looks more pleasant?" test can be valid only between cljs/Om and the CoffeeScript from which the generated JS was compiled. By presenting Coffee's not-quite-idiomatic JS output as the counterpoint, the otherwise well made argument for Om's pleasantness is weakened.
- elwell 13y ago
  yeah, it's riddled with '_ref's and the like.
elwell 13y ago
Widget delays the load of the rest of the page.
jah 13y ago
Om and React are cool, but this comparison is disingenuous. The author should have compared the Om implementation to a native (JS) React implementation. 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.
- bostonOU 13y ago
  Is your project open source? I'd love to see what you're doing. From my understanding of React/Om, Om shouldn't cause a full re-render if React wouldn't. The immutability of Om/cljs means that the code for determining re-renders (shouldUpdate lifecycle method) is (always?) faster than React.
twfarland 13y ago
Om looks interesting for more complex stuff, but I agree with others that the jquery version shown for comparison is a bit baroque. Here's a simpler one for comparison https://gist.github.com/twfarland/9285304 https://gist.github.com/twfarland/9285304 Short, magic-free, and sufficient for something this simple.
darklajid 13y ago
That sample widget was not a good idea. Tried reading the article on mobile & tablet, but I cannot: Every iteration showcasing a different testimonial changes the height of the widget, causing the _complete_ article to jump up and down. Might be only a problem on a device like mine (S3 or Nexus 7), but it completely breaks the whole page.

63 points by danielszm 13y ago

> Is it a rhetorical question were I to ask which of the two versions, Om + Clojurescript vs vanilla JavaScript, looks more pleasant? 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.

masklinn 13y ago
* did-mount is a mapping to React's componentDidMount[0] lifecycle method (and, in Om, part of the IDidMount protocol[1]) * 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 ) * peek's a bit more complex because it requires knowledge of interesting features (?) of Clojure collections: all clojure collections are immutable, and often built with conj(oin). conj "adds an item to a collection", but where it does so depends on the collection (and its efficiency profile): (conj '(1 2 3) 0) -> '(0 1 2 3) but (conj [1 2 3] 0) -> [1 2 3 0] (lists can be efficiently extended from the head, vectors from the tail). `peek` essentially returns the last conj'd item, so on lists it's equivalent to `first`, on vectors it's equivalent to `last` (but faster) [0] http://facebook.github.io/react/docs/component-specs.html#mounting-componentdidmount http://facebook.github.io/react/docs/component-specs.html#mo... [1] https://github.com/swannodette/om/wiki/Documentation#wiki-ididmount https://github.com/swannodette/om/wiki/Documentation#wiki-id...

Udo 13y ago

I know the use of object-to-HTML-mappers is only going to grow from here on out, but I really don't see the appeal in most cases where pure HTML would have been a perfectly readable and lightweight choice. We're becoming so scared of angle brackets that we seek refuge behind object-like constructs that are nothing but yet another impoverished and leaky abstraction layer above an already abstract markup language. 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.

benaiah 13y ago
It actually looks much more pleasant than HTML. The syntax is almost identical, except that HTML is much more verbose and difficult to read. This is a very different beast from Jade - Lisps translate to HTML very easily and transparently.
- mercurial 13y ago
  I'm not the world's foremost Lisp advocate, but you're absolutely right. It's even better than HTML in the sense that you don't have the "sometimes close the tag, sometimes not close the tag" inconsistency issue.
paulwithap 13y ago
Weird. I've come back to our Jade templates months later, thankful I decided to use to Jade. My only beef with it at the time was the lack of documentation, but that seems to have improved since.
dustingetz 13y ago
The difference is that a traditional approach requires you write code that updates your templates (the function `update` in his javascript example). The React version has no analogous logic. So you end up writing less code, and the code you do need to write is simpler.
catshirt 13y ago
"nobody should write literal HTML anymore" isn't really relevant. React actually goes out of it's way to enable HTML syntax with JSX. the templating is subjective. i for instance prefer writing my template in the same language as it's logic.
IanCal 13y ago
> only the JavaScript one is also deliberately sabotaged in order to really stand out as an abomination. 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) {

deleted 13y ago

[deleted]

brandonbloom 13y ago

I'm a huge proponent of both ClojureScript and Facebook's React. However, this is a severely broken comparison.

jbeja 13y ago
Its give me sympathetic shame.

stevejohnson 13y ago

Your post content keeps moving up and down when the ticker changes size. Makes the post unreadable.

Cless 13y ago

That JavaScript code is ugly because either: 1) the author tried to make it ugly. 2) the JavaScript was generated by a compiler. Or, I suspect, both.

nickfargo 13y ago

The "looks more pleasant?" test can be valid only between cljs/Om and the CoffeeScript from which the generated JS was compiled. By presenting Coffee's not-quite-idiomatic JS output as the counterpoint, the otherwise well made argument for Om's pleasantness is weakened.

elwell 13y ago
yeah, it's riddled with '_ref's and the like.

elwell 13y ago

Widget delays the load of the rest of the page.

jah 13y ago

Om and React are cool, but this comparison is disingenuous. The author should have compared the Om implementation to a native (JS) React implementation. 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.

bostonOU 13y ago
Is your project open source? I'd love to see what you're doing. From my understanding of React/Om, Om shouldn't cause a full re-render if React wouldn't. The immutability of Om/cljs means that the code for determining re-renders (shouldUpdate lifecycle method) is (always?) faster than React.

twfarland 13y ago

Om looks interesting for more complex stuff, but I agree with others that the jquery version shown for comparison is a bit baroque. Here's a simpler one for comparison https://gist.github.com/twfarland/9285304 https://gist.github.com/twfarland/9285304 Short, magic-free, and sufficient for something this simple.

darklajid 13y ago

That sample widget was not a good idea. Tried reading the article on mobile & tablet, but I cannot: Every iteration showcasing a different testimonial changes the height of the widget, causing the _complete_ article to jump up and down. Might be only a problem on a device like mine (S3 or Nexus 7), but it completely breaks the whole page.