5

Originally, I started off doing jQuery plugins, then moved onto Backbone.js applications, then been experimenting with MicroJS MVC modules, but these days I'm even wondering if there is any need for them at all.

Recently, I've been prototyping a new application, and the code is slim, sleek, and beautiful. I then proceeded to rewrite it over 3 hours into a Backbone.js application, and the code turned away from its fitness model petiteness, into a bloated, complex, and ugly mess.

The problem is, these days, this always happens. As soon as the MVC/MV* architecture is introduced, it all goes to puke.

I'm wondering if the day and age of requiring these things on the client-side are over now, now that browsers are actually quite capable beings, maybe we don't need all the bloat of MV* frameworks anymore. What are your thoughts? Has others run into this? To MVC, or not MVC?

Improve this question
5
  • Gosh, thanks for the heads up about this technology, ref: microjs.com/#micro
    – Elliptical view
    Commented Jan 18, 2014 at 15:10
  • 3
    "now that browsers are actually quite capable beings, maybe we don't need all the bloat of MV* frameworks anymore." I don't understand this question. What do improvements in the DOM have to do with structuring your code for separation of concerns?
    – user16764
    Commented Jan 18, 2014 at 16:58
  • 1
    @user16764 most models in MVC frameworks are simply containers around javascript objects with getters and setters that emit events — this is a lot of boilerplate over just working with the objects directly, but has been a necessary evil until recently. Now with modern browsers, we have mutation observers, proper getters/setters, allowing us to write proper models without MVC frameworks. The same goes for separation of concerns, templating, views, etc. The browser is becoming more capable, deprecating boilerplate of MVC frameworks, to the point where it's questionable if there is anything left.
    – balupton
    Commented Jan 22, 2014 at 18:42
  • 1
    @user16764 youtu.be/DH1vTVkqCDQ is a good presentation of this
    – balupton
    Commented Jan 22, 2014 at 18:44
  • Maybe your issue is the common observation that Backbone is a very boilerplate-heavy solution. Which may be why it has been superceded in the intervening years.
    – Jimmy Breck-McKye
    Commented Jul 2, 2015 at 9:25

4 Answers 4

Reset to default
10

Maybe your applications aren't very big? I remember the first big app I co-wrote, it consisted only of a large number of complex jQuery plugins. There was no separation of concerns, the code was convoluted, testing it was almost impossible.

The next app we wrote in Backbone. It gave us a basic structure to build upon. Obviously, Backbone introduced its own share of problem but it solved a lot more.

Our problems mainly concerned reacting to model & view changes, we started to have a large number of events & handlers hard to control. Even then, it was heaven compared to what we had in the previous app!

We decided to rewrite the app in AngularJS (personal preference, you can substitute Angular for Ember in this paragraph and arguments will probably stay). It allowed us to make our client code 40% smaller and so much easier to maintain; testability was a bonus too. We could focus more on the app logic than on manual DOM modifications.

To summarize, my experience is contrary to yours. I'd think similarly to you in case of simple sites since MVC always introduce some boilerplate and you need certain application size to experience the benefits.

Improve this answer
5

It depends.

MVC is a visual design pattern that makes it easier to swap out UI technology over the life of an application.

So you need to ask yourself:

Are you throwing out a down-and-dirty little web application that you're never going to come back to? If so, then don't bother with MVC. Seriously.

Or are you writing a substantial web app that will have a number of views, and potentially even a measure of logic controlling how a user navigates between pages? MVC starts looking a lot more attractive in this case. It increases your chances of being able to re-use controllers, and perhaps even a chance at re-using some of the partial HTML pages you write.

But it's easier making a decision when you're looking at the two extremes. If your app is somewhere in the middle, then I would suggest you look at the future. If you hope it will grow into something or if you know you'll keep coming back to working on the application, then I would still recommend MVC. Yes, there is a cost to creating and maintaining the scaffolding to support things. But that scaffolding helps promote separation of concerns. And that separation is what will make your future changes a lot easier to do.

Improve this answer
2

I think you are asking the wrong question. Its not MVC or not to MVC. I think a seperation of concerns is always a good idea. But do you want to use a framework for that? You can also write MVC in javascript without using frameworks for that.

When you are doing backend stuff in .NET for example I think the MVC framework is great. However, the backend of a website is stateless, so the structure is relatively simple compared to the frontend. You dont have to worry about callbacks or state. Thats why the one-size-fits-all MVC frameworks on the backend work.

The frontend is more complex. Most javascript frameworks i have seen are enforcing a particularly design. Most javascript MVC dont add that much anyway. Most of those frameworks automatically bind your events at the view side, which means you have less control in your controllers and your views are coupled to the controller and in proper MVC it should be the other way around. Another problem is that in GUI code a lot of times you have a component in a component (in maybe another component) and you want to abstract and reuse these components. Most MVC frameworks only allow one layer of abstraction (which is the result of the controllers not having enough control).

Javascript is a really powerful language and you can write great code without a framework. Personally i learned the most about the book Javscript: the Good Parts and reading up a bit about javscript design patterns.

Improve this answer
-2

I write all my applications in Delphi (As a layer of abstraction), I don´t want and don´t need Javascript or HTML, although the framework generates them for me. We program in layers abstraction since we left assembler.

I've also written about these sucking times, of lego applications.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.