▲ 80 points
back
77 comments
I'm old enough to have written in SmallTalk. I also have written a ton of 'web' MVC in recent years. Enough to know that this article was written based on some assumptions about MVC that most developers don't adhere to. I'm not sure why people jump into new framework dogmas every few years thinking it will magically solve their poor programming practices.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 :)
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.
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
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.
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.
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.
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.
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.
Don't entrust your skills to a crappy framework. It will fade, much like the Web.
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.
> 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.
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.
"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".
> 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. ;)
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.
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).
> 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.
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.
Your github.io link is broken. Perhaps you meant to link to the project page [1]?
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.
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.
> 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.
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.