DISCLAIMER: The purpose of this post is to discuss certain aspects of app development — not to flame or flame-bait anyone. Your thoughts are welcome as long as they are constructive; do respond in a courteous and professional manner at all times.
I'm hoping to move a discussion that's running on Twitter at the moment into this thread, as I feel we've got past what we can get across in 140 chars.
"Dangers of Turbolinks" kicked off the discussion how Turbolinks in general should not be baked into Rails as 'enabled' by default.
First of all, the there are two primary means of going client-side: (i) your app is entirely in {insert your framework of choice here}JS with the backend app framework simply acting as a Datastore<->JSON API gateway or (ii) your app is (for the continuity of this post) entirely Rails but you serve some DOM areas via instances of Backbone.js as 'widgets'.
Why Client-side? Seriously.
Just because we can, doesn't mean we should. Sure, client-side is great for UX, but what about the development experience? Does this matter to you?
The obvious benefits of going client-side are two fold: User experience (UX) as a result of almost instantaneous responsiveness — even if it's just a facade in the form of fancy ajax spinners. Perhaps its a psychological thing...
Anyways, in general, it's considered to be fantastic so everyone and their boss want client-side apps.
...and the world ended in 2012.
In 2012, there was a significant shift to client-side. Why? All our bosses bought an iPad and hell froze over... I'm kidding, well, sort of.
At the time, the 'web design and development' world was transitioning between responsive design and native mobile apps (iOS/Android, et al.). The simplest approach was to setup your Rails/Django app purely as an API (hopefully authenticated and versioned) allowing seamless development for the native mobile versions.
This seems to have snowballed into a plethora of JS frameworks from Batman.js to Angular, Ember, and quite a few more. These have one thing in common though — they are more full-fledged, opinionated solutions which is world's apart from the likes of Backbone.
Backbone is flexible, extensible and lightweight — it's code for 'you're in for a fun ride'. It also means you bring your own view and memory management (event/object binding cleanup) to ensure GCing works as it should.
I recently watched an excellent screencast by @toranb demoing the latest API changes within Ember pre-1.0, whilst its maintainers are cleaning things up.
There are many who believe that apps in 2013 should be entirely client-side and those who prefer a pragmatic approach instead. Let's look at both cases.
Completely Client-side
If you love Ruby, having a complete JS app infrastructure means that you're going to, for the most part, be writing less Ruby — although this may not be the case if you get a chance to work on the API and you go way down the rabbit hole, say ElasticSearch with Tire and some fancy AWS/Heroku setup.
That said, your app is still in JS, in a model-first land thanks to your JS models 'more or less' syncing with your Rails models. So, what's so bad about this?
- Particularly for Backbone, view management is left entirely up to us and done wrong, you'll end up in GC hell sitting with that profiler all day long; had you gone with say, Ember.js, this wouldn't be the case.
- Two sets of testing frameworks: you've got one for Rails, one for JS be it Jasmine/Mocha or Mocha/Chai thanks to Konacha.
- You're writing less Ruby. More CoffeeScript; potential FTW!
Pragmatic Client-side
The approach I'm recommending is to 'widgetise' areas of the app with Backbone; making gracious use of namespaces for keeping various widgets contained. And what about the Rails app underneath it all?
(** work in progress)