Live data from Hacker News

React is mostly hype

en.arguman.org

101–110 of 138 posts

Re: React is mostly hype

#101

Earlier quoted context omitted.

Angular was a bad idea. In sooo many ways... -Two-way binding in all cases is slow -Directives are unecessarily hard to write -Angular's default DI model breaks on alpha conversion, the basis of every JS minifier ever. All the fixes are cumbersome. -The system is poorly documented, making it hard for a dev to get started. -The system is overly complex, slow, and hard to debug ($digest already in progress, anyone?). -…

Two way data bind is fast because a graph of binds and dependency is created. So you can have atomic updates while in virtual dom you must rerun all the tree. See vue.js and ractive But is also true that 2way double binding take more memory that virtual dom.

Two-way binding CAN be fast, however, due to various issues, Angular's only option was Dirty Checking, which is sloooow.

And no, a depgraph doesn't make it fast. What can make it fast is firing less events, using better triggers, and basically handling it exactly the way that Angular didn't.

VDOM can help, but really not much. However you want to put it, two-way binding is costly, and it should be avoided whenever possible, or minimized by catching multiple bind events at a higher up element on the tree (see http://lhorie.github.io/mithril-blog/asymmetrical-data-bindi...)

Just spraying it everywhere, the way Angular encourages, with no optimization (like the aforementioned asymetrical bindings), should be considered an antipattern.

Re: React is mostly hype

#102

Earlier quoted context omitted.

Mithril is also apparently really good at fast. But I've merely seen the benches.

Mithril for what i know is under a rewrite and with this rewrite should be really fast

I never heard that, but it seems pretty fast now. If Leo shows up, hopefully he'll tell us.

Re: React is mostly hype

#103

Earlier quoted context omitted.

Angular was a bad idea. In sooo many ways... -Two-way binding in all cases is slow -Directives are unecessarily hard to write -Angular's default DI model breaks on alpha conversion, the basis of every JS minifier ever. All the fixes are cumbersome. -The system is poorly documented, making it hard for a dev to get started. -The system is overly complex, slow, and hard to debug ($digest already in progress, anyone?). -…

Two way data bind is fast because a graph of binds and dependency is created. So you can have atomic updates while in virtual dom you must rerun all the tree. See vue.js and ractive But is also true that 2way double binding take more memory that virtual dom.

Not sure what you mean "rerun all the tree", if you change a a state variable that is added as a prop in another component it has to rerun refresh on those components, but only those components, so not all the tree. Also not sure how this relates to atomic updates, with a flux pattern each state change is associated with ui changes propogating down, the difference to angular is, they aren't supposed to be allowed to propogate up, which you can do in angular since there isn't necessarily a central state store and since there is two way binding children or parent can change the variable.

It's easy enough to write two way binding into a react state variable, it's just nice to not have it happen by default since having state able to change anywhere in the app can get confusing.

Re: React is mostly hype

#104
post #59
post #47

Earlier quoted context omitted.

Well, React has one huge disadvantage: It requires you not suing FB, even if they abuse some of your own patents. That patent license they have in their project basically means you can only use React as dev in a company if your company does not have patents or noteworthy IP.

The important point is, you don't lose FB's license grant if you counter sue them. You lose the grant only if you initiate a lawsuit. Here is the relevant section from the PATENTS file: if Facebook or any of its subsidiaries or corporate affiliates files a lawsuit alleging patent infringement against you in the first instance, and you respond by filing a patent infringement counterclaim in that lawsuit against that p…

I guess it's possible to replace react with preactjs.com with a little amount of effort.. In cases where the legal aspect prevents you from suing FB..

Re: React is mostly hype

#105
post #74

Earlier quoted context omitted.

Willy-nilly DOM and state modification wasn't a requirement with jQuery, it was just how a lot of people chose to (not) structure their applications.

It wasn't a requirement but it was encouraged. jQuery was all about selecting a node or node list and then applying manipulations to it.

To "encourage" means to openly advocate.

Never ever have I seen active encouragement of poor programming discipline. You are correct in that's what jQuery was about, but it had no opinion on how to go about that task.

Re: React is mostly hype

#106
post #74

Earlier quoted context omitted.

It wasn't a requirement but it was encouraged. jQuery was all about selecting a node or node list and then applying manipulations to it.

To "encourage" means to openly advocate. Never ever have I seen active encouragement of poor programming discipline. You are correct in that's what jQuery was about, but it had no opinion on how to go about that task.

It might not have a explicit opinion stated anywhere but in any library or framework, the API provided influences how those APIs are used.

By having the central unit of work start with a query selector is one such influence which I feel implicitly encouraged DOM manipulations.

Taking a look at the original jQuery website on web.archive, this is the introduction to the $() function:

"The functionality of jQuery centers around one central function: $(). Everything in jQuery is based upon this, or uses this in some way. The most basic use of this function is to pass in an expression (usually consisting of CSS or XPath), which then finds all matching elements and remembers them for later use. For example:"

And then goes to show a DOM selection followed by a chained mutation.

Re: React is mostly hype

#107

I see some point-missing arguments being made here. React isn't for scale. And it isn't to side step learning about html and css. It's main reason for existence is to make complex UIs easy to manage. Pretty much the only argument I can think of against React is that it's a boil-the-ocean system. Once you start doing your UI with it, you pretty much need to make the entire thing use react to really benefit from its mo…

"Once you start doing your UI with it, you pretty much need to make the entire thing use react to really benefit from its model." In my experience React is quite ideal for cases where some parts of a site or an app need dynamic behavior. I'm currently working on an e-commerce platform's admin panel, and for us a complete rewrite would have been nearly impossible. With React we can keep the old HTML + jQuery codebase,…

Right - it does work and we have incrementally introduced react as well.

But that works if the various existing components on the page don't have strong multi-directional data flows between them. At least that's what I've experienced.

Re: React is mostly hype

#108

Earlier quoted context omitted.

Two way data bind is fast because a graph of binds and dependency is created. So you can have atomic updates while in virtual dom you must rerun all the tree. See vue.js and ractive But is also true that 2way double binding take more memory that virtual dom.

Two-way binding CAN be fast, however, due to various issues, Angular's only option was Dirty Checking, which is sloooow. And no, a depgraph doesn't make it fast. What can make it fast is firing less events, using better triggers, and basically handling it exactly the way that Angular didn't. VDOM can help, but really not much. However you want to put it, two-way binding is costly, and it should be avoided whenever po…

Angular 2way is based on dirty check. Ractive and vue.js are really data binding with atomic changes.

Re: React is mostly hype

#109

Earlier quoted context omitted.

Two way data bind is fast because a graph of binds and dependency is created. So you can have atomic updates while in virtual dom you must rerun all the tree. See vue.js and ractive But is also true that 2way double binding take more memory that virtual dom.

Not sure what you mean "rerun all the tree", if you change a a state variable that is added as a prop in another component it has to rerun refresh on those components, but only those components, so not all the tree. Also not sure how this relates to atomic updates, with a flux pattern each state change is associated with ui changes propogating down, the difference to angular is, they aren't supposed to be allowed to…

Yes but generally speak you must do all this things manually and also optimizatio s and binding you must know what updates. In a real 2way db this is automatic also for performance.

Re: React is mostly hype

#110

Earlier quoted context omitted.

Two way data bind is fast because a graph of binds and dependency is created. So you can have atomic updates while in virtual dom you must rerun all the tree. See vue.js and ractive But is also true that 2way double binding take more memory that virtual dom.

Two-way binding CAN be fast, however, due to various issues, Angular's only option was Dirty Checking, which is sloooow. And no, a depgraph doesn't make it fast. What can make it fast is firing less events, using better triggers, and basically handling it exactly the way that Angular didn't. VDOM can help, but really not much. However you want to put it, two-way binding is costly, and it should be avoided whenever po…

Data binding is also about computates function where you know the dependencies of this and know when recalculate it
Post reply on HN