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.
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.
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.
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.
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.