Ember

Ember grew out of the SproutCore 2 project and is among a handful of full-fledged frameworks used to build elaborate client-side applications. The first commit happened in April 2011, and it reached its first stable production version, 1.0, in August 2013. Ember.js is a very opinionated framework of JavaScript, which means there is usually a single best way to implement a certain task.

Ember

It adopts the “convention over configuration” philosophy, found in Ruby on Rails. It means there should be a default way that the building blocks of the framework fit together without the application developer explicitly specifying so.

Why Ember.js?

Ember.js is designed for building ambitious web applications, as its motto states. It is the most comprehensive browser application framework out there, making it a wholesale solution for building client-side applications. There is no need to add libraries that plug into it to access different functionality, like managing views or handling routes.

Ember and JS

Although it is a comprehensive solution for building client-side applications, it is not a monolithic block of code. It leverages several small JavaScript libraries, like router.js for routing, backburner for managing the run loop, and Glimmer for its view layer.

The release of Glimmer.js marked the beginning of Ember moving to become a truly modular framework.

Currently, the Ember.js Modules API is being adopted in version 2.16, and Embroider is actively being worked on. This means a future where only the pieces of an application’s framework are shipped to the browser is not far away.

Opinionated nature

Ember.js is no doubt an opinionated framework. These opinions are woven into its core, and consequently, there is usually a best way for each task and a best place for each piece of code.

That doesn’t mean that the developer becomes a code monkey, left to follow the framework’s bidding - far from it! Instead, once working with the framework becomes second nature, the developer can focus on business logic problems, improving user experience, and writing robust, well-tested, flexible code.

Another great benefit: developers inheriting an Ember project or contributing to an open source Ember application do not need a lot of ramp-up time to figure out it’s layout and how it works. Firm best practices make developers’ lives easier and save time when getting started or handing over projects.

Let’s give you some high-level, uncompromising points of view:

1. URLs are the most distinctive feature of web applications, whether server- or client-side. Thus, any framework worth its salt has to support URLs.

Putting development time and thought where its metaphorical software mouth is, Ember.js has an outstanding router with a wide range of features, clearly thought-out and refined along its development process. It supports different location types and query parameters out-of-the-box. Each route defined in the routing table begets a full-fledged route object. Its callbacks, also called route hooks, allow for loading data from the backend, checking authorization to view the page, redirecting to another route, handling user actions, and many more features.

2. Convention over configuration

Convention over Configuration is a chief design principle in Ember. The major building blocks, routes, controllers, and templates are held together by a naming schema derived from route names.

3. Only code that is worth writing should be written

Made possible by “Convention over Configuration,” Ember goes to great lengths to relieve developers from having to write code that can be deduced by the framework. One example of this is generating the right kind of controller for a route on the fly.

4. Declarative templates and The Rule of Least Power

Ember templates are written in a declarative templating language called Handlebars. Unlike in other view libraries, you have a constrained set of helpers you can wield and you cannot use JavaScript directly in templates.

This conforms to the Rule of Least Power, as expressed by the World Wide Web Consortium (W3C), which posits that to solve a given problem, one should choose the least powerful language.

5. Stability without stagnation

During the march to Ember 2.0, the core team could have decided to part ways with concepts and syntaxes that proved obsolete or too complex. However, coming up with totally new APIs would have broken a lot of existing 1.x Ember apps. On the other hand, had they hung onto old ways of doing things, better ideas might not have been adopted. Not wanting to do either, the Ember core team adapted the philosophy of “Stability without stagnation.” New features were integrated into the framework over time, in minor 1.x versions, when they were found robust enough to be merged. Old features were phased out gradually, leaving Ember developers ample time to migrate their applications. Having a strict, six-week release strategy made the whole process easy to foresee and plan for. This method proved very effective and has remained in place for the 2.x development process.

On top of that, any change to the framework now has to go through the Request for Comment (RFC) process. The RFCs are open for comments and suggestions from the community so people can voice their concerns before the suggested change makes it into the framework.