- The examples of bad code are numerous and hard to fix. It is really hard to understand the intent and really hard to both support and enhance. In the end, the client pays the price from both a monetary perspective and a maintenance one.
- Developers like to “play” with the new hotness leaving breadcrumbs of learning something new of a framework that gets dropped or at least minimally maintained.
Hi Sasmito, as for technical issues, we where plagued by various problems that are not related.
The app 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’d argue that all these newfangled libraries are actually detrimental to the user experience in some 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.
We’ve spend a lot of time getting Backbone to work properly, as the easy-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. 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.
Alas, keep it simple and don’t repeat yourself.