Share this post
When I started working with Originate on a new project, I was given the freedom to choose my own stack. The CEO’s requirements were simple: create an MVP to replace the current process of resource planning that we use today. This meant creating a replacement for their Excel based process using a web app. I told the CEO: Don’t worry, I’ll get something out to you in two-three weeks.
So there I was, staring at my computer, having absolute freedom to choose my tools. I should’ve been happy.
I wasn’t. I was stressed. I really wanted to impress them, to use the latest technologies.
I knew JavaScript very well, and I’d done a few node projects, so I picked that. I didn’t have too much relational data, so I picked Mongo.
But which front-end frame to use to make a snappy single page app?
The Decision process:
I really wanted to pick the best one, but as getting hands-on with a framework can take anywhere from a few days to weeks, I just didn’t have that time to spare.
So which one should I pick? Angular? Knockout? Backbone? Ember? Meteor? I was in a bit of pickle.
I’ve used many technologies over the years but I hadn’t really experimented with Angular, Knockout, or Ember. I’ve used Backbone, but it’s just too messy for my taste and not really structured.
So I started reading about all the technologies.
The instant ‘No’s:
- Meteor seemed amazing – really smart people building such a great concept. The idea of front-end and back-end in the same system seems incredible. I actually wrote similar code in one of my past projects to move models from the back-end to the front-end, so I instantly connected with the concept. However, it was still very early days for Meteor and no big production environment was running it at the time, so it was out. After checking on them recently I notice they seem to have made great strides and are doing very well. That’s one tech that I’d keep my eyes on personally.
- Backbone – I never liked Backbone that much and I’m not a huge Marionette fan either. I just felt it’s too messy for my taste.
Now there was the tossup between the ones that were left:
- Angular– the most popular one at the time, with lots of support due to it being a Google product. However, I’d read complaints about it using its own idioms and engineering concepts that one must learn in order to use it. Still, it was the most popular and most commonly used MVC, so I was not going to dismiss it easily.
- Ember – As I was reading about Ember and doing my background investigation, I leant that out of all the frameworks Ember is the most opinionated and that using it requires following a very particular structure, whereas Angular is more configuration based. I also learnt that Ember is stable and used by quite a few serious companies.
My decision wasn’t simple, but ultimately I picked Ember for two main reasons:
- Ember and Angular seemed to me the most stable, and the ones that have some serious customers using them in production.
- Ember’s convention over configuration. Ember forces you to follow a particular structure, which can be a very good thing as it solves many of the engineering decisions for you. Plus, no one has to be the “code police” that makes sure you put files in particular directories, or call classes with certain names. I liked that, and since I’m not only the engineer but also the project manager and team lead, and needed to put more developers from various time-zones on the project, I thought that would be awesome. Boy, was I right.
Getting Started With Ember:
Now, once I’d chosen my tools it was time to start getting some hands on experience in building my MVP.
Naturally I started on the Ember official tutorial. However their tutorial was based on used Ember-Data. Ember-Data is an ORM like layer that is separate to Ember. It provides the front-end with models, and all related operations and uses dependency injection to inject an object called the “store” into all parts of an Ember app. While the concept is wonderful, at the time I was starting out Ember-Data was separate to Ember, and they had mentioned it would soon make it’s way into the main branch. As such I decided it was too big of a risk to rely on it and developed my own data layer, using my own store. At the time of writing this post it has not made it’s way in, and went through many breaking changes. As such this decision was spot on.
The first week with Ember was painful. The concept of convention over configuration means there is the Ember way, and the Ember way. Trying to do things in a none-Ember manner just creates frustrations and will get you no where, so the best way is to understand what Ember expects and to do it that way. For example, let’s say you’d like to update certain elements, hide or show etc. While in traditional jQuery you’d just bind to an event, the Ember way would mean you should add an action to some element.
Ember a couple of months in:
Once you do understand how Ember works, and what to do, you become super productive and you can crank out code in a fraction of the time it would otherwise take you.
Ember has a very particular way for all objects in the system to interact. Ember gives you an excellent router, with each route having a very particular point in which it loads the model (Either stand-alone model object, POJO, or the ember data models), a controller object that wraps around your model, and can provide various computed fields, or connect various models together, handle actions and more, and the view that wraps the templates, which uses HTMLBars (ex. Handlebars) templates. Here is an anatomy diagram:
Ember really gives you a framework to do great stuff in a very easy to use manner (once you understand the manner as it’s perceived by Ember); I found myself completing whole pages, and complex UI components, in lighting fast speeds, with it being re-usable in other places later on. Once you’re up to speed with Ember, you’re going to love it (or at least I hope so).
Ember Decision Epilogue:
My Ember journey has been very exciting. It started with Ember 1.3 and now I’m Migrating to Ember 1.10 with Ember-cli. I have written a complete data layer for my Ember app, and the application today is 150,000 lines of code and used by a significant company in production. I have gone through performance optimization and made a few interesting observations about Ember:
- Us geeks tend to love technologies for technological reasons. But the reason I love Ember is from a business perspective – convention over configuration. This means that you can move new engineers on and off a project, and as long as they understand Ember they can start to be productive very quickly.
- During my work on this project, I assisted the company with implementing a new consulting agreement. Having the customer use Ember made it very easy for me to detect design flaws, and to do isolated re-factoring, rather than a complete throw away!
- The company had another codebase that everyone suggested was a throw away. The code was indeed poor in many ways, but since it was Ember it was easy to salvage, to re-factor and shift snippets around, to make it usable and re-factorable, saving the company months of work.
- I have hired a few engineers to work on this project, from multiple places around the world. I was amazed at how fast they have picked up Ember, and even though they are junior, Ember has allowed them to be highly productive from day one.
- The Ember-Cli build system is an awesome addition that takes care of so many things, there is no other MVC framework that provides it.
I’m finding more and more companies are using Ember, and I’m the big advocate of convention over configuration along with Ember. True, there is the downside that Ember has forced its users into making constant re-factors to it’s code-base, but I suspect this is still better than Angular 2.0’s throw everything away! Also when using the latest and greatest you should expect things to change, and overall Ember provides developers and product owners with lots of bang for their buck. I think it’s more complete and my #1 choice for CRUD like application, front-end MVC.
Thanks for reading and I hope you’ve found my experience helpful.
Cheers
Dory 🙂
