Published on February 14, 2015 by Toran Billups
It might be important to call out that my reasons for picking ember have changed over the years. Back in 2012 I wrote about this topic but focused on how ember-data (along with ember) provided a programming model that was closer to traditional server side development. An interesting aside => I'm not even using ember-data anymore (personal preference/not hating on the library or the many smart people working to solve that very challenging problem).
The big win for ember development teams is that this is a solved problem. And even better, the entire community is behind it / supporting it/ improving it so you can ship features that add value instead of reinventing the wheel. Applying the same concepts that made ember so productive to the command line tooling is huge. This means you can learn the tooling once and be productive across your entire organization/ the next organization/ some open source project you hack on/ any other team or project that uses ember.
Another often over looked benefit is not having to argue with your team about the build tooling/ project structure/ etc. If you don't like a convention get involved with the community and hash it out. If it's a great idea/improvement it will stick and everyone wins. Gone are the days when you'd write a build tool in isolation!
Early in my short career I spent some time with the .net stack (long before NuGet hit the scene) and I remember just how painful it was to share code across teams. The funny part is that back then I didn't know just have powerful a concept it was to share code easily like we do today.
My first real exposure to a great package manager wasn't until 2011 when I was first introduced to pip (the preferred python package manager). At first I remember thinking "this seems like a lot of extra work for no real benefit", but within 3 months I started thinking "how on earth do teams ship software reliability without something like pip and virtualenv". Funny how such a simple concept can change how you view the world sometimes.
Fast forward to 2013/early 2014 and ember-app-kit/ember-cli starts to pave a real path for sharing code. Today if I want to share a module between projects or teams it's trivial. What's even better is that a new addon starts with a functional test suite out of the box so authors literally fall into the pit of success from the very start. Sharing web components across your company is one thing, but having a huge community of addons is something that takes story to the next level. I imagine in just a few months almost anything you can think of will have an ember-cli addon that's supported and easily installed.
When I speak to younger (in years of experience) developers they often seem most excited about web components. For some reason this has always seemed odd because I don't think web components (alone) will get you a web application you'd want to maintain/pass on.
For starters, if I just have a web page with 10 web components sprinkled throughout how do they get data from a single source (ish)? How do the communicate between each other (event based or something else entirely)? What is the url doing as you navigate around the application? How can you test the interaction between several components (and please don't mention selenium)?
Without a true application framework you often find what's lacking is a truly holistic solution. You still need and could leverage web components as part of the bigger application but building something that could compete with a desktop app requires more than a handful of widgets.
I can always tell when a developer or team is more excited about the opportunity to reinvent the wheel than it is to provide value/build what the customer really needs. These same teams usually love the "ability" to pick and choose each little piece of the library/framework. With ember you get the exact opposite of this and it has 2 major advantages.
We are solving a lot of the same problems over and over again so it only makes sense that a few great patterns would rise to the top. The community has done a great job putting together what works and throwing out what didn't.
Having the freedom/ability to quickly refactor a route/controller/template and not worry about how many mock tests broke is a strategic advantage. Having the ability to drop down and write a unit test for any object or component without having to pivot to some selenium DSL is a big win for productivity on any team.
In the split world of client/server you are stuck trying to do "some server work" and "some client work" which requires a lot of moving pieces to do any "user like" testing. But when you make the jump to all client work the testing story becomes much simpler. You can write your tests and execute them quickly without any sleep/timeout based hacks because it's all running in the same stack.
The biggest advantage of ember-testing is that developers have a true tdd/feedback loop again. Selenium is great but it was never intended to be a quick feedback/ test-driven development tool for feature development. It's a regression tool to catch differences between client and server (and it does that well). But for those of us who want to ship software quickly and sustainability I'm glad better options have emerged!