31 Aug 2017
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
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.
Just because you can, doesn’t mean you should
I forgot the first rule of programming - Keep It Simple, Stupid. I didn’t keep it simple, I was stupid.