Remove "V in MVC" text from the website

[ryanflorence]

Lots of people use React as the V in MVC

I'm sure there was some thought put into this phrase on the website, but I think it breeds the idea that you just dump React.render inside of a Backbone.View.render as though its a recommended application architecture. In my experience, people end up with all the same problems they had before react: incomprehensible webs of events, cascading updates, etc.

Perhaps something like:

React is only concerned about rendering UI. Since it makes no assumptions about the rest of your technology stack, it's easy to try it out on a small feature in an existing project, or at the top of a new one.

[vjeux]

👍

[vjeux]

cc @petehunt who also wants it gone

[ghost]

👍

[MicheleBertoli]

+1

[blowmage]

👍

[daannijkamp]

👍

[jimfb]

I know it's entirely anecdotal, but here is my story:

Long before I ever considered joining the React team, I had a friend recommend React as a framework to check out. This particular friend recommends that I "check out" half a dozen different libraries/languages each week, so it wasn't a particularly strong endorsement, but it was enough to get me to open the web page.
My level of due-diligence on one of his recommendations is generally to read the homepage of the tool/library/language, maybe poke around for some example code so I can see what it would look like, and insert it into my mental index so I know it exists if/when I need to call upon it.
All the terminology was foreign to me. "Virtual DOM" and "JSX" and "reactive data flow" and "Elements" vs. "Components". I was about to file it away as "I don't really understand what they're trying to accomplish" (a category for things that try to solve problems I'm not experiencing).
When I saw the sentence "Lots of people use React as the V in MVC.", it suddenly all clicked. I knew MVC, and I now understood what React meant by "Just the UI". They meant that I could define my own models and controllers using my own tools, and I could use React to render the view in my application. This was the critical point where I decided to click the download button.
Now, needless to say, I'm a huge fan of React.

Anyway, now that I fully understand React, I can understand why that sentence is arguably a bit misleading, but I also see how it succinctly communicates what React actually does in terms that were very familiar to me.

[BerkeleyTrue]

I think it would be prudent to add

and ditch the MC althoughter

instead. It implies that React can be used on its own but can also be a view in other frameworks while being succinct.

[gaearon]

How about something like

Since React makes no assumptions about the rest of your technology stack, it's easy to try it out on a small feature in an existing project. Lots of people start using React as the V in MVC and later realize that they might not need M or C anymore.

[gaearon]

Oh wait, @ryanflorence already said that better. I missed that in his initial comment.

[jquense]

@jimfb really succinctly said what I've found really helpful about the line as it is. it's terse and clear, and used analogy I already understood well. Sure it's technically misleading if you already understand react, but I found it really helpful as a newcomer. Which is more to the point that the tag line is for people who don't know React, but likely do all know about views in MVC's

[gaearon]

I'm kind of ambivalent about it. I'd like to have it phrased in a way that keeps the original “just the UI” meaning but also suggests React is better off without MC baggage.

[graue]

Something has to replace the MC though. Whether it's Flux, Relay or another system entirely. The default option of callbacks passed down 4+ levels deep as props (as you get if you extrapolate from Thinking in React) becomes quickly unmanageable.

Maybe take @ryanflorence's suggestion, and also add to the "Data Flow" bullet point:

React implements one-way reactive data flow which reduces boilerplate and is easier to reason about than traditional data binding. Combine it with Flux for a full replacement for MVC architecture that helps you build great apps faster.

This way, we still explain how it relates to MVC and present a recommended architecture.

[jimfb]

No comments for over six months. It isn't clear that we want to change this, so the bug isn't actionable. This might get changed/fixed as part of a bigger docs rework, but let's close for now.

[sophiebits]

Going with #7012.