Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Faster, Better DOM manipulation with Dommy and ClojureScript

blog.getprismatic.com

Post reply on HN
Print view View original

41–50 of 51 posts

Re: Faster, Better DOM manipulation with Dommy and ClojureScript

#41

Post by jwhitlark »

bjourne wrote: post #38
rads wrote: 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 can mark things so that their names aren't mudged via ^:export.

Re: Faster, Better DOM manipulation with Dommy and ClojureScript

#42

Post by codewright »

Jonovono wrote: post #24
aria wrote: post #19

Earlier quoted context omitted.

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.

Cool! I am wondering if you have worked with other frameworks like Pedestal.io, C2, or WebFUI, Ganelon. Or any others. What do you think of them? I am just getting started with Clojure/CS and am evaluating the different options. http://pedestal.io/ http://keminglabs.com/c2/ https://github.com/drcode/webfui http://ganelon.tomeklipski.com/

Take a look at Luminus.

Re: Faster, Better DOM manipulation with Dommy and ClojureScript

#43

Post by jwhitlark »

ConstantineXVI wrote: post #21
jzelinskie wrote: post #11

Earlier quoted context omitted.

How mature is ClojureScript these days? I remember people saying it and Clojure on Android was rough when I was exploring Clojure a while back. Does the compiler eliminate unused code from the final output?

I'm led to believe the issues with Clojure (and other JVM languages) on Android are due to Dalvik not being as friendly to other languages as the Sun JVM. I don't blame Google, but it's unfortunate.

There are actually games written in Clojure that run on Android quite well. A bit slow to start up, but not nearly as bad as I had expected. Take a look at https://play.google.com/store/apps/details?id=com.friendlyvi... and check out their development blog.

EDIT: The guy who did NightWeb talks about Clojure on Android here: http://nightweb.net/blog/clojure-on-android.html

Re: Faster, Better DOM manipulation with Dommy and ClojureScript

#45

Post by k3n »

connerp wrote: post #36
k3n wrote: 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 man…

Isn't Dommy basically testing plain JS vs. jQuery at this point? That's kind of my point.

I'm also curious how well Dommy would perform in the 'real world'; seeing as everything is compiled down to plain JS, then the divide between library and implementation is removed. jQuery is a larger download hit on the first visit, but if it's already in cache (perhaps before they even reach your site) then the only code required to be downloaded is your app's specific implementation.

In the Dommy example for the templates, the jQuery code is 10 lines -- when formatted like generated.js (the equivalent Dommy code) and removing 2 unnecessary variable declarations. By contrast, generated.js is around 60 lines (giving you a few on account that there's some empty else-statements...). I know minification can do wonders, but the jQuery implementation is clearly going to be much fewer bytes. At what point does it eclipse the size of the jQuery lib itself? I guess that's up to usage.

If your library is the implementation, then it'd seem like you'd have a lot more data being sent over the wire, and likely more often as well on account of any changes to the Dommy which alters the output will have an effect on the cached files for each of them where that functionality was used. On the other hand, updating jQuery means only the 1 file has to be re-downloaded -- and not every userland implementation which uses the API.

Re: Faster, Better DOM manipulation with Dommy and ClojureScript

#46

Post by w01fe »

codewright wrote: post #34

Carthago delenda est: when are you re-releasing the software you yanked from your Github?

We're working on it! We removed the software because it needed extensive cross-project reorganization, consolidation, and cleanup which just wasn't possible to do with a clean upgrade path using available resources (3 backend engineers). Plans are to re-release all of this and more, and we've already started with Plumbing and Graph: https://github.com/prismatic/plumbing. Which librar(ies) in particular are you most interested in?

Re: Faster, Better DOM manipulation with Dommy and ClojureScript

#47

Post by notimetorelax »

lukev wrote: post #25
olenhad wrote: 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?

At Relevance we've released a "framework" for this; it's not MVC, but it addresses the same concerns. It's still in an alpha/beta state, but you should check it out if this stuff interests you: http://pedestal.io/

I'm planning to use it in my next pet project. What I like the most in your framework is the URL generation feature. IMHO it was missing in all other Clojure web libraries. So thank you for your contribution!

Re: Faster, Better DOM manipulation with Dommy and ClojureScript

#48

Post by j_m_b »

All this talk of jQuery and no mention of domina (https://github.com/levand/domina) the native clojurescript dom manipulation library? I've since abandoned css and jquery selectors in favor of using domina.xpath.

I also want to mention webfui (https://github.com/drcode/webfui). 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.

Re: Faster, Better DOM manipulation with Dommy and ClojureScript

#49

Post by disnet »

swannodette wrote: post #27
jlongster wrote: post #16

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?

Yes indeed. Sweet.js already uses syntax objects internally so the groundwork is there for syntax-case. We "just" need to implement and surface the API :)

Re: Faster, Better DOM manipulation with Dommy and ClojureScript

#50

Post by vorg »

epidemian wrote: post #17
aria wrote: post #8

Earlier quoted context omitted.

Other languages can totally have macros, but unless you have homoiconicity, which lisp languages do, macros aren't easy to use or support. In ClojureScript, macros are built into the language.

Agreed. But it's not like macros without homoiconicity are totally useless. They are just more cumbersome to write. In Groovy, for example, you have the equivalent of macros in the form of AST Transformations †, that look just like Java annotations, but can actually convert the code their are applied to (or, more specifically, the AST node) and transform it into something else at compile time. Writing AST Transformat…

> you have to deal with the AST nodes as objects (there are DSLs for this fortunately)

I tried using D'Arcy's DSL for Grϕϕvy's AST a few years ago but it was very slow.

Post reply on HN