4 ms·

MVC is a simple concept. You don’t need a framework to organize your modules. You can easily do MVC in Js from a vanilla setup. As another commentor suggested,

MVC is a simple concept. You don’t need a framework to organize your modules. You can easily do MVC in Js from a vanilla setup. As another commentor suggested, maybe MVC isn’t the right abstraction for the need. That’s the balance in my experience. Sometimes it makes sense, sometimes not. In the end make the compromise that allows you to develop with high reasoning ability and iterate from there.

meesterdude 9y ago
> Sometimes it makes sense, sometimes not. for at least 90% of the problems out there, its the the best approach. There are a lot of design patterns out there, but you can do a lot with MVC. From what i've seen, the reason developers tend to shy away from it is because it's TOO simple. They don't feel proud of it, because its so cut and dry. They want to create something unique and interesting and challenging, even if a simple solution would do just fine. But it's not a balance, or a 50/50 sort of decision making. Really, MVC should be your first choice, and you better have a really good reason for it to not be, and a really viable alternative.
- throwanem 9y ago
  This sounds a bit like having a hammer, and seeing at least 90% of everything as a nail. Not that I don't find the MVC architecture useful - but really, it is hardly the only valid or reasonable approach, and your speculations on why people choose other approaches strike me as rather ill thought out besides.
  - ryanbrunner 9y ago
    On the other hand, if you find you need new complex told for every job you work on, you might be choosing those tools out of self interest rather than what's most effective. To extend the analogy to its breaking point, just because some people treat every problem as a nail too be fixed with a hammer doesn't mean that you can't use a hammer if you genuinely need to push in a nail.
    - throwanem 9y ago
      Sure, untrammeled neophilia is a problem too, but that's not what we're discussing here, either. No one is saying that MV* is never useful, only that it's not the be-all end-all that the comment I chose to interrogate presented it as being. If we were discussing untrammeled neophilia, though, I'd note that in a fast-moving field it merits the professional to keep up a lively familiarity with the new tools which will likely soon deprecate the old, and it likewise merits the organization invested in such a field to avoid letting that investment grow so stale that it becomes difficult to find good people to work with it. There's really nothing here that hasn't happened with almost any other software specialization over the last few decades. It's only that it happens faster now, because everything happens faster now. There can be a certain fatigue in that, and from the outside - or from the perspective of one who has suddenly noticed that the world has moved on while he has not - it can seem as though there's nothing to it but new shiny things for new shiny things' sake. I have not found it so; instead I find that today's tools enable those who know how to use them to do more things, better, and faster, than yesterday's tools could support - and I confide that tomorrow's tools will improve the situation still further. But perhaps my own perspective is the one that's flawed.
      - marcosdumay 9y ago
        > the new tools which will likely soon deprecate the old Aren't you assuming a bit too much? What normally happens is that those new tools are deprecated sooner than the old ones they are replacing.
macspoofing 9y ago
>MVC is a simple concept. You don’t need a framework to organize your modules. If you're writing 1000 lines of throwaway code I agree with you. If you're writing a 100,000 lines of code that is meant to be supported for years - then I disagree wholeheartedly.
- beaconstudios 9y ago
  I think the move away from MVC frameworks and the move towards microservices go hand in hand. MVC frameworks are usually better suited to monolithic apps and that's just not the way things are done at the moment, for better or worse.
- dfischer 9y ago
  Maybe we're not aligned in what I'm trying to communicate. You can create a simple MVC abstraction without a framework. It's just separation of modules and their appropriate concern.
acjohnson55 9y ago
Gotta disagree with you there, given the number of frameworks that interpret MVC dramatically differently. I actually don't think it makes sense as a paradigm for server programming to begin with, and we've been trying to shoehorn the M, V, and C on to constructs that are a different thing entirely.

meesterdude 9y ago

> Sometimes it makes sense, sometimes not. for at least 90% of the problems out there, its the the best approach. There are a lot of design patterns out there, but you can do a lot with MVC. From what i've seen, the reason developers tend to shy away from it is because it's TOO simple. They don't feel proud of it, because its so cut and dry. They want to create something unique and interesting and challenging, even if a simple solution would do just fine. But it's not a balance, or a 50/50 sort of decision making. Really, MVC should be your first choice, and you better have a really good reason for it to not be, and a really viable alternative.

throwanem 9y ago
This sounds a bit like having a hammer, and seeing at least 90% of everything as a nail. Not that I don't find the MVC architecture useful - but really, it is hardly the only valid or reasonable approach, and your speculations on why people choose other approaches strike me as rather ill thought out besides.
- ryanbrunner 9y ago
  On the other hand, if you find you need new complex told for every job you work on, you might be choosing those tools out of self interest rather than what's most effective. To extend the analogy to its breaking point, just because some people treat every problem as a nail too be fixed with a hammer doesn't mean that you can't use a hammer if you genuinely need to push in a nail.
  - throwanem 9y ago
    Sure, untrammeled neophilia is a problem too, but that's not what we're discussing here, either. No one is saying that MV* is never useful, only that it's not the be-all end-all that the comment I chose to interrogate presented it as being. If we were discussing untrammeled neophilia, though, I'd note that in a fast-moving field it merits the professional to keep up a lively familiarity with the new tools which will likely soon deprecate the old, and it likewise merits the organization invested in such a field to avoid letting that investment grow so stale that it becomes difficult to find good people to work with it. There's really nothing here that hasn't happened with almost any other software specialization over the last few decades. It's only that it happens faster now, because everything happens faster now. There can be a certain fatigue in that, and from the outside - or from the perspective of one who has suddenly noticed that the world has moved on while he has not - it can seem as though there's nothing to it but new shiny things for new shiny things' sake. I have not found it so; instead I find that today's tools enable those who know how to use them to do more things, better, and faster, than yesterday's tools could support - and I confide that tomorrow's tools will improve the situation still further. But perhaps my own perspective is the one that's flawed.
    - marcosdumay 9y ago
      > the new tools which will likely soon deprecate the old Aren't you assuming a bit too much? What normally happens is that those new tools are deprecated sooner than the old ones they are replacing.

macspoofing 9y ago

>MVC is a simple concept. You don’t need a framework to organize your modules. If you're writing 1000 lines of throwaway code I agree with you. If you're writing a 100,000 lines of code that is meant to be supported for years - then I disagree wholeheartedly.

beaconstudios 9y ago
I think the move away from MVC frameworks and the move towards microservices go hand in hand. MVC frameworks are usually better suited to monolithic apps and that's just not the way things are done at the moment, for better or worse.
dfischer 9y ago
Maybe we're not aligned in what I'm trying to communicate. You can create a simple MVC abstraction without a framework. It's just separation of modules and their appropriate concern.

acjohnson55 9y ago

Gotta disagree with you there, given the number of frameworks that interpret MVC dramatically differently. I actually don't think it makes sense as a paradigm for server programming to begin with, and we've been trying to shoehorn the M, V, and C on to constructs that are a different thing entirely.