1

In my experience MVC is a synonym for overflowing complexity. I found it’s more of a Monk thing (Adrian Monk) than a real helper in programming robust code.
While with a direct hacker approach you need usually one piece of code, with the MVC pattern you need (at least) three. And even if it sounds very well to have logic and representation divided – it’s a self-deception.

You will never ever achieve that goal because you can never represent something that didn’t pass your logic handlers.
So each time you implement additional functionality you will need tons of “pattern”-code. Leading to more code, more complexity, more download-time, more interfacing, harder debugging…

I don’t like it. I like the agile programming of small collaborating components (some of them actually meet the MVC concept…).

posted at 10:55 am on August 18, 2009 by proxiss

2 Yes, but...

Actually, this a very good article as it will introduce a lot of people to a very common programming acronym and concept and, like it or not websites are becoming more and more “programmable”.

However, the articles does fail to raise the problems of client-side validation – if a user has Javascript disabled or the user is a “bot” then the validation will not occur. You always need server-side validation and trying to do this in Javascript is an invitation to disaster.

What Javascript does very well is allow you to provide good user feedback in realtime – avoiding the problem of users filling out a whole form, pressing submit, waiting and then being told they’ve made some mistakes. Some of the work can be split between the browser and the server or Javascript can simply pass messages back and forth using AJAX (yuck), JSON (less yuck) and preferably SSE. Future extensions to HTML might allow browsers to implement some of this directly based on the metadata.

Most web-frameworks now provide transparent generation of this kind of code so you don’t have to worry about it yourself but it’s a very good idea to have some understanding of what’s actually going on.

@proxiss – loosely coupled components are certainly preferable but I’d rather have developers working with some standard programming model rather than hacking it every which way each time. More time is spent reading code than writing it.

posted at 11:11 am on August 18, 2009 by Charlie Clark

4

@proxiss – As your program grows in size, you will be forced to consolidate common code fragments, or code maintenance will quickly become unmanageable. The only sane way to do that is to generalize your code so that it’s re-usable, and that is exactly what MVC accomplishes. But if your program is so small that you hardly have any common code fragments, then of course you shouldn’t use MVC.

posted at 12:20 pm on August 18, 2009 by Geoffrey Lee

5 Overkill

I’ve seen the term MVC pop up over the past few years, always wondering what’s so great about it. I have yet to find an answer. I’ve worked with a couple of systems that implement a MVC methodology and trying to troubleshoot or debug MVC code ends up taking far longer than doing the same with non-MVC code. One idea behind MVC is that a system should be designed to be able to accommodate a large variety of recurring patterns when in fact, they rarely recur. Maybe I haven’t worked with MVC enough, but from the experience that I have had with it, MVC ends up creating so much obfuscation that it becomes totally unwieldy. The time it takes to develop a robust MVC far outweighs the benefits, as the time required to maintain and debug it will trump any times it saves in writing code that uses the MVC. I agree with virtually all of what proxiss wrote earlier.

To me the real issue, or problem, lies in the fact that we’re forcing people to create MVC patterns to account for shortcomings in whatever language it is that they’re using. In other words, why should we have to develop such complex structures to account for patterns that have become so commonplace? Validating email? Any language by now that is used on the web should have this built-in. Using JavaScript as an example, why after nearly 15 years of existence does it not inherently do something as simple as email validation? The problem exists in the language itself not keeping pace with demand; therefore we have to come up with workarounds until it does so.

I consider objects, functions, methods, etc. all ways to reuse code quite easily. I say the problem is that the tools we are using are not updated as often as they should be which forces us to come up with these workarounds. Elegance lies in simplicity. While MVC may have its place, I’m sure we’ll look back at some point and question what were we thinking. JavaScript is popular because it is dead simple to use, not because it can be bent into a framework.

posted at 01:02 pm on August 18, 2009 by catchmyfame

6

@catchmyfame – What you’re really arguing for is a library to handle all your commonplace patterns, such as jQuery or Dojo. A programming language itself has no place in dealing with ever-changing specifications for things like input validation. Imagine having to update your JavaScript engine every time one of the many RFC specifications change, when you could simply link to an updated library.

Try implementing a Content Management System sometime, or design a website with hundreds of dynamic pages, and you’ll see where MVC really shines. But if you don’t have the complexity to warrant it, then don’t use MVC. It’s as simple as that.

posted at 12:57 am on August 19, 2009 by Geoffrey Lee

7

Geoffrey, I did in fact just recently implement a CMS which uses a MVC and it was a nightmare to troubleshoot. Also, how often do RFC specs change? Not often. I hardly think that something as essential as email validation is too much to ask to have in a language like JavaScript.

posted at 01:27 am on August 19, 2009 by catchmyfame

8 Pleading for specialization

I agree with catchmyfame. Why bother with generalization on every single subject. I.e. PHP was encouraged enough to pack the http-post mechanism into the core engine (_POST array) – and PHP has i.e. a simple “mail()” call that does what you expect.
Seems they are not afraid of RFC changes…

On the other hand, Geoffrey, you have generalized libraries that may handle every – never needed – use case for you (like javax and javamail), but force you to write tons of code (and xml configurations) for the one simple appliance you need in 99% of all cases.

I also agree with Geofffrey – choose your tool carefully, and choose a tool that’s not too much generalized.

We’re wasting too much time with foreseeing things that never eventuate.

posted at 04:32 am on August 19, 2009 by proxiss

9

I think, the idea is very good, but in most cases the usage of a MVC principle is just an overdose of script (except in large scaled projects).

I really like the way, code is seperated in its logic functions, but in the case of JavaScript, there are better ways. I mean writing some pieces of generalized code, that give me the amount of flexibility can have nearly the same result, without making the issue that complex. (I aggree – in very large project there may be a point, you can think about the usage of a JSMVC.)

Thank you for the article. Good work.

posted at 07:25 am on August 19, 2009 by benediktr

10 Don't forget Johnny

John Resig should be mentioned somewhere in the article considering that his work alone likely accounts for 50% of the revolution in JavaScript we’ve been seeing in the last 2 years. I messed with other frameworks and, like everybody else, came to jQuery like, “Oh my god. I can’t believe it”. Without jQuery (and some help from Prototype) JavaScript wouldn’t exist anymore.

posted at 12:21 pm on August 19, 2009 by nuovo labs