When comparing Angular and Ember, people often say that frameworks like Ember enforce a strict structure, which frees you from making the same decisions all over again, and makes you more productive. In this article I will explore if it is the case.
ON STRUCTURE AND CONVENTIONS
The only thing I am discussing here is when enforcing conventions is good for you. This is why I am setting aside other aspects of Ember, such as the framework’s API, community, maturity, tooling, etc. And since Rails is probably the most well known framework enforcing conventions, I am going to use it as example as well.
WHEN IT IS TOO MUCH
Though I do not believe that programming tools should be designed for novice programmers, there is an element of truth in saying that Ember is hard to learn. Though an experienced developer can become productive with Ember in a few days, a junior may be overwhelmed by the amount of stuff you need to keep in your head.
I would argue that for junior programmers it is easier to pick up Angular than Ember. Yes, there is a lot of complexity in Angular when you go deeper, but the knowledge required to build a simple TODO application is minimal. It should not sound surprising. It was noticed that such programmers prefer a less formal structure.
WHEN IT IS JUST RIGHT
Now imagine someone with a few years of experience. They have acquired some domain knowledge and know about MVC. They understand the need of separating concerns. They know the applications they build need structure, but may not know how to choose solutions to fulfill those needs. Many of their solutions are ad-hoc.
Such programmers will benefit from imposed structure and enforced conventions. They want some guidance to make their work more effective and their code more consistent. Rails and Ember are great tools for such developers. Although the given structure may not be optimal, it is better than most ad-hoc solutions such developers can come up with on their own.
WHEN IT IS NOT ENOUGH
Expert programmers are the ones that know the domain of building software very well, and are also able to effectively identify the needs of their applications and choose solutions for those needs. They understand how different compositions of components affect the design. These high-ability programmers know how to take shortcuts, and how to remove duplication. They also tend to work on non-trivial applications that evolve over time.
Since there are not that many Ember applications that have been in active development for a few years, I will use Rails as an example here.
Many long-lived Rails applications move in the same direction: controllers are becoming thinner and just delegating to some service objects, and application code is moving to the lib directory. I hope it is clear that you are not taking any advantage of the Rails structure at that point. Your application out grew the framework. As a result, you are trying to build your own structure that reflects the needs of your application better. The problem, of course, is that you now have two sets of conventions: the one you crafted for your application, and the one you inherited from Rails. Only the former is actually valuable, and the latter is nothing but a burden.
In his talk “Deconstructing the Framework,” Gary Bernhardt says that separating everything into models and controllers is not much of a design, and suggests a very different arrangement. I highly recommend you watch his talk to see how much Rails controllers are actually responsible for. A non-trivial application has many different concerns and separating them into just controllers and models is overly simplistic.
Gary Bernhardt is not the only one. Pretty much every experienced Rails developer has their “right way” of writing Rails apps, which usually boils down to “Write your application as if Rails were not even there. So don’t put a lot of code into controllers and models.”.
Does it mean that Rails is bad? Does it mean developers using Rails are not expert programmers? No! Obviously, there are a lot of expert programmers using this framework, and for many projects the provided structure can actually work alright. For many others, however, especially for long-lived ones, this is not the case.
Similarly, Ember looks like a great tool for certain kinds of problems, and it’s definitely worth learning. But although it is too early to say, it seems to me that many Ember applications are going to have the same problems that Rails applications have.
CAPABILITIES A LA CARTE
I think that frameworks which provide capabilities a la carte are better suited for long-lived applications, and can be used more effectively by expert programmers. Conventions still have to be present, but I do not think they should be enforced and baked into the framework. It may be harder to set up, but it is easier to evolve when the needs of your application change (and they will).