Live data from Hacker News

Is ReactJS really fast?

blog.500tech.com

131–140 of 191 posts

Re: Is ReactJS really fast?

#131
post #127
post #102

Earlier quoted context omitted.

> 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.

i'm not a web dev, so i could be missing something obvious, but i can't think of any use cases for inspecting the dom from native code. example?

The comment makes some sense if you replace "native" with "plain" or "vanilla" JavaScript.

Re: Is ReactJS really fast?

#132

Earlier quoted context omitted.

I'm no AAA game dev but I'm pretty sure games are all about mutable state. I'd love to see some examples of what you're talking about.

Sorry I should have said view state.

The DOM is not a view. In fact it stands for Document Object Model :P I know it's confusing since it's where you create the view for your app, but the DOM is actually a model of your view (i.e. the V on your app's MVC is built manipulating the M on the browser's MVC).

Why can't the web draw at 100 FPS from immutable data? Because the web renders through constraints based on the DOM, and constraints cascade, which is a problem more akin to physics in games (which are mutable for a reason) than their graphics. The bottleneck is updating such model.

Also, game physics constraints are usually faster to calculate because action at a distance is unusual and there are optimizations like quad-trees. In web pages, inserting a single DOM node can trigger a huge change, making it more like simulating hydrodynamics that the common solids found in videogames.

Re: Is ReactJS really fast?

#133
post #110
post #102

Earlier quoted context omitted.

> 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?

netflix = have their own renderer. that is lot of hours of good engineers dedicated to that.

facebook = probably hack away all the low level stuff they need to tweak.

bbc = they probably have the same problem we have here. that does not stop them or we to boast that we use react all over the place. doesn't mean we like it.

Re: Is ReactJS really fast?

#134
post #112

Earlier quoted context omitted.

We're in the process of migrating from ExtJS to React, and it is, to put it simply, awesome. Ext was great when we started because it gave us all these great out-of-the-box components to just mix and match and shove things together and get things out the door. But relatively quickly (i.e. as soon as we wanted to make something look like it wasn't Ext, and you can always easily tell an Ext app) we ran into Ext's infle…

Is your main complaint over theming ExtJS? We're also building enterprisey software that's for the most part not consumer facing. Our clients are much more concerned about functionality. So while we have several custom themes for our products, we haven't drastically altered the base themes. Regarding boilerplate, I'll give you a simple example. In ExtJS 4, it's one line of code to wire up an event handler in your con…

@mejari - the reason why I wrote out the React code long-form is because I couldn't figure out how to write it concisely :) Not because I'm biased hehe.

I disagree it's not identical to React+Flux at all. There's more pieces and wiring required for the typical "Save" button example. In react+flux, the views need to listen on stores:

    MyStore.listen(this._onMyStoreChange.bind(this));
The views manually call action creators:

    MyActions.saveData();
Action creators dispatch separate events for beforeRequest, onRequest, onError events:

    this.actions.onBeforeSaveSomething();

    // do the save
    this.dispatch({ type: 'SUCCESS', data: myData });
Stores need to listen for action creator events:

    this.bindAction(actions.onBeforeSaveSomething, this.onBeforeSaveSomething);
    this.bindAction(actions.onSave, this.onSave);
    this.bindAction(actions.onError, this.onError);
    
In the Flux flavor I'm using (alt), stores automatically dispatch events when their state is changed, but I found managing the store state is annoying because of the loading, error flags[1].

So the store.onSave might look like this:

    this.loading = false;
    this.error = null;
    this.data = data;
Finally, the view updates it's state in response to a store change which automatically calls render.

Then in the view render, you can show your loading/saving mask.

[1] https://news.ycombinator.com/item?id=9315503

Re: Is ReactJS really fast?

#135
post #131
post #127

Earlier quoted context omitted.

i'm not a web dev, so i could be missing something obvious, but i can't think of any use cases for inspecting the dom from native code. example?

The comment makes some sense if you replace "native" with "plain" or "vanilla" JavaScript.

yep. like 99.9% of the code ad networks expect. they want to check DOM state to make sure you are not a sleazy publisher hiding the ads under the content or if you are not being shown in an iframe on some porn site.

with react, they will get inconclusive results because their code might run while they are virtualized or god forbid during the render. and you will only get garbage ads because now they consider you a garbage publisher.

Re: Is ReactJS really fast?

#136
post #94

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.

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.

Actually, games are generally an area where immutability is relatively easy to use. All of the mutation code can be isolated in one place that handles the transition to the next "tick", leaving nothing but immutables in the game logic itself. This is analogous to how ReactJS manages things through diffing.

Re: Is ReactJS really fast?

#137

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 little time I've spent learning Mithril [1] makes me think it's a nice middle ground between speed and pleasurable coding experience. Their benchmarks have it at 8x faster at rendering (uncompiled) and 28x faster to load (although Benchmarks Lie (TM)). It feels like writing vanilla javascript for the most part, which is delightful and exciting. The Views part however, which is most comparable with React since Rea…

Mithril is awesome (been using it for 7 months now). I really like that they finally have implemented components and described how they should be made.

Re: Is ReactJS really fast?

#138
post #76

Earlier quoted context omitted.

You've got that backwards. Every other framework "only renders what has changed". React re-renders everything.

Reread that in the context of the parent's statement. There is a misconception that every other template library blows away parts of the dom on each update and that only React will do something like input.value=newValue, but this is not the case.

I sure don't see where that misconception is the fault of "the React community."

In fact, this comment is the first time I've seen that formulated. I'll be honest, I don't read every React-related forum entry on the Internet, so I may have missed someone somewhere spreading such a misconception, but there certainly is no such centrally communicated premise.

Re: Is ReactJS really fast?

#139

Earlier quoted context omitted.

Is your main complaint over theming ExtJS? We're also building enterprisey software that's for the most part not consumer facing. Our clients are much more concerned about functionality. So while we have several custom themes for our products, we haven't drastically altered the base themes. Regarding boilerplate, I'll give you a simple example. In ExtJS 4, it's one line of code to wire up an event handler in your con…

@mejari - the reason why I wrote out the React code long-form is because I couldn't figure out how to write it concisely :) Not because I'm biased hehe. I disagree it's not identical to React+Flux at all. There's more pieces and wiring required for the typical "Save" button example. In react+flux, the views need to listen on stores: MyStore.listen(this._onMyStoreChange.bind(this)); The views manually call action crea…

I guess it just comes down to comparing two different things. Yes, you have to do more setup with React because React isn't what Ext is. But if you set up your React to the point that Ext is at, with data binding and error handling and event listening that Ext magics away you get code that is very similar. Almost all of your code is doing what Ext magically does, but in a React application of any size these things are handled via components and mixins and such and you don't have to deal with them in the clunky way you're describing.

Re: Is ReactJS really fast?

#140
From a ClojureScript viewpoint, the whole "really fast" thing is a red herring anyway. I don't care whether it's faster than Angular at rendering some tables. What I do care about is the model: my views can now be functions of my immutable data structures and I can write components that react to changes.

There are two performance-related issues I care about: React doesn't modify the DOM if it doesn't need to, and my components do not even re-render most of the time, because they don't need to if the data hasn't changed (and thanks to immutable data structures the comparisons are really cheap).

It is this approach that is revolutionary. "Really fast" has nothing to do with it. Sure, I'm glad that I can easily create complex apps that have exactly zero performance issues right from the start, but I'm not going to compete in any benchmarks anyway.

Post reply on HN