Talk:React (software)

The first statement in the criticism section has no supporting reference (meaning the part about it being high; the reference on the 2nd statement merely supports the fact that a virtual DOM is used). It is also context-free (high compared to what? how high?). As such I think it stands to either be removed or detail added to make the section meaningful. Certainly the virtual DOM is only a part of the overall memory footprint of the framework. It would be good to compare it to the memory use for an equivalent UI implemented directly in native code. — Preceding unsigned comment added by 128.187.112.17 (talk) 16:00, 27 July 2018 (UTC)

It's self explainable. If you have a separate "copy" of the DOM then you consume more memory then by just using DOM. It's not possible to not use DOM at all. --Nux (talk) 13:36, 2 August 2018 (UTC)

It's not necessarily that keeping a separate copy is bad (in the end it's usually negligible), it's that iterating through any DOM is bad ^[1]. Htmlghozt (talk) 08:24, 15 July 2019 (UTC)

In terms of memory? It is always bad. Especially on mobile devices. But yes, it can have benefits in some cases (ease of use mostly). That's why some libraries use VDOM. But you pay the price for this. --Nux (talk) 12:28, 16 July 2019 (UTC)

I wanted to find more information to see if I could find accurate information on the example size of a Virtual DOM in memory and ended up coming short. What I did find was an enormous discussion on DOM diffing strategies. Htmlghozt (talk) 07:46, 17 July 2019 (UTC)

I agree the statement is that it has high memory (RAM) requirements doesn't have enough context. The argument you consume more memory using an abstraction than utilizing a built-in API is really a criticism of all libraries/frameworks Htmlghozt (talk) 08:24, 15 July 2019 (UTC)

No. Definitely not all frameworks. Not all frameworks use VDOM, the concept is relatively new and even some new frameworks don't use VDOM and are reported to be even faster. In the end after all VDOM diffs you still need to do a DOM operation. There are frameworks that try to optimize diffs when building the application and just skip VDOM diffs. --Nux (talk) 12:28, 16 July 2019 (UTC)

Any module used is going to add overhead, as you're adding more code that needs to be processed, which requires more memory. The statement high memory (RAM) requirements doesn't have any meaning because high doesn't have context, using any library/framework in conjunction with the DOM is going to be higher than utilizing the DOM alone. I'm suggesting that the statement is tautological without context. Htmlghozt (talk) 07:46, 17 July 2019 (UTC)

I haven't been able to find memory benchmarks, but an alternative restructuring could be The Virtual DOM has notably high memory (ram) requirements when compared to other DOM manipulation strategies. - ref needed -. Htmlghozt (talk) 07:46, 17 July 2019 (UTC)

React works poorly with the browser's built-in component model. Citation: See issue being tracked here: React issue #9242

Alternative libraries which rely on browser standards to implement their components. Citation: UIBuilder — Preceding unsigned comment added by 50.35.67.147 (talk) 02:26, 15 July 2019 (UTC)

FYI, I did take out the criticism section as it seemed very vague and not well-sourced (before noticing this discussion). Llightex (talk) 16:25, 9 August 2019 (UTC)

Looking for react-examples, I found "Most Popular Websites Built With React", containing Facebook, Instagram, Airbnb, Netflix, WhatsApp Web, Discord, Dropbox, Twitch, Reddit, Codecademy and GitHub. When I fed them to the validator.w3.org checker, all of them showed tons of errors, warnings and other messages. Twitch had only 2 errors, airbnb and reddit refused the check by URL, I checked by page source. Even react.dev itself contains errors. Is it intentional not to be able to publish a react website that passes the validator without any message? OttTheTormentor (talk) 17:14, 22 July 2024 (UTC)

This article should have a section, explaining how this library is related to the reactive programming ideas. How is the react framework related to reactive extensions? They share similar ideas, don't they? — Preceding unsigned comment added by 217.250.121.176 (talk) 11:04, 20 January 2017 (UTC)

This article should have a section, explaining React's tight relationship to the javascript extension language TypeScript. Fashoom (talk) 20:31, 25 July 2017 (UTC)

I disagree on that, there is not a so strong relation between Typescript and React (you can perfectly write React Code without knowing anything about Typescript). However, having a Paragraph about Flow Check System could be relevant. Lolobosse (talk) 21:13, 12 January 2018 (UTC)

While I concur with this sentiment I do think a mention of TS is prudent as it has become the default for many developers when reaching for a modern framework. DaxSudo (talk) 00:39, 29 July 2023 (UTC)

The section "Architecture beyond HTML" seems poorly written and not very relevant. Instead, a section about React Native would seem better, as React Native has gained a lot of attention.

Thoughts? — Preceding unsigned comment added by Ncusa367 (talk • contribs) 04:06, 7 December 2015 (UTC)

Hello Ncusa367, I even think that React Native deserves a whole article because it really gained in popularity during the past years, would review mine if I find the courage to write one? Lolobosse (talk) 21:16, 12 January 2018 (UTC)

Concerning editing and maintaining JavaScript-related articles...

This was included in the article. The question about how JSX turns into JavaScript has been addressed. The author makes a good point - we could clean up this article and create a separate one for JSX itself. It's popularity in web development make these and the related topics noteworthy.

This section needs expansion with: JSX syntax is very different from normal JavaScript, some examples should be provided, or a new article created with in-depth technical detail on how it works, how it compiles, etc.... You can help by adding missing information. (May 2017)

Cypherquest (talk) 13:58, 12 May 2018 (UTC)

Yes. I imagine it'd be a fairly short article, but it does exist as an entity separate to React. Basie (talk) 22:07, 20 May 2018 (UTC)

Do we know what it would contain that wouldn’t be better off as a redirect here? Artw (talk) 23:34, 20 May 2018 (UTC)

Well for one thing, I suppose it would make the point that a (possibly non-trivial) number of Angular, Vue, and Ember devs prefer to make use of JSX, so although it became widely popular as a result of React, it isn't just associated with that library anymore. There's more that could be said about syntax, differences from HTML, examples etc. Worth thinking about. Basie (talk) 01:39, 21 May 2018 (UTC)

Done. jareha ^(comments) 19:04, 20 May 2021 (UTC)

It is stated without attribution that JSX stands for "JavaScript XML". Though this is commonly stated on the intercords, it is not mentioned in the official docs nor the spec. — Preceding unsigned comment added by Dotancohen (talk • contribs) 16:23, 20 August 2020 (UTC)

Found this, which hints at “JavaScript Syntax Extension”: “It is called JSX, and it is a syntax extension to JavaScript.” (Source: https://reactjs.org/docs/introducing-jsx.html.) jareha ^(comments) 19:17, 20 May 2021 (UTC)

I'm curious about . Sure, FB acquired Instagram, but can Instagram really be said to be the React developers? At least, any more than any other React-promoting company. I feel like just saying "Facebook" is correct here. Ping: Nux. Basie (talk) 02:14, 11 June 2018 (UTC)

@Basie: Facebook as a company is the main maintainer of React and Instagram is now just another trademark (and app) owned by Facebook. So, yeah mentioning Instagram separately just seemed redundant. That's why I removed it... But I'm not sure what are you saying? You seem to agree, but you also seem to question the edit? --Nux (talk) 00:43, 13 June 2018 (UTC)

Wow, sorry yeah I managed to look at that diff exactly backwards! NVM, nothing to see here... Basie (talk) 00:46, 13 June 2018 (UTC)

No worries. Happens to the best of us :-). --Nux (talk) 21:56, 14 June 2018 (UTC)

The above mistake should be rectified. From O'Reilly: "React Is a Library, Not a Framework One important distinction between libraries like React and frameworks like Ember.js and AngularJS is that React is concerned only with rendering the UI and leaves many things up to each project to put together." Source: https://www.oreilly.com/library/view/what-react-is/9781491996744/ch01.html

From reactjs.org: "A JavaScript library for building user interfaces". WikiMane11 (ThunderPeel) (talk) 15:44, 21 January 2021 (UTC)

I agree that the title should be changed because it is contradictory to the first statement in this article. It says it is a JavaScript library. So it should remove a self-contradiction. Dlee612 (talk) 06:12, 23 January 2021 (UTC)

What is the distinction between a framework and a library? I see many projects that call themselves frameworks that appear to have the same feature set as React. For example Vue. Vue does not come with a router or state control, it has a template engine similar to JSX. But Vue calls itself a framework. Can someone explain the difference? I came to this page to find this out and it's not clear why React is a lib and Vue and others that have apparently the same feature set are frameworks. Thanks! Coolhand2120 (talk) 18:48, 3 February 2023 (UTC)

Please see Requested move 31 January 2021. You could ask react's authors why they have not changed it. Largely because react as project is closer to a jQuery replacement than a project that provides a cohesive solution from within it's own managed projects as Vue, Angular, or Next does. Bluchez0 (talk) 14:31, 18 February 2023 (UTC)

I can't find any reference calling react "bazingaJS" nor any history of previous names. Let's drop that name or find sources to support that claim. barraponto (talk) 15:29, 4 February 2021 (UTC)

I think Forms are a critical part of web applications. But in this article it is not introduced how we can use Forms in React. Why don't we add a separate Forms section? We may add Controlled / Uncontrolled Forms and if needed, introduce 3rd party libs like Formik. Dlee612 (talk) 21:44, 21 February 2021 (UTC)

Since forms and inputs are included and it's not an actual omission, I'd remove it from the lead, but having an example with controlled/uncontrolled inputs might be interesting since it's very illustrative of the unidirectional data flow. Aveis (talk) 08:45, 26 February 2021 (UTC)

@Aveis I am sorry I couldn't find about forms from the article. Could you tell me where it is? I agree to add controlled/uncontrolled forms. Dlee612 (talk) 01:47, 27 February 2021 (UTC)

@Aveis I think I misunderstood what you said. The lead was talking about missing part from React but Forms are supported with controlled / uncontrolled components. So Forms are no omission. That being said, if we use a library like Formik, we can have a complete solution including validation, keeping track of the visited fields, and handling form submission: Fully-Fledged Solutions

In terms of another missing part, I think HTTP client or AJAX should be mentioned here. Usually large and complicated applications are required to make remote API calls to fetch or mutate data and React team recommends to use AJAX library such as Axios, jQuery AJAX or window.fetch How can I make an AJAX call Dlee612 (talk) 06:39, 8 March 2021 (UTC)

@Dlee612 I think where we disagree is how much to talk about what's "missing" from react in the lead. I don't think we should talk about what's missing that much since it doesn't claim to be a compete solution for anything but for rendering views, and that much is already clear from the shorter, previous lead. Also, the lead should briefly summarize the article and none of the things we're talking about here are mentioned in the article itself. Right now half of the lead is taken up by what's "missing" from react and other solutions for that rather than react itself. I would rather keep the summary short and sweet and mention the solutions for the things you mention here in the article itself. Does that sound reasonable? Aveis (talk) 15:26, 8 March 2021 (UTC)

@Aveis Yes, it makes sense to me. By the way, I didn't intent to talk about what React misses. Just wanted to mention HTTP Client or working with remote API is also as important as Routers. I agree with your suggestion to have a short introduction but with point. I think we can make a new section like "Integrations with 3rd party libraries" or other title and move Routers and AJAX to that section. Does it make sense? Dlee612 (talk) 02:37, 9 March 2021 (UTC)

@Dlee612 That sounds great! I think I may have time later today or this week to start a section like that (or if you want to do it) and we can extract and elaborate on some of what we've talked about in the section. It also might be possible to move some of the redux/flux stuff there since they feel a bit out of place where they are now.

@Aveis Cool! I will also try to make it over weekend. Like you said, Redux/Flux can be moved to the integration section. And also we can explain about useContext and useReducer to be able to replace Redux. I am working with that way and working great. Dlee612 (talk) 05:12, 12 March 2021 (UTC)

Section History: Shouldn't "react2shell" be "React2Shell"?

--Mortense (talk) 17:35, 12 December 2025 (UTC)