Do You Really Need a JavaScript Framework?

A while back, I built a new BugMuncher control panel using the JavaScript framework Ember.js, in order to make use of the REST API back-end I’d also been working on. Deciding to go with a JavaScript framework for the control panel, instead of building it entirely in Ruby on Rails, is easily my biggest regret with regards to BugMuncher. And that includes re-writing the entire code-base from scratch. Twice.

I’m writing this post in the hopes it will help someone else avoid making the same mistake. There’s a time and a place for Thick Client JavaScript Frameworks like Ember, Angular and React, but they’re few and far between. So why is it most web app control panels seem to use some kind of JavaScript framework?

I suspect Shiny Object Syndrome is somewhat to blame, JavaScript frameworks are the new shiny technology to which we programmers are drawn like magpies. However, I don’t think that’s the only reason, I know in my case the main reason was simply “it seemed like a good idea at the time”.

So first I’m going to talk about how I ended up in this situation, and then I’m going to explain why it was such a bad idea.

It’s a slippery slope

It all started innocently enough. Somewhere during BugMuncher’s very first complete ground up re-write, I really wanted to tidy up the horrible spaghetti code of the feedback interface. Because of what BugMuncher’s feedback interface does (allows users to highlight and blackout areas of a page and then take a screenshot), JavaScript had to do all the heavy lifting.

This was around the time JavaScript frameworks were becoming mainstream, with Backbone and Sproutcore being popular. Having tried both, I found Sproutcore made more sense to me, so that seemed like the obvious choice for BugMuncher’s feedback interface.

When it came time to start coding I was surprised to discover Sproutcore had been renamed to Ember.js, but it seemed to the name was the biggest change, so I used quite an early beta of Ember to build BugMuncher’s new feedback interface.

The main goal of this complete re-write was to move BugMuncher’s back end from CodeIgniter on PHP to Ruby on Rails. I’ve heard many times that you should never completely re-write software from the ground up, but I stand by my decision to migrate to Rails. It took a long time to do, but it’s saved me more time in the long term.

Then around two years ago I decided I wanted to add a full REST API to BugMuncher, even though no-one had asked for it.

While building this API, it occurred to me that I could reduce the Rails app to just an API, and move the control panel out into a separate Ember app. I remember thinking it was a good idea as it would give me separate codebases for each part of the app, and reduce the overhead required of the back end server (*cough*premature optimisation*cough*)

I was also looking forward to being able to take advantage of Ember’s fancy features such as instant page loads and realtime updates. A.K.A. Shiny Object Syndrome.

What followed was a long drawn out process of simultaneously creating a full REST API in Rails, and a new control panel in Ember.

I actually realised the error of my ways before I’d finished the Ember control panel, but I was far enough through that it was easier just to keep going with it. Of course, with hindsight, I would have saved myself a lot of time and headaches in the long run had I just scrapped what I’d done in Ember and gone back to doing it all in Rails.

So what’s wrong with JavaSript Frameworks?

Having separate codebases for the API, control panel and feedback interface seemed like a good idea, but in reality it just meant more software with more dependencies to keep updated, more tests to run, and a much more complicated deployment process.

I also found myself fighting with Ember a lot, partly because it was still relatively new and bug prone, but also because of the way Ember is. While Ruby on Rails sells itself as opinionated, Ember.js is just downright arrogant, I often found that if for some reason I couldn’t do something “the Ember way”, I was shit out of luck.

Opinionated software is good, it gives you well thought out frameworks for doing things, but understands that some use cases will require different methods and allows for that. Arrogant software tells you how to do things, with no option of doing things differently. Ember.js definitely falls into the arrogant camp.

Of course this may not be a problem with other JavaScript frameworks, the problem was I committed to using Ember before I knew enough about it, for reasons that turned out to be flawed logic.

Just because you can, doesn’t mean you should

The main reason using a thick client JavaScript framework was such a bad idea is because I didn’t need to! There’s nothing in the BugMuncher control panel that couldn’t have been done easier and quicker with a CRUD Rails app. Even if I was a seasoned pro with Ember, it’s still a case of two frameworks vs one, two codebases vs one, two test suites, two deployments processes, you get the idea.

I forgot the first rule of programming - Keep It Simple, Stupid. I didn’t keep it simple, I was stupid.

And now when I look around and see all these fancy JavaScript framework based web apps that could have easily been built using a single back-end technology, I can’t help but suspect they fell foul of the same flawed logic. Will they too regret their decision down the line? Do they regret it already?

So next time you’re starting on a new project, and you’re considering using a JavaScript framework, for your own sanity ask yourself this one question: “Do I really need a JavaScript framework?”. Web apps often look complicated from the outsite, but underneath most of what they do is simply Create Read Update Delete, and you really don’t need a fancy JavaScript framework to do that.

I’ve learned my lesson, I’m sticking to Ruby on Rails CRUD apps with occasional sprinklings of JavaScript where needed from now on. There’s a time and a place for JavaScript frameworks, and whatever it is you’re building probably isn’t it.

- Matt