Although client-side MVC may indeed have been a bad choice for the development of Charm, I disagree with the author's conclusion that it's an inferior design pattern for SaaS web apps as a whole.
Most of his criticisms are invalid:
>> ...and if you use something like Ember (which we didn’t), it’s even worse as all applications using it practically look the same
This seems strange to me. Client-side MVC frameworks like Ember and Backbone have absolutely no effect on the appearance of your application at all.
>> We’ve spend a lot of time getting Backbone to work properly, and the ease-of-use quickly deteriorates when your models get more complex
Backbone is imperfect, but this is hardly a point against client-side MVC as a whole.
>> What you end up with is building a layer cake that doesn’t add any value and slows down development. Especially when you’re starting out and need to stay flexible you don’t want to have too much code around—and Rails is great for that, but… adding a JSON API layer and basically a second application that runs on the client is annihilating this advantage for you.
This, I think, is his strongest point. There certainly is extra code you need to write for applications that rely heavily on front-end code. But, on the flip side, there are advantages, too. For example, you tend to have a significantly snappier user interface without having to resort to complex and error-prone nested caching schemes. There's also the beneficial side-effect that you'll end up testing your JSON API very robustly.
At the end of the day, the "correct" answer is likely the boring one: the pattern you should use depends heavily on personal constraints such as who you are, what you're familiar with, and what you're building.
i'm not sure who is right (having been in both sides of the issue) but we can all agree on this one thing. client side MVC frameworks like backbone.js, knockout, angular, have helped front-end devs earn a "lot" more money than ever before. so you really can't fault them for using these frameworks regardless of if it's good or bad. :)
> For example, you tend to have a significantly snappier user interface without having to resort to complex and error-prone nested caching schemes.
Depends on how you define "snappy"… the ability to use a lot of seemingly live interactions? Yes, but…
We found that all the client-side templating was a client-side slow-down. Charm did not have a ultra simple UI like Twitter (not that they're a fabulous example of client-side MVC success, but there you go).
Which is why sending packets of HTML would actually be faster. Insertion of HTML is faster on the client-side. The exception would be if you're sending a LOT of HTML, vs the amount of bits the JSON formatting takes up. Depends on where the complexity is.
We didn't have server-side performance problems for rendering.
Most of his criticisms are invalid:
>> ...and if you use something like Ember (which we didn’t), it’s even worse as all applications using it practically look the same
This seems strange to me. Client-side MVC frameworks like Ember and Backbone have absolutely no effect on the appearance of your application at all.
>> We’ve spend a lot of time getting Backbone to work properly, and the ease-of-use quickly deteriorates when your models get more complex
Backbone is imperfect, but this is hardly a point against client-side MVC as a whole.
>> What you end up with is building a layer cake that doesn’t add any value and slows down development. Especially when you’re starting out and need to stay flexible you don’t want to have too much code around—and Rails is great for that, but… adding a JSON API layer and basically a second application that runs on the client is annihilating this advantage for you.
This, I think, is his strongest point. There certainly is extra code you need to write for applications that rely heavily on front-end code. But, on the flip side, there are advantages, too. For example, you tend to have a significantly snappier user interface without having to resort to complex and error-prone nested caching schemes. There's also the beneficial side-effect that you'll end up testing your JSON API very robustly.
At the end of the day, the "correct" answer is likely the boring one: the pattern you should use depends heavily on personal constraints such as who you are, what you're familiar with, and what you're building.