Ember. Your best bet.

If you’re considering what tool to use in helping you build out your next application, you need to consider Ember.js. Building out a frontend application is extremely complex and encompasses a variety of issues. It’s an adventure you don’t want to take alone and you want to be prepared for any scenario that comes up. Ember has your back and I’m going to shed some light on why you should consider it for your next project.

Libraries are not frameworks.

Libraries are tools. They enable you to do a specific thing. Consider a paint brush, it does one job and one job only. Frameworks encompass multiple tools. In Ember, these tools have been curated by a community to be the best solutions to some of the most complicated and common problems in frontend development.

The problem I see is that the frontend community as a whole has confused the two quite a bit. For example, Glimmer.js, Vue.js and React.js are view layer tools — they help you manage rendering elements on a page. However, there are tools that tackle other issues, such as React-Router and router.js for routing support as well as create-react-app and ember-cli for tooling.

Frameworks encompass these tools so that you can get started building your app. My first framework was Rails, an excellent example of a framework composed of some excellent libraries. The problem is that a backend framework doesn’t mentally translate on the frontend, because after all the frontend is just the UI — right?

No. Frontend development encompasses web api support, tooling, deployment, testing and more. These individual pieces have been improved by many libraries, but having a framework in your pocket is crucial — it enables you to deliver software faster, minimizing decision fatigue.

Delivering Software.

Ensuring that great software gets shipped is my primary responsibility. As a software engineer, I build things. These things are customer facing and anything that gets in the way of that goal is a distraction.

Some may say that establishing a framework is the responsibility of a software engineer. And, it is. However, we also need to balance the cost of chores versus user facing value.

The teams I love working with the most care about shipping software. They recognize there is a delicate balance and distinct difference between the need to solve commonly held development problems with the needs of the customer.

Ember does this out of the box. It’s established a community that works together to solve common problems while delivering the features you need the most in your app. If it doesn’t have what you need, it’s extensive addon ecosystem most definitely has a solution for you. If ultimately that doesn’t work, I’m sure you’ll find others who would be willing to help you out.

Benefits for choosing Ember.

A simpler life.

Since I’ve chosen Ember, I haven’t worried about tooling, web api support, security compliance and more. Why is that? Because the community is comprised of experts in these fields who have dedicated their lives to helping you, me and everyone else out.

Testing in Ember is a perfect example of how life has become easier. Unit, integration and full on acceptance testing is part of the framework. You only have to choose which test runner (e.g. qunit[2], mocha, etc…) you want to use. Everything else comes together and you can quickly start writing and executing your tests.

Empowering engineers to painlessly write acceptance tests can remove the requirement of a separate QA department, especially for small teams and tight budgets. And you get all of this for free.

A friendly community.

The community is probably one of the best aspects to choosing Ember. Because conversations are transparent and open to the public, the reasons behind why a pattern is implemented over another or why a certain technique is better — is all documented on the web[3]. Ready for you to review, critique, avoid or implement.

Also note that Ember is not going away. The foundation that the Ember community has established is built by a coalition of individuals and companies. Everyone in the community comes from different backgrounds, with different problems and a ton of opinions. But this is where the core strength of the framework lies — in the healthy discussion, implementation and delivery of tested solutions.

Documentation.

The library is extremely well documented[4]. From source code, guides or slack channel conversations— you can find the answer to your question. And even better — it’s taken seriously. Documentation is versioned, community based conversations on Github are thorough and the core team has implemented guidelines that help with this standard procedure being implemented in it’s extensive addon system.

Common criticisms of Ember.

It’s not cool.

Well, it is — there are a bunch of features in the framework I bet you’d love to use. For example, source maps works out of the box — meaning you can use Chrome’s developer tools to extensively build your app.

Favoring stability may not be flashy if you’re starting out, and it may bother you that Ember doesn’t let you break things. We used to do that, and it wasn’t so fun.

The good news is that your voice can be heard. Ember has a an organized RFC process to debate major changes in the framework. You can learn about changes before they occur, give your two cents or create your own RFC for feedback.

Learning curve is steep.

Ember is comprised of various crucial pieces that help ease the application development process. For example, routing, deployments and automated testing is baked in. Which means, not only will you need to learn about Ember’s recommended design patterns — but you’ll need to learn about other aspects to shipping good working software.

This makes the learning curve a bit steep, because there is more than just learning about composing components for the visual layer. The argument about Ember’s steep learning curve has been used against it, but I would challenge that with the fact that you would eventually need to learn these other aspects of development as your needs grow beyond the view layer.

Note that this has caught the attention of the core team, and there is a big movement to simplify things to ensure that the barrier of entry is simplified. For example, moving to JavaScript classes, removing the need for this.get and this.set and more have been proposed to remove the biggest confusion sources for JavaScript developers.

Native is not a primary citizen.

Ember is a framework committed to the Single Page Application (SPA) architecture. The benefits you get from SPA are the benefits of Ember. Since SPA isn’t a concept for native apps, Ember is a poor fit for native.

Keep in mind Ember is making headway with progressive web apps. So if thats an option you would like to consider, check out Building a Progressive Web App with Ember by mixonic.

Why you should choose Ember.

Ember is being utilized in the startup world and at the enterprise level. There are various applications out there that have proven themselves to be resilient to time. It’s utilized in many industries and has proven to scale quickly and effectively. Ember has helped businesses ship value and stabilize development teams.

Coming from a software engineering perspective, the stabilization of a team is worth more than anything else I’ve worked on. When you can work on a team and share the same language with little to no confusion on techniques, the team grows and becomes more valuable than the actual product.

From a product perspective, you can see rapid progress. In fact, if the tool you’ve chosen gives you the ability to iterate quickly on features and implement feedback in little to no time — that to me seems like the right tool for the job.

And ultimately from a business perspective, the sooner I can add value to my product the better.

If you want your team to be more productive and satisfied while delivering value, then you should consider choosing Ember. If you’re still hesitant, feel free to reach out to me on Twitter at @alvincrespo, I’m more than happy to help you figure out the best tool for the job.

Thanks.

Thank you to everyone who helped me write this post. Your time and effort is very much appreciated and I hope that my words here correctly reflect your review.

Notes.

[1] create-react-app (CRA) is slightly based on the same philosophy as ember-cli. CRA provides a beginning experience in creating an app, however once your needs exceeds the goals of that project — you’re on your own. On the other hand, ember-cli provides an addon ecosystem that gives you the ability to hook into the cli to customize your builds.

[2] ember-qunit is the default test runner, requiring no configuration up front

[3] Examples of transparent conversations:

• https://github.com/emberjs/rfcs/pull/176
• https://github.com/emberjs/rfcs/pull/240

[4] Examples of documentation:

• https://github.com/emberjs/ember.js/blob/v2.15.0/packages/ember-runtime/lib/mixins/observable.js#L96
• https://github.com/emberjs/ember.js/blob/v2.15.0/packages/ember-routing/lib/system/route.js#L1458