So we shut down our second web app, Charm.*
Charm, as it is, is using Backbone.js, Underscore.js and Zepto on the front-end, and Rails 2.3, Postgres, memcached, redis, resque, and for websockets Sinatra, and a few other things. The front-end is communicating with the back-end via a JSON API.
I argue that all these newfangled libraries are actually detrimental to the user experience in many ways, as they lock you into certain patterns (it’s hard do to things the authors didn’t anticipate) and if you use something like Ember (which we didn’t), it’s even worse as all applications using it practically look the same (many people choose using Twitter’s Bootstrap library, for example).
We’ve spend a lot of time getting Backbone to work properly, and the ease-of-use quickly deteriorates when your models get more complex. It’s a great choice for simple stuff, but email is far from simple. We also had to add yet an other extra layer of processing to generate “ViewModels” on the server because the normal Rails serialization of objects wouldn’t cut it.
What you end up with is building a layer cake that doesn’t add any value and slows down development.
Perhaps your inner nerd gets off on how structured and separated and oh so clean everything is. But, especially when you’re starting out and need to stay flexible you don’t want to have too much code around — and Rails is great for that, but… adding a JSON API layer and basically a second application that runs on the client is annihilating this advantage for you.
As an added bonus, keeping things on the server allows for much better error and performance monitoring and thus quicker turnaround for fixes.
There’s also a lot of great stuff in this direction in recent Rails versions (like Turbolinks, a sort-of-successor to PJAX, which is a handy replacement for RJS).
Alas, keep it simple and don’t repeat yourself.