Live data from Hacker News

Faster, Better DOM manipulation with Dommy and ClojureScript

blog.getprismatic.com

31–40 of 51 posts

Re: Faster, Better DOM manipulation with Dommy and ClojureScript

#31
post #20
post #10

This is super impressive. I'm going to use this for my frontend work now. On a side note, what's the idiomatic structure, or "design pattern" for cljs front end code? I would assume something based on MVC, with models comprising of atoms with watches, Views consisting of hiccup templates and controllers gluing dom events to models and views. Am I close?

I'm not sure there's an agreed upon design pattern. At Prismatic we've adopted a component-based system where a component is essentially the MVC for a single logically-grouped part of the application. Its defined as a record that binds its own events and renders markup from it's template. We try to push mutability and asynchronous functions (xhr, file io, etc.) as far up as possible to avoid unnecessary state manipul…

I'm extremely interested in this component based system -- I'm currently working on a project in the Seaside framework for Smalltalk and have fallen in love with the composability offered by this approach. However, I'm also a fan of Clojure, and it also seems like Clojure has a stronger community at this time. I'd be very happy if you release this at some point!

Re: Faster, Better DOM manipulation with Dommy and ClojureScript

#32
post #19
post #10

This is super impressive. I'm going to use this for my frontend work now. On a side note, what's the idiomatic structure, or "design pattern" for cljs front end code? I would assume something based on MVC, with models comprising of atoms with watches, Views consisting of hiccup templates and controllers gluing dom events to models and views. Am I close?

We internally have a nice component/widget abstraction we use which is not quite MVC, but we think cleans up a lot of web development. We will release in the near future once we perfect it.

Are you going to re-release the stuff you yanked off your github?

Re: Faster, Better DOM manipulation with Dommy and ClojureScript

#33
post #26

Earlier quoted context omitted.

Did the speedup of script execution have other costs? One would imagine that using Clojurescript would incur some other costs somewhere. This feels like a free lunch somehow.

It's incompatible with standard Javascript libraries, which is why you would use Dommy because you can't use jQuery. The ClojureScript compiler is also fairly slow (due to google closure compiler I think) so even with a running jvm it takes several seconds to compile small example files. To slow for me so I switched back to CoffeScript which is lightning fast.

"It's incompatible with standard Javascript libraries, which is why you would use Dommy because you can't use jQuery."

Not true.

    (def $ js/jQuery)
    (.append ($ "body") "hello world")
The reasons you'd use Dommy over jQuery are outlined in the original post.

Re: Faster, Better DOM manipulation with Dommy and ClojureScript

#35

Earlier quoted context omitted.

Not yet, but it's theoretically possibly with all the groundwork that's already been done. See https://github.com/mozilla/sweet.js/issues/12 So I should have said syntax-rules (for now). My bad!

Seems like you would still need to provide something like syntax objects and a special API to manipulate them?

This involves a longer discussion, and I'm not sure what Tim is thinking along those lines. Suffice to say, Clojure's macros are always going to be the best, but I have pretty high hopes that you can get 95% of the way with sweet.js. :)

Re: Faster, Better DOM manipulation with Dommy and ClojureScript

#36
post #22

Interesting, but I'm not sure how appropriate it is to be comparing it to jQuery in such a head-to-head fashion such as by saying "15x slower", etc. Does Dommy offer the same features (including the browser support) that jQuery does? If not, then you're just comparing apples to oranges, and it doesn't sound like it does (or even plans to) on account that it sounds like there are design decisions that separate the two…

> Does Dommy offer the same features (including the browser support) that jQuery does?

No, currently Dommy has a smaller feature set that we think covers a majority of use cases, while maintaining reasonable browser support. Our general philosophy is to add functionality as we need it or others request it. I don't think this makes the comparison invalid. We're comparing the general use cases (selectors, basic dom manipulation, etc.) that any DOM library should have. Can you point out a specific comparison that doesn't apply because of api differences or browser support?

> wouldn't it be more accurate for the selector testing to actually test against Sizzle[1]?

Part of the point is to show that you can achieve the same elegant chaining-like syntax as jQuery without wrapping selections, so maintaining the wrapped jQuery selectors are important for comparison.

> Other features aren't even present in jQuery, such as templating, and so I'm not sure why you'd even compare that.

The point of the templating comparison is to show that macros can provide a significant performance boost while maintaining a sane syntax.

Re: Faster, Better DOM manipulation with Dommy and ClojureScript

#37
post #28

>> Again the time saving comes from macros moving the work of parsing the template data structures from runtime to compile-time and directly generating efficient JavaScript. If it ends being javascript string in the ends, how is it 7x faster (or whatever number)? I mean, sure the compiler could optimize a part of my code, but other javascript compiler could do it to.. right? Although I find the Clojure example very s…

Re sort-by: the point there was to show how Dommy gets for free "features" that have to be added to jQuery and contribute to its code size.

Re one/map: you can still do operations on sets of 0, 1, or any number of elements, without knowing how many, by always doing map. There's nothing to keep track of, everything always only works on one object, so you're explicit about whether you're operating on exactly one object, or whether you don't care how many objects you're operating on. The latter is just as convenient as jQuery; the former is safer and deliberate. In jQuery, on the other hand, you have to keep track of what works on one object and what works on multiple objects: .text() and .text('a string') are asymmetrical, for example.

Re: Faster, Better DOM manipulation with Dommy and ClojureScript

#38
post #33
post #26

Earlier quoted context omitted.

It's incompatible with standard Javascript libraries, which is why you would use Dommy because you can't use jQuery. The ClojureScript compiler is also fairly slow (due to google closure compiler I think) so even with a running jvm it takes several seconds to compile small example files. To slow for me so I switched back to CoffeScript which is lightning fast.

"It's incompatible with standard Javascript libraries, which is why you would use Dommy because you can't use jQuery." Not true. (def $ js/jQuery) (.append ($ "body") "hello world") The reasons you'd use Dommy over jQuery are outlined in the original post.

Not quite. The following shows what doesn't work:

    (def $ js/jQuery)
    (.each ($ "body") (fn [idx, val]
                        (.write js/document "In a lambda")))
The Google Closure Compiler munges names of functions so that any function declared in ClojureScript cannot be called from jQuery which means that no jQuery function that takes a callback can be used. And you really want to use GCC because without its dead code removal a simple helloworld.js file takes more than 700kb.

Re: Faster, Better DOM manipulation with Dommy and ClojureScript

#39
post #38
post #33

Earlier quoted context omitted.

"It's incompatible with standard Javascript libraries, which is why you would use Dommy because you can't use jQuery." Not true. (def $ js/jQuery) (.append ($ "body") "hello world") The reasons you'd use Dommy over jQuery are outlined in the original post.

Not quite. The following shows what doesn't work: (def $ js/jQuery) (.each ($ "body") (fn [idx, val] (.write js/document "In a lambda"))) The Google Closure Compiler munges names of functions so that any function declared in ClojureScript cannot be called from jQuery which means that no jQuery function that takes a callback can be used. And you really want to use GCC because without its dead code removal a simple hel…

You just need to compile your ClojureScript with the popular jQuery externs file.
Post reply on HN