Live data from Hacker News

Is ReactJS really fast?

blog.500tech.com

161–170 of 191 posts

Re: Is ReactJS really fast?

#161
post #94

Earlier quoted context omitted.

> 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 ho…

Conceptually it's very easy:

World(t+1) = Sim(World(t))

but performance in practice is going to suffer a lot compared to in-place mutation, for any simulation that has a great degree of temporal coherence. I don't know of real world examples of game developed with immutable / reactive patterns, outside of thought experiments like Carmack's (Or Tim Sweeney's), or a few simple games in Haskell, Elm, etc. But I'd love to hear of more examples.

(Edit: some parts of games and game engines use this sort of "double buffer" approach for other purposes: smoothing and interpolation mostly, of visual frames in between logic ticks, or for network prediction. But in the cases I have seen or coded, most of the world state is not interpolated and not duplicated)

Re: Is ReactJS really fast?

#162
The jsblocks library authors are being incredibly deceitful with the tests they are showing off. Their entire premise is that they are faster than react but their tests are just manipulated. They posted this up on product hunt, http://www.producthunt.com/posts/jsblocks, and at that point it claimed to be at 800ms on initial load where as react had 1250ms. I checked out the react code and there was a hidden input that was being rendered with every td element on the table. React has very heavy inputs which is why you are supposed to use state.

original test (with hidden td elements)

js blocks: 800ms

react: 1250ms

After removing hidden element

jsblocks: 350-400ms

react: 200-350ms

So yes, jsblocks can render a lot more input elements that you shouldn't be using faster than react. The react team explains why the inputs are fairly heavy when rendering a large amount, https://github.com/facebook/react/issues/3771 They didn't stop there though and they responded to my claims and came back with a new test. This time they just ramped up the number of data points by double and added an extra td element to make it an unreasonable absurd amount of elements.

revised test (original test of 5000 elements to 18000 elements)

jsblocks: 600ms (they posted 700ms, so ill give them that)

react: 700ms (they posted 950ms)

After removing half of the data to about 9000 elements react already started to tie jsblocks

jsblocks: 450ms

react: 450ms

Going down to about 5000 elements

jsblocks: 250ms

react: 200ms

Whether or not there is any merit to this library, you can't just go claiming that you have the fastest library so audaciously like this blog post and their marketing. It's terrible for the community. There are an absurd amount of javascript libraries and getting devs to push a few key frameworks forward is already difficult enough. And if you are going to add another library to the list, at least be able to back up your claims.

I will admit that jsblocks seems to be better at rendering extremely large amounts of tabular data, but that is never an issue for me and you should be using lots of different techniques to mitigate that anyway. But once you get to realistic scenarios react is still faster and comes with tons of other advantages.

I didn't test the angular one because I don't know enough to spot odd code, but without even looking into the code the fact that angular was the only one that didn't have a minified library seems fishy. It's at 900+kb compared to the jsblocks/react at 125ish kb. To me it seems like since status qua is react is faster and angular is slower, they just constructed these tests to make it 3. angular, 2. react, 1. jsblocks (the fastest library ever!!).

So there's my rant. Please stop promoting your library like you are, it's just distasteful.

edit: https://drive.google.com/folderview?id=0BxTyg4RuMOHUfjlvTkN3... Here's a link of the original test without the hidden elements, the response test that required a ton of elements, and the email they sent still talking about their amazing speed!

Re: Is ReactJS really fast?

#163
post #91

Earlier quoted context omitted.

> Finally, wrt to React: it's just a view layer. Comparing it to Ember or Angular as if it were a fully fledged, swappable alternative doesn't really make sense. This every time. If there's any bloggers among you: as soon as you start doing a 1:1 comparison between Angular and React, stop.

I (apparently incorrectly) thought they were similar enough to compare. What are the significant additional features that Ember and Angular provide?

Ember provides everything Angular does plus:

* More mature router (IMHO, the best router out of all JS frameworks) * A CLI for developers to generate their models, views, components, controllers, routes * An opinion on where things should live and how they should be structured (ups the learning curve but saves time in the seemingly endless developer debates when discussing architecture)

Re: Is ReactJS really fast?

#164
AngularJS is like writing in assembly. Sure, if you work really hard you can make it as performant as compiled C (ReactJS), but by that time your C buddy has built so much functionality you might as well stop all together.

(note: I've done professional angularjs and reactjs projects)

Re: Is ReactJS really fast?

#165

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 also had issue with the amount of setup with React, which is part of what drove me to Mithril, which has almost zero boilerplate. Nearly every line of code you write is either relevant application logic or declarative view code.

Re: Is ReactJS really fast?

#166

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…

> Observables+DOM elements is a leaky abstraction The DOM itself is also a leaky abstraction. Render cycles are so prohibitively slow that we've started maintaining a parallel DOM and implementing diffing algorithms in JavaScript. As brilliant as that may be, it's also crazy that it's come to that. This is a problem that should be solved in the browser. HTML5 should add a simple API to transactionally update the DOM…

For what it's worth, transactional DOM update is a fantastic idea that I hadn't heard before your comment. Are you familiar with anyone actively exploring such a thing?

Re: Is ReactJS really fast?

#167
post #161

Earlier quoted context omitted.

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 ho…

Conceptually it's very easy: World(t+1) = Sim(World(t)) but performance in practice is going to suffer a lot compared to in-place mutation, for any simulation that has a great degree of temporal coherence. I don't know of real world examples of game developed with immutable / reactive patterns, outside of thought experiments like Carmack's (Or Tim Sweeney's), or a few simple games in Haskell, Elm, etc. But I'd love t…

I am not yet a professional game developer, but I did write a multiplayer server in Clojure. It had most of the features of the current version, which was ported to golang:

https://secure.emergencevector.com:8000/

(Be sure to mouse click on the map, otherwise your arrow key keystrokes may never get read due to focus.)

I got pretty similar performance out of Clojure's persistent collections as I got out of mutable state in a traditional game loop in golang. (Though to be honest, in neither case was that enough performance. 150 to 250 concurrent users, potentially all in the same location, interacting.)

Re: Is ReactJS really fast?

#168
post #92

Pet peeve: Can we please stop blindly abusing `track by $index` without understanding it? The thing with `track by $index` that nobody talks about is that, like many of the workarounds in Angular, it's a footgun in disguise. Consider this: http://plnkr.co/edit/qKm7fYZFCkXHI5pkPMYL?p=preview and focus on the first input. Notice that the focus stays on the first input, instead of sticking with the value as it jumps aro…

This is absolutely a contrived example. $index is the equivalent to `var ctrl = angular.controller`, something that serves very well to communicate basic concepts but that you would never use in a real-world application. If you're dealing with server side data, your model should have a real unique key/id, and that is what you track by.

The amount of stuff in AngularJS that "serves very well to communicate basic concepts but that you would never use in a real-world application" is a huge problem with the framework. It's a perfect storm of a documentation site and blogosphere full of misleading and/or contradictory advice and examples, combined with conceptual and implementation complexity that makes it incredibly hard to just read the source and deduce best practices from first principles.

This article contains a good example of the phenomenon: it suggests switching from `$timeout` to `setTimeout` with `$digest` to "give both frameworks the same information". Is that a silver bullet solution, or does it come with trade-offs, and if it does, what are they? I'm not sure, but my gut says that I shouldn't change this pattern in my code everywhere without doing a bunch of research to understand exactly what is going on. That's fine, researching how our tools work is a big part of the job, but I feel like Angular has a disproportionate amount of this sort of complexity compared with other tools I've used.

Re: Is ReactJS really fast?

#169
post #87

Earlier quoted context omitted.

That's a sign someone has fundamentally misunderstood Angular and is hacking around their misunderstanding.

Why do you say that? What about it makes it fundamentally misunderstanding?

You should never have to use $scope.digest() unless you're testing a directive. You should never have to fire a digest loop manually.

Re: Is ReactJS really fast?

#170

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…

> Observables+DOM elements is a leaky abstraction The DOM itself is also a leaky abstraction. Render cycles are so prohibitively slow that we've started maintaining a parallel DOM and implementing diffing algorithms in JavaScript. As brilliant as that may be, it's also crazy that it's come to that. This is a problem that should be solved in the browser. HTML5 should add a simple API to transactionally update the DOM…

The DOM _is_ only rendered after your JavaScript is finished running - as long as you don't ask for properties that can only be known By rendering it out.
Post reply on HN