My first ajax-y attempts were done with prototype. It all seemed so natural and seamless: prototype came with rails and there were those nice javascript helpers like link_to_remote which generated the javascript code for calling prototype functions. Until you looked at the code! (and the weight of it). I’m not talking about the ruby code but the output HTML, which is heavy and plagued with very obtrusive javascript.
Since I’m a concerned person, I decided to ditch Prototype and its Scriptaculousy effects and use jQuery instead. And I thought: since jQuery is so cool, I’m pretty sure that somebody will have done a replacement for the default javascript helpers (based in Prototype)
. But I was wrong. Not completely wrong, but quite a bit.
There’s some work done in this area; a guy whose page is titled Katz got your tongue? is working hard in getting a jQuery On Rails plug-in up and running. Incidentally it seems he’s also a jQuery developer so that’s very good too. But since the plug-in is not finished yet, I kept looking for less obstrusive alternatives. I remembered about the unobtrusive plug-in that Luke Redpath & Dan Webb talked about in a LRUG meeting, UJS, and although it looked really cool, I realized am not sure if that’s what I want.
Right now, it looks easier to simply write the HTML and add some JS (not in the html itself) which behaviourizes the elements, using jQuery for this, rather than using UJS’s apply_behaviour. Specially because at the end, UJS is still using Prototype, and it is very slow compared with jQuery.
In my tests, which are so unscientific that I don’t have any result indicator more than my own subjective speed perception, effects made with Prototype+Scriptaculous ended with what I call the 1fps syndrome: the screen gets updated only 1 time per second, so you forget about concepts like smoothness, transitions, easing and all that quite quickly. Way more quickly than it takes the effect to execute, actually; when it finishes you have almost forgotten what you wanted to do. Meanwhile, jQuery kept always a decent framerate and didn’t feel like overloading the processor. And this happens in all types of machines.
So I think I’m going for jQuery, doing things in the style of this guy over here, and will keep an eye in jQuery for Rails development.
jherber
jquery is faster in some benchmarks: http://jquery.com/blog/2007/07/01/jquery-113-800-faster-still-20kb/
but, for ajax interactions, what i do is call the scriptaculous effect so the user still gets the visual feedback, but i wrap the actual processing/updating the client side model with an async timer call. that gives the effect time to run before the model is tweaked.
also, the scriptaculous effects scale on my machine. if there isn’t time to process the visual effect, the entire effect animation does not occur, rather just an ‘estimation’ of the effect occurs depending on load. i wrote my own table which randomly adds and removes rows to make sure the effects would look fine under heavy load conditions beyond the torture a few humans could instill at 100ms ajax event rates and had no problems with functionality.
sole
Yes, I had seen that benchmark, but sometimes is good to talk about subjective perception :-)
In any case even checking the examples in each library page demonstrates those differences without having to check any benchmark. And I’m not relying too much in visual effects so jQuery is more than fine (apart from the substantial style difference between programming with it or prototype). But thanks for the comment anyway.
Jon
Why do so many people insist on using a framework?
The JS involved for creating a remote connection and serializing an object is minimal.
Frameworks make people lazy.
sole
It’s called compatibility across platforms and knowing that somebody else has been testing that code thoroughly before releasing it.
noihex
I tend to agree with Jon. Code differences to create the necessary objects for client-server communications are well understood and amount to a line of code.
falk
@jon: i am a lazy programmer – and think being a lazy programmer using some nifty tools is not uncool. you just have to know your tools.