Because it's built on the assumption that just because DOM access is slow, then it's a good idea to just add another layer of JS in order to provide a cached-like faster DOM access speed, rather than focusing on fixing DOM access speed issue itself.

React augments the complexity of a stack that it's already too complex, to an unneeded, non-sustainable and dev-unfriendly way in which we are supposed to use HTML tags inside JS scripts.

React is just a Facebook's own short-sighted solution to slow DOM manipulation. The fact that it is OSS doesn't make it necessarily a good thing.

React is not a product of love for a greatly engineered system, but obviously just a product of FB's understandable necessity to work faster "today and here", in order to keep bringing home their daily profit.

React is not a solution, it's a patch, a ugly one.

We are not forced to like it just because FB made it and made it OS.

> Because it's built on the assumption that just because DOM access is slow, then it's a good idea to just add another layer of JS in order to provide a cached-like faster DOM access speed, rather than focusing on fixing DOM access speed issue itself.

The virtual DOM is just an implementation detail. In my eyes, React's big feature is that it is a declarative, component-based UI model. Look at React Native or ComponentKit - they are not built around the idea that CocoaTouch is slow, but rather that there are simpler ways to do UI than the traditional imperative approach.

> React augments the complexity of a stack that it's already too complex, to an unneeded, non-sustainable and dev-unfriendly way in which we are supposed to use HTML tags inside JS scripts.

In my experience, as I mentioned above, React actually provides a fantastic abstraction that makes it simpler to build UIs. I haven't found it to be dev-unfriendly at all, the opposite actually - I find that it is a highly pragmatic, productive and pleasant way to work. But I suppose that's a matter of preference. What do you find unfriendly about it in particular?

> React is not a product of love for a greatly engineered system, but obviously just a product of FB's understandable necessity to work faster "today and here", in order to keep bringing home their daily profit.

This point I must disagree with absolutely. I have had many interactions with people who work on React and from my point of view it is indeed a labor of love as much as any I've seen on an OSS project. Do you have any examples that you can point towards to back up your assertion? Just watch presentations by any of the React team members and you'll see that there are real people behind it that care deeply about it. Better yet, talk to any of them in person and see how excited they are! This isn't a heartless top-down mandated project by a massive organization to squeeze more money out, but rather it started off as a skunkworks project by a single engineer in his spare time who thought that UI could be simpler, that caught on within the company because it turned out to be a great idea.

> React is not a solution, it's a patch, a ugly one. > We are not forced to like it just because FB made it and made it OS.

Well, isn't the world beautiful, so many different opinions! I'm extremely curious what your preferred tooling is, or any suggestions you have to make React better. Maybe you could write a longer form essay to elaborate on your criticisms above?

I wish you would start with this argument, instead of the one that looked very much like trolling.

Can DOM be faster? Maybe so. Does that mean React is a bad idea? No. In fact, React is Multiple Buffering[1] in the age of DOM. It is not that DOM is slow, it is that change of DOM triggers the layout and layout is inherently slow, because it is complex.

If you do not need re-layout on each DOM change (and most of the time you do not), React allows you to batch changes in a very clean way.

[1] https://en.wikipedia.org/wiki/Multiple_buffering

There isn't a relayout on each DOM change. Changes trigger layout when you read DOM properties such as clientWidth or when the event loop loops.

The DOM is slow meme confuses me. Yes, if one isn't careful, one can get into trouble. But the same is true for all platforms/frameworks/concepts/religions.

As it turns out, the fastest way to build + update DOM, is with the DOM... #mindblown (its also the only way ;))

I believe the actual pain felt, is one of ergonomics. This is largely related to what MrBra mentioned, it turns out a complex stack is complex I suppose we just need to keep fighting the entropy us developers like to add.

As others point out, this is provably false. React's use of a virtual DOM is merely an optimization. The same principle is used in many other areas: Double-buffered rendering in graphics engines, for example.

Facebook clearly chose HTML syntax (JSX) to be familiar with how developers are used to interact with HTML, thus lowering the learning curve. As others point out, the JSX syntax is still beneficial when not targeting the DOM, as in the case of React Native. JSX is just a preprocessor, and no different than writing, say, Mustache templates.

What React brings to the table is a framework for declarative UI components. Functionally, React components are no different than, say, Backbone views (indeed it's quite trivial to port a backbone view to a React component), but the data flow principles promoted by React (unidirectional MVC, immutability, declarativity, discrete state transitions) are different, and somewhat novel in the UI/MVC space.

React is definitely not just a "patch". If you think that, you've clearly not studied it closely enough.

Thanks for the effort :), but these points are simply unsound. Far from being a patch, React offers -one- standard model for writing UIs on any platform. Thus React at its core has nothing to do with the DOM (see React-Hardware, React-Blessed, React-Native, React-Canvas...React-DOM is just another rendering target). Also, in a real-world app React drastically simplifies actual code with the tiny tradeoff of adding a small amount of complexity onto "the web stack". If you actually care and weren't just trolling, you---or a reader who shares your uninformed intuition---might enjoy this wonderful high-level overview of what React is actually about: https://www.youtube.com/watch?v=H1vW1w8k7J0

I do not know where to start with this. Not one single part is true and all of them come from a very misinformed and misguided understanding of both the DOM (and what it is, why it's slow) and React.

It's hard to unpack all of it without writing an essay.

You don't have to JSX inside your render function. You can use React's built-in factories.

Other than that, getting around slow DOM manipulation is only one advantage of React. There are many others, such as making it super easy to reason about complex code, for example by not having to worry about the excruciating details of how multiple event handlers that are bound to the same element will behave.

Separating the state from the DOM itself is a brilliant idea and the elegance with which React accomplishes this disproves your claim that it is simply an "ugly patch".

It's basically like creating a diff patch, so you're close.

It is like this:

1. Create full new version

2. Run a diff with the old version

3. Patch

Because of 1, it is bound to be slow (in a computational complexity sense). Based on the popularity of React and its wide acceptance, I wonder if people learn computational complexity theory anymore these days?

PS: yes I know there are tricks to make 1 faster, but these are really hacks (require extra thinking and are error-prone) and deviate from the original "React" philosophy (they are basically the old style of doing things), so these don't count.

Part of implementing an efficient React app is making sure that prop/state transitions are minimized. Coincidentally, this is also (abstractly) true about any UI technology, not just React. But React sacrifices a little bit of speed in order to make the UI declarative, as opposed to the finicky, error-prone and messy way we used to do it before with frameworks like Backbone.

Have you actually developed a large React app? Because you might be surprised at how fast React really is in practice.

Large React apps are actually no faster than large apps written in Ember or Angular, and I've personally been surprised by how slow React got on a large app. At some point, in every framework, you will run into bottlenecks and none of them provide silver bullets.

> Large React apps are actually no faster than large apps written in Ember or Angular

This is (more or less) true now. It wasn't when React first showed up. Angular is also only just as fast when you actively code your apps in the same way as React (basically using a prop/state system but in an Angular way). This isn't also the method generally championed in Angular (1.x anyhow).

Ember was always pretty fast but post-React it changed a lot of how it did it's rendering... influenced by React!

So claiming that React apps are no faster is a bit disingenuous as the reason for that is because the other frameworks saw what React was doing and agreed with it.

Actually, simply using "track by" in Angular puts it on par with React's performance regardless of whether or not you follow React's patterns. You do understand that Angular 1.x's $scope is essentially a virtual DOM inasmuch as it's a javascript representation of the DOM which provides a more efficient means of diffing (dirty checking in Angular's case). "Virtual DOM" is just a fancy buzzword for React's solution to figuring out what to change. React's requirement that the entire DOM tree be re-rendered any time any state changes meant that dirty checking would be prohibitively expensive, so they had to come up with a clever workaround which, to their credit, ended up being just as performant as Angular's dirty checking.

You can use Angular 1.x in exactly the same way you use React by only ever using 1-way binding and constructing your entire application out of directives scoped to elements. The only thing Angular 1.x doesn't let you do is use JSX, but then again, you could just use plain old javascript and imperatively build up your DOM elements (which is what JSX does under the hood anyways) if you really don't want to have .html files.

Sure, but the fact that React is as fast as those other frameworks, with none of the code overhead of having to manually patch the DOM, is a benefit. React doesn't need to be faster, it just needs to be comparably fast.

What do you mean by "none of the code overhead of having to manually patch the DOM"? None of the other frameworks make you manually patch the DOM, they all do it automatically in their own way.

I actually don't know Angular or Ember well — before React I was largely using Backbone, where DOM patching is manual unless you use templates, so that's really what I was referring to. The benefits apply to those frameworks, too, then, of course.

mmm not quite.

Step 1 would be slow if it created it in a real dom but as it's not (that's why it's called a "Virtual DOM") and is in fact just an object representation of the dom it's actually rather fast.

After all - it's just an object tree, and that's quite fast to parse.

The diff part is probably the slowest part in the React chain actually - because it actually has to compare to the other (virtual) representation of the DOM. Deep comparisons are just... well they'll never be trivial.

But no, it's really not extra thinking, it's not error prone, and it's basically due to it not really being what you're describing it as.

I think you totally missed the point.

Let's say that you have a page containing a billion little images. On every update, your React-enabled code needs to create a virtual DOM containing all those images. This takes time, regardless of whether the virtual DOM is fast. Hence my point.

And even if it may be only a few milliseconds for a hundred images, it will take seconds or even minutes for millions of images. And even if only 1 of the images changed. This is of course not acceptable.

Most programmers are already happy if it works for 100 images. However, imagine that the inventor of quicksort invented bubblesort instead, stating it is fast enough for 100 elements. From a CS point of view, this situation is just ridiculous.

Succinct and to the point.

See my comment elsewhere in this topic.