[What is React?](https://remysharp.com/2016/08/15/what-is-react "Permanent Link: What is React?")

Lock Thread

Login

Add Comment[M ↓   Markdown]()

[Upvotes]()[Newest]()[Oldest]()


Erv Walter

0 points

7 years ago

Others are commented along these same lines, but to me, the key benefit of React is the switch to an "immediate mode" programing mentality instead of a "retained mode" mentality.

Old school web development meant describing your UI as a series of DOM elements and then morphing them incrementally in response to user interaction or other outside stimuli. In order to handle stimuli happening in unpredictable order, that event handling code that updated the UI had to anticipate all possible starting UI states and handle them appropriately. This is certainly doable (the web works, after all), but requires more thought and is (IMHO) more error prone.

React’s immediate mode mentality, in contrast, says, "given your applications' state, describe your UI completely from top to bottom." You don’t have to worry about what it looked like before. You just have to write code the draws the correct UI for a given set of state data. The underlying library (React) is in charge of detecting what is different about your new UI vs the previous UI and making any updates efficiently. And I agree with you that I hope that someday this will be built into the browser and optimized even further.

But "render your UI given this state" (and the related "just update the state based on user interaction and let everything get rerendered") was a pretty big shift from the old way I used to build web applications. Whether React or some other library is facilitating this style of programming 10 years from now, I expect the methodology to still be around.


bobby

0 points

7 years ago

The VDOM is a red herring. What is missing in all UI development is making it easy for a developer to understand all the ways something can break.\ A pure view or pure function or idempotent function means there is only one single way for something to break. It’s the params that got past I to your function when it was called. Things don’t change from when the promise was start until the then it’s called. No wrapped mutable objects that changed because calling one thing triggered a cascading event. The end user thinks in time. One thing happens then another. For a program if even the slightest thing is out of order it crashes. Time is the worst enemy of a program. Pure views eliminate time as a factor. React accidentally figured out how to make the easy thing to do performant in real world apps.\ React might come and go but pure views are as revolutionary as OOP.


Garry Taylor

0 points

7 years ago

I find the debates about React very interesting. I can only give my option, it is fact but you’re not free to dis-agree.\ I have built some shitty websites in Php, Java, CGI, Perl, ASP Clasic/DotNet/MVC/Core, Durandal, Angular and some major sites most people in the UK will have used. I have build SPA systems in Durandal/Angular/React that process millions of pounds of business per month. For this reason, I know what I am doing, and that’s why you should read more.

I am a programmer, I solve problems.. The design and moving data in and out of the HTML/DOM is a pain in the ass and a complete waist of my time.\ React allows me to continue being a programmer all the way down the layer. It allows me to split all assets/components to our private NPM and share across the teams (I have 10 developers all working of different parts of multiple projects across multiple Sprints). I don’t need to worry about builds failing at UAT and killer merge conflicts, I only worry about features. For my clients that means that their systems are getting better each day and components are UAT tested using our test partners (cheap == risk) and then pushed to our full scale clients with some serious SLA.

For too long the issue of getting "data" in and out of HTML has been a big problem and many tools have been designed to solve this problem. With React this problem is now removed.. there is no spoon (DOM).\ To be fair, I work on some major site where clients change specifications daily, and I am talking "Drop your pants" changes. Building REST API don’t work for us, we use GraphQL as the spec can change 15 times in one week and changing full stack is too expensive and time consuming. We can’t use MVC and this ties too many items together and they are too coupled. Changes here will involve too must code touching and will create major merge conflicts between our developers who are working on the same code as you (the same lines).\ With React we NPM everything and this is then dropped into out "UI" applications that put this all together.

Personally if I was making a new website, on my own (I remember them days) then I would still using React. However I understand that a single developer who knows JQuery/PHP and how to get data in and out of a database already has lots of "Copy and paste" code that allows them to get a new project up and running.

There are 9 till 5 developers who have learned enough PHP to grab data out of a database and then focused on HTML and CSS. They have never learned design patterns, GOF, Multiple Development Team issues, working all night to fix a branch that has 10 merging conflict branched. They are salary developers and are not truly interesting in bettering the world of the web.

In the next 10 years I hope that HTML,CSS and React will be dead. It’s a crap solution for such a simple problem (displaying pretty dynamic data to users). I hope the browsers will design a new API to DOM solution, who known, React could power this…​


rem

0 points

7 years ago

This comment is spectacular nonsense. This is only my options, it is fact, but you’re free not to disagree. (lol)


Andy Hume

0 points

7 years ago

What on earth are you talking about?


Munawwar

0 points

7 years ago

My two cent (warning: I am not very fond of React, but I’ll try to be unbiased): React reduced number of states to track compared to older frameworks like ExtJS (since updating the view is easier and less intermediate states are needed) or two-way binding frameworks like Knockout (two-way binding is mostly redundant. I think two-way binding isn’t as useful as it was claimed). This is possible since, the view purely relies on state change rather than DOM updates.

Redux/Flux takes this further. To make communication across components easier, redux gives you a "subscribe-able data/state store". So instead of changing another component’s state directly (or using it’s methods), dispatch an action event to the store (e.g. 'increment'), you code how to change the state from it’s current state, redux then calls subscribers and a component can subscribe to update UI/whatever. Since all changes go through the data-store, it is easy to store all of them and replay/rewind them.

Is this a radically new concept? Nope. It’s pretty much the "command stack" pattern. You’ve seen it before…​example - the undo/redo buttons of a WYSIWYG editor. UI action → Undo/Redo command handler for that action (which changes state, then fires 'update') → Subscriber handles the update. \[Actually, more accurately most editors treat the DOM as the state. They update the DOM in the undo/redo handler itself, and only fire 'update' for plugins. But the example still holds.]

EDIT: By the way, for most applications, Redux/Flux is an overkill. Using refs and calling component’s methods (to cause it to change it’s state) is fine for smaller applications.


jiyinyiyong

0 points

7 years ago

React is a mixture of a lot of things.

there can be more. Will some of them be replaced in the future, probably!

What is React? What ever Facebook add to it, and it changes over time.


firasd

0 points

7 years ago

My view is that the core idea of React is definitely not virtual DOM. It’s about rendering view as a function of state, making JavaScript-driven UI declarative the way HTML is declarative. Your comments about state control are the closest to this concept. I wrote some more thoughts in my article (I think you’ll find the 'further reading' links useful): [https://medium.com/@firasd/…​;](https://medium.com/@firasd/interface-from-data-using-react-to-sync-updates-and-offline-activity-across-devices-f672b213701c)


Ben

0 points

7 years ago

React is essentially render target agnostic. What that means is that adaptations can be (and have been) made to target canvas and the native mobile UI layer, etc, in the same way one would an HTML DOM, and this is made possible by React’s ethos of granular components, declarative UI development (JSX) and in-memory render trees. This versatility is, for me at least, the clincher.


Tracker1

0 points

7 years ago

React is a rendering library that uses dom-diffing for UI updates. That said, the usage of react leans towards flux-like frameworks, the community has pretty much settled on Redux, though mobx and others are interesting. This leads to a consistent component state and event/data flow.

Most applications are probably best with server-rendering and a smattering of JS to orchestrate some pieces. Where React comes into play is when you want to develop with isolated components, as well as using more modern build tooling (webpack/browserify/rollup with babel). It allows you to develop components with consistent state management.

There are other options. Angular 1.x has some things to offer, but tends to encourage a path that will lead to state management issues. Angular 2.x allows for a unidirectional workflow (flux-like) but has similar niggles imho. React’s error reporting is better than any other UI toolkit I’ve used in my 20+ years developing web based applications.

Web Components (Polymer) is also an interesting approach, that is kind of the inverse of React.. React components are JS first and render views…​ Web Components are view first and embed control logic. I prefer the React approach as I feel that working with JS outside the components is a better workflow.

YMMV, but that’s my $.02


Julian KrispelSamsel

0 points

7 years ago

React isn’t a framework. It’s hardly a library. I think of react as a polyfill. A polyfill for the virtual dom. Which is ultimately a much simpler way to build web apps. I strongly believe the virtual dom will carry on after react has fallen out of fashion, hopefully it will be implemented in browsers.

Bear in mind this also angular’s mission: building a better platform for web development.


Eric

0 points

7 years ago

Quoting Dan Abramov: "React’s true strengths: composition, unidirectional data flow, freedom from DSLs, explicit mutation and static mental model."

[https://medium.com/@dan\_abr…​;](https://medium.com/@dan_abramov/youre-missing-the-point-of-react-a20e34a51e1a#.c5klam414)


James Kyle

0 points

7 years ago

\> What is React? What is React to building web sites in 10 years?

React is building the web. The same way we all are. We’re experimenting, we’re figuring what works and what doesn’t, we’re finding ways to be more productive, ways to improve our own development experience, ways to build things that are faster, you could go on in this train of thought for awhile.

Popular libraries and frameworks have a huge impact in the design of the web. They’ve informed standards time and time again, they’ve paved over the hard parts until the standardization process can catch up.

The parts of the web that were designed in an echo chamber are the parts we hate the most, because they are uninformed about real world use cases. The parts that were informed by the community, the ones that were just standardizing what people already thought was a good idea, those are the parts we like. I don’t think any reasonable person wants a web where we have standardization gods above us telling us the right and wrong way to do things.

React really changed the way we think about developing applications. In a way it brought us back to the early days to having a declarative way of describing highly dynamic applications the way HTML described documents when it was designed.

Virtual DOM was proof that when we have a declarative system we can optimize the rendering process without having to love and care for it. This should inform standards, it should have an impact on the web in the next 10 years, because the lessons we’ve learned shouldn’t be forgotten.

In the meantime we keep innovating, we keep finding ways of making more and more possible with the tools we have today, and we keep pushing the web forward. I don’t see a problem with frameworks being temporary providers of consistency and productivity in the meantime.


Thomas Raba

0 points

7 years ago

I’ve been in software developing for 10 years and I think redux/react will be the only "JS" framework that will be around for a while. It’s a move forward, redux (or flux) with it’s unidirectional pattern is finally giving something truly predictable


Jonathan Fielding

0 points

7 years ago

But redux is completely separate from React, sure they are often used together but Redux is just as powerful when used separately


duder77

0 points

7 years ago

The core take away from React is that application state should be immutable and UI state and behavior should be described declaratively. This makes testing, debugging, and code-reuse massively easier.

React has nothing to do with Reactive programming. 2 completely different things. React is a poster child for "use simple tools to build complex things". It’s easy for beginners to understand: input state, get output DOM. It’s like 2 + 2 = 4 for DOM, the result of a given input is always the same.

There are probably about 10 core React methods, it wont take you longer than an hour to learn the basics, so I suggest you try it out for youself and see what you think.

IMO it’s bigger than the web. It’s how all UI development, web, mobile, and desktop will work in 10 years. Maybe not using React lib specifically, there are already faster vdom implementations and compelling framework alternatives (like Elm), but the idea of declarative UI and immutable state is how we’ll do all UI on all platforms (except maybe extremely resource constrained platforms like embedded/iot) in 10 years.


jaffathecake

0 points

7 years ago

It’s great to see (from your Twitter replies) that we’re over the whole "The DOM is slow, React is fast" thing. Given that React itself uses the DOM, it cannot be faster than the DOM.

The benefit of React is in its functional leanings. You end up with a single function call returning the state the world should be in, as opposed to more traditional DOM patterns which revolve around working out what needs to change about the current state of the world.

Returning the world from a function call loses you some performance, as you spend some time redescribing the current state of things. Then, more performance is lost as React translates that back into the more traditional "what needs to change about the current state of the world" - that’s the diffing part.

The benefit you get is developer convenience. The less state you’re depending on, the fewer state-related bugs you’re going to have. Your application also becomes easier to test.

Ignoring React for a moment, if I click "Home" at the top of this blog I get a full page reload. I could argue this isn’t optimal, as a full page reload involves the restating of a lot of content that already exists on this page. It also involves the reparsing & execution of CSS & JavaScript - work that’s already been done on this page.

You could optimise by using pushState instead, and changing only what needs changing, and (ignoring the loss of progressive rendering) the result may be faster. But by doing this you put yourself in the position of controlling navigation state, and that’s really difficult to get right. Personally, I cling on to my full page reloads as long as possible, as the minor performance loss is worth it for the clean slate and navigation handling the browser gives me for free.

It isn’t about performance, it’s about safety and predictability. The question is, is the safety and consistency for the developer worth the per-load performance penalty for the user? That can only be answered on a case by case basis, and it’s a question too rarely asked.


Yaakov Belch

0 points

7 years ago

The surprise of react is that what you describe as 'slower' (re-writing the whole page, diffing and changing the DOM) often comes out much faster than doing the changes manually. This is counter-intuitive but if you look into it, it’s right:

True: If you just have one event with a single resulting change, then the manual solution will be optimal and react will be slower. But here performance doesn’t matter because in this use case, the browser is 100 times faster than we can perceive changes.

Performance matters when one event leads to many changes and follow-on changes. Here, the browser can get a lot of work and the user can feel the amount of work by the time that passes by…​

As it turns out, it is really difficult to hand-optimize many changes that come out of one event. You need to keep all the dependencies between objects in your head. In most cases, you will simplify your programming by letting the computer do more work…​

The clarity of react (e.g. when coupled with redux or mobx) makes it very easy to optimize your changes in the library --- so you don’t have to do it. All you need to do is not to mutate state. So, the library can very efficiently check what is happening.

Bottom line: The functional approach of react creates clarity. This clarity allows react to optimize your application much better than you could do manually.

So: where performance matters (complex updates) react can be faster because of consistency that allows for better optimizations.


Stephen Cleary

0 points

7 years ago

IMO, the core of React is quite simple: better component boundaries. Saying that it’s OK to define the "view" and "logic" of a component in the same place, since it’s just one component (and usually a change in one necessitates a change in the other). And saying that it’s OK to include some "style" as part of that "view" instead of forcing all styles to be global. That’s really all React is - IMO the virtual DOM is just an optimization.

React by itself says nothing about state management. Redux, however, does bring an important advancement to the table. Redux is really just taking some basic functional concepts and applying them to web page state management ("apply" - see what I did there ;). Redux originated in React, but there’s already a Redux library for Angular, and I wrote a Redux library for Aurelia.

[Commento](https://commento.io)