My Migration to Ember.js

and how I convinced my team to “switch”.

This started as a brief outline but has turned out to be rather lengthy. I started to go back and simplify but I would rather be comprehensive so that maybe other people could benefit from my journey. I am a little wary to share this because I do not want to get caught in a flame war between what seems like 2000 different frontend frameworks. In the end, I chose Ember.js and and I’d like to share my non overly technical reasoning as to why. But first..

Some back story…

Just over two years I was hired as an IT intern to help develop an in-house project management web application. The app was initially created a few years ago by a couple of college students as a summer project. As with most projects, it quickly ballooned beyond a simple summer project and, in consequence, a full time employee was hired to develop it. What that employee, my boss currently, did not realize was the app consisted entirely of spaghetti code and quick fixes. For what I am sure seemed like an eternity, he rebuilt the app in a framework. I won’t say which one. Not my favorite framework. But, considering he did most of this in his free time and essentially built everything twice until all of the previous functionality was duplicated, it is hard to complain. Especially as a new hire. Especially as an intern.

I was hired around a week after “version 2.0" was launched. My job initially was to prototype some interfaces and flows and was pretty much given free reign as far as front end development. In fact, the biggest rule was Don’t Touch the Backend. My first assignment was to design an admin interface for an online training section for new employees.

The assignment started on the “summer project” level. It would just be a list of files that an employee would need as a new hire. Easy. Static site. However, like the project management app before, it grew and became increasingly complicated. Not all of those the files applied to every employee. How would anyone know if they read them? What if they were videos and not files? Who would manage these files? What if there were questions?

The simple was not simple anymore.

The road to Ember.js

As the full scope of my assignment grew, it became increasingly clear that I would need something more than jQuery. More than jQuery was a completely foreign idea to me and my team. But as long as I followed the golden rule of not touching the backend, I was free to explore. I quickly found Backbone and relatively quickly built around 30% before I hit a road block. Backbone just wasn’t enough. Categories contained files that were verified by quizzes that had varying pass rates which could be reset by different people. I could not even fathom wiring all of those things together. Also, I had written a gigantic app.js file which was a complete bear to go back through. I needed another upgrade and quickly. After some light research, I was choosing between using Backbone with a handful of extensions/plugins/helpers, Angular and Ember. I want to share how and why I ended up choosing Ember and how that decision made Ember an easy choice for my team’s future projects.

I am not a smart man…

I consider myself decently proficient at programing but I am, by no means, an expert. I do not know all of the best practices nor do I have the time to learn all of them. Often time a simple Google search is not enough. This was exponentially more true when it came to Javascript.

One of the more frustrating parts of using Ember initially, but the better part long term, is that it is extremely opinionated. Though things can be overridden and modified, life is a lot easier when you think of things and write things the Ember way. And the Ember way isn’t a bad way. Each time I dug into why Ember was doing things a certain way, I found that it was grounded in a reason that was well thought out and forward thinking. I found that I did not have to know volumes of best practices or the best ways to structure an app; Ember is built on those out of the box. Once you learn the Ember way, you get those for free.

Better still, when you receive some code written in Ember, you know where to start and generally what to expect.

Community

I am sure there are more elegant ways to say this, but the community that surrounds Ember is kickass and it may be the biggest reason I ended up using it. Ember is often criticized for its initial learning curve and for me it was no exception. After I wrestled with Ember for around two weeks, I posted a random tweet about how frustrated I was. I woke up the next day with several replies wanting to help. I was taken back. If it weren’t for those replies, I probably would have given up on Ember that day. Instead, a jsbin later, my problem was solved and I was back to building my app. This was not a fluke situation. Nearly every time I reached out for help, whether it be on twitter, Stack Overflow or even Reddit, the community was warm and helpful. Several times even members of the Ember core team took time to answer my frequently noob level questions. In short, the community made it feel like a team of people were helping me on this project.

Trust the Docs and Source Code

I hate reading docs and source code. Not because I hate reading, but I hate reading things written poorly and often the docs and source code seem like an after thought. Or even worse they seem to be written for people who already understand and are just there for reference. Usually when someone says “look at the Docs” as an answer, I would consider it a lost cause. For those of you who have not read the Ember API in a while, do yourself a favor and do it. And if that is a bit over your head, read the guides. They have come a long way, and I wish that I had these available when I first started.

Start small

One of the great things about using a frontend framework is that you can start small without scrapping your existing ecosystem. Ember is designed to be versatile yet still remain powerful. The accounting team went rogue and set up their own foreign backend with MSSQL (true story)? No problem. Want build a small section of your app in Ember and leave the rest? I hope you do. That is what I did and the people that used those sections noticed. And it did not burden the people responsible for the backend. They actually prefer it now. Either they specify how something spits JSON out or I do. It doesn’t matter to me. And combining these small sections together was just a matter of changing the router and a few files. I was able to start small and grow.

You can actually be at the cutting edge

The ember core team is adamant about minimizing breaking changes with each new release (which they aim to do every 6 weeks I believe). What does this mean for you? You can have new features without worrying about it breaking what you have already written. I wanted to start using Query Parameters in some code that I had written a few months ago. I swapped out the older version for the newest version and everything worked. Actually I am convinced it is quite a bit faster. And they are continuing to make it better.

This is really the tip of the iceberg…

There are a lot of specific things like the routed computed properties that I did not get to touch on but really make this framework powerful. Also, things like the Ember Inspector and Ember-Data are insanely useful. And projects like HTMLBars and the ember-cli show that Ember is only getting better.

In conclusion

There are flaws in every framework/tool but Ember has thus far proven to be the best fit for where I work and I hope this has at least persuaded you to take a look at Ember. I cannot promise that it will be the right fit, but I’ll try my best to help if you have any questions or concerns. If I cannot, as I said earlier, you have the strength of an awesome community at your disposal.