ClojureScript is so different from JavaScript that it makes sense write a more native DOM library for it. As someone with a lisp background, it's very cool to see a high-profile company like Prismatic using it.<p>However, macros for javascript are being worked on. sweet.js is coming along <i>really</i> well, and just needs to continue ironing out bugs and maturing. <a href="http://sweetjs.org/" rel="nofollow">http://sweetjs.org/</a> I believe that it could have a profound effect on JavaScript, such as parsing selector string at expand time.
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 with regards to the published API ("Inspired by jQuery, but adapted to be functional in order to better fit with ClojureScript core").<p>Also, wouldn't it be more accurate for the selector testing to actually test against Sizzle[1]?<p>Other features aren't even present in jQuery, such as templating, and so I'm not sure why you'd even compare that. Yes people can and do use templates with jQuery, but that's an implementation detail and is not a concern of the library itself; jQuery does not coerce or force you to use a slow templating system, and most any good templating system will also have a compilation step that is run at build-time. So yeah, you can take some ugly userland jQuery example code and make specific code that is faster..<p>1. <a href="https://github.com/jquery/sizzle" rel="nofollow">https://github.com/jquery/sizzle</a>
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?
>> 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.<p>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?<p>Although I find the Clojure example very sexy, I don't like how the examples tries to compare to contrived Javascript. I.e. I've been coding javascript for a couple years and I've never used jQuery "sort/filter/slice". But more importantly, it uses pre-defined function in Dommy but not in javascript. For instance:<p><pre><code> (->> (sel [:ul.my-list :li])
(sort-by #(-> % (sel :input.last-name) .-value))
</code></pre>
This uses sort-by where there's:<p><pre><code> function(a, b) {
return (
$(a).find('input.last-name').val()
.localeCompare(
$(b).find('input.last-name').val()
)
);
</code></pre>
in Javascript.. Obviously, I can say:<p><pre><code> $('ul.my-list li').sortBy(function(x) { return x.attr('last-name'); }
</code></pre>
My point isn't that much that jQuery is longer/shorter, but mostly that if two examples in two different languages are to be compared, it makes sense to use the same function.. where in this case sort-by is a high-level sort.<p>>> One is the loneliest number<p>It's not just "1" or "more than one", it's also zero. Iterating on a list makes it such that you can freely think in a high-level way about the operation and not about the exceptional cases. I.e. $('.blabla').hide(); It Just Works.<p>>> (mapv #(add-class! % :first-ten-adults)))<p>Yes, of course you can use map.. but using $('..').addClass('first-ten-adults') makes it so much easier to deal with, instead of knowing what works on one object, what works on multiple objects, what will throw an error if there's nothing, etc.<p>Meh.<p>I think Dommy is a great library but the author didn't do a great job at explaining why it rocks. I guess attacking a very popular language with its most popular library doesn't help :p
Whilst I'm sure this is clever - I guess I'll never understand the obsession with micro DOM optimisations. When, ever, are we severely held back by the 'speed' of our selectors? It just doesn't happen!
All this talk of jQuery and no mention of domina (<a href="https://github.com/levand/domina" rel="nofollow">https://github.com/levand/domina</a>) the native clojurescript dom manipulation library? I've since abandoned css and jquery selectors in favor of using domina.xpath.<p>I also want to mention webfui (<a href="https://github.com/drcode/webfui" rel="nofollow">https://github.com/drcode/webfui</a>). It is authored by Conrad Barski, who also wrote Land of Lisp. He gave a nice talk about it at the Chicago Clojure meetup group a few months back. He is a fellow hacker news user so I figured he deserved a shout out.
I'd love to use Clojure and clojurescript to replace js/ruby. It's a shame I never come across consulting gigs that use it. Or know any local clojure devs, so I'm still wary of using it on my own projects.<p>So it continues to only be the ideal choice for pet projects.
It would be more interesting if someone wrote something like this for standard jQuery-compatible syntax. jQuery code in, compiled selectors out. And it's just standard javascript, so no learning curve to learn or anything.