Huge fan of your work. Been in love with Rails since the pre 1.0 days. Our team internally (we have an existing Rails 3 app that we want to improve rendering performance) has been going back and forth with "Rails should emit JSON and render client side" and "We should be smarter about caching and AJAX-ifying our pages".
Your post has given more ammunition to the Rails-only side, so that is really awesome; thanks for that!
There are reasonable arguments on both sides.
For Rails Improvement:
* We know Rails
* Scaling Rails is a solved problem
* You can "just throw money at it"
For JS UI:
* We know Javascript (http://www.github.com/toura/mulberry)
* Why spend server $$ on boring HTML rendering?
* We have better GUI test tools in the framework side (we can unit test our componentized JS GUI much easier than a mashed-together Rails ERB HTML)
* We don't have that much money to throw at it, and that's wasteful besides
Presupposing, of course, that the server rendering JSON takes less time than stitching together ERB and the developer toolkit isn't any harder, would you find it more interesting?
Matt, I don't think there's all that much difference in money spent (you still need to buy servers either way and you still need to cache even if you return JSON). We crank out functionality faster when it can be done server-side because the development experience is better and because Ruby still beats even CoffeeScript (although not as thoroughly as it used to beat vanilla JavaScript) for productivity.
I find the complexity needed in having MVCs on both client and server side to be the main problem. Especially since much of what applications like Basecamp are not all that heavy on the UI-interaction. A few bits are, like a calendar, so we use it there.
But obviously you can make it work either way. Just like Facebook manages to make PHP work. And some crazy kids still use Java. You should pick a development environment and style that fits your brain and your sensibilities. If you think client-side development is lovely, then by all means, go to town. Some people even think JavaScript is still as well as Ruby and that you don't even need CoffeeScript -- peace be with them.
I'd be curious as to how much benefit could be derived by moving the business logic in the server side MVC to the database in the form of triggers, stored procedures etc. Seems like that's the really natural place for some of the functionality, such as validation, that can't be implemented safely client-side.
Thanks for the reply. Look forward to using Basecamp NEXT (we use all the 37 signals products here) and seeing the evolution of your process as you continue.
Huge fan of your work. Been in love with Rails since the pre 1.0 days. Our team internally (we have an existing Rails 3 app that we want to improve rendering performance) has been going back and forth with "Rails should emit JSON and render client side" and "We should be smarter about caching and AJAX-ifying our pages".
Your post has given more ammunition to the Rails-only side, so that is really awesome; thanks for that!
There are reasonable arguments on both sides.
For Rails Improvement: * We know Rails * Scaling Rails is a solved problem * You can "just throw money at it"
For JS UI: * We know Javascript (http://www.github.com/toura/mulberry) * Why spend server $$ on boring HTML rendering? * We have better GUI test tools in the framework side (we can unit test our componentized JS GUI much easier than a mashed-together Rails ERB HTML) * We don't have that much money to throw at it, and that's wasteful besides
Presupposing, of course, that the server rendering JSON takes less time than stitching together ERB and the developer toolkit isn't any harder, would you find it more interesting?
Thanks,
-- Matt