The Model View Controller architecture is of course a very popular programming paradigm, so much so that it nearly feels like heresy to speak out against it. In some ways I feel like I embrace the concept, so this post is really more about where I believe it has overreached.
Firstly, where I embrace it is at a pre-programming level. The Model is your database schema, or maybe the markdown syntax if you use file storage. The model is whatever you commit to permanent storage and the patterns you derive from that. The View is of course your web browser, and if you want to be more specific it's the html that your browser renders. Here's the catch though: the Controller is also the web browser. More specifically it's the actionable subset of html on the page, either via controls built into static html itself, or the event enabled html added via javascript and css.
So the first and most fundamental problem I have with MVC on the web is the conflation of the view and controller, because in reality we have both and neither. Instead we have a far more powerful tool than was first imagined when the phrase was coined, a dynamic rendering tool capable of seamlessly integrating both a view and the controls required to manipulate that view into one user interface.
The more insidious problem with MVC on the web is it's filtration as a concept into web frameworks. If you choose to write code with the help of a framework, you are choosing to make a trade-off between a set of constraints that are placed on you and the tools that framework makes available to you. I don't have a problem with frameworks if you are making an informed choice to do this, but as Kevin Marks said on indieweb chat the other day, "you call a library, but a framework calls you".
The problem with the constraints of a framework that have embraced an MVC paradigm is that you have to operate within this artificial distinction. This is where I see the overreach occurring. If it wasn't such an obvious separation of roles, maybe it could be ignored, but instead it has become the main feature of many frameworks and pushed as far as possible. Today's javascript rendered client frameworks being the latest and greatest example.
Enough of the hating, what else is possible?
I like the idea of clean distinctions between concepts when warranted. A great phrase from the IndieWeb is "if you can't curl it, it's not on the web". This prioritizes outputting clean, renderable html to whoever or whatever (service) is requesting it. Starting from this point makes me think that static site generators are heading in the right direction.
From a coding point of view, I believe that simple pragmatic programming is a great place to start. There's nothing wrong with writing opinionated software, but what you bake in from the beginning is important. Functional and Object Oriented programming is great when the linkage that flows between your code makes sense. What that flow should embody on the web however is fast load times, clean output, simple and expressive api's and an interconnectedness with other projects that makes the sum greater than the parts.
That's what I'm working on with my project dobrado, I know I've got a long way to go!
The Problem with MVC on the Web
Firstly, where I embrace it is at a pre-programming level. The Model is your database schema, or maybe the markdown syntax if you use file storage. The model is whatever you commit to permanent storage and the patterns you derive from that. The View is of course your web browser, and if you want to be more specific it's the html that your browser renders. Here's the catch though: the Controller is also the web browser. More specifically it's the actionable subset of html on the page, either via controls built into static html itself, or the event enabled html added via javascript and css.
So the first and most fundamental problem I have with MVC on the web is the conflation of the view and controller, because in reality we have both and neither. Instead we have a far more powerful tool than was first imagined when the phrase was coined, a dynamic rendering tool capable of seamlessly integrating both a view and the controls required to manipulate that view into one user interface.
The more insidious problem with MVC on the web is it's filtration as a concept into web frameworks. If you choose to write code with the help of a framework, you are choosing to make a trade-off between a set of constraints that are placed on you and the tools that framework makes available to you. I don't have a problem with frameworks if you are making an informed choice to do this, but as Kevin Marks said on indieweb chat the other day, "you call a library, but a framework calls you".
The problem with the constraints of a framework that have embraced an MVC paradigm is that you have to operate within this artificial distinction. This is where I see the overreach occurring. If it wasn't such an obvious separation of roles, maybe it could be ignored, but instead it has become the main feature of many frameworks and pushed as far as possible. Today's javascript rendered client frameworks being the latest and greatest example.
Enough of the hating, what else is possible?
I like the idea of clean distinctions between concepts when warranted. A great phrase from the IndieWeb is "if you can't curl it, it's not on the web". This prioritizes outputting clean, renderable html to whoever or whatever (service) is requesting it. Starting from this point makes me think that static site generators are heading in the right direction.
From a coding point of view, I believe that simple pragmatic programming is a great place to start. There's nothing wrong with writing opinionated software, but what you bake in from the beginning is important. Functional and Object Oriented programming is great when the linkage that flows between your code makes sense. What that flow should embody on the web however is fast load times, clean output, simple and expressive api's and an interconnectedness with other projects that makes the sum greater than the parts.
That's what I'm working on with my project dobrado, I know I've got a long way to go!