Hacker News Reader

Comment by dasil003 | Hacker News Reader

I don't see the point in making these subtle pattern distinctions. The model notifying the view is not significant enough of an architectural criteria to merit its own term. I submit that there are dozens of such architectural variances between MVC frameworks and that defining high-level terms to codify those differences isn't helpful. I'll even take it a step further and suggest that a focus on taxonomy diminishes ones ability to think fluidly about the low-level architecture and how to improve it to solve different problems.

This is quite different from (for example) the debates about the definition of REST. In that case there is a seminal paper and all kinds of subtle points leading to material benefits in web apps. What does Model2 have to teach us?

View on HN

Because it's not subtle. In particular, once you introduce "client/server" into the pattern, you've walked into a completely different domain, with completely different problems, solutions, and patterns, and in particular you suddenly have a great deal of concern over matters of latency and bandwidth, which MVC has no particular consideration for, because the entire paradigm was built on the desktop.

Just like trying to hide network-based RPC behind the same abstraction layer as a simple function call is a profoundly bad idea, inviting a pattern of thought into your head which will encourage you to neglect the client-server component of your solution is also a bad idea. Even if you think it won't fool you that badly, why let it fool you at all? Why not actually think of it in the proper terms?

Some combination of MVC and client-server is possible, but even then further specification is required to be clear about what you're doing, because the client/server can be placed in arbitrary locations in patterns, and particularly for web environments one must be careful to specify which components of the various elements are the canonical ones, where they live, and which are ultimately just cached copies.

Further it appears to be empirically the case that people who get MVC-happy begin to mistake MVC for being the one and sole and singular definition of good design, and start sticking it places it doesn't belong, while neglecting the proper design practices that should be used. MVC is actually a brain bug; seeing someone go on about MVC is an almost 100% accurate marker for someone who doesn't deeply understand design at all, and just has a hammer and is hitting things with it.

Your reply is spot on, but wasn't the time raise this issue 7 years ago when Rails was released? Or maybe earlier if Java frameworks were self-described as MVC? To try to push Model2 now seems like an impossible task with almost no reward. It's like complaining about common usage of the word "hacker". It serves no one to take up arms, just let it be and move forward. Maybe coin a new term.

I've been raising it for a couple of years now.

And my beef isn't the terminology issue, though I would observe that if we decide to just declare that everybody using "MVC" is using it correctly, we immediately dilute the term to the point that it has no meaning whatsoever. It's more the brain bug part.

I wouldn't want to "fix" MVC usage, we'd be much better off simply eliminating it. It's almost never used in a productive manner. As for what to replace it with, that's easy: DRY, Don't Repeat Yourself. The particular structure of the code is always particular to your local problem, rarely fits into any particular paradigm when considered as a whole anyhow, and the real design criterion is DRY. I can't quite say it's impossible to have badly-designed code that is also completely DRY, but I would imagine it must be a challenge.

I don't see how you can call this a subtle pattern distinction.

MVC contains 3 words: 'model', 'view' and 'controller'. These interact completely different in "real" MVC and in most "MVC" web frameworks.

The point isn't the observer pattern; that's just a tool. The point is that in MVC, only the controller talks to the model. The model in turn notifies the view, but doesn't know anything about it. In Rails & co, the controller knows a lot about the view. Also, there typically is only one view per controller. These limitations are not there in real MVC, because the controller does not know anything about the view.

This nearly complete independence of the three components of MVC is what makes it good. Exactly this is what traditional web frameworks don't have.

Agreed. I can't find any insight or advantage in making this kind of a distinction.

The article attempts to address it by saying that people attempt to implement Model2 on a Javascript front-end. That is awkward. However, it isn't awkward because you should be using real MVC. It is awkward because Javascript is asynchronous and you want to make sure the user interaction stays responsive without devolving into spaghetti. The key insight is "asynchronous" rather than "let's do REAL MVC!"

I've seen this obsessive focus on taxonomy of solutions divorced from specific problems in domains outside computing. I suspect it's a cultural thing. Some cultures obsess over gadgets more than others. That works out until people start arguing about who has the shinier toy, instead of actually using said toys as tools.

So could one call Rails a sort of "synchronous MVC" and javascript MVC "asynchronous MVC"?

Hmm. Maybe? Seems impoverished to me.

Someone on the comments for the original article said, the big idea in Rails wasn't so much MVC as much as separation of concerns. I'm on-board with that. Thinking in that way has brought a lot of advantages for me over the years I've been working with Rails.

By extension, if the big idea is "separation of concerns", then I should be applying it in my non-Rails code too, whether that's "MVC" or not "MVC". In fact, my small taste of functional programming allowed me to play with "separation of concerns" in a different coding style, one that I've imported back into the Ruby code I write. Write functions without side-effects. Treat data as immutable. Interesting times.

> It is awkward because Javascript is asynchronous and you want to make sure the user interaction stays responsive without devolving into spaghetti.

This is exactly the feeling I've been getting recently as I foray into writing my first Chrome extension. The asynchronous nature of XHR is ending up making my code a little more spaghetti-like that I would prefer. Would you happen to have any recommended resources for possible approaches to addressing this issue?

Reply on news.ycombinator.com