What web developers thought of in the noughties as being MVC doesn't scale(fishbowl.pastiche.org)
fishbowl.pastiche.org
What web developers thought of in the noughties as being MVC doesn't scale
http://fishbowl.pastiche.org/2014/05/16/no_really_what_web_developers/
80 comments
I think the reason it doesn't appear to scale is that its been misused so often. For example, what Backbone.js calls a View really isn't at all in my opinion. It's some strange combination of Model and Controller.
Or the Yii framework which is just an abortion of code through and through.
Or the Yii framework which is just an abortion of code through and through.
It's not even being misused, it's not being used at all.
MVC may be the epitome of poorly defined design patterns. It's a unicorn. No one can even tell you with certainty what a controller is, or how the hell MVC maps from a Smalltalk UI pattern to being used on a server stack. This always devolves in inane pedantic discussions. And it's too late to try to put some order in this wreck of a pattern definition, because everyone has already appropriated it for themselves and decided what it means for them.
MVC is not a pattern anymore, it's a marketing term with zero regards for correctness. It's used by framework designers to tell developers that their libraries will be familiar and easy to work with and they should totally try them out. And it's being used by that Facebook dude to agitate Rails coders and stir controversy and draw attention to their trendy new lib, and it's working flawlessly to that end. Pure marketing brilliance.
But only madness lies in the direction of trying to salvage MVC as an engineering term with any degree of correctness, and whether whatever it supposedly means is really scalable or not. It's not even worth the effort. The only lamentable consequence of the bastardization of the MVC name is that by slapping it over everything, the bulk of web devs nowadays are left with a very poor vocabulary and a very poor understanding to try to describe server architectures with.
MVC may be the epitome of poorly defined design patterns. It's a unicorn. No one can even tell you with certainty what a controller is, or how the hell MVC maps from a Smalltalk UI pattern to being used on a server stack. This always devolves in inane pedantic discussions. And it's too late to try to put some order in this wreck of a pattern definition, because everyone has already appropriated it for themselves and decided what it means for them.
MVC is not a pattern anymore, it's a marketing term with zero regards for correctness. It's used by framework designers to tell developers that their libraries will be familiar and easy to work with and they should totally try them out. And it's being used by that Facebook dude to agitate Rails coders and stir controversy and draw attention to their trendy new lib, and it's working flawlessly to that end. Pure marketing brilliance.
But only madness lies in the direction of trying to salvage MVC as an engineering term with any degree of correctness, and whether whatever it supposedly means is really scalable or not. It's not even worth the effort. The only lamentable consequence of the bastardization of the MVC name is that by slapping it over everything, the bulk of web devs nowadays are left with a very poor vocabulary and a very poor understanding to try to describe server architectures with.
You can lead a horse to water, but you can't make it drink.
I've discussed, or watched coworkers present, MVC as an idea many times. After they draw the three boxes and arrows on the whiteboard, they start winging it. You can tell someone to make three files for everything they do, but it's a whole different plane to get them to see the beauty and power of it and to go the long route sometimes to make code that won't bite them in the ass a few months later. But now we're talking about developer aptitude and professionalism, a whole different matter. Frankly, we should be discussing architectural design and code reviews if that's the problem we're on.
I've discussed, or watched coworkers present, MVC as an idea many times. After they draw the three boxes and arrows on the whiteboard, they start winging it. You can tell someone to make three files for everything they do, but it's a whole different plane to get them to see the beauty and power of it and to go the long route sometimes to make code that won't bite them in the ass a few months later. But now we're talking about developer aptitude and professionalism, a whole different matter. Frankly, we should be discussing architectural design and code reviews if that's the problem we're on.
Seeing so many web frameworks come in and mostly fail over the years makes me wonder if there isn't a inherent problem to the web development environment that is inherently harder than what we've dealt with native apps.
People have been able to be quite productive writing apps in all kinds of all frameworks: Visual Basic, Swing, Delphi... not every framework has been well regarded, but many allowed inexperienced developers to write very interactive applications successfully.
On the web, we have a whole lot more people, and they are not inherently worse than the ones that gave us those old frameworks. And yet, we have a billion little frameworks now that don't age very well, and don't really make us more productive than in the old days.
I can't blame the framework developers, or the new application developers, so the problem must be further down. Is it the DOM? Is it Javascript itself? Is it the lack of strong components? I am not sure, but I sure wonder what makes web development such a problem.
People have been able to be quite productive writing apps in all kinds of all frameworks: Visual Basic, Swing, Delphi... not every framework has been well regarded, but many allowed inexperienced developers to write very interactive applications successfully.
On the web, we have a whole lot more people, and they are not inherently worse than the ones that gave us those old frameworks. And yet, we have a billion little frameworks now that don't age very well, and don't really make us more productive than in the old days.
I can't blame the framework developers, or the new application developers, so the problem must be further down. Is it the DOM? Is it Javascript itself? Is it the lack of strong components? I am not sure, but I sure wonder what makes web development such a problem.
It's because the Web is a giant pile of hacks upon hacks. It is the ultimate manifestation of New Jersey design philosophy. Systems can only be as conceptually sound as their underpinnings allow. In this case, the broken design of the Web forces everything built on top of it to be a ridiculous mix of HTML/CSS/JS.
Users not closing their tags? It's OK, we'll complicate the parser to accommodate them. Users want to interact with what should be static documents? No problem, we'll throw a scripting language in there. Users want to interact with hardware peripherals? OK, we'll just expose that.
The real tragedy is how much of systems research has died at the hands of this crappy sentiment of Good Enough that pervades the Web. Literally everything the Web touches gets infected with Good Enough.
Users not closing their tags? It's OK, we'll complicate the parser to accommodate them. Users want to interact with what should be static documents? No problem, we'll throw a scripting language in there. Users want to interact with hardware peripherals? OK, we'll just expose that.
The real tragedy is how much of systems research has died at the hands of this crappy sentiment of Good Enough that pervades the Web. Literally everything the Web touches gets infected with Good Enough.
I upvoted you, but I disagree with you.
The Web is built on a system of hacks, but those hacks are usually temporary and we can ultimately ignore most of them eventually. I was writing JavaScript back in '98, it is much easier now (and we have CoffeeScript to make it even easier!). Browser incompatibilities are slowly going away (and we have jQuery to make it even easier!). Things that used to be hard, like organizing an application to take keyboard input and respond to property changes, are now easy with things like Ember (and soon EmberUI will be out of alpha, and common things like searchable selects, buttons, date pickers, etc., will be easier) and other JS frameworks.
I would reword it to "Good Enough For Now", because things do get fixed after the cool kids have kinda hacked around it for a while.
The Web is built on a system of hacks, but those hacks are usually temporary and we can ultimately ignore most of them eventually. I was writing JavaScript back in '98, it is much easier now (and we have CoffeeScript to make it even easier!). Browser incompatibilities are slowly going away (and we have jQuery to make it even easier!). Things that used to be hard, like organizing an application to take keyboard input and respond to property changes, are now easy with things like Ember (and soon EmberUI will be out of alpha, and common things like searchable selects, buttons, date pickers, etc., will be easier) and other JS frameworks.
I would reword it to "Good Enough For Now", because things do get fixed after the cool kids have kinda hacked around it for a while.
Why should we have to hack around it?
This is exactly the sort of defeatism and learned helplessness I was alluding to.
We've accepted this crappy universal platform because it distributes software well. Despite being in a discipline where we can easily change the tools to work better for us, we just sit here and take it.
This is exactly the sort of defeatism and learned helplessness I was alluding to.
We've accepted this crappy universal platform because it distributes software well. Despite being in a discipline where we can easily change the tools to work better for us, we just sit here and take it.
We've accepted this crappy universal platform because it is universal. Replacing something that is used by literally Billions of people is decidedly non-trivial and takes _decades_.
Not to mention that "because it distributes software well" is stated as if it isn't a huge deal. Has anything ever distributed anything so well, so cheaply, and so accessibly as the internet distributes web software?
We've accepted this crappy universal platform because it distributes software well.
Given that until very recently, the overwhelming majority of software consumers were also software producers, one can see how this attitude would be very attractive. It's New Jersey all the way down.
Given that until very recently, the overwhelming majority of software consumers were also software producers, one can see how this attitude would be very attractive. It's New Jersey all the way down.
Yeah, but it's still hacks underneath. Does building a UI in HTML, CSS, and JS feel right to you? It's awful.
I think you meant the "Internet" is a pile of hacks not just the web.
BTW I used to work on OSI based networking* - so I have seen solidly designed networking.
But some times "good enough for jazz" wins out over a more robust solution Beta vs VHS for example.
* Update apart from sprints X.400 offering that was rubbish
BTW I used to work on OSI based networking* - so I have seen solidly designed networking.
But some times "good enough for jazz" wins out over a more robust solution Beta vs VHS for example.
* Update apart from sprints X.400 offering that was rubbish
I upvoted you and I agree with you.
On my own web site, I'm on a hunt for the remnants of any CSS and javascript (mostly google site metrics blurbs) to leave only pristine and validating HTML5.
With links that work.
On my own web site, I'm on a hunt for the remnants of any CSS and javascript (mostly google site metrics blurbs) to leave only pristine and validating HTML5.
With links that work.
You could always use Java applets. These would solve a number of the problems you describe, but introduce a whole new set of problems.
* RAD (rapid application development) tools:
Visual Basic and Delphi were tools with beginner friendly programming language. We had FrontPage and Dreamweaver to design earlier HTML4 frame & table based layouts. But there are no RAD tools to create modern CSS based web page designs.
* Client only vs. client-server:
Client-server web applications are a lot harder (software architecture), than Win32 client-only.
* Consistent API:
The WinAPI that was exposed through COM was easy to understand and more consistent than the HTML, JS, CSS that has grown over the years thanks to various vendor extensions/additions (Netscape, Microsoft, etc).
* Documentation, books, articles in magazines (copy&paste examples):
We used to have good API documentation and MSDN used to have a good relevant search (no C# API result if one search for C/C++ or VB API) and an index. Various magazines had really good articles with short example source code that one could type or copy&paste (web). Books shipped with a CD-Rom with a CHM file (earlier ebook format, Windows Help) that was similar to epub/mobi but the Windows Help viewer was far superior.
* Common controls:
Windows shell offers various common controls that are available in some form in VB, Delphi. The HTML standard still offers only very limited form controls. Were is the file list control, the menu bar control, etc?? Instead every website has come up with its own menu bar - thanks to DHTML movement.
* APIs vs. Frameworks:
In the Win32 world one used libraries (in form of DLLs) and its public API. In the web world one can do the same old fashion way by using C++ like languages like PHP with its hundreds libraries (exposes C API directly and optional object oriented boilerplate API) or the framework style (Ruby on Rails, etc., house of cards). If you know what you (and your team) is doing, you know what to choose in the long term anyway.
--
Nevertheless, I kind of prefer the HTML5 web app world over the vendor-lockin yet again that is Android vs. iOS apps. And real Win32 development is uncommon lately. But I would like a innovative RAD tool, a next-gen FrontPage/Dreamweaver - something that made Visual Basic so easy to use.
Visual Basic and Delphi were tools with beginner friendly programming language. We had FrontPage and Dreamweaver to design earlier HTML4 frame & table based layouts. But there are no RAD tools to create modern CSS based web page designs.
* Client only vs. client-server:
Client-server web applications are a lot harder (software architecture), than Win32 client-only.
* Consistent API:
The WinAPI that was exposed through COM was easy to understand and more consistent than the HTML, JS, CSS that has grown over the years thanks to various vendor extensions/additions (Netscape, Microsoft, etc).
* Documentation, books, articles in magazines (copy&paste examples):
We used to have good API documentation and MSDN used to have a good relevant search (no C# API result if one search for C/C++ or VB API) and an index. Various magazines had really good articles with short example source code that one could type or copy&paste (web). Books shipped with a CD-Rom with a CHM file (earlier ebook format, Windows Help) that was similar to epub/mobi but the Windows Help viewer was far superior.
* Common controls:
Windows shell offers various common controls that are available in some form in VB, Delphi. The HTML standard still offers only very limited form controls. Were is the file list control, the menu bar control, etc?? Instead every website has come up with its own menu bar - thanks to DHTML movement.
* APIs vs. Frameworks:
In the Win32 world one used libraries (in form of DLLs) and its public API. In the web world one can do the same old fashion way by using C++ like languages like PHP with its hundreds libraries (exposes C API directly and optional object oriented boilerplate API) or the framework style (Ruby on Rails, etc., house of cards). If you know what you (and your team) is doing, you know what to choose in the long term anyway.
--
Nevertheless, I kind of prefer the HTML5 web app world over the vendor-lockin yet again that is Android vs. iOS apps. And real Win32 development is uncommon lately. But I would like a innovative RAD tool, a next-gen FrontPage/Dreamweaver - something that made Visual Basic so easy to use.
I sure wonder what makes web development such a problem.
It's not any one bit, it's the fundamental design upon which it was all built. We're stuffing applications into a document viewer.
A very good document viewer that has through the path of least resistance had more and more tacked on until it evolved into the terrible application VM we know it as today.
It's not any one bit, it's the fundamental design upon which it was all built. We're stuffing applications into a document viewer.
A very good document viewer that has through the path of least resistance had more and more tacked on until it evolved into the terrible application VM we know it as today.
I think it's because the webs "ABI/API" is so broken and inconsistent.
Delphi, Swing, Visual Basic all had fixed static targets (in the case of Delphi and VB, the Win32 API which had excellent backwards compatibility) in the case of Swing the JVM which is legendary for that.
The web "ABI/API" is just broken by comparison, the primary language is a single threaded language that has much brain damage (controversial but I'll defend it) which isn't that surprising when it wasn't designed for what we are using it for (even nominally, insert joke about Win32 API as you please).
The other issue is that because the web is so damn big it has massive inertia making it very difficult to get people to move to newer technologies, in my dream world the web would have a proper (not asm.js) secure VM in the browser that could be directly used, the "webby" bit that renders HTML/JS would just be an application in that vm and other stuff could directly target the underlying VM, can't see it ever happening though as it requires the browser vendors to simultaneously agree on supporting an open standard without screwing each other over and then sticking to it.
That would be my dream web though.
Delphi, Swing, Visual Basic all had fixed static targets (in the case of Delphi and VB, the Win32 API which had excellent backwards compatibility) in the case of Swing the JVM which is legendary for that.
The web "ABI/API" is just broken by comparison, the primary language is a single threaded language that has much brain damage (controversial but I'll defend it) which isn't that surprising when it wasn't designed for what we are using it for (even nominally, insert joke about Win32 API as you please).
The other issue is that because the web is so damn big it has massive inertia making it very difficult to get people to move to newer technologies, in my dream world the web would have a proper (not asm.js) secure VM in the browser that could be directly used, the "webby" bit that renders HTML/JS would just be an application in that vm and other stuff could directly target the underlying VM, can't see it ever happening though as it requires the browser vendors to simultaneously agree on supporting an open standard without screwing each other over and then sticking to it.
That would be my dream web though.
As a user, your dream web is a bunch of closed blobs that I can't hope to shape or process in any way. Forget Ad-blocking, Greasemonkey scripts, Reddit Enhancement Suites or any kind of personalization not granted by the author. Changing a bit of a page becomes the equivalent of having to patch a binary instead of writing a couple of XPath expressions. Scraping changes from reading a DOM tag to extracting in-memory structures or in the limit having to do OCR.
Give me the very flawed, but still much more open web any day.
Give me the very flawed, but still much more open web any day.
That is a problem but the lack of a viable way to do native feeling apps on mobile devices has (I think) to a large extent driven walled garden app stores which are just as pernicious.
It's not all roses in any case.
It's not all roses in any case.
In a native client, global mutable state makes many problems straightforward to solve. The web takes that away, puts the state in a funny format in a database or a very limited session store. Even native apps that relied on remote databases still had to orchestrate a bunch of state around the UI, and that was vastly easier without the world resetting every time someone clicked a button, which is traditionally what happens on the web.
ASP.NET WebForms was an attempt at encapsulating the lifecycle of separate components on page. It was widely reviled because that encapsulation stretched to the UI and gave you little or no control over your HTML output. Reuse was also hard, as adapting components to your model layer was often impossible (many of Microsoft's built-in components spoke directly to your database to get work done). It was also born a little too early to be built from the group up with Ajax in mind, and so maintained state with giant serialized blobs posted back to the server.
I've lamented that this component-oriented approach was never revived or perfected (although Arc and Seaside both had continuation based approaches to page state, as I recall). Back then, of course, you'd get shouted at if your app didn't work with JavaScript turned off so you needed a solution on the server. It's now very interesting to see JS MVC frameworks framed in this way.
I don't do much web stuff now, but I'd still like to hear more about approaches to reuse in these frameworks.
I've lamented that this component-oriented approach was never revived or perfected (although Arc and Seaside both had continuation based approaches to page state, as I recall). Back then, of course, you'd get shouted at if your app didn't work with JavaScript turned off so you needed a solution on the server. It's now very interesting to see JS MVC frameworks framed in this way.
I don't do much web stuff now, but I'd still like to hear more about approaches to reuse in these frameworks.
WebForms were the worst. The problem was, even if you wrote it properly, the end result always felt clunky because of all the server postbacks. The bill pay app for my electricity company uses it, and I hate it, it's like driving a car through molasses.
I think the component thing is good though; it just needs to be something client side. Probably something like React.
I think the component thing is good though; it just needs to be something client side. Probably something like React.
Yeah, the abstraction was very leaky, and it was too easy to end up with megabytes of ViewState going back and forth, or a screen refresh on every button press.
React, and Om built on top of it, seem very interesting. They also seem to be built on abstractions that that get out of your way while guaranteeing good performance.
React, and Om built on top of it, seem very interesting. They also seem to be built on abstractions that that get out of your way while guaranteeing good performance.
I've not seen the residue of these problems get worked out yet. We're still committing sins of architecture with undesirable side-effects of byzantine frameworks which are amazing for Hello, World, but devolve into an exhausting mess for modification and long-term maintenance...
3-5 years from now, when new low or framework naive mid-tier devs approach our current javascript MV* frameworks, they are going to be getting screamed at by the business and exec parts of orgs because they seem inefficient or incompetent.
They may be working on dead platforms, without strong communities, breaking things as they fix or change other things, and doing it all so much slower than the original dev did. It will be interesting times.
It's bad enough to try to work on 5-year-old, well-known/popular paradigms in the brownfield, but try making what seems like a simple change to the brownfield while not being able to tear out the deadwood, and since-maligned, framework trends we've been building on now.
3-5 years from now, when new low or framework naive mid-tier devs approach our current javascript MV* frameworks, they are going to be getting screamed at by the business and exec parts of orgs because they seem inefficient or incompetent.
They may be working on dead platforms, without strong communities, breaking things as they fix or change other things, and doing it all so much slower than the original dev did. It will be interesting times.
It's bad enough to try to work on 5-year-old, well-known/popular paradigms in the brownfield, but try making what seems like a simple change to the brownfield while not being able to tear out the deadwood, and since-maligned, framework trends we've been building on now.
This is one of the reasons why for my "startup" (it's a SaaS product but for a niche industry so not a typical "grow big/grow fast" project).
I chose PHP/Postgres/Apache/JQuery and Knockout.js
None of them are particularly exciting or sexy but I'll place bets on all of them still been around in 3 years and as a solo developer I chose conservative technologies I know really well (with the exception of Knockout.js but I needed something to marshal jQuery and Knockout fits my workflow really well (lots of forms and bits and pieces)).
Essentially I picked "boring" solutions, I like boring, boring is supported in a year, boring doesn't fall over at 2am for some obscure edge case, boring has taken it's beating and had it's rough edges warn off, boring has google results for "Unknown Error: FinangleFoo has thrown error 12131NOTDOCUMENTED".
I like boring.
I chose PHP/Postgres/Apache/JQuery and Knockout.js
None of them are particularly exciting or sexy but I'll place bets on all of them still been around in 3 years and as a solo developer I chose conservative technologies I know really well (with the exception of Knockout.js but I needed something to marshal jQuery and Knockout fits my workflow really well (lots of forms and bits and pieces)).
Essentially I picked "boring" solutions, I like boring, boring is supported in a year, boring doesn't fall over at 2am for some obscure edge case, boring has taken it's beating and had it's rough edges warn off, boring has google results for "Unknown Error: FinangleFoo has thrown error 12131NOTDOCUMENTED".
I like boring.
Out of interest are you using a PHP framework? Just wondering what your choice would be because unless Laravel is boring yet I haven't got any experience with the boring ones :)
Yup, I use Laravel (was a tough choice, it's new but the features and speed benefit make it worth the risk plus it's open source and built on symfony to a large extent which is going nowhere) but my application is mostly decoupled from it (Uncle Bob Martin style).
I could (relatively) painlessly move to another framework (particularly Symfony2) the only major pain point would be the Eloquent ORM but as I've wrapped all that behind repositories the interface would remain consistent.
I could (relatively) painlessly move to another framework (particularly Symfony2) the only major pain point would be the Eloquent ORM but as I've wrapped all that behind repositories the interface would remain consistent.
I've been wondering this as well. I maintain a large enterprise app and some former dev's used `ThisThat.js` and `SomethingNewThisWeek.js` to accomplish a few hacks, but low and behold a few years later and they are all EOL and breaking, not to mention many cannot be upgraded because they are so amateur they don't use namespaces and conflict.
The many sites are going to be bit in a few years when the recent JS Explosion of new libraries wanes and we've got 1000 unsupported JS libraries out there and you're having to tell the department head the whole app UI has to be written, again, to keep up with that zag no one saw coming with the web.
For this reason I love Google Web Toolkit(I've done the ExtJs/Bootstrap/YUI/JQueryUI thing too) as it's totally open source, community driven, Google backed, and still going strong with releases and community support 8 years later. The beauty is with Maven, I just increment the framework version number and I get all those new compiler optimizations, IE versionX++ and Blink support for free.
As long as JS remains a shell of a language, I think compiling down to JS is the most sensible approach (i.e. Typescript/Dart/ASM.js/GWT) rather than having to fight the vagaries of torturing another trick from JS. Use a framework in a high level language that makes your life easier and future proof. Of course, one day ECMAScript might really become a serious language, but then I'll just update my GWT compiler and take advantage of that with a recompile.
The many sites are going to be bit in a few years when the recent JS Explosion of new libraries wanes and we've got 1000 unsupported JS libraries out there and you're having to tell the department head the whole app UI has to be written, again, to keep up with that zag no one saw coming with the web.
For this reason I love Google Web Toolkit(I've done the ExtJs/Bootstrap/YUI/JQueryUI thing too) as it's totally open source, community driven, Google backed, and still going strong with releases and community support 8 years later. The beauty is with Maven, I just increment the framework version number and I get all those new compiler optimizations, IE versionX++ and Blink support for free.
As long as JS remains a shell of a language, I think compiling down to JS is the most sensible approach (i.e. Typescript/Dart/ASM.js/GWT) rather than having to fight the vagaries of torturing another trick from JS. Use a framework in a high level language that makes your life easier and future proof. Of course, one day ECMAScript might really become a serious language, but then I'll just update my GWT compiler and take advantage of that with a recompile.
It is interesting to see the term "view first" again. Last (and only, that I can recall) time I saw that was in the lift framework.[1][2]
Is this the same general idea? Or just another approach to rejecting the "MVC" paradigm as it was imagined on the web? Any other frameworks following this at all?
[1]https://www.assembla.com/wiki/show/liftweb/View_First [2]http://en.wikipedia.org/wiki/Lift_%28web_framework%29
Is this the same general idea? Or just another approach to rejecting the "MVC" paradigm as it was imagined on the web? Any other frameworks following this at all?
[1]https://www.assembla.com/wiki/show/liftweb/View_First [2]http://en.wikipedia.org/wiki/Lift_%28web_framework%29
Relevant article from F8 where facebook claims MVC does not scale: http://www.infoq.com/news/2014/05/facebook-mvc-flux
Having built out largescale backbone apps & android apps, I'm inclined to aggree.
Having built out largescale backbone apps & android apps, I'm inclined to aggree.
After reading the above article, I can see how Facebook ended up with their current approach, but it seems to me that Flux is a roundabout and possibly inferior way of using state machines to organize application logic and user interface communication. For instance, statements like "The Dispatcher can be made to reject actions while it has not finished processing a previous action." indicate (to me, at least) that Flux could likely be more efficiently coded and used if it were based explicitly on hierarchical state machines.
> (..) largescale backbone apps
Having built some what large backbone-apps, and then moving on to more mature frameworks, I personally think backbone apps just don't have the correct building blocks to scale.
For instance: data bound templates, computed properties, array/object proxies, controllers etc. These things help tremendously with keeping the code maintanable.
Having built some what large backbone-apps, and then moving on to more mature frameworks, I personally think backbone apps just don't have the correct building blocks to scale.
For instance: data bound templates, computed properties, array/object proxies, controllers etc. These things help tremendously with keeping the code maintanable.
Building statefullness onto a stateless medium unsurprisingly leads to quite a few hacks/problems.
I think a lot of people miss a key point of MVC in that it is extremely popular, taught in schools and advocated for in a lot of circles.
This doesn't mean that it is inherently good at what it says it will accomplish for every project that it's used on. However, it does mean that on-boarding devs is considerably easier if you're using an architecture/framework that they'll likely be at least passably familiar with.
I'm all in favour of moving on, adapting and playing around with all of the hot new toys/frameworks but the broad "we" here at HN are in a bubble if we believe that the majority of our ilk has any interest in these types of discussions.
MVC isn't being used because it is the best at what it does, or that it is appropriate for all situations. It is being used because it is familiar to the vast majority of developers.
This doesn't mean that it is inherently good at what it says it will accomplish for every project that it's used on. However, it does mean that on-boarding devs is considerably easier if you're using an architecture/framework that they'll likely be at least passably familiar with.
I'm all in favour of moving on, adapting and playing around with all of the hot new toys/frameworks but the broad "we" here at HN are in a bubble if we believe that the majority of our ilk has any interest in these types of discussions.
MVC isn't being used because it is the best at what it does, or that it is appropriate for all situations. It is being used because it is familiar to the vast majority of developers.
MVC has some nice properties but the thing that always bothered me about it is that it introduces a mental hurdle that shouldn't really be there. "We use MVC, therefore the kinds of objects I can write are models, views, and controllers" seems to be the default, if unarticulated, position of the inexperienced developer. Realizing that no, you can actually write other classes and functions outside of your controller is now a epiphany that one must have to grow as a designer of code. Would these people be writing a jumbled single class containing even more without MVC? I guess, maybe, but a 2000 line controller calling a 2000 line model is only a slight improvement. Anyway, I've had to deal with enough fucked MVC code in my day to question whether or not even giving the methodology a name is a good idea.
"The sleight-of-hand was the assumption—baked into the servlet spec—that each HTTP request would map to a single controller which would delegate to a single view."
I've been struggling for a while to explain why I don't like MVC in web apps. Some of it is definitely just annoyance at how "MVC" has come to be simply a synonym for "good design" without any particular reference to any particular design, resulting in the term MVC being smeared over anything that has three classes that have a vaguely-plausible claim to fitting some interpretation of a "model" (this is the one most often got most correct), "view", or "controller" (both these latter just sort of get slung about with wild abandon). Despite how long it's been around, it is certainly a fad in every sense of the term, including large numbers of coattail riders and hangers on who don't really "get it".
But beyond that, regardless of what the "MVC" is, we've still got some sort of separation going on. But the separation is often pointless. The original MVC in the GUI arena was written for Ms, Vs, and Cs to be highly interconnected, not in the "coupling" sense but in the sense that there should be a significant number of many-to-many relationships between all the layers. But a lot of web "views" and "controllers" are used in only place, talking to only one other "thing", or perhaps the view talks to three "controllers" each of which is used nowhere else. The models are often reused, but more as just a data access layer.
If you don't have rich and free mixtures of all three pieces going on, you've split out your design on a useless dimension, and blown valuable design budget for a feature you're not going to use. And MVC is particularly designed for simultaneous usage of multiple things... one of the touchstones of needing the MVC model is when you have two simultaneous dynamic views on the same data, which multiple controllers may be simultaneously affecting. If you don't have that, seriously question your use of MVC.
Every once in a while, you may encounter a web app that really does deeply mix and match, in which case, go nuts. But it's going to be a special-purpose thing, not something used by everything. It's not always inappropriate... it's just that it's not anywhere near always appropriate, and it's appropriate rarely enough that it is, frankly, a stupid default for a web framework. Further, it's something that you can easily fold in only where needed; oh, do you have a statistics component where you really are using simultaneous views on the same underlying mutable data (perhaps a query)? Sure, use MVC for that. But as a default code structure? Be sure that mixing and matching Ms, Vs, and Cs at scale (not "I have this one class out of dozens that may sometimes need two views" but "this combination of 5 models, views, and controllers will be nearly arbitrarily mixed and matched") really is how your app's needs are going to change over time.
I've been struggling for a while to explain why I don't like MVC in web apps. Some of it is definitely just annoyance at how "MVC" has come to be simply a synonym for "good design" without any particular reference to any particular design, resulting in the term MVC being smeared over anything that has three classes that have a vaguely-plausible claim to fitting some interpretation of a "model" (this is the one most often got most correct), "view", or "controller" (both these latter just sort of get slung about with wild abandon). Despite how long it's been around, it is certainly a fad in every sense of the term, including large numbers of coattail riders and hangers on who don't really "get it".
But beyond that, regardless of what the "MVC" is, we've still got some sort of separation going on. But the separation is often pointless. The original MVC in the GUI arena was written for Ms, Vs, and Cs to be highly interconnected, not in the "coupling" sense but in the sense that there should be a significant number of many-to-many relationships between all the layers. But a lot of web "views" and "controllers" are used in only place, talking to only one other "thing", or perhaps the view talks to three "controllers" each of which is used nowhere else. The models are often reused, but more as just a data access layer.
If you don't have rich and free mixtures of all three pieces going on, you've split out your design on a useless dimension, and blown valuable design budget for a feature you're not going to use. And MVC is particularly designed for simultaneous usage of multiple things... one of the touchstones of needing the MVC model is when you have two simultaneous dynamic views on the same data, which multiple controllers may be simultaneously affecting. If you don't have that, seriously question your use of MVC.
Every once in a while, you may encounter a web app that really does deeply mix and match, in which case, go nuts. But it's going to be a special-purpose thing, not something used by everything. It's not always inappropriate... it's just that it's not anywhere near always appropriate, and it's appropriate rarely enough that it is, frankly, a stupid default for a web framework. Further, it's something that you can easily fold in only where needed; oh, do you have a statistics component where you really are using simultaneous views on the same underlying mutable data (perhaps a query)? Sure, use MVC for that. But as a default code structure? Be sure that mixing and matching Ms, Vs, and Cs at scale (not "I have this one class out of dozens that may sometimes need two views" but "this combination of 5 models, views, and controllers will be nearly arbitrarily mixed and matched") really is how your app's needs are going to change over time.
MVC in Web frameworks won by being watered down to almost nothing, repackaged, and sold in a manner that appealed to non/novice/intermediate devs. They were told that if they put their code in these tightly-coupled boxes, then they wouldn't have to worry about all those hard things like design or coupling. Instead, development could almost be a process of coloring by number so that anybody could do it. And they were told it was good design because it was MVC, which is an acronym that smart people talked about long ago, so it must be good. And they were told they were being saved from those other developers who have the gall to do things differently!
I cannot overstate the appeal of a prescribed architecture. This removes some of the essential anxiety a newer developer has when building things by narrowing the available choices. Rather than fret about where to put things, and how much objects should do, they have two neat categories to choose from. The problem is a novice/intermediate dev often knows they should be thinking about the design, but they don't know where to put things, so they waffle about things rather than just putting it somewhere and trusting themselves to fix it when they're wrong.
Combine a prescribed architecture with a relentless marketing campaign that repeatedly tells developers exactly what they want to hear: "blog in 15 minutes!", "design is wankery, just use the framework!", "testing just isn't worth it, it's too hard".
This is anti-intellectualism. It advocates ignoring software engineering principles established over the past few decades, and ignoring design feedback in the name of pragmatism.
Don't entrust your skills to a crappy framework. It will fade, much like the Web.
I cannot overstate the appeal of a prescribed architecture. This removes some of the essential anxiety a newer developer has when building things by narrowing the available choices. Rather than fret about where to put things, and how much objects should do, they have two neat categories to choose from. The problem is a novice/intermediate dev often knows they should be thinking about the design, but they don't know where to put things, so they waffle about things rather than just putting it somewhere and trusting themselves to fix it when they're wrong.
Combine a prescribed architecture with a relentless marketing campaign that repeatedly tells developers exactly what they want to hear: "blog in 15 minutes!", "design is wankery, just use the framework!", "testing just isn't worth it, it's too hard".
This is anti-intellectualism. It advocates ignoring software engineering principles established over the past few decades, and ignoring design feedback in the name of pragmatism.
Don't entrust your skills to a crappy framework. It will fade, much like the Web.
Don't entrust your skills to a crappy framework. It will fade, much like the Web.
Yes, they are.
The near-religious association devs have with frameworks seems to have almost displaced the association they had with languages. I'm not sure what prompts it, but frameworks die out even faster than languages. You don't have to work very long in the industry to see this happening.
Don't sweat that opinion, BTW. HN is not very kind to any sort of software engineering discussion. I presume this is a direct fallout of the Lean/"move fast and break things" ideology.
The near-religious association devs have with frameworks seems to have almost displaced the association they had with languages. I'm not sure what prompts it, but frameworks die out even faster than languages. You don't have to work very long in the industry to see this happening.
Don't sweat that opinion, BTW. HN is not very kind to any sort of software engineering discussion. I presume this is a direct fallout of the Lean/"move fast and break things" ideology.
Ironically, I'm in favor of using frameworks for when you need to move fast and break things. You're effectively creating a working prototype to test the idea in the market and thats one area where frameworks are useful. The problem is that then the developers always build the actual production version on that working prototype instead of taking what they learned and doing it right.
I'm sure someone will say, "but it takes too much time to rewrite it!" which in my experience is wrong. In fact you'll rebuild it faster because of what you learned in developing the prototype.
I'm sure someone will say, "but it takes too much time to rewrite it!" which in my experience is wrong. In fact you'll rebuild it faster because of what you learned in developing the prototype.
Sometimes the best thing that can happen to you is that you never get around to backing up your laptop with your working prototype, and somebody breaks into the trunk of your car late Tuesday night while you're parked on the street around the corner from the Stud at 9th and Harrison, eating grilled hot dogs wrapped with bacon and smothered with caramelized onions at Trannyshack, and steals all your hard work, so you have to rewrite it all from scratch.
I've felt the same way about ORMs. I've never understood the appeal of abstracting away from writing your own queries which is the closest to natural language as programming comes.
The appeal of an ORM has never been about abstracting away the writing of queries...almost every developer I've met is comfortable writing SQL queries. But the appeal of an ORM framework is in not having to write the code that maps the results of the sql query to/from the properties of an object. When you combine the annoyance of writing and maintaining that type of code with the realization that the majority of queries you end up making are one of the CRUD operations and you it completely explains the popularity of ORM frameworks. It's about not having to constantly write code that could just as easily be written by a CS 1 student.
ORM systems almost universally suck, but so does the alternative.
ORM systems almost universally suck, but so does the alternative.
> But beyond that, regardless of what the "MVC" is, we've still got some sort of separation going on. But the separation is often pointless.
Django divides things into models, views and templates, which correspond to most other web frameworks' models, controllers and views.
One reason this division makes perfect sense is that the views and templates are worked on by different people. The templates are mostly HTML with some markup language and will be the responsibility of the designers. The views and models provide functionality and will be worked on by more backend-oriented programmers.
Another reason is that the views are actually reusable. You have generic views for browsing a model by date, or for a simple edit form. You can bind them to a model and skin them with a template to quickly get basic functionality that would otherwise require boilerplate.
Django divides things into models, views and templates, which correspond to most other web frameworks' models, controllers and views.
One reason this division makes perfect sense is that the views and templates are worked on by different people. The templates are mostly HTML with some markup language and will be the responsibility of the designers. The views and models provide functionality and will be worked on by more backend-oriented programmers.
Another reason is that the views are actually reusable. You have generic views for browsing a model by date, or for a simple edit form. You can bind them to a model and skin them with a template to quickly get basic functionality that would otherwise require boilerplate.
I'll tell you one thing that I do not doubt. The splitting of the M, V & C is far better than bundling them in one page.
I'd take a crap MVC design over the pre-MVC stuff I worked on any day of the week.
The thing you don't seem to be saying is what you're doing instead? You're just waving hands at the moment and saying it's bad, but it used to be much worse.
I'd take a crap MVC design over the pre-MVC stuff I worked on any day of the week.
The thing you don't seem to be saying is what you're doing instead? You're just waving hands at the moment and saying it's bad, but it used to be much worse.
"The thing you don't seem to be saying is what you're doing instead?"
DRY. Just, DRY. If DRY leads you to MVC, rock on. But DRY is the real thing. It isn't a framework, and you have to think about it. But it's what you're really trying to do.
You're trying to define yourself the win by imputing to me a motivation to go "back" to crappy design. It's quite disingenuous, since I just got done complaining that MVC is often a crappy design, and logically concluding from that that I must want crappy designs is ludicrous once I call it out.
And if you further feel inclined to say "But you didn't give me an answer!", well, the need for "one" answer is part of the problem. There isn't one answer for which design structure will lead you to the DRYest design. Sometimes it'll be MVC. But you have to think. Not just knee-jerk MVC and think you've "designed".
DRY. Just, DRY. If DRY leads you to MVC, rock on. But DRY is the real thing. It isn't a framework, and you have to think about it. But it's what you're really trying to do.
You're trying to define yourself the win by imputing to me a motivation to go "back" to crappy design. It's quite disingenuous, since I just got done complaining that MVC is often a crappy design, and logically concluding from that that I must want crappy designs is ludicrous once I call it out.
And if you further feel inclined to say "But you didn't give me an answer!", well, the need for "one" answer is part of the problem. There isn't one answer for which design structure will lead you to the DRYest design. Sometimes it'll be MVC. But you have to think. Not just knee-jerk MVC and think you've "designed".
The whole idea that all problems can be broken up into three different essential concepts that you can describe with a TLA seems like a throwback to the Christian doctrine of Trinity: the Father, Son and the Holy Ghost. They're one God in three persons, monotheistic polytheism! Monolithic polymorphism!
People seem to think that if you dress software architecture up in the trappings of religious dogma, then it's easier to evangelize and recruit people to your cause. Well maybe they're right: it kind of worked for Larry Wall, for a while...
It usually turns out that there are more like 17 different essential concepts that you need to get a complex software project off the ground, but 17LAs like MVPATQSDYKRFXZFHW aren't as catchy, and are too hard to remember and pronounce, so they end up cramming everything that's not obviously M or V into the kitchen sink C.
DRY is great, but you should also DRTMOTP: Don't Repeat The Mistakes Of The Past!
People seem to think that if you dress software architecture up in the trappings of religious dogma, then it's easier to evangelize and recruit people to your cause. Well maybe they're right: it kind of worked for Larry Wall, for a while...
It usually turns out that there are more like 17 different essential concepts that you need to get a complex software project off the ground, but 17LAs like MVPATQSDYKRFXZFHW aren't as catchy, and are too hard to remember and pronounce, so they end up cramming everything that's not obviously M or V into the kitchen sink C.
DRY is great, but you should also DRTMOTP: Don't Repeat The Mistakes Of The Past!
It's still the wrong approach to the problem.
Desktop app UIs were never this painful. Even Swing's.
Desktop app UIs were never this painful. Even Swing's.
Desktop app UIs were never this painful? WPF, WinForms, WTL, MFC... all could be pretty darn painful when you got beyond the basic Hello World examples.
Interestingly, MFC was painful at least partly because instead of MVC, it wanted to drive you toward a Document/View architecture, where Document had both Model and View. This was painful exactly because of some of the problems that MVC was designed to fix.
That's a really good point.
A good counter proposal to the "typical" server-side web architecture is seaside (www.seaside.st).
Its tutorial (A walk on the seaside on http://seaside.st/documentation/tutorials) is rather basic, but shows the concepts well. (edit: longer article http://book.seaside.st)
Of course it has a different set of quirks to get used to, so it's not a cure-all - but it gives a different perspective on web-things.
Its tutorial (A walk on the seaside on http://seaside.st/documentation/tutorials) is rather basic, but shows the concepts well. (edit: longer article http://book.seaside.st)
Of course it has a different set of quirks to get used to, so it's not a cure-all - but it gives a different perspective on web-things.
Solid copy on this. I'm under no delusions that MVC is The One True Way to handle architecting software, but I'll take it over joining a bunch of strings to generate a web page.
I'd say anyone upset over MVC's leaky abstractions could better funnel that energy spent into making something better but I can't help to think that no software project is ever going to so neatly conform to having a structure imposed upon it.
I'd say anyone upset over MVC's leaky abstractions could better funnel that energy spent into making something better but I can't help to think that no software project is ever going to so neatly conform to having a structure imposed upon it.
> I can't help to think that no software project is ever going to so neatly conform to having a structure imposed upon it
That's the problem with prescribing an architecture ahead of time. That's why you learn the basics and improvise/draw on established architectures as the project evolves.
That's the problem with prescribing an architecture ahead of time. That's why you learn the basics and improvise/draw on established architectures as the project evolves.
Yeah, enough with the hand waving. I can't say I've ever experienced any pain using MVC for web apps but I'm very happy to be enlightened. Let's see the side-by-side code examples (or if someone can can at least explain what they're doing instead I'll have a crack at it :) ).
Agreed. MVC is vastly, vastly superior to what people, especially inexperienced programmers, "naturally" seem to do - which is to dump their models into their views.
Ok St. Joe...
Perhaps you should google "Martin Fowler empty bags of getters and setters" for a dose of real domain model justification. There are too many outright false assertions in the MVC camp. WebForms encourage mixing code and markup? Actually, they fairly obviated that practice which slowly JIT compiles into the crappy GUID-name microlibs now predominant in Razor CSHiTMeaL views. Much easier than viewstate and page lifecycle? Only if you call the necessary AJAX, LINQ, and routing trivial. In all of the examples I have seen, ASP.NET MVC views only route back to a single controller, which makes them pretty tightly coupled, thus no better than web forms. I pity the "inexperienced" programmers subject to your review.
> I've been struggling for a while to explain why I don't like MVC in web apps.
That doesn't sound like struggling to me -- you've explained the fundamental problems with the MVC Cargo Cult perfectly! I'd love to read what you write when you don't feel like you're struggling. ;)
That doesn't sound like struggling to me -- you've explained the fundamental problems with the MVC Cargo Cult perfectly! I'd love to read what you write when you don't feel like you're struggling. ;)
[deleted]
I asked Alan Kay about his thoughts on MVC:
From: Don Hopkins
I'm interested in knowing more about the evolution of MVC and Morphic, and any other approaches that people have taken to user interface programming that you think are important. I've heard about Morphic, but I haven't been able to find out too much about it on the web. My understanding is that it was originally written for Self, then ported to Smalltalk. Is it still in development, or has it morphed into something else? I don't know much about how it works or the ideas behind its design. What makes it unique and interesting?
There was a discussion on Reddit about "Is MVC the best pattern for web development", which is something I have strong opinions about and like to discuss!
I've drawn a lot of my opinions from this fascinating discussion on C2: http://c2.com/cgi/wiki?WhatsaControllerAnyway
Here's the reddit discussion, which is about how MVC applies to web development: http://www.reddit.com/r/programming/comments/lovjq/is_mvc_th...
The article: http://feedmyconstraint.wordpress.com/2011/10/24/is-mvc-the-...
I posted a comment whose TLDR summary was "Fuck MVC!" -- It has a totally different meaning for web server programming, and in the 32 years since the term was coined, there have been better ideas.
http://www.reddit.com/r/programming/comments/lovjq/is_mvc_th...
There are two different meanings that MVC has these days: user interface MVC, and web server MVC. User interface MVC has its own problems, the least of which is being 32 years old. And nobody can agree on what a controller is, anyway, except that it's the dumping ground for all the brittle junk and dependencies that none of the other well defined classes wanted.
From: Alan Kay
Things seem to hang on in computing just because they work a little bit.
MVC was originally done at PARC almost 40 years ago. The good part was philosophical -- the idea to adapt the notion of "cameras" and "worlds" in the original 3D graphics stuff I participated in at Utah 45 years ago. The bad part of MVC was how we implemented it -- much too much machinery, etc.
We (my various groups since then, including Viewpoints Research) have not thought about MVC since, but have used and devised various viewing methods over the last 20+ years. I like to do views as "watchers" which do not affect what they are viewing. There are lots of ways to do this. Similarly, I like to also use "watchers" (context sensitive to the views) to catch needed inputs. We have never done a really satisfactory automatic inverter for dealing with the loss of "dimensions" that happen when a view is made (but we have done some experimental ones).
One important criterion is for end-users of all kinds to be able to easily make their own views in a very powerful ad hoc way via construction. We have done a number of adaptations and generalizations of how this can be done in Hypercard -- and this seems to work well (enough).
Since we always roll our own languages and development systems, we don't care about problems that other systems might have. For example, we have very little knowledge about C#, etc.
We do try to learn from the few good systems that are out there.
From: Don Hopkins
I'm interested in knowing more about the evolution of MVC and Morphic, and any other approaches that people have taken to user interface programming that you think are important. I've heard about Morphic, but I haven't been able to find out too much about it on the web. My understanding is that it was originally written for Self, then ported to Smalltalk. Is it still in development, or has it morphed into something else? I don't know much about how it works or the ideas behind its design. What makes it unique and interesting?
There was a discussion on Reddit about "Is MVC the best pattern for web development", which is something I have strong opinions about and like to discuss!
I've drawn a lot of my opinions from this fascinating discussion on C2: http://c2.com/cgi/wiki?WhatsaControllerAnyway
Here's the reddit discussion, which is about how MVC applies to web development: http://www.reddit.com/r/programming/comments/lovjq/is_mvc_th...
The article: http://feedmyconstraint.wordpress.com/2011/10/24/is-mvc-the-...
I posted a comment whose TLDR summary was "Fuck MVC!" -- It has a totally different meaning for web server programming, and in the 32 years since the term was coined, there have been better ideas.
http://www.reddit.com/r/programming/comments/lovjq/is_mvc_th...
There are two different meanings that MVC has these days: user interface MVC, and web server MVC. User interface MVC has its own problems, the least of which is being 32 years old. And nobody can agree on what a controller is, anyway, except that it's the dumping ground for all the brittle junk and dependencies that none of the other well defined classes wanted.
From: Alan Kay
Things seem to hang on in computing just because they work a little bit.
MVC was originally done at PARC almost 40 years ago. The good part was philosophical -- the idea to adapt the notion of "cameras" and "worlds" in the original 3D graphics stuff I participated in at Utah 45 years ago. The bad part of MVC was how we implemented it -- much too much machinery, etc.
We (my various groups since then, including Viewpoints Research) have not thought about MVC since, but have used and devised various viewing methods over the last 20+ years. I like to do views as "watchers" which do not affect what they are viewing. There are lots of ways to do this. Similarly, I like to also use "watchers" (context sensitive to the views) to catch needed inputs. We have never done a really satisfactory automatic inverter for dealing with the loss of "dimensions" that happen when a view is made (but we have done some experimental ones).
One important criterion is for end-users of all kinds to be able to easily make their own views in a very powerful ad hoc way via construction. We have done a number of adaptations and generalizations of how this can be done in Hypercard -- and this seems to work well (enough).
Since we always roll our own languages and development systems, we don't care about problems that other systems might have. For example, we have very little knowledge about C#, etc.
We do try to learn from the few good systems that are out there.
When I was living with David Levitt, who worked with Alan Kay at Atari Cambridge Research, I was snooping around his bookshelves and read through some of the fascinating notebooks, in which Alan Kay wrote about the idea of a two way mapping/projection between the model and the view.
It's always seemed to me that the "controller" was just extra baggage, because the view knew the most about drawing the model, and naturally would also know what it needed to reverse that projection back from user input through to manipulating the model. But right now we usually meticulously write the view drawing and mouse tracking code by hand, without a lot of help from the system. (That's something I consider a high art form, which I enjoy diong, so I'd probably be horrified and out of a job it it were too easy! ;)
I think Ben Shneiderman's term "direct manipulation" describes the style of user interface that Alan Kay was getting at -- or at least DM has to deal with a lot of the same problems: "continuous representation of objects of interest, and rapid, reversible, incremental actions and feedback" according to http://en.wikipedia.org/wiki/Direct_manipulation_interface ...
By that I mean DM user interface programming could benefit from some kind of automatic inverter, but usually it's just implemented in an ad-hoc manner, usually by input tracking code in the view.
I think the way Smalltalk and Self/Morphic use reflection to present editable user interfaces to objects is another example of a two-way mapping between projecting the view on the screen, and editing the model via user input. Booleans whose values you can toggle, numbers whose values you can drag up and down, color pickers and things like that are all fine and good, but for many properties it has to fall back to standard widgets that don't know much about the semantics of the data they're viewing or editing.
I had the opportunity to play around with Sk8 when I was at Kaleida. That certainly let you drill down, see and modify everything there was in the system, and it was totally prototype based! Plus it had cool looking windows with neat shapes, which I like! ;)
I'm curious about what Kay meant by "projection", and what successful examples there are of automatic bi-directional mapping, and powerful user composition. I take it that projection is the problem that you lose dimensions and have to hide information by flattening the structure out onto the screen (via a 3d projection or scaling or filtering or whatever infovis technique you're using), and there's no visible place to click or affordance to edit some every property of an object (or you have to build scaffolding in the form of clumsy indirect manipulation techniques like browsers, outliners and pop-up menus).
It's always seemed to me that the "controller" was just extra baggage, because the view knew the most about drawing the model, and naturally would also know what it needed to reverse that projection back from user input through to manipulating the model. But right now we usually meticulously write the view drawing and mouse tracking code by hand, without a lot of help from the system. (That's something I consider a high art form, which I enjoy diong, so I'd probably be horrified and out of a job it it were too easy! ;)
I think Ben Shneiderman's term "direct manipulation" describes the style of user interface that Alan Kay was getting at -- or at least DM has to deal with a lot of the same problems: "continuous representation of objects of interest, and rapid, reversible, incremental actions and feedback" according to http://en.wikipedia.org/wiki/Direct_manipulation_interface ...
By that I mean DM user interface programming could benefit from some kind of automatic inverter, but usually it's just implemented in an ad-hoc manner, usually by input tracking code in the view.
I think the way Smalltalk and Self/Morphic use reflection to present editable user interfaces to objects is another example of a two-way mapping between projecting the view on the screen, and editing the model via user input. Booleans whose values you can toggle, numbers whose values you can drag up and down, color pickers and things like that are all fine and good, but for many properties it has to fall back to standard widgets that don't know much about the semantics of the data they're viewing or editing.
I had the opportunity to play around with Sk8 when I was at Kaleida. That certainly let you drill down, see and modify everything there was in the system, and it was totally prototype based! Plus it had cool looking windows with neat shapes, which I like! ;)
I'm curious about what Kay meant by "projection", and what successful examples there are of automatic bi-directional mapping, and powerful user composition. I take it that projection is the problem that you lose dimensions and have to hide information by flattening the structure out onto the screen (via a 3d projection or scaling or filtering or whatever infovis technique you're using), and there's no visible place to click or affordance to edit some every property of an object (or you have to build scaffolding in the form of clumsy indirect manipulation techniques like browsers, outliners and pop-up menus).
You might like MVP then. There is pure UI manipulation (V - the view) and then the actual logic behind marshaling the UI and backend calls (P - the presenter), and finally the model. If you're on mobile/table/desktop, the presentation logic (i.e. form validation, RPC) will be the same, but the actual view code (to fetch the form field values/clear/set them) will differ.
I started with this on some projects last year and find it simplifies a lot of things. To boot, you can now rather easily test your presentation logic with no UI dependence (it's all in the V).
With MVP all the persistence stuff is a whole different place, in the REST/RPC services on the server (services and repositories) but it has no coupling at all with the UI or MVP. Makes life a lot easier.
I started with this on some projects last year and find it simplifies a lot of things. To boot, you can now rather easily test your presentation logic with no UI dependence (it's all in the V).
With MVP all the persistence stuff is a whole different place, in the REST/RPC services on the server (services and repositories) but it has no coupling at all with the UI or MVP. Makes life a lot easier.
I've thought of the projection (bi-direction mapping) in terms of bijective functions that might be used in a data binding language.
So, consider a textbox on screen and an integer attribute on a model.
A bijective function might be a pair of (intToString, stringToInt) functions; one is the getter that projects out of the model, the other is the setter that takes from the view and pokes into the model.
Next, start think about how to compose bijective functions. How might they be packaged into bundles that represent a sub-component view of an individual model amongst many. And what might the mapping from a collection model look like; consider detail views (as in master-details), with a source of "currency" you can map from collection to "current item", and so on.
So, consider a textbox on screen and an integer attribute on a model.
A bijective function might be a pair of (intToString, stringToInt) functions; one is the getter that projects out of the model, the other is the setter that takes from the view and pokes into the model.
Next, start think about how to compose bijective functions. How might they be packaged into bundles that represent a sub-component view of an individual model amongst many. And what might the mapping from a collection model look like; consider detail views (as in master-details), with a source of "currency" you can map from collection to "current item", and so on.
Some alternatives to MVC for user interface programming that I've used and love are constraints / data binding / events and delegates.
I worked on the internals of "Garnet", a constraint based user interface management system written in Common Lisp on X11 (Brad Meyers' research system developed in the 90's at CMU) -- http://www.cs.cmu.edu/afs/cs/project/garnet/www/papers.html -- and also on the internals and applications of "OpenLaszlo", an open source cross platform XML/JavaScript based web programming system that supports Flash and browser JavaScript/HTML. http://www.donhopkins.com/drupal/node/124
Here is an article I wrote about constraints in OpenLaszlo and Garnet: Constraints and Prototypes in Garnet and Laszlo http://www.donhopkins.com/drupal/node/69
Oliver Steele (one of the architects of OpenLaszlo, and a great Lisp programmer) describes how OpenLaszlo supports "instance first development" and "rethinking MVC": http://osteele.com/archives/2004/03/classes-and-prototypes http://osteele.com/archives/2003/08/rethinking-mvc
I've used OpenLaszlo a lot, and I will testify that the "instance first" technique that Oliver describes is great fun, works very well, and it's perfect for the kind of exploratory / productizing programming I like to do. (Like tacking against the wind, first exploring by creating instances, then refactoring into reusable building block classes, then exploring further with those...)
OpenLaszlo's declarative syntax, prototype based object system, xml data binding and constraints support that directly and make it easy.
OpenLaszlo's declarative syntax and compiler directly support instance first development (with a prototype based object system) and constraints (built on top of events and delegates -- the compiler parses the constraint expressions and automatically wires up dependences), in a way that is hard to express elegantly in less dynamic, reflective languages. (Of course it was straightforward for Garnet to do with Common Lisp macros!)
I worked on the internals of "Garnet", a constraint based user interface management system written in Common Lisp on X11 (Brad Meyers' research system developed in the 90's at CMU) -- http://www.cs.cmu.edu/afs/cs/project/garnet/www/papers.html -- and also on the internals and applications of "OpenLaszlo", an open source cross platform XML/JavaScript based web programming system that supports Flash and browser JavaScript/HTML. http://www.donhopkins.com/drupal/node/124
Here is an article I wrote about constraints in OpenLaszlo and Garnet: Constraints and Prototypes in Garnet and Laszlo http://www.donhopkins.com/drupal/node/69
Oliver Steele (one of the architects of OpenLaszlo, and a great Lisp programmer) describes how OpenLaszlo supports "instance first development" and "rethinking MVC": http://osteele.com/archives/2004/03/classes-and-prototypes http://osteele.com/archives/2003/08/rethinking-mvc
I've used OpenLaszlo a lot, and I will testify that the "instance first" technique that Oliver describes is great fun, works very well, and it's perfect for the kind of exploratory / productizing programming I like to do. (Like tacking against the wind, first exploring by creating instances, then refactoring into reusable building block classes, then exploring further with those...)
OpenLaszlo's declarative syntax, prototype based object system, xml data binding and constraints support that directly and make it easy.
OpenLaszlo's declarative syntax and compiler directly support instance first development (with a prototype based object system) and constraints (built on top of events and delegates -- the compiler parses the constraint expressions and automatically wires up dependences), in a way that is hard to express elegantly in less dynamic, reflective languages. (Of course it was straightforward for Garnet to do with Common Lisp macros!)
> One important criterion is for end-users of all kinds to be able to easily make their own views in a very powerful ad hoc way via construction.
This sounds exactly like Doug Engelbart's "viewspec" idea in NLS.
This sounds exactly like Doug Engelbart's "viewspec" idea in NLS.
I've thought a lot about this topic because of the pains I've experienced w/ bad MVC, and because of the work I'm doing with my own MVC framework Mithril ( http://lhorie.github.io/mithril ). I wrote about some of my thoughts here ( https://groups.google.com/d/msg/mithriljs/WOvJARwmOYA/ovA_HV... ), here ( http://lhorie.github.io/mithril-blog/an-exercise-in-awesomen... ) and in the Mithril site ( http://lhorie.github.io/mithril/practices.html ).
My approach to it has been to avoid implementing design patterns as classes as much as possible - after all, doing so misses the whole point of design patterns.
I'm spending a lot of my time now writing about the MVC pattern as a conceptual entity and documenting coding techniques, with the goal of putting the architecturing and engineering responsibilities back in developers' hands (as opposed to doing it for them inside the framework... and failing like everybody else)
It's a bit disheartening that there's so many people jumping into the latest AngularJS education bandwagon, but almost no one bothers to try teaching the age-old underlying concepts that are actually valuable and that people can use for the rest of their careers. I'm hoping to help correct that with my work on Mithril and the blog.
My approach to it has been to avoid implementing design patterns as classes as much as possible - after all, doing so misses the whole point of design patterns.
I'm spending a lot of my time now writing about the MVC pattern as a conceptual entity and documenting coding techniques, with the goal of putting the architecturing and engineering responsibilities back in developers' hands (as opposed to doing it for them inside the framework... and failing like everybody else)
It's a bit disheartening that there's so many people jumping into the latest AngularJS education bandwagon, but almost no one bothers to try teaching the age-old underlying concepts that are actually valuable and that people can use for the rest of their careers. I'm hoping to help correct that with my work on Mithril and the blog.
Your github.io link is broken. Perhaps you meant to link to the project page [1]?
[1]: http://lhorie.github.io/mithril/
[1]: http://lhorie.github.io/mithril/
Oops, yes. Fixed, thanks for catching.
If you're charging money for a web app, you'll probably be fine: for most people starting something, that product/market fit is the tough bit. If you've got something you can sell, then you have revenue to pay for scaling.
What's tough is if you are just building something that's free / ad supported, where the revenue per user is minimal, so making every last bit of resources counts.
What's tough is if you are just building something that's free / ad supported, where the revenue per user is minimal, so making every last bit of resources counts.
Good read and echoes my experience. Something that I've been doing more and more recently is building more of my business logic into my models - that way no matter where they are used they maintain consistent behavior. This allows my views/templates/controllers to be extremely simple and lightweight and just reference the appropriate model methods.
It's really worth noting that this terrible version of MVC didn't start with the web. MFC used a similar version of the concept way back when. I think it comes from the inflexible object model that languages like C++ (particularly the 90s version of it) and Java use. It's just almost impossible to avoid strong coupling that defeats a lot of the advantages of the model. What's really a shame is that Rails fell into the trap even though Ruby has a rich and flexible object model.
But yeah. This expresses a lot of the things I feel about MVC for the web.
But yeah. This expresses a lot of the things I feel about MVC for the web.
> Once upon a time, there was this thing called the Model View Controller architecture. It was a product of the Smalltalk community, but then so were Design Patterns and Extreme Programming.
This is obviously trolling.
This is obviously trolling.
[deleted]
The article is confusing the conceptm with an implementation, when it comes to arguing. Just because you "can't scale" in your java application doesn't mean the concept is flawed
Just because the concept was invented 40 years ago and applied in a totally different context, before the people who invented it abandoned it and moved on the other much better ideas long ago, doesn't mean that the concept is a silver bullet that should be accepted without question.
Do you have any handy links about some of these better ideas? I'm curious to learn about them.
I included some links to other ideas here: https://news.ycombinator.com/item?id=7755759 and here: https://news.ycombinator.com/item?id=7756215 and of course here is some stuff about Morphic: https://en.wikipedia.org/wiki/Morphic_(software) -- but the important point is that there are so many ways of doing things, that there's no way to summarize them all!
But taking a few steps back from which three letter acronyms to use:
User interface software architecture is so dogmatic and cargo cultic these days, compared to how wide open and free wheeling it was years ago when nobody agreed on anything, and people were experimenting with building all kinds of uniquely original systems from the ground up, instead of iterating on imitating imitations of imitations like they are today.
One book that deeply impressed and influenced me, and made me realize how many extremely different approaches and ways of thinking about user interfaces there were, was "Methodology of Window Management", the proceedings of a 1985 workshop where an amazing group of brilliant pioneers got together and discussed a wide range of vastly different approaches and ways of thinking about user interface architecture and software design. Fortunately it's online now and you can read it for free!
http://www.chilton-computing.org.uk/inf/literature/books/wm/...
Overview
F R A Hopgood, D A Duce, E V C Fielding, K Robinson, A S Williams. 29 April 1985. This is the Proceedings of the Alvey Workshop at Cosener's House, Abingdon that took place from 29 April 1985 until 1 May 1985. It was input into the planning for the MMI part of the Alvey Programme. The Proceedings were later published by Springer-Verlag in 1986.
It's got some great historical retrospectives, like Warren Teitelman's "Ten Years of Window Systems - A Retrospective View", describing much of the groundbreaking work at Xerox PARC: http://www.chilton-computing.org.uk/inf/literature/books/wm/... -- and some papers about cutting edge technology of the time, like James Gosling's "SunDew - A Distributed and Extensible Window System", which was the original name of NeWS: http://www.chilton-computing.org.uk/inf/literature/books/wm/... .
For example, AJAX was not invented in 2005 -- that's just a recent buzzword for a much older good idea:
http://www.chilton-computing.org.uk/inf/literature/books/wm/...
"There was a general view that the ability to download procedures to the window manager was a good way to tailor facilities to applications, for example to filter out all mouse events for a particular application. The same effects can be obtained through table-driven systems, though downloading was felt to be more elegant. However, there is still more work to be done in this area."
Even though some of the information may seem dated and laughable, like the "Interface to GKS": http://www.chilton-computing.org.uk/inf/literature/books/wm/... -- it's still valuable and amusing reading, just to get the perspective that people haven't always agreed on basic concepts like what an icon is, or what you can do with a window, and that there is still a lot of room to innovate if only we stop rehashing old ideas. The back-and-forth in the working group discussions is fascinating and prescient, and I think it's even more interesting to read today than it was before, to compare their predictions and recommendations with what's evolved over the 29 years since it was published.
http://www.chilton-computing.org.uk/inf/literature/books/wm/...
"18.8.4 Icons. Icons are regular (small) pictograms which may be defined and changed by applications. They can serve many functions, frequently to conserve screen real estate. They can be used as an alternative to a window as in Cedar; as an alternative representation (perhaps concurrently visible) of the window (Sapphire); or as a representation of a task to be invoked or data which is to be operated on (STAR, Macintosh). The icon can thus range from an application-prescribed static bitmap representation to an entity which has all the attributes of a window (eg can receive all types of input). Since use of icons in user interfaces is commonplace. the provision of support in the window manager for operations on them is desirable."
But taking a few steps back from which three letter acronyms to use:
User interface software architecture is so dogmatic and cargo cultic these days, compared to how wide open and free wheeling it was years ago when nobody agreed on anything, and people were experimenting with building all kinds of uniquely original systems from the ground up, instead of iterating on imitating imitations of imitations like they are today.
One book that deeply impressed and influenced me, and made me realize how many extremely different approaches and ways of thinking about user interfaces there were, was "Methodology of Window Management", the proceedings of a 1985 workshop where an amazing group of brilliant pioneers got together and discussed a wide range of vastly different approaches and ways of thinking about user interface architecture and software design. Fortunately it's online now and you can read it for free!
http://www.chilton-computing.org.uk/inf/literature/books/wm/...
Overview
F R A Hopgood, D A Duce, E V C Fielding, K Robinson, A S Williams. 29 April 1985. This is the Proceedings of the Alvey Workshop at Cosener's House, Abingdon that took place from 29 April 1985 until 1 May 1985. It was input into the planning for the MMI part of the Alvey Programme. The Proceedings were later published by Springer-Verlag in 1986.
It's got some great historical retrospectives, like Warren Teitelman's "Ten Years of Window Systems - A Retrospective View", describing much of the groundbreaking work at Xerox PARC: http://www.chilton-computing.org.uk/inf/literature/books/wm/... -- and some papers about cutting edge technology of the time, like James Gosling's "SunDew - A Distributed and Extensible Window System", which was the original name of NeWS: http://www.chilton-computing.org.uk/inf/literature/books/wm/... .
For example, AJAX was not invented in 2005 -- that's just a recent buzzword for a much older good idea:
http://www.chilton-computing.org.uk/inf/literature/books/wm/...
"There was a general view that the ability to download procedures to the window manager was a good way to tailor facilities to applications, for example to filter out all mouse events for a particular application. The same effects can be obtained through table-driven systems, though downloading was felt to be more elegant. However, there is still more work to be done in this area."
Even though some of the information may seem dated and laughable, like the "Interface to GKS": http://www.chilton-computing.org.uk/inf/literature/books/wm/... -- it's still valuable and amusing reading, just to get the perspective that people haven't always agreed on basic concepts like what an icon is, or what you can do with a window, and that there is still a lot of room to innovate if only we stop rehashing old ideas. The back-and-forth in the working group discussions is fascinating and prescient, and I think it's even more interesting to read today than it was before, to compare their predictions and recommendations with what's evolved over the 29 years since it was published.
http://www.chilton-computing.org.uk/inf/literature/books/wm/...
"18.8.4 Icons. Icons are regular (small) pictograms which may be defined and changed by applications. They can serve many functions, frequently to conserve screen real estate. They can be used as an alternative to a window as in Cedar; as an alternative representation (perhaps concurrently visible) of the window (Sapphire); or as a representation of a task to be invoked or data which is to be operated on (STAR, Macintosh). The icon can thus range from an application-prescribed static bitmap representation to an entity which has all the attributes of a window (eg can receive all types of input). Since use of icons in user interfaces is commonplace. the provision of support in the window manager for operations on them is desirable."
I have found MVC to be far better than anything else I've used over the years, and whenever I hear it 'doesn't scale', I've often wondered 'what exactly are you doing?'.
I've seen a ton of web forms apps that didn't scale. I've seen a ton that did. I've seen a ton of PHP apps that didn't scale, and I've seen plenty that do just fine.
MVC as a seperation logic works great, and you should be doing it. If you are building controller actions for every single request, well, honestly, maybe you should be in another line of work.