Live data from Hacker News

Why you might not need MVC with React.js

code-experience.com

41–50 of 81 posts

Re: Why you might not need MVC with React.js

#41
post #3

I've been doing a broad survey of these JavaScript frameworks for a month or so now. I've looked primarily at Ember, Angular, React, and Knockout. One thing is for sure: React has the community that feels the most "enlightened." I've watched several videos and read several posts similar to this one that express this sentiment of "when I finally understood it, it just clicked , and now I realize it's the best thing in…

I'd be interested to hear what you think of ChaplinJS - it's very small, but it does this kind of compartmentalized event thing really well. You can listen for events using @delegate in each view and subview, which is just a map to $.on using that view's DOM container.

Re: Why you might not need MVC with React.js

#42
post #12
post #9

Well you need a router and a way to persist data.Does React offer this? How do I manage page changes with React? React only concern is the view afaik. An app is more than a view,even in the client. So react is not MVC,but you still need MVC somewhere.unless you write one page apps of reactive documents. > It does not define how communication flows. I think it does ,in pure MVC: - view is stateless,view is 100% model…

React doesn't offer routing. The React TodoMVC implementation uses Director, a separate library for routing: https://github.com/tastejs/todomvc/tree/gh-pages/architectur...

The devs that created React are using React + Backbone.Router for Instagram's desktop site.

It's very easy to integrate Backbone.Router into a project.

Re: Why you might not need MVC with React.js

#43
post #8

Some code samples would be nice to really demonstrate what the article states. Conceptually I don't see much of a difference from what knockout and other data-binding libraries did in the past, or even an event-based system; React's breakthrough is really the virtual DOM and template system.

Imagine multiple nodes. In order to communicate between them, they need some kind of connection, this is coupling. When you have too many connections the application is hard to maintain and extend. The connections are all on the same layer, therefore is too confusing. Now think of a tree. Now imagine the nodes being some points on the branches on the tree. If one node want to communicate with another, it has to go do…

The connections are not all on the same layer in Knockout. It does not seem like you have ever used it? It uses a hierarchy/tree of binding contexts. For dependent values you have a computed binding which creates an implicit dependency which triggers a change whenever it's dependency changes. It works very well in my experience.

Re: Why you might not need MVC with React.js

#46
post #27

Earlier quoted context omitted.

That has less to do with React specifically, and more to do with how languages/tools/libraries generally gain adoption. React is at a point where there's still an emerging "early-adopter" community. Angular was like that a year ago (I distinctly recall the tone on HN to be similar to your impression of the current sentiment around React). Now Angular is starting to reach the mainstream (loosely defined), which means…

I don't know, I think the excitement around angular was because it made things easy, while the excitement around react is based on its simplicity of its model. It's a deeper thing than just being a shiny new thing imo.

I think you're absolutely right. People aren't used to dealing with the functional paradigm that React has introduced and it's interesting, and in many cases the benefits are immediately apparent and in others are only apparent over time (meaning, with direct use). With Angular, however, there was very little philosophical "newness" but a lot of immediate "wow" and the momentum from that was enough to carry it quite far (and rightfully so).

What's happening with React is different though, and happens only once in a very long while: engineering complexities that seem to have spun wildly out of control become radically simplified by something sitting right under your nose.

It's exciting. Congrats to all of those who have contributed to React.

Re: Why you might not need MVC with React.js

#47

I'm glad to see people (besides DHH) finally beginning to question the necessity and/or wisdom of complex client side MVC frameworks. If you want something even simpler than react.js: http://intercoolerjs.org

Whoo hoo! Let's party like it's 2008 with intercooler.

Re: Why you might not need MVC with React.js

#48
post #35

I've never been a fan of MVC (I've used it for both php/backbone.js and iOS). My main problem with it is that the functionality of model is obvious, view is obvious, but controller can be anything from "a model for multiple views" to some kind of delegate, to an extension of the model. I find it so nebulous that even today, I can't explain to someone with 100% confidence where the model ends and the controller begins…

That's funny, because in my opinion, the functionality of the model, data without display logic, is obvious, and the view is obvious, layout for data. but the line between the controller and the view seems very nebulous. At which point is the data general enough to warrant a new view, or specific enough to need only a controller to marshal between the view and the data... It seems to me that a Model->Controller->Widg…

i am not sure why this is downvoted. I also find model to be the easiest to wrap my head around. At one my pervious jobs we took the 'model' out of a desktop app and put a web front on it.

Re: Why you might not need MVC with React.js

#49

I'm glad to see people (besides DHH) finally beginning to question the necessity and/or wisdom of complex client side MVC frameworks. If you want something even simpler than react.js: http://intercoolerjs.org

Whoo hoo! Let's party like it's 2008 with intercooler.

Get off my lawn.

Re: Why you might not need MVC with React.js

#50
post #34

There are two problems with React which I see at the moment: 1) Layouting 2) (more to the point of this article) what if your app isn't composed as a tree? More specifically, what if I have two tightly coupled components in two different places (physically and hence in the DOM), which need to share state? I don't want to have to go through a massive tree all the way to the root just to get that information between th…

In a large Backbone project, I experienced this issue. Many people solve the problem with an event bus. To me, that makes debugging a huge pain and coupling rather difficult to analyze. I solved it by passing a single flat context object that provides the API exposed by all of the ancestors of a component. Components can either pass this context unmodified to their children or make modified copies to add to the API s…

Please do finish the post, this is a hard problem.
Post reply on HN