October 2, 2013 at 13:27Why we switched to Marionette.js
If you look at the history of desktop applications, you can see that it started with powerful servers that could send text screens to thin clients. Thin clients gave a command that the server processed and then sent a new screen back to the client.
Over time, the equipment became cheaper and we came to the current model, when the client does a significant part of the work, and communicates with the server only to get information, save information or give a command that should be run in a secure, controlled environment.
Now, if you think about it, in those days it was easier to develop, due to the fact that all users were equally limited by the hardware.
Unfortunately (for developers), the restrictions imposed by this model are also completely unacceptable to end users. They want responsive, fast, beautiful software, which is almost impossible in conditions when any small action leads to a request-response to a remote server.
You can see a similar evolution in web development. We are in a state of paradigm shift, and the further you go, the harder it will be for applications written in the old paradigm. Why use something that is not responsive and gives a little interactivity when we have alternatives spared it?
UI architecture is a very difficult design problem, and even if large companies have invested millions of dollars in its solution for years, we still don’t even have “One Right Way” to do this. Many JavaScript “MVC” frameworks (this is almost as bad a term as server MVC frameworks) have appeared over the past years and are fundamentally different in how to apply the ideas of UI architecture of the last 50 years to the web.
We tried many frameworks, but for brevity, I will describe the four most popular: Backbone, Ember, Knockout, and Angular.
Before starting, I want to say that all these are really amazing projects that have deserved popularity. There is no such thing as a “Silver Bullet” in development that would be good in all situations and problems, and each of these frameworks has strengths and weaknesses.
We have (approximately) 250 thousand lines of code for an industrial Rails application. It spent most of its life following the Rails Path, and we learned a lot from this. The application contains an unrealistic amount of business logic. Thus, scalability and flexibility were two key criteria that guided us when choosing a framework.
Based on the documentation and talk by Yehuda Katz (wycats) about Ember.js, this is basically an attempt to do Rails on the client side.
Ember is the most ambitious framework available now and its strengths are obvious. It deprives you of a choice in some cases, and it can be quite convenient. In particular, I like their approach to routing (State Manager / StateManager), I think this is much better than other implementations.
The weakness of Ember is the result of its advantages; if you do not want to follow the path of Ember - hard times come for you. If you encounter a problem, then you are dealing with an extremely complex framework, and most likely you will not be able to quickly solve the problem. Ember has just reached version 1.0 and will change significantly in the coming years. With frameworks that have such a level of presence in every aspect of your code, updating can be a difficult test (it took us more than a year to finish upgrading Rails to the third version).
The last straw for me was what control Ember has over your architecture. We have enough skills to make our own choices, so I believe that working with so many restrictions on us is a bad choice.
Angular uses an approach whereby HTML and JavaScript do not have key things that make it more suitable for creating complex interfaces. In the case of JavaScript, what you need are observable objects. For HTML, the missing part is some form of templating. Since both are extensible languages, what Angular does is add features.
I am a big fan of Angular. It provides a transparent separation between representations and business logic, a component implementation that combines behavior and structure — what the current web really needs. It also contains Dependency Injection framework, which many developers consider redundant, but I think this is a good idea.
The place when I stopped agreeing is how template implementation is implemented. I have been engaged in web development since 2000, and during this time I have seen a steady tendency to distinguish between three parts of web technology: style, behavior and structure. I saw (and was part of) this movement and I think things that encourage behavior in HTML and HTML in JavaScript is a bad way. After all, what's the difference between
and
In environments like Xcode, I have no problem with this style of binding in the view, since the “view” is not a code for me, but a design surface. But since we are building the web differently, I consider this a bad development direction.
I would not even consider this a weakness, but rather a difference in approaches. I think Angular's weakness is this: a cumbersome API, the fact that web standards go in a different direction than Angular, and that abstractions are quite fragile. It's easy enough to be outside the regulated Angular world when you need a deep understanding of how this works, and where / how to come back.
The decisive minus for me was how difficult it was to make my own directive, which I consider to be the most valuable feature of the whole framework. Over the course of my career, the only platform that has approached the level of torment when trying to expand it is the server controls in ASP.net WebForms. This is a solvable problem, and I think if we were now at the point where Angular reached the second or third version, that would be my choice.
Knockout takes the Microsoft MVVM-inspired frontend approach. They have a powerful language for databinding, and binding html to view models. They have a basic router, and that’s all. Knockout is not so much a “framework" as a good library for data binding.
I think the ideal use for Knockout is when you make a “hybrid” application, when you have the interaction between page reloads, but the server still holds most of the logic. If this is your case, then you have modest needs in the client side, and the separation of state and behavior is most likely what you need.
Knockout's weakness is that if you need a significant amount of client logic, this will become part of its solution.
Backbone is the most popular front-end library of this type, but also the simplest. The Backbone philosophy is to provide the minimum set of things needed to structure front-end code on the web. You can learn to use Backbone very quickly (and read the code base from start to finish in an hour), due to its simplicity.
You should use Backbone when you have modest needs (or initially moderate, but slowly growing). Backbone is even more a philosophy than a framework. Backbone also has a surprisingly active community, which means you can “build your own framework” by choosing from a variety of third-party extensions and libraries. Backbone is very JavaScript-based, that is, if you understand the language you are writing in, you will understand the framework, as it does everything in the style of JavaScript.
The weakness of Backbone is that it really doesn’t do much on its own, and you do yourself a bad service if you don’t know what to connect to it. This “JavaScript-ness” can also be a hindrance, since many “web developers” have scant knowledge of web technology, and if you are one of them, you can easily get lost with Backbone.
Marionette argues that if Backbone offers the minimum necessary to structure any type of application, large applications end up with a huge amount of boilerplate code. Marionette provides the framework needed by these kinds of applications, and also provides guidance on how to organize large amounts of code.
The reason we opted for Marionette was their approach to organizing code, which in many respects coincides with ours; separation of large blocks of code into smaller ones that communicate with each other using well-defined and simple interfaces. Separation of management and computing, to make the code of representations as declarative as possible, and code management - as high as possible. And also follow the established patterns of working with large and complex code bases.
Marionette solves the biggest Backbone problem - all this boilerplate code in the views. It is also easy to build your own component architecture (which is too complicated right now in Angular), and get a minimal structure for everything you need (unlike Knockout). It will take work to finish a good architecture and build the infrastructure, but given our requests and the current state of other libraries, I think this is a good compromise.
This is an assessment of the specific situation and point of view, and, I believe, that makes sense for our product and our development team. As I said at the beginning, all of these options are great for their own purposes. If someone tells you, “I used the X framework and it’s bad, but now I use the Y framework and feel like I'm traveling through the sunny fields on a magic horse.”, Most likely he just made the wrong choice for the first time.
Original Author Matt Briggs.
Over time, the equipment became cheaper and we came to the current model, when the client does a significant part of the work, and communicates with the server only to get information, save information or give a command that should be run in a secure, controlled environment.
Now, if you think about it, in those days it was easier to develop, due to the fact that all users were equally limited by the hardware.
Unfortunately (for developers), the restrictions imposed by this model are also completely unacceptable to end users. They want responsive, fast, beautiful software, which is almost impossible in conditions when any small action leads to a request-response to a remote server.
Web Interface Evolution
You can see a similar evolution in web development. We are in a state of paradigm shift, and the further you go, the harder it will be for applications written in the old paradigm. Why use something that is not responsive and gives a little interactivity when we have alternatives spared it?
UI architecture is a very difficult design problem, and even if large companies have invested millions of dollars in its solution for years, we still don’t even have “One Right Way” to do this. Many JavaScript “MVC” frameworks (this is almost as bad a term as server MVC frameworks) have appeared over the past years and are fundamentally different in how to apply the ideas of UI architecture of the last 50 years to the web.
Choosing a framework
We tried many frameworks, but for brevity, I will describe the four most popular: Backbone, Ember, Knockout, and Angular.
Before starting, I want to say that all these are really amazing projects that have deserved popularity. There is no such thing as a “Silver Bullet” in development that would be good in all situations and problems, and each of these frameworks has strengths and weaknesses.
Our situation
We have (approximately) 250 thousand lines of code for an industrial Rails application. It spent most of its life following the Rails Path, and we learned a lot from this. The application contains an unrealistic amount of business logic. Thus, scalability and flexibility were two key criteria that guided us when choosing a framework.
Ember.js
Based on the documentation and talk by Yehuda Katz (wycats) about Ember.js, this is basically an attempt to do Rails on the client side.
Ember is the most ambitious framework available now and its strengths are obvious. It deprives you of a choice in some cases, and it can be quite convenient. In particular, I like their approach to routing (State Manager / StateManager), I think this is much better than other implementations.
The weakness of Ember is the result of its advantages; if you do not want to follow the path of Ember - hard times come for you. If you encounter a problem, then you are dealing with an extremely complex framework, and most likely you will not be able to quickly solve the problem. Ember has just reached version 1.0 and will change significantly in the coming years. With frameworks that have such a level of presence in every aspect of your code, updating can be a difficult test (it took us more than a year to finish upgrading Rails to the third version).
The last straw for me was what control Ember has over your architecture. We have enough skills to make our own choices, so I believe that working with so many restrictions on us is a bad choice.
Angular.js
Angular uses an approach whereby HTML and JavaScript do not have key things that make it more suitable for creating complex interfaces. In the case of JavaScript, what you need are observable objects. For HTML, the missing part is some form of templating. Since both are extensible languages, what Angular does is add features.
I am a big fan of Angular. It provides a transparent separation between representations and business logic, a component implementation that combines behavior and structure — what the current web really needs. It also contains Dependency Injection framework, which many developers consider redundant, but I think this is a good idea.
The place when I stopped agreeing is how template implementation is implemented. I have been engaged in web development since 2000, and during this time I have seen a steady tendency to distinguish between three parts of web technology: style, behavior and structure. I saw (and was part of) this movement and I think things that encourage behavior in HTML and HTML in JavaScript is a bad way. After all, what's the difference between
and
ng-click="foo();"
In environments like Xcode, I have no problem with this style of binding in the view, since the “view” is not a code for me, but a design surface. But since we are building the web differently, I consider this a bad development direction.
I would not even consider this a weakness, but rather a difference in approaches. I think Angular's weakness is this: a cumbersome API, the fact that web standards go in a different direction than Angular, and that abstractions are quite fragile. It's easy enough to be outside the regulated Angular world when you need a deep understanding of how this works, and where / how to come back.
The decisive minus for me was how difficult it was to make my own directive, which I consider to be the most valuable feature of the whole framework. Over the course of my career, the only platform that has approached the level of torment when trying to expand it is the server controls in ASP.net WebForms. This is a solvable problem, and I think if we were now at the point where Angular reached the second or third version, that would be my choice.
Knockout.js
Knockout takes the Microsoft MVVM-inspired frontend approach. They have a powerful language for databinding, and binding html to view models. They have a basic router, and that’s all. Knockout is not so much a “framework" as a good library for data binding.
I think the ideal use for Knockout is when you make a “hybrid” application, when you have the interaction between page reloads, but the server still holds most of the logic. If this is your case, then you have modest needs in the client side, and the separation of state and behavior is most likely what you need.
Knockout's weakness is that if you need a significant amount of client logic, this will become part of its solution.
Backbone.js
Backbone is the most popular front-end library of this type, but also the simplest. The Backbone philosophy is to provide the minimum set of things needed to structure front-end code on the web. You can learn to use Backbone very quickly (and read the code base from start to finish in an hour), due to its simplicity.
You should use Backbone when you have modest needs (or initially moderate, but slowly growing). Backbone is even more a philosophy than a framework. Backbone also has a surprisingly active community, which means you can “build your own framework” by choosing from a variety of third-party extensions and libraries. Backbone is very JavaScript-based, that is, if you understand the language you are writing in, you will understand the framework, as it does everything in the style of JavaScript.
The weakness of Backbone is that it really doesn’t do much on its own, and you do yourself a bad service if you don’t know what to connect to it. This “JavaScript-ness” can also be a hindrance, since many “web developers” have scant knowledge of web technology, and if you are one of them, you can easily get lost with Backbone.
Backbone.Marionette
Marionette argues that if Backbone offers the minimum necessary to structure any type of application, large applications end up with a huge amount of boilerplate code. Marionette provides the framework needed by these kinds of applications, and also provides guidance on how to organize large amounts of code.
The reason we opted for Marionette was their approach to organizing code, which in many respects coincides with ours; separation of large blocks of code into smaller ones that communicate with each other using well-defined and simple interfaces. Separation of management and computing, to make the code of representations as declarative as possible, and code management - as high as possible. And also follow the established patterns of working with large and complex code bases.
Marionette solves the biggest Backbone problem - all this boilerplate code in the views. It is also easy to build your own component architecture (which is too complicated right now in Angular), and get a minimal structure for everything you need (unlike Knockout). It will take work to finish a good architecture and build the infrastructure, but given our requests and the current state of other libraries, I think this is a good compromise.
UI is complicated and there is no Silver Bullet
This is an assessment of the specific situation and point of view, and, I believe, that makes sense for our product and our development team. As I said at the beginning, all of these options are great for their own purposes. If someone tells you, “I used the X framework and it’s bad, but now I use the Y framework and feel like I'm traveling through the sunny fields on a magic horse.”, Most likely he just made the wrong choice for the first time.
Original Author Matt Briggs.