4 ms·

In the context of the Web and HTTP (which is a stateless protocol) MVC had to be adapted to fit this context. Isn’t this a bit like saying that in the context

In the context of the Web and HTTP (which is a stateless protocol) MVC had to be adapted to fit this context. Isn’t this a bit like saying that in the context of mountain rescue (which involves rough and steep terrain) cars have to be adapted to fit? Cars simply aren’t useful in that situation, and while helicopters are great, they aren’t cars any more. Moreover, the innocent belief of a five-year-old that a helicopter is just like a car but with some rotor blades on top does not mean that people with engineering degrees should start calling them cars because the meaning of the word “car” has been diluted.

e12e 13y ago
Not quite. The apps still have state. That is what we today call web apps, have state. Web pages and REST documents probably shouldn't have state, or have very carefully managed state -- different from say a spreadsheet with a (continuously updated (ok, call it "reactive" if you must)) graph. So, if you want to build stateful apps on top of web and http (which are stateless) -- you'll end up playing with the same concepts as that of MVC -- but you need to adapt. I agree you probably shouldn't adapt the MVC pattern (it's a pretty high level abstraction) -- but you'll have to paper over http somehow. So far building fat clients, lately using either javascript, objective-c or java/dalvik -- seems to work better than sticking the state in a cookie and pretending everything is ok. In other words: MVC is still valid, and the adoptions aren't really to MVC -- they are to the surrounding framework. I'm not quite sure how that fits with the mountain rescue analogy, though.