Is ReactJS really fast? • Hacker News Board

Re: Is ReactJS really fast?

#101

Post by lucisferre » Mon, Jun 01, 2015, 4:54 PM UTC

feedjoelpie wrote: post #13

React.js is actually just really pleasant to work in and easy to reason about, and the virtual DOM is what makes that all possible without it becoming unacceptably slow. DOM diffing isn't there to make React faster than everything else ever imagined. It's there to let you stop thinking about the DOM and focus on the world state of your frontend instead. I wasn't truly interested in React until I read this, which does…

The leaky abstraction thing is at the core of everything that is wrong the the AngularJS model. I still like a number of things about AngularJS, but the data-binding model was really poorly thought out and implemented.

As far as I can tell this has been recognized even by the core team and is a major reason for the sizeable changes in 2.0. It surprises me how many people in the community continue to defend it as "OK" when even the AngularJS team has arguably admitted it's mistakes.

Re: Is ReactJS really fast?

#102

Post by gcb0 » Mon, Jun 01, 2015, 4:56 PM UTC

feedjoelpie wrote: post #13

React.js is actually just really pleasant to work in and easy to reason about, and the virtual DOM is what makes that all possible without it becoming unacceptably slow. DOM diffing isn't there to make React faster than everything else ever imagined. It's there to let you stop thinking about the DOM and focus on the world state of your frontend instead. I wasn't truly interested in React until I read this, which does…

> pleasant to work with

if you're a startup or small shop.

if you have to deal with any native code that expects to know something about the dom, now you just forced that code to do expensive and constant polling algos because you completely pulled the dom from under its feet.

Re: Is ReactJS really fast?

#103

Post by lucisferre » Mon, Jun 01, 2015, 4:56 PM UTC

dmak wrote: post #86

drapper wrote: post #69

When I was using Angular I thought doing something like setTimeout(function() { $scope.$digest(); }, 0); was an ugly hack and a sign of angular's leaky abstractionism showing up. Is this considered a good practice now (or always was)? Edit: just to clarify, I'm asking because in OP this was given as a one of the way to fix Angular speed issues.

It's the same thing as using $timeout; It runs a digest at the end after a setTimeout. I wouldn't call it a good practice, but it wouldn't bother me either if I saw it in a codebase. You are also welcome to use things like $evalAsync.

It's not the same thing, as the author points out since using `$timeout` in the example without an isolate scope was the source of the original problem. Instead he's suggesting you use $timeout without it's default behaviour (something that's possible now through the false argument or by calling setTimeout directly).

This is absolutely a leaky abstraction, and whether or not it's necessary sometimes when using Angular, it should still bother you.

Re: Is ReactJS really fast?

#104

Post by mmarklar » Mon, Jun 01, 2015, 4:59 PM UTC

mrharrison wrote: post #24

From other devs I know they have said React functionality on mobile is quite poor. Drag and drop and scroll, doesn't work as well, because the virtual DOM isn't adapted work to well on mobile. So for that reason, I won't use React, and rather go Vanilla or use Backbone. After getting burned by Angular, I'm really weary to adopt another fancy framework.

Drag and drop/scroll should work on the real DOM not the virtual DOM, no? I use Drag and Drop in a web app (using Om, which is a clojurescript library built on top of React) and it works just fine across all platforms.

Re: Is ReactJS really fast?

#105

Post by TheCoelacanth » Mon, Jun 01, 2015, 5:02 PM UTC

Touche wrote: post #60

whoisthemachine wrote: post #4

The basic premise seems to be that AngularJS can be just as performant as ReactJS if you do your homework and avoid common pitfalls of AngularJS. I would argue that the beauty of ReactJS is that it doesn't have any gotchas. It's performant without needing a deep knowledge of the framework.

> I would argue that the beauty of ReactJS is that it doesn't have any gotchas. It's performant without needing a deep knowledge of the framework. shouldComponentUpdate is just as "deep" as this Angular optimization.

Just use PureRenderMixin for all components and you never have to implement shouldComponentUpdate.

Re: Is ReactJS really fast?

#106

Post by agmcleod » Mon, Jun 01, 2015, 5:07 PM UTC

feedjoelpie wrote: post #13

React.js is actually just really pleasant to work in and easy to reason about, and the virtual DOM is what makes that all possible without it becoming unacceptably slow. DOM diffing isn't there to make React faster than everything else ever imagined. It's there to let you stop thinking about the DOM and focus on the world state of your frontend instead. I wasn't truly interested in React until I read this, which does…

I completely agree. Trying out react and learning how to structure things with it. It all just felt natural.

Re: Is ReactJS really fast?

#107

Post by strictfp » Mon, Jun 01, 2015, 5:07 PM UTC

Jare wrote: post #94

strictfp wrote: post #79

Earlier quoted context omitted.

I just have to add that this is how pages were generated server-side before XmlHttpRequest emerged. This was deliberate. Addressable and re-loadable states were part of the original design by Tim Berners-Lee. The fact that we have had this whole circus with mutable state on the client side is just a joke to me. I hope that someone invents a sane client-side lib with sane page generation quite soon. Should certainly b…

> If game devs redraw their stuff at 100+ FPS and haven't needed mutable state Well I wouldn't quite say that... although there was a time when "dirty rectangles" was an important feature of a graphics engine. Generally speaking, games are based on mutation of entities: to move an existing entity, we mutate their position, not recreate them in the new position.

Sorry I should have said view state. Dirty rectangles are indeed such an optimization, you are right.

Re: Is ReactJS really fast?

#108

Post by [deleted] » Mon, Jun 01, 2015, 5:15 PM UTC

[deleted]

Re: Is ReactJS really fast?

#109

Post by EGreg » Mon, Jun 01, 2015, 5:16 PM UTC

No kidding. I've been saying that frameworks like Angular, Ember etc. do their dirty-checking in the MODEL, whereas React, Mithril and others do their dirty-checking in the VIEW.

The former sometimes get some misses when the underlying data changes but the bound views stay the same. And how often does that really happen? On the other hand, "two-way data binding" is extra sugar that is, indeed, slow. Even Angular 2 got away from that.

So what is the point of using React or Mithril? Well, there are two. One is if you enjoy having idempotent rendering functions rendering EVERYTHING OFFSCREEN ON EVERY FRAME for making 1-1 correspondence between "state" and "view" explicit. The other is that Facebook actually uses it in their own products, and open-sources React Native, so you can technically build native apps (if you're willing to put up with their embedded JS environment instead of the browser's). And since they are so enthusiastic about it, maybe someday you will be able to re-use a bunch of components Facebook, or others, write for you, in your apps.

Personally, I will prefer http://platform.qbix.com ;-)

Re: Is ReactJS really fast?

#110

Post by nroman » Mon, Jun 01, 2015, 5:19 PM UTC

gcb0 wrote: post #102

feedjoelpie wrote: post #13

React.js is actually just really pleasant to work in and easy to reason about, and the virtual DOM is what makes that all possible without it becoming unacceptably slow. DOM diffing isn't there to make React faster than everything else ever imagined. It's there to let you stop thinking about the DOM and focus on the world state of your frontend instead. I wasn't truly interested in React until I read this, which does…

> pleasant to work with if you're a startup or small shop. if you have to deal with any native code that expects to know something about the dom, now you just forced that code to do expensive and constant polling algos because you completely pulled the dom from under its feet.

> small shop

Like Facebook? Netflix? The BBC?