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.
Is ReactJS really fast?
151–160 of 191 posts
Re: Is ReactJS really fast?
#152I 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 doesn't break line numbers in error messages because JSX to JS transform preserves line numbers.
Re: Is ReactJS really fast?
#153Earlier 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.
Re: Is ReactJS really fast?
#154React.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 fact that you can then transfer that to a dynamic website with reasonably good performance is huge IMO.
Re: Is ReactJS really fast?
#155Earlier 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.
Re: Is ReactJS really fast?
#156Point 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?
#157Earlier 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…
Obviously there are other libs / frameworks that can do that, all of them using some sort of shadow DOM.
Re: Is ReactJS really fast?
#158Earlier 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.
Re: Is ReactJS really fast?
#159Earlier 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…
Re: Is ReactJS really fast?
#160Earlier 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…