Is ReactJS really fast? • Hacker News Board

Re: Is ReactJS really fast?

#141

Post by kansface » Mon, Jun 01, 2015, 7:38 PM UTC

manishsharan wrote: post #28

I have been using Backbone + moustache/handlebar templates and I am not clear on why use a virtualDOM. My application has several views and in my views, I use events to sync data model changes with the view and the view's render function maintains the DOM element . None of my views have to deal with the whole DOM. Therefore, I am really confused. So with my apologies for asking a dumb question : why maintain the whol…

At Floobits, we started out using Backbone and handlebars because that is what we knew. About a year ago, we did a rewrite into React + Flux (our own implementation, because it was a year ago). The rewrite reduced KLOCs by something like 40%. Moreover, it radically simplified the code base. The big wins include one way data binding, updating views reactively, and removing boilerplate.

I did not realize it at the time, but two way data binding is evil. We spent a disproportionately large amount of time tracing (hard) bugs related to dispatching events. Bugs related to a child updating its parent that may or may not update the child again. Data should flow in one and only one direction. It may be possible to do this in Backbone, but its not encouraged when listening to models.

With any View system for the front end, you are necessarily responsible for creating the initial state of the DOM. You are also typically responsible for updating the DOM with your application state. If you ever run into a performance bottleneck, you will be forced to step out of your template system - you will either have to decompose your templates into needlessly small atomic chunks or resort to ad hoc DOM munging. Either solution is awful. React more or less lets you specify how to turn data in DOM in exactly one place for all time. In other words, if you care about performance, you will end up poorly reimplementing one of the best features of React.

And finally, Backbone has to be the most verbose JS framework I've ever used.

Re: Is ReactJS really fast?

#142

Post by ufo » Mon, Jun 01, 2015, 7:40 PM UTC

zserge wrote: post #137

jszymborski wrote: post #126

Earlier quoted context omitted.

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.

Whats the situation about components now? Last time I checked this a while ago React would encourage having lots of components with internal state and calling setState on a subcomponent would only update the DOM on that subtree. On the other hand, most other virtualdom frameworks they would encourage you to keep a single global model object to describe the whole page.

Re: Is ReactJS really fast?

#143

Post by dustingetz » Mon, Jun 01, 2015, 7:40 PM UTC

strictfp wrote: post #79

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

> I hope that someone invents a sane client-side lib with sane page generation quite soon. Should certainly be possible.

No good libraries that I know of yet but people are already doing it, at least I am: https://groups.google.com/d/msg/clojurescript/T6no_srtBzc/8o...

Re: Is ReactJS really fast?

#144

Post by aikah » Mon, Jun 01, 2015, 7:46 PM UTC

awinder wrote: post #125

aikah wrote: post #22

Earlier quoted context omitted.

> 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. While AngularJS(1.x) is a bit faster now, your comment is a bit like saying Ruby can be equally fast to Java if one does it homework. AngularJS has architectural problems that can only be reduced if one doesn't use much of angular features(scopes,watches) inside directive…

Given the above discussion about the great performance differences largely being rectified by using angular's `track-by`, I think we can rule out templates as a major driver of performance grief. Templates are usually compiled into native javascript code once (or at least, can and should be), so I really don't see how there should be grand differences between what React is doing and how template processors work. This…

> Templates are usually compiled into native javascript code once

no they aren't.

> (or at least, can and should be)

not by default. React doesn't have templates at all ,so case closed.

Re: Is ReactJS really fast?

#145

Post by Nemcue » Mon, Jun 01, 2015, 7:56 PM UTC

bpicolo wrote: post #80

JDDunn9 wrote: post #36

I think many of the "advantages" of ReactJS are just hype - Immutable data, one directional data flow are easier to learn, understand, harder to break etc. - This isn't anything new, these are just concepts taken from declarative programming. You could always have used those concepts in your JS. They aren't better/worse than imperative programming. That's like saying Haskell is better than C++. - Two-way binding crea…

Routing, http, and models aren't hard problems. Blaming React for not being an entire MVC framework is silly. It's not designed to be, and there are any number of ways to solve that problem. Being able to use it with ANY different set of solutions for MC is especially good. I can use React for UI on top of old jQuery pages if I want to. I'm not forced to change my entire application to use it. Decoupling is a really,…

models aren't hard problems?

OK, then show me a js model system that does one-to-one, one-to-many, and many-to-many relationships — while still having clear, concise and understandable code.

Re: Is ReactJS really fast?

#146

Post by michaelchisari » Mon, Jun 01, 2015, 8:03 PM UTC

curun1r wrote: post #122

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…

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

Seeing as how ES6/7, HTML5 and CSS3 specs haven't been afraid to incorporate ideas that started in external libraries, I do hope we see this baked directly into the browser at some point.

Re: Is ReactJS really fast?

#147

Post by sebringj » Mon, Jun 01, 2015, 8:08 PM UTC

Speed is just one concern but there is a huge ecosystem and native aspects that is more than just one dimension.

Re: Is ReactJS really fast?

#148

Post by istvan__ » Mon, Jun 01, 2015, 8:18 PM UTC

JDDunn9 wrote: post #36

I think many of the "advantages" of ReactJS are just hype - Immutable data, one directional data flow are easier to learn, understand, harder to break etc. - This isn't anything new, these are just concepts taken from declarative programming. You could always have used those concepts in your JS. They aren't better/worse than imperative programming. That's like saying Haskell is better than C++. - Two-way binding crea…

I have to disagree especially with your last point. I just use React to render the UI not to replace the entire backend application with JS. For that, React is perfect.

Re: Is ReactJS really fast?

#149

Post by strictfp » Mon, Jun 01, 2015, 8:19 PM UTC

kaoD wrote: post #132

strictfp wrote: post #95

Earlier quoted context omitted.

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…

You bring up some interesting points. I guess you could compare the DOM to the OpenGL/DirectX scene, with some differences. I'm not entirely convinced that the graphics rendering is less complex though, considering occlusion lightning etc. My main point was really yhat re-building the entire scene is entirely possible and a lot easier to code than manipulating a stateful scene.

I guess physics is stateful since the programmer only sets initial conditions and the engine moves it forward, so the final state is unknown to the programmer.

Dom is a fine tool but I would like a better separation between the model and the view, which re-rendering gives you in a straightforward way. The other way is data binding, but it's considerably more involved and probably not worth it for 99% of the cases IMO.

Re: Is ReactJS really fast?

#150

Post by nogridbag » Mon, Jun 01, 2015, 8:31 PM UTC

mejari wrote: post #139

nogridbag wrote: post #134

Earlier quoted context omitted.

@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 ar…

Not to keep harping on this issue because I know we're way off topic, but I'm genuinely curious how the React code can be simplified because this was one of my main pain points using React. Reflux and alt were major improvements over the Facebook flux impl, but they still require the boilerplate I posted above. If you remove that then you have "Flux magic" :)

There's no Ext magic in the code I posted. Flux and MVC are different patterns. In MVC, the controller typically has direct access to the view and model which is why the code is simple:

    myView.setLoading(true);
    myModel.save(...)

That would look the same in Java Swing for example. Flux is a fundamentally different pattern and one that I really haven't seen the need for in the products we're building to justify it's disadvantages. But for some applications, it's probably the right solution.