
Is Model-View-Controller dead on the front end? - prostoalex
https://medium.freecodecamp.com/is-mvc-dead-for-the-frontend-35b4d1fe39ec?imm_mid=0ea80e&cmp=em-web-na-na-newsltr_20161109
======
skrebbel
MVC was originally designed as a pattern for desktop UIs. It has a _single_
controller and a _single_ model, not the MVC style that Rails popularized with
one controller class and one model class for every kind of data. In classic
MVC, Views query the Model for relevant data. The Controller handles user
actions and uses that to update the Model, then asks the View to redraw
(preferably in some smart efficient manner). This is unidirectional data flow
_pur sang_ and it comes from 1988. How is React+Redux _any_ different from
this?

I agree with the author that components are the true innovation of React,
because it encourages reusable building blocks _by default_. Contrast with
classic desktop and mobile UI toolkits which, while often also using or
encouraging MVC, do not require the developer to not subdivide their own
codebase into reusable widgets. Instead, they allow composing an entire screen
(window, page, form, whatever) from the built-in widgets. Making a reusable
widget is possible but extra work and therefore not done. In React, it's the
only way to go.

This is awesome about React, but it has _nothing_ to do with data flow
architecture, which is what MVC is.

The mistake webdevelopers made for years was trying to shoehorn DHH's backend
remix of MVC into the frontend, throwing away decades of UI building
architecture knowledge. I'm happy the Facebook people rediscovered MVC and I'm
even happy they gave it a new name (Flux) because MVC frankly has gotten way
too many definitions.

But saying that Flux/Redux killed MVC is like saying Clojure killed Lisp.

~~~
qznc
> MVC was originally designed as a pattern for desktop UIs. It has a single
> controller and a single model

Not quite. Let me quote from "A cookbook for using the model-view controller
user interface paradigm in Smalltalk-80" by Glenn E. Krasner and Stephen T.
Pope, 1988, which according to Wikipedia defined the term MVC originally:

> In the scheme described above, views and controllers have exactly one model,
> but a model can have one or several views and controllers associated with
> it.

~~~
skrebbel
Good point!

All that said, they mean that you should use separate controller-view pairs
for entirely different pieces of the application. A nice example would be MS
Word's document editor (1 view with 1 controller) and MS Word's Print Preview
view (same model, but a separate view and a separate controller).

What I was getting at is that in backend-MVC (and backbonejs-MVC), you usually
build a view, a controller and a model for each domain entity (i.e. for each
database table). This is fundamentally different from what Krasner and Pope
describe, and it probably won't work well for the kinds of dynamism and
interactivity most single-page apps are single-page apps for. I believe this
is the flavor of MVC the author is talking about.

In our case at TalkJS, we don't have anything like a print preview -
essentially our entire application is a pretty unified piece of UI (much like
MS Word's document editor which, while complex, is pretty much inseparable),
so we have only one controller and one root view. I made the thinking mistake
that most UIs only have one root view, and of course that's not true. So
thanks for that.

------
Quarrelsome
Its the same pattern. The whole point of MVC isn't the damn precise
implementation its about separating out the concerns of the view, the
services/data and a thing or some things that control and/or glue it all
together.

The point is to not munge all these things into one monolithic horrible grim
mess. As long as you are separating the concerns of showing something to a
user, allowing them to control it and backing it all with potentially remote
service who cares what the pattern is precisely called? Its still flavours of
this original desire that we named MVC.

All these presenter/unidirectional patterns are _just_ the underlying desire
of MVC and the only reason that people seem to talk about how "MVC isn't
right" or "is dead" is because they've followed MVC like dogma instead of just
a guideline of separating your presentation, control and service logic. I had
exactly this debate back when everyone was talking about MVP as if it was some
revolutionary new thing. Its not, its all the same thing and GOF was never
supposed to be a template for software but a way of talking about specific
ideas that architects could then riff on. They're chords, not one specific
tune that you _must_ play in a very specific way.

~~~
blowski
I agree completely. If you model is echoing long bits of HTML, or your views
contain lots of SQL, that's not really MVC. Almost everything is just details.
We get excited about labelling them as 'ADR' or 'MVVM' but they are all just
variations on a theme.

Perhaps the problem is that rules like 'no SQL in your views' is now so
ingrained, a lot of juniors have never seen a monolothic mess of SQL mixed
with HTML. So MVC is almost ubiquitous, and we then try breaking it down into
different sub-categories.

~~~
at-fates-hands
>> SQL mixed with HTML

And now we have Javascript being mixed with HTML; which I never thought would
happen.

~~~
simplify
JavaScript isn't a type of logic, it's a language. You wouldn't say JavaScript
is the M in MVC, for example. If you have JS in HTML, and that JS code is
strictly view logic, then your code still has a clear and useful separation of
responsibilities.

------
hcarvalhoalves
> As more and more developers start to see the advantages of components and
> unidirectional architectures, the focus will be on building better tools and
> libraries that go down that path.

"Unidirectional architecture" is a weird name for what is a fairly standard
abstraction. Every front-end at the top level is:

    
    
        f(my_entire_state, some_event) -> my_entire_state'
    

In the end all you need are well defined state transitions, an event bus and a
main loop to connect the two. Persist the sequence of events for undo/redo,
audit, debugging ... and the current state for caching or having durability
between sessions. Push side-effects to the boundaries. You may find this is
good enough.

Front-end development has been plagued by unclear patterns w/ weird names
(MVC, MVVM, MXYZ...) since forever; everytime the patterns are criticized you
hear "you did not understand it"; and new names keep popping up. It seems the
industry is stuck remixing reasoning around nouns, and is unable to step back
and reason around data.

BONUS: Sprinkle some CSP to get elegant concurrency, throw away callback-hell.
Sprinkle some React to get fast DOM manipulation, throw away Flux (heresy!) -
it has way too many names to worry about (action creator, action, dispatcher,
callbacks, stores, store events, views) and encourages some bad practices
around use of stores.

My $ 0.02

~~~
Davertron
The CSP thing is something I've been looking at recently, and while it seems
like it's a little bit lower-level than things like Rx, it seems like channels
are more flexible streams (i.e. channels are two-way so you can do back-
pressure etc.). I've been playing with [https://github.com/ubolonton/js-
csp](https://github.com/ubolonton/js-csp) and it's pretty nice; the "yield"
statements everywhere are a little wonky, but otherwise it seems like you can
implement some pretty sophisticated concurrency between processes with pretty
straight-forward code.

For examples of that sort of thing, David Nolen and James Long have written
some really great articles on the subject:

[http://swannodette.github.io/2013/07/12/communicating-
sequen...](http://swannodette.github.io/2013/07/12/communicating-sequential-
processes)

[http://swannodette.github.io/2013/07/31/extracting-
processes](http://swannodette.github.io/2013/07/31/extracting-processes)

[http://jlongster.com/Taming-the-Asynchronous-Beast-with-
CSP-...](http://jlongster.com/Taming-the-Asynchronous-Beast-with-CSP-in-
JavaScript)

There was also an article recently that described a flux-like architecture
using channels that I found pretty interesting, but I can't track it down
right now.

~~~
shoover
Those articles are excellent and held my interest since they were published,
but at the same time React and Flux were exploding and I never saw any further
talk of modeling UI logic with processes and channels. It is still in my
notes: Take another look at Hoare CSP for UI programming perspective. I once
asked David Nolen on twitter if he thought the CSP approach is still useful
given the perspective of React/Om. He said yes but that was the extent of the
conversation.

In particular, I have yet to see any examples of integrating the CSP approach
with React or similar architectures. For example, can you hook a process-based
autocomplete widget into a React view? Is anyone doing this or have we
rejected CSP for UI logic? I am interested if you can find article you
mentioned.

~~~
nickik
David has moved away from it, in OM.next you do not use CPS. You can of
course, but it would only be a implementation detail and not fundamental to
the structure of Om.next.

~~~
shoover
I think that's what I'm driving at: apart of the Om architecture itself, does
it make sense to drop something like a CSP autocompleter into an Om app, or
are those things incompatible?

------
tambourine_man
It's in times like this that I'm glad I don't blindly follow the hype.
According to the consensus, I should have gone with Backbone.js in 2011 (then
Knockout, Ember, Meteor, Angular…)

I'm still not completely convinced by React, and I may very well be wrong, but
the same skepticism that sometimes makes me feel out of touch, also provides
some sanity in this madness.

For some reason that I can't quite point out yet, Vue.js feels like the nicest
one yet, though I've only played with it briefly.

~~~
lojack
If you went with Backbone.js (or similar) you would have been better off than
the standard bag of jQuery methods. Curious what you ended up going with back
then?

Most projects I start these days tend to use React. I've looked into Vue, and
liked what I saw. I also maintain a 5 year old project built with Backbone.js
(by someone else) and I'd say it checks all the boxes for maintainability,
stability, and testability. It has its flaws -- as any old codebase will --
but I'm happy they went with Backbone. I'd probably be saying the same thing
for the other frameworks mentioned.

Its easy to point out all the flaws from our past. Much more difficult to
predict how thing will be in the future. Making a choice now, even the wrong
one, is almost always better than clinging to things that are known to not
work.

~~~
patates
Exactly! So many people assume that the emerging of a new "best" way of
writing front-end software renders all previous architectural decisions wrong.

It even came to the point that some people reject using any frameworks or even
a helper like jQuery and "take everything under their control" because they
don't want to deal with "deprecated" libraries.

Meanwhile, a small development team I know keeps using Knockout.js
successfully in huge projects.

~~~
joquarky
I'm a web dev since the beginning. Of all the frameworks I've worked with,
Knockout has the most utility for the least obtrusiveness.

------
jwdunne
The whole "x is dead" is pretty common headline pattern. It's dramatic,
extreme and often just an exaggeration.

I can guarantee that MVC is still used on the fronted as on the backend.
People are still generating value from MVC apps.

Perhaps it's not held up as the holy grail, since the new holy grail is
pronouncing it dead. Perhaps it is dying. Dead it is often not.

After building out some front-end MVC work, I can see the value in Flux
architecture and React components. I'd have a hard time justifying a rewrite
though. It's still very much alive there for me. That's also the case for many
others.

------
k__
At the moment I'm sold on Mode-View-Intent, which is more delarative and non-
OOP. I also have the feeling it lets me compose a bit more easy.

    
    
        DOMStream = view(model(intent(DOM)))
        DOMStream.subscribe(render)
    

intent() takes the DOM, wires up some interactions and returns streams "of"
these interactions

model() takes streams of interactions, wires them up with data retrieval and
mutation streams and returns these data-streams

view() takes the data-streams and uses them to create DOM mutations-stream,
which it returns.

The nice thing is that these observable streams are really nice to filter,
map, debounce etc. Also, it helps with fast realtime data stuff, because you
can easily wire up these fast streams with a tiny part of your app and the
rest of it won't even notice (which is a bit ugly if you got a big state-tree
that represents your whole app state).

The not so nice thing is, that controlling them completely declaratively has a
steep learning curve.

~~~
jobigoud
> model() takes streams of interactions, wires them up with data retrieval and
> mutation streams and returns these data-streams

I think that's called a controller or presenter in other patterns.

Actually your view and intent also do what a controller would do. The DOM is
your actual view, and your data your actual model.

~~~
k__
You're right, the names are badly choosen.

In every function the same is happening, streams are created/wired up with
other streams.

The differentiation here seems to be, that the Model function just wires up
streams for the data, the View function just wires up streams for the display
and the Intent function just wires up streams for the interactions.

------
d0m
I closely follow the Elm way (but in javascript with React), and it's still
pretty much MVC.

    
    
      Model = the state,
      Controller = the update function changing the state based on action.    
      View = declarative, need to send actions to change the state. Gets redraw on state change.
    

Redux/flux are also similar.

The idea of MVC, as far as I'm concerned, is to separate the View (Declarative
as much as possible), the State (Just data, no logic) and the Controller
(Business logic receiving commands/actions/called/whatever which changes the
states and let the view knows that it needs to update).

Is that pattern dead? Far from it.

~~~
amelius
But how do you update the view efficiently, and robustly (without introducing
bugs or becoming less efficient as your view becomes more complicated)?

~~~
d0m
Well, this is exactly the goal of this pattern.

One thing I didn't mention is that I use MVC per component, not for the full
application. (I use something else for the global Application level).

So, every major component has its own MVC. I.e. One page on mobile listing a
items with a bunch of interaction would have its own MVC.

And why it's robust and efficient:

Very easy to reason about the data and write unit tests. The whole data is in
the State, and only the controller can alter that state.

The view is completely decoupled because it can't change the state, it can
only declaratively render something (we use React with immutable). And this is
also very easy to test and mock with fake data.

As for performance, I've tried various strategies over the past few years, and
I find Immutable data structure + virtual Dom pretty damn amazing. I
personally use React.js + Immutable.js, mostly for the great documentation but
this is definitely not the only libraries.

And if the view becomes that much more complex, then it's time to spawn a new
component with its own MVC.

~~~
amelius
I don't think that works well if the view is a complex function of the state.
You can break the MVC into smaller components with an inner state, but how do
you know which components to update when the outer state is updated? I believe
you can't know, unless you duplicate the complexity of the smaller components
into your larger component.

~~~
joncrocks
From what I understand, react + redux has a couple of tricks up it's sleeve.

As the components don't hold state, only display the state of the model (part
of the redux store state), components only need to be re-rendered if the state
has changed.

If you combine this with reselect
([https://github.com/reactjs/reselect](https://github.com/reactjs/reselect)),
then this allows you to only re-render components when the sub-set of the
state tree is changed that can affect your component.

So to a certain extent you're registering your component's interest in a sub-
set of the state, and then only re-rendering when that sub-section changes.
The trick is then to ensure that as you build your app you don't build a
single component that depends on everything and pass state down as props, but
lots of smaller components that depend on a small sub-set of the tree.

~~~
amelius
Does that also work if the dependence on the state tree is not hierarchical?
I.e., subcomponents referencing the state in a random-access way?

~~~
d0m
It would be much easier if you provided an example of what you have in mind.
The approach I mentioned work perfectly for us, but it doesn't mean it'd work
for you.

But to answer your question, it shouldn't matter if subcomponents reference
the state in a random-access way. Our workflow is like this:

a) Main components fetch data from an external module. (That module either
queries the server, gets the data from the client database or uses something
already in the memory cache).

b) That main component generates a ModelView state. Basically, it transforms
the fetched data into something it can use. It could mean joining models
together, etc.

c) The view uses the ModelView state to render itself. Each component
generates a virtual dom representation and then renders themselves in the DOM.

d) Now, there are two different ways this ModelView state can be altered:

    
    
      1) From a global event (eg. New changes came from the server. Or a component elsewhere in the app sent a global event.)
    
      2) From the component itself (eg. An event/action is sent from the view)
    

e) Either way, once that ModelView state has changed because of that event,
the view gets re-generated very efficiently. I.e. Only the small part that
visually change gets rendered.

------
cm2187
I have the feeling I am reading Vogue describing what should be the new trend
this winter.

~~~
bsaul
I have the feeling fashion entered the IT world in the era of the first tech
bubble when being a geek suddendly became synonym for being rich, and open
source technologies started to do marketing instead of white papers and specs.
Not sure it's the best thing that happened to our field.

------
dmvaldman
A component, a la React, is merely an opinion on MVC. M are props, and V is a
pure function of these props. React encourages both M and V to live in the
same file, which is a deviation from best practices in MVC land. But there is
still an M and a V.

C, in the front-end world, has less of a direct equivalent, but can be thought
of as your router, which React also has as a separate entity.

What MVC does not have an opinion on, is that the M is really one giant
object, where each component receives a sub object of it. Where MVC can go
wrong is when many objects have dependencies between their state. React comes
along and says that two objects with a dependency should derive this shared
state from something above them, not inside them. This is a useful pattern. It
is still merely an opinion on how to organize Ms in an application. It is not
something "different".

In functional programming, in its purest sense, there is no M. That's
different.

------
willvarfar
I'm a bit confused by the way the article describes MVC as going from "server-
side" to "front-end" :)

When I was growing up coding native UI apps, MVC was all about front-end. UI
toolkits were traditionally MVC or M(V+C) going all the way back to SmallTalk,
and "server-side" typically meant apps without "V" or a "V" that was so small
and hardcoded in without separation...

------
wslh
Am I the only one thinking this kind of discussion is not hitting the nail on
the head? I think the main issue with web UIs is the lack of good UI design
tools, and nice and robust components. When I am developing a UI I am spending
a lot of time writing code code while I just want to drag and drop components.

~~~
brianwawok
When has drag and drop ever worked for any programing environment?

~~~
wslh
VB6? Delphi? Windows Forms? WPF? Flash? QT? Xcode?

I am not saying I don't want to write a single line of code, just saying that
the UI components can be assembled and "configured" with a design tool.

~~~
Noumenon72
Having started on Android and then gotten into a Delphi environment, Android
development tools seem like they're directly evolved from Delphi.

------
nwienert
We've sort of evolved in our stack, which leans heavily on two less-popular
options (MobX + Horizon), towards a pattern that I now think of as invaluable.

I started calling it Model-View-Store recently as I think that best describes
it. There are a few unique things here that I think are valuable.

Starting with Models: Models all return observable values. So if I query for a
single record I get back an observable object, or a list, observable array. I
define `@query` decorators on the models to set up these queries. Model's
include prop validation, normalization, consistent operation names, and more.

Views come in two types: application and presentational. App views are all
decorated to automatically react to mobx observables, so you can literally
have a Model `Car` and in a view call your query `Car.latest()`, and your view
will trigger the query and react to it accordingly. One line model <-> view
connections!

Then you have Stores: they are just logical containers for views. Any time a
view needs to do more than some very simple logic for a view, you can attach a
mobx store to it with very little code. Stores also can manage the data from
the Model (and because the Model returns observables, this is usually a one-
liner). But they don't have to. Stores are located side-by-side with the views
they control (and are be passed down to sub views when needed).

I've been working on this system for a bit now along with our startup and
we've been able to deliver some pretty incredible stuff very quickly. Having a
consistent model system is crucial, I can't imagine programming without having
prop validation and a single place to look for my model queries.

Going to be releasing pieces of it over coming weeks and hopefully a full
stack example thats really legit soon.

------
stevesun21
I worked with MVC before, but eventually I found that DDD (Domain Driven
Design) is what I'm looking for. Domain Driven Design is more like a set of
rules of how to apply the existing design partners (eg: repository, factory
and aggregation) and building blocks (eg: layering architecture) to design
your business models and keep the integrity, invariance between data.
Moreover, it lets you easily define the boundary between your services for
Microservice architecture.

MartinFowler DDD blogs:
[http://martinfowler.com/tags/domain%20driven%20design.html](http://martinfowler.com/tags/domain%20driven%20design.html)
Book: [https://www.amazon.com/Domain-Driven-Design-Tackling-
Complex...](https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-
Software/dp/0321125215)

------
hvidgaard
Isn't this akin to what has been called MVVM in WPF land, or Presentation
Model pattern by Martin Fowler, both more than a decade ago?

You have Model, View, ViewModel, and whatever auxiliary libs those need.

~~~
buovjaga
From a comment to the article:

"The unidirectional data flow approach that’s in the spotlight right now
thanks to Facebook is actually pretty darn close to what “real” MVC (as in the
design pattern introduced first in Smalltalk decades ago and not the “server-
side” appropriation that frameworks like Ruby on Rails popularized) is."

~~~
Silhouette
Exactly. If you ignore misappropriation of terminology like the server-side
"MVC" frameworks that had very little to do with MVC, and you ignore modern
buzzwords like "unidirectional data flow" for the old idea that interactions
update the model and that leads to updated rendering, then front-end web
development today is following a broadly similar path to what general GUI
architectures and visualisation tools did about 10-20 years ago.

People have noticed that views and controllers tend to come in pairs, and
experimented with how to set up the controllers to receive events without
creating excessive coupling.

People have noticed that you often want some sort of intermediate state
derived from your model to support your view rendering, instead of
regenerating expensive data from the model itself each time you render.

People have noticed that rerendering everything can be a bottleneck and
developed tools for identifying only the changed areas to render selectively.

Tune in next week for: Immutable data structures are relatively slow. Large-
scale declarative rendering is relatively slow, even if you use diffs. Fine-
grained publish/subscribe models are relatively fast, and flexible enough to
cope with both computing derived state and triggering UI updates, but you need
good tools and a clean design or the edge cases will overwhelm you. Small-
scale declarative UI updates triggered by a fine-grained publish/subscribe
model is a useful approach in a lot of cases. And everyone hates
temporary/transient state in forms.

~~~
lmeyerov
We went the reverse: fine-grained to coarse-grained. The "aha" is that the
speed is just not a big enough deal for most cases. Consequently, go full
declarative for the 95%, and only go fine-grained for the 5%. More concretely:
we went from mostly Rx to mostly React. Both have their strengths, but it's
not a 50/50 thing in terms of lines of code.

~~~
Silhouette
In my experience, it depends very much on what you're doing.

If a UI has light to moderate rendering requirements, React's approach might
be fast enough on its own. In that case, a lot of the other ideas are just
extra complexity for no real benefit. I'm speculating here, but I'd guess this
actually accounts for a large majority of the web front-end work that is being
done today.

I haven't found that React alone scales very well to more demanding
environments, though. If your model has significant constraints between the
data points that need to be enforced or you need non-trivial view-state
between your model and your rendering code, you're back to having dependencies
in the data that need to be implemented somehow. That is outside React's
scope, so something else needs to bridge the gap.

I find React's design itself also struggles with scaling up beyond a certain
point, though it's a high bar that I expect most UIs running in browsers
wouldn't reach. However, if you're implementing something like a complicated
dashboard with many data dependencies and interactions, you start needing
shouldComponentUpdate almost everywhere to achieve acceptable speed. That has
profound implications for how other parts of your app are structured because
you need some way to make shouldComponentUpdate fast, and it can also lead to
more and sometimes artificial subdivisions of your rendering components so you
can use shouldComponentUpdate at the necessary level of granularity.

Overcoming those scalability issues usually seems to bring me back to the
approach I mentioned before for larger, more complicated UIs: data
dependencies are handled through some sort of observer model and/or lazy
queries, but a library like React is still useful for declarative rendering of
each smaller part of the UI so you don't have to worry about transitions most
of the time.

~~~
lmeyerov
FWIW, it's worth considering we (graphistry) work at the edge of what is
possible in browsers. We hook up GPUs in the client to GPUs in the cloud for
an unprecedently rich visual analytics experience. Think building Netflix,
Photoshop, or Google maps for data. If mostly react and falcor, with only
sprinkling finegrained rx, is how we handled the perf and composition mess,
I'm pretty sure simpler apps can do even less than us.

~~~
Silhouette
Looks interesting... You're doing statistical visualisations using WebGL and
GPU acceleration? If that's right, would you mind sharing a little of how
you're setting up your overall architecture?

The web projects I'm working on are in a slightly different field. We also
seem to be pushing the practical limits of browser-hosted GUIs with some of
our interactive visualisations, but they tend to use SVG. WebGL is one of the
technologies that is definitely on my "could be interesting/useful" radar, but
I haven't tried to do anything serious with it yet, so I'm wondering how
different a real-world-scale project would be.

------
owenjones
For anyone interested in a surprisingly pleasant to use front-end MVC
framework I am a huge fan of [http://mithril.js.org/](http://mithril.js.org/).

It espouses a (I believe?) slightly more traditional MVC interpretation where
your Controllers are usually extremely light and in most cases completely
optional. It encourages a MVVMC (Model View View-Model Controller) approach to
encapsulate view-state.

------
LeanderK
I think there is a problem defining MVC. If you argue that current innovations
in the frontend do not violate MVC, then MVC is a very useless term. If you
think of an very conservative, OOP definition of MVC i don't think React fits
the model. Of course that means that many other frameworks are not truly MVC,
but MVC-inspired, but i don't have a problem with that.

------
leejefon
Great article, couldn't explain the pain better. I worked a lot with Angular1
in the past couple years, and the controllers tend to get very messy because a
lot of ui state and app data mixed together in the controllers. I am using
React for most of my apps now, but I look forward to see what frontend
architecture will come out in the next few years. I feel as ES6/7 is getting
more and more common for js development, probably some OOP patterns that are
used in Java/C# will be developed for frontend, but of course, front end apps
is still different from Java server apps because of the nature of the language
and the purpose of the app (frontend is more view and user interaction
oriented)

------
supernintendo
Agreed. MVC has always been sort of an awkward pattern for frontend web
development. The fact that the DOM is extrinsic to the JS runtime can lead to
a messy collaboration of MVC components. An input that makes an AJAX request
on each keystroke and renders the results to a list (typeahead.js for example)
is easy to implement but involves quite a bit of indirection with this
paradigm.

That being said, I don't know how to feel about Angular 2's approach to
components. Decorators are useful but can diminish the benefits of component
based architecture when misused.

------
sangnoir
> The Controller is highly dependent on the View.

OP is painting with an overly broad brush: Angular is not representative of
all client-side MVC. I maintain an app where the view handles the browser
events - as it should, and the only data that gets passed between the view and
the controllers are the (business) models.

------
brendanw
On android, MVC is dead. Talk about overly-circuitous code that is not
straight forward to step through. MVP is great, when not over-done by folks as
well (eg making a model-view-presenter unit recursively for every element on
screen rather than having one unit associated with the a given screen).

------
dandare
So what if anything COULD replace components and unidirectional architectures
in five/ten years?

------
thetechdude
I wouldn't say MVC is dead in the front-end, rather I would say MVC is a
necessary stepping stone towards modern front-end architecture. It still has
some kind of model, view and whatever the controller is called.

Before the time of Single page applications, MVC was not practical as the
state of the page would be destroyed as soon as you click on a link. With the
whole "single" page approach your page lives on and your applications remains.
This was the considered the "holy grail". We are thought all the problems are
solved, but then came the performance and memory leak issues. Because the page
lives on throughout the user journey, memory management became a problem.. and
so was SEO. As always front-end will continue to change rapidly year after
year and it's now all about Flux/Redux and Universal javascript?

Saying MVC is dead is like saying "CPU" is dead, no it's not, but it will
always keep on improving.

------
bananicorn
Well, we still use Models and Views, but not with React or Rails, no no no.
With _classic ASP_. Also I'm not sure as to where the line is being drawn
between frontend and backend...

------
jmcdiesel
MVC never made sense on the frontend, unless it was a completely silo'ed
frontend app with no backend.

------
sriram_iyengar
i write ember code and for me it still lives a lot, though MVVM

------
caretStick
MV __arises naturally. You can run the entire application logic without UI
components, and you can test it that way also.

Other abstractions are designed similarly to allow tests against pieces of the
internal API in total isolation, though separated on different lines. Maybe
you have transient state stored in view models while persisted state is stored
in models. The isolation only helps as size grows, and it can keep size under
control mostly by having a good data model for what each component / layer /
aspect actually does.

It makes it easier to rewire everything when you start with a switchboard. UI
changes are either "Oh my god we're going to have to re-write so much stuff if
we do it that way!" and you wind up not making drastic UI changes or "Sure, we
can make that thing tickle the controller instead of that other thing."

------
MrPatan
Yes, and good riddance.

