On deciding how heavily to use client side code [closed]

Question

I'm developing a site which will have a fairly extensive admin section. The front end is fairly simple, and doesn't need a complex UI at all, so I don't intend to have too much client side code there.

I'm trying to figure out at this stage how much logic to place on the client side for the admin section. I'm using Ruby on Rails - as one extreme, I could generate the admin pages entirely server side and use extremely light client side code for some basic enhancements. At the other extreme, I could use a framework like AngularJS to make a single page application for the admin section, communicating with the server by JSON.

The main disadvantage I see for the extreme client side approach is that there will be a significant initial page load time, and it'll feel heavy on mobile devices. The advantages I see are that it'll be far more responsive after the initial load, and that the application on the server will be purely an API, and easy to extend or use in other ways should the need arise.

I saw this article about how basecamp manages to be fast and responsive with minimal client side code. While they talk about how they achieved their speed improvements, they don't mention their reasons for sticking with heavily server side code.

So how do I settle on the right balance between client side and server side code? I'd really appreciate any insights into this, pros and cons I have not considered, and resources I could look into. Thanks!

Answer 1

This is a really interesting topic, and I guess a lot of developers are asking themselves the same question.

First of all it really depends on the project at hand. But here are some points that may help you with your decision.

The UI

If your application will have a complex user interface with a lot of user interaction (clicking, dragging etc) and is supposed to "feel responsive" and more like a desktop application I think the client-side approach is the right choice.

However you said:

The front end is fairly simple, and doesn't need a complex UI at all, so I don't intend to have too much client side code there.

Rails and Development Experience

It seems like DHH and therefore by extension Rails is not that interested in the client-heavy approach.

You have to remember that Rails originated from Basecamp and the recent features (introduced in Rails 4: like russian doll caching and turbo links) were developed for Basecamp. If you look at the UI for the new version one is able to see the reasoning behind these features, however not every application and user interface fit this document-centric model. So take the impressive results from 37signals (and for that matter all performance related figures) with a grain of salt (e.g. the caching hardware they use is incredible and not everyone is able to afford such a setup).

Also remember that angular and ember are fairly young projects and (especially ember) are going through a lot of (potentially breaking) changes which may result in frustrating api fixes.

Also ask yourself, what development environment do you prefer?

The Ruby/Serverside development style with TDD and RSpec and fast feedback loops, compared to debugging in the browser and writing Javascript. (Although projects like the Ember Inspector are making great progress and improve the experience.) Don't underestimate this point as you will be spending a lot of time in these environments.

Speed

Like DHH mentions in his article, they were able to achieve fantastic results with more traditional, server side methods.

I think you cannot get a scientific result without writing the same application for both architectures and do some performance testing for each.

This is of course an ideal and unrealistic scenario, but I also think it isn't even needed: It comes down to the UI and the perceived speed/performance of your application. If you have a "one-page" UI where the user is mostly busy on one page :) the client-side approach will probably be perceived as "snappier" and the initial performance hit from downloading the javascript will be made up for.

Api

If you are planning to write a good json API for your application, there is a good argument to be made for the client side approach. eviltrout:

One amazing side effect of a rich client side app is you end up with a battle tested API. Our app has consumed our own API since day one, so we know it works.

References/Reading/Watching

People/Projects you can follow:

• Discourse, a client-side heavy forum software
• Jeff Attwood (I guess you know who he is :))
• Robin Ward (cofounder discourse)
• Sam Saffron (cofounder discourse)
• All of them have been on the ruby rogues podcast http://rubyrogues.com/episode-guide/
• Robins article on why they chose ember for discourse

• http://www.codinghorror.com/blog/2013/03/why-ruby.html

• David Heinemeier Hansson

• Railsconf 2013

• http://37signals.com/svn/posts/3090-basecamp-nexts-caching-hardware

• Yehuda Katz (Ember/Rails team)

• Tom Dale (Ember team)

• Screencast by Yehuda for Ember Inspector

• http://blog.scriptybooks.com/railsconf-2013-keynotes-rails-4-vs-ember-dot-js/

Again, it depends on what kind project you are undertaking. If it is a less serious application and you are curious about new technologies and client side frameworks like ember and angular, and you want to tinker with them: I would totally go for it.

This a very "hot" topic at the moment, and for the years to come and I'm very interested in how it will all work out. Hope this helps a little.