Thomas Fuchs
Aug 27, 2015 · 3 min read

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’ve come to the realization that this much client-side processing and decoupling is detrimental to both the speed of development, and application performance (a ton of JavaScript has to be loaded and evaluated each time you fire up the app). It’s better to let the server handle HTML rendering and minimize the use of JavaScript on the client. You can still have fast and highly interactive applications, as the new Basecamp shows — letting the server handle most stuff doesn’t mean that you have to cut back on cool front-end features and user friendliness.

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.

Photo Credit: Joelk75

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.

All in all, my current recommendation for SaaS-type web apps is, and has been for years: Rails, a Postgres database, as much HTML generation on the server as possible and augment that with RJS (older Rails’ mechanism to push JavaScript snippets to the client that get eval’d). This allows for direct re-use of server-side templates, and it’s simple, and works well.

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.

*This is an edited repost of a comment of mine on Amy’s blog post about why we shut down Charm.

Thomas Fuchs

Written by

I make and run web apps: and I made Zepto.js and and am a Ruby on Rails core alumni. Started web dev in '94.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade