It would help to have a conclusion or abstract somewhere, listing the main points that the article makes, so that I have a way to know where to invest my attention when reading it.
But the broad-strokes recommendations seem approximately like these things I would say(which are not exactly the things the author says):
* Some things are best done in an incremental fashion rather than a big "update"
* You often need to copy state in your UI code
* It helps to focus on building explicit synchronization points(which I turn to FSMs to do)
* Modelling abstract cursors on data is a helpful UI idiom
I'm actually interested in principled criticism of weaknesses of the MVC model (I've been a fan for decades). Anybody have a good link?
1) No one agrees about what the Controller does
2) As a result no one knows what should make up the Model
3) Therefore this leaves the Views in a real bad state
I don't know about the component state on the web, but from my perspective I think that is backwards. As I said I'm not a web developer, but for me those terms are meaningful this way:
Assume I have a program for designing aircraft jet turbines.* It uses a parametric model that lets you specify shaft length, blade length, combustion chamber camber, etc. It has its own constraint system that doesn't let you put 10 meter blades in a 4 meter diameter housing. Etc. I have a whole little set of operations (these days called a DSL) that allow a programmer to manipulate the model using the vocabulary, metaphor, and mental models of a typical jet turbine designer.
That is the M in MVC.
I also have a library of routines for drawing parts of the turbine on the screen. They themselves are parametric with orientation, zoom, etc. A set of view parts -- the V.
Finally I write a little window that displays a turbine with some mouse gestures and the like that allow me to zoom, rotate etc. Maybe point and ask questions.
You might write a different program that does the display on an ipad, calling from my set of Views to fit your interaction model. You won't necessarily need to know much about turbines, frankly, as my model should give you all the affordances you need.
After reading your great note, I went and read a bit from the article and it seemed that the author is entirely in the display -- in the "C". Elements like a user name (let's say a part number in this example) aren't so much as model items -- high level abstractions, but simply inputs. To me the model is the program domain model. To be forced to take the same approach with mere UI widgets is cruelty indeed, and perhaps that's the author's argument?
* obviously nobody would write such a program this way; this is expositional
> 1px wide gradient edge
wtf is a 1 pixel gradient?