Live data from Hacker News

Is ReactJS really fast?

blog.500tech.com

151–160 of 191 posts

Re: Is ReactJS really fast?

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

oh! yeah, that does make more sense; i was thinking of something like a qt webview.

Re: Is ReactJS really fast?

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

> - JSX breaks your IDE's error checking and line numbers in error messages (and not using JSX is a pain/verbose)

JSX doesn't break line numbers in error messages because JSX to JS transform preserves line numbers.

Re: Is ReactJS really fast?

#153
post #144

Earlier quoted context omitted.

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.

> no they aren't. says who?

Re: Is ReactJS really fast?

#154

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 agree completely - I've been recently using React to build a static website, and it's a joy to use over standard HTML, or something rendered server side. Being able to split apart the different parts of your page into small components makes it easy to reason about without needing to take an entire page in.

The fact that you can then transfer that to a dynamic website with reasonably good performance is huge IMO.

Re: Is ReactJS really fast?

#155
post #144

Earlier quoted context omitted.

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.

Okay, but react has a bunch of performance and design pitfalls that one could fall into just as easily as not compiling templates. In fact, probably easier to fall into, because compiling templates is a best practice thats built into scaffolding libraries and discussed all over the place.

Re: Is ReactJS really fast?

#156
We worked really hard to try to optimize angular code to make it "Fast enough" for our cordova app.. On the web, it doesn't really matter because everything was 250ms. We tried lots of hack with angular, and eventually, I tried replacing the slowest view with React. And without hack it was so much faster. It's obviously possible to do the same thing with Angular by not using the dirty checking (or not using $scope at all), but at this point, you're not really using angular anymore).

Point is, for us, React led to a much cleaner and faster code. I was also waiting for an excuse to jump on ES6 and prefer the controlled state/props to the $scope/directives philosophy. We're not using flux but have been highly inspired by it and (Optmimizely's) nuclear.js library.

Re: Is ReactJS really fast?

#157
post #58
post #41

Earlier quoted context omitted.

Say you want a form with as-you-type validation. You can't have a view containing the whole form and just re-render that as someone types. If you did, you'd lose the user current focus on every render. This forces you to manipulate parts of the DOM "by hand", something React abstracts for you. I find Backbone events extremely hard to work with (error-prone, super hard to test / debug), because there are many operatio…

> You can't have a view containing the whole form and just re-render that as someone types. If you did, you'd lose the user current focus on every render. This forces you to manipulate parts of the DOM "by hand", something React abstracts for you. This is not how most modern view engines work. Somehow the React community has convinced the entire JS world that they invented the idea of "only render what has changed" w…

We're talking about Backbone + templating here, and that is what happens with those libs.

Obviously there are other libs / frameworks that can do that, all of them using some sort of shadow DOM.

Re: Is ReactJS really fast?

#158
post #58

Earlier quoted context omitted.

> You can't have a view containing the whole form and just re-render that as someone types. If you did, you'd lose the user current focus on every render. This forces you to manipulate parts of the DOM "by hand", something React abstracts for you. This is not how most modern view engines work. Somehow the React community has convinced the entire JS world that they invented the idea of "only render what has changed" w…

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

React only "renders" everything within its shadow DOM. It then applies the results of diffing the previous and current version trying to use the most atomic operation (innerText, add/removeClass, add/removeNode, etc)

Re: Is ReactJS really fast?

#159
post #112

Earlier quoted context omitted.

I was swept away by the React hype a bit. I tried to sell my team on React by stating many of the same points and eventually we decided to stick with our current JS framework: ExtJS. And I'm thankful I was overruled a bit. For our team and the types of applications we're building ExtJS simply makes much more sense. I've used React now for a simple web app and also a Chrome extension. For certain UIs scenarios like Fa…

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…

I've also been thinking about migrating away from Ext--on the one hand there are theming issues--on the plus side, I rather like their grid widget. But, their licensing model just seems to keep changing and that worries me enough to want to move away. For example, now it's just not possible to buy a single developer seat.

Re: Is ReactJS really fast?

#160
post #129

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…

It's not the over-theming (although that is part of what creates that easily-recognizable Ext-ness), it's the strictness with which they expect you to use their components. If you want a dropdown that functions exactly the way Ext made a dropdown it is the easiest thing in the world, but if you want a slightly different behavior then it's a whole rigamarole of events and overrides and stuff. It's not just how it look…

To be fair, I think that ExtJs 4 offered a number of improvements over 3--but also introduced a lot of backwards incompatibility...
Post reply on HN