Why I hate MVC’s (and how Ember.js is different)

My experiences with MVC’s (that’s short for model-view-controller, for those who don’t know) have been pretty negative overall.  I started with Ruby on Rails a good while ago.  I got into it and figured I may just make a career out of using it.  Then I started having problems.  Windows has a passive-aggressive hatred for all things Linux, and I experienced this.  There were incompatibilities.  There were things that would have worked fine if I had some clue as to what I was doing (which I didn’t, admittedly), there was the addition of several new skills I had to learn that were more exciting in principle than they were in practice.  Those being command-line generators and the concept of TDD (test-driven development).

For those of you who use it every single day, you probably have no qualms about using generators or TDD.  That’s good for you and I’m very happy that you enjoy those things… but for me, I had built up Ruby on Rails to the point where I expected it to auto-fix bugs and work right out of the box.  I mean, it can generate all this code for me using a single command… why can’t it work without me doing any kind of modification to the controllers, views, and models?

Here’s (in part) what I like about Ember.  You don’t have that ‘auto-generating’ nonsense going on.  There’s no room for me to assume that Ember is going to do everything for me.  It does, however, handle the boilerplate code for me, and allows me to extend the base controllers, models, and views pretty easily.

The javascript files have to be added by hand.  That’s another thing.  The ‘magic’ of having your models automatically loaded because they were all in a particular folder left me feeling like I had less control of the development process than I really did.  Faulty logic, perhaps, but it extends deeper than that.  Again, it became a matter of having unrealistic expectations of the framework.

Comparing Ember to Rails or .NET is like comparing a VW Beetle to a Ford GT.  Both of them are cars, and they can get you where you need to go.  Ember is a client-side MVC.  It does its work in the browser (guess that should go without saying since it’s ‘Ember.js’…).  That will reduce server load, but it may mean your app runs like molasses.  It also means you will be using JSON to model objects, which was a tad clunky for me, as I am accustomed to seeing C, C++, Python, and Ruby.  The nice thing, though, is it doesn’t give a flying something-or-other about what operating system I’m running it on.  Ruby on Rails and .NET is the Ford GT in the metaphor above.  It’s widely used, well-supported, well-documented, has an active and passionate user-base, and people make big money developing in it.  At the end of the day, it’s just more car than I may ever need.

TL; DR:  The MTG webapp I’ve been working on is up and running.  It’s ugly, there are features that don’t work…. and so on.  The code base is to the point where it is getting unmanageable, and I need some structure so it’s more organized, easily maintained, and extensible.  An MVC framework gives me that, and Ember seems like the perfect fit.

So far, learning Ember has been a joy and pleasure…. I hope it stays that way, as I have yet to dive into TDD with it yet.  Thoughts, comments and suggestions are always welcome.

Leave a Reply

Your email address will not be published. Required fields are marked *