Your Questions: Client-side JavaScript Frameworks?
Thanks for coming through with more questions, guys! I’ve got enough for this week and maybe another week after that. You rock.
This first question I picked because it’s related to JavaScript, and, well, I’m in a JavaScript mood (and in the mood to pimp our ebook!).
Nicolas Papon, a French developer, wrote in:
I saw on your blog that you are publishing an ebook of JavaScript tips, I’m definitely interested!
Why, thank you, Nicolas, for giving me an opportunity to shameless promote our JavaScript Performance ebook.
Remember, y’all, you can save 20% off the cover price by signing up for our little email list.
But only if you register by Wednesday! So don’t forget.
The Question
Back to our regularly scheduled program:
I used to handle JS through Prototype.js and Scriptaculous. And the more I get into it, the more I start hating Rails RJS.
I’ve heard that some people wanted to build up some kind of client-side controller using JavaScript, to handle everything linked to effects and Ajax, but I couldn’t find any mature Rails projects. Unobtrusive JavaScript seems dead or dormant (until when?).
Have you any info about that, what do you think of the idea, is there a future for such an architecture in the Rails project?
OK, so I’m going to respond to your question in three parts:
You’re sick of RJS
This is something I totally understand. (Don’t know about RJS? Check out my RJS cheat sheet.)
RJS is a great timesaver for very simple Ajax call-and-response stuff, like adding items to a to-do list, inserting new content into divs, and that sort of thing. That’s what it’s made for.
Once you get beyond that, it loses its charm… and it’s simply no longer effective. You may keep trying to use it, but you’re using it for the wrong thing.
For example, our time tracking app, freckle, uses a mixture of totally hand-coded JavaScript and RJS, even though we’ve got a couple JavaScript experts “on staff.”
But be careful if you’re thinking that because RJS isn’t enough for you, that the next step is another framework.
Existing Full Stack JavaScript Frameworks
Here are the two full stack client-side JavaScript frameworks (complete with views, controllers, and models) that I’m aware of:
Incidentally, both are modeled on Rails. Sproutcore’s made to interact well with Rails, too.
And yes, Unobtrusive JavaScript appears to be dead, but I don’t think this is a big deal. (Somebody ask me why, for a future post, cuz I don’t have time to cover it today!)
What do I think of the idea?
Sproutcore seems really nifty, for building extremely interactive apps. Which may prompt you to (in my mind) ask, “Is my app an extremely interactive app, Amy?”
Probably not. Your app probably doesn’t fit my definition of extremely interactive. Freckle, for example, doesn’t, either, and we’ve got all kinds of Ajaxy goodness going on.
Rule of thumb: If your app isn’t like a desktop-replacement app, and it’s less interactive than the SproutCore Photo Album demo app, then I’d say SproutCore is not for you.
You’re looking for the wrong tool.
In conclusion…
Nicolas, I’m going out on a limb here, but it sounds like you’re in that no-man’s zone where RJS doesn’t do enough for you, but you’re not ready for SproutCore.
I have to give you the same tough-love advice I gave to people who were in the same position as you, but with Rails scaffolding rather than Rails JavaScript:
You’re going to actually have to use (pure) JavaScript.
The little helper tools—RJS, helper methods, and frameworks—will only take you so far. They are like Bandaids, not entire ecosysems.
It’s better to just embrace the fact that to get a rich JavaScript experience, beyond a certain point, you’ll have to write custom JavaScript.
Once you decide to do it, it’s not so bad!
To be continued?
I’d love to answer some more JavaScript questions.
The next stack of questions are UI and design-related, but I’m up for whatever!
Don’t forget
We’re shipping our beta book on JavaScript performance on Wednesday, so getcher 20% off coupon while you can!
What about JQuery and Rails integration ?
I agree with your final outcome ("You’re going to actually have to use (pure) JavaScript.") but I’m kind of confused by your statement that "Unobtrusive JavaScript appears to be dead", so I’ll be the one asking why, be it in another post or here in the comments.
First, in my opinion unobtrusive JavaScript is far from dead, it’s just a (best, if you ask me) practice just like separating css styling from the html structure rather than a single technology.
Second, are you advocating writing more complex JavaScript logic within the html code (assuming that simple cases are handled by RJS)?
The Rails plugin Unobtrusive JavaScript is dead. 🙂
But, related tangent, the idea of highly interactive JavaScript-powered apps with graceful degradation is a myth.
If you want to do well for people without JavaScript and with screenreaders, it’s better to do like Google does and design a different interface specifically tailored to them.
For what it’s worth, Sproutcore is based on Merb.
The thing I hate about RJS most is that it loads JS into the browser to execute, when all of the JS should be loaded on PAGE LOAD first, and then executed inside the app. It makes things VERY messy and difficult to follow.
"The Rails plugin Unobtrusive JavaScript is dead. :)"
Ah, thus the capitalization 🙂 We can all agree on that.
"But, related tangent, the idea of highly interactive JavaScript-powered apps with graceful degradation is a myth."
I think it’s a question of where you draw the line. Google Maps works beautifully without JavaScript, so it’s built very much with progressive enhancement in mind.
However, accessibility is only one (albeit important) goal of unobtrusive JavaScript. In the same way that I don’t want to mix domain logic in my Rails views or clutter up my html source with font tags, I want to keep my JavaScript logic separated from the structure and presentation of the page. And the more interactive and complex the logic gets, the higher I think the need for that separation is.
@Jarkko I think the issue is that separating the JavaScript logic from content ‘just because’ is overengineering for most sites. It’s important that people know that there is no golden rule they can follow, because, as so many things, it depends.
So here’s my advice on this:
I agree with you that it’s necessary if you have a highly complex presentation logic. RJS is a great solution to reuse Rails partials for (simple) interactive updates, it just works and you don’t have to fiddle with integration.
For medium complexity I’d advocate to just throw in a script tags (or possibly, with Rails, collect script fragments with content_for, and throw it at the end of the page). This has performance advantages (we’ll cover this in our book!) plus you can keep presentation logic and presentation markup together in one file, and in my experience keeps the number of possible bugs and side effects down.
For highly complex stuff, and for certain components that are client-side only (e.g. in freckle we’ve a calendar element), I’d go for the do-it-all-in-JavaScript route.
SproutCore sounds great!
Was wondering what meets your definition of a fully interactive app?
I would also add http://www.javascriptmvc.com/ to your list of js frameworks.