Thrown Down in the Dojo
With the release of Dojo 1.0, I thought it was time to pick up that particular torch, and add it to our project. It's quite sexy, what it can do.
So I spent the morning trying to get Rails to choke down the include tags (which, if you Google it, you'll see is non-trivial). Once that was working, I goofed around with a few forms, then abandoned the idea.
Yes, abandoned it.
According to Firebug, my load times on any particular page went from 281ms to over 2.1 seconds.
It sure does look cool, though. And if we end up creating some big Ajaxy page, where the user sits and doesn't leave, then I'll whip it out again. But in the meantime, it goes against the grain of what we're doing and is clearly too heavyweight.
Maybe someday I'll get back in the dojo.
3 comments:
Are you sure it wasn't an issue of file caching and custom build? I use Dojo, and in my experience it's quite snappy, once the JS files are cached.
Making a custom build targeted to your codebase use should speed up the initial release even more.
There was definitely a caching issue (I was running in development without caching). My decision was perhaps more based on the observation that Dojo *seems* intended for a one-page, ajax-heavy application (think GMail). Our application is jumping around with every click.
I just don't think it's worthwhile.
Yet. :)
The two aren't in conflict. Our app is also multi-page, but any browser will cache the external files after the first load, so subsequent references to dojo.js on other pages are instant.
I specifically set a no-cache HTTP header on our dynamic pages, but not on static content; so after the initial access, Dojo is very fast in my experience.
Incidentally, count yourself lucky to be looking at it in version 1.0. I am migrating from 0.4 right now, and it's a pain.
Post a Comment