
What web developers thought of in the noughties as being MVC doesn't scale - ingve
http://fishbowl.pastiche.org/2014/05/16/no_really_what_web_developers/
======
silverbax88
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.

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

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

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

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

~~~
3pt14159
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.

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

~~~
eric_h
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_.

~~~
sanderjd
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?

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

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

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

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

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

~~~
mcintyre1994
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 :)

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

------
taeric
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](https://www.assembla.com/wiki/show/liftweb/View_First)
[2][http://en.wikipedia.org/wiki/Lift_%28web_framework%29](http://en.wikipedia.org/wiki/Lift_%28web_framework%29)

------
PhrosTT
Relevant article from F8 where facebook claims MVC does not scale:
[http://www.infoq.com/news/2014/05/facebook-mvc-
flux](http://www.infoq.com/news/2014/05/facebook-mvc-flux)

Having built out largescale backbone apps & android apps, I'm inclined to
aggree.

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

------
dpeck
Building statefullness onto a stateless medium unsurprisingly leads to quite a
few hacks/problems.

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

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

------
jerf
"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 _in_ appropriate...
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.

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

~~~
mattgreenrocks
It's still the wrong approach to the problem.

Desktop app UIs were never this painful. Even Swing's.

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

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

------
DonHopkins
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](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...](http://www.reddit.com/r/programming/comments/lovjq/is_mvc_the_best_pattern_for_web_development/)

The article: [http://feedmyconstraint.wordpress.com/2011/10/24/is-mvc-
the-...](http://feedmyconstraint.wordpress.com/2011/10/24/is-mvc-the-best-we-
can-do-on-the-web/)

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...](http://www.reddit.com/r/programming/comments/lovjq/is_mvc_the_best_pattern_for_web_development/c2ug2tp)

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.

~~~
DonHopkins
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](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).

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

~~~
DonHopkins
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](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](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](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/2004/03/classes-and-prototypes)
[http://osteele.com/archives/2003/08/rethinking-
mvc](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!)

------
lhorie
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](http://lhorie.github.io/mithril) ). I wrote
about some of my thoughts here (
[https://groups.google.com/d/msg/mithriljs/WOvJARwmOYA/ovA_HV...](https://groups.google.com/d/msg/mithriljs/WOvJARwmOYA/ovA_HVTawnQJ)
), here ( [http://lhorie.github.io/mithril-blog/an-exercise-in-
awesomen...](http://lhorie.github.io/mithril-blog/an-exercise-in-
awesomeness.html) ) and in the Mithril site (
[http://lhorie.github.io/mithril/practices.html](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.

~~~
indiv0
Your github.io link is broken. Perhaps you meant to link to the project page
[1]?

[1]: [http://lhorie.github.io/mithril/](http://lhorie.github.io/mithril/)

~~~
lhorie
Oops, yes. Fixed, thanks for catching.

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

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

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

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

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

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

~~~
lhorie
Do you have any handy links about some of these better ideas? I'm curious to
learn about them.

~~~
DonHopkins
I included some links to other ideas here:
[https://news.ycombinator.com/item?id=7755759](https://news.ycombinator.com/item?id=7755759)
and here:
[https://news.ycombinator.com/item?id=7756215](https://news.ycombinator.com/item?id=7756215)
and of course here is some stuff about Morphic:
[https://en.wikipedia.org/wiki/Morphic_(software)](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/...](http://www.chilton-
computing.org.uk/inf/literature/books/wm/overview.htm)

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/...](http://www.chilton-
computing.org.uk/inf/literature/books/wm/p004.htm) \-- 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/...](http://www.chilton-
computing.org.uk/inf/literature/books/wm/p005.htm) .

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/...](http://www.chilton-
computing.org.uk/inf/literature/books/wm/p019.htm)

"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/...](http://www.chilton-
computing.org.uk/inf/literature/books/wm/p009.htm#c9p3) \-- 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/...](http://www.chilton-
computing.org.uk/inf/literature/books/wm/p018.htm)

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

