Live data from Hacker News

React is mostly hype

en.arguman.org

111–120 of 138 posts

Re: React is mostly hype

#111

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…

A virtual dom is stupid about the view is only an algorithm that diff 2 trees. A data binding can create a graph of knowledge about the view and can create the best and fast mode for update the view. Library like ractive and vue are the best tools for create animations in svg or where there are many updates of view

Re: React is mostly hype

#112
post #106

Earlier quoted context omitted.

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

> [...] I feel implicitly encouraged DOM manipulations.

That's jQuery's primary job. It isn't DOM manipulation that causes code/architectural issues.

"All" (I'm simplifying) jQuery does is provide mechanisms to select and manipulate DOM. How to organize its usage is an exercise left to the reader, and most readers did it poorly.

It's not jQuery's fault that people wrote shitty code with it. And, in fairness, when Prototype/jQuery/etc. came out, sites were simpler. When people started doing more, if they didn't take control of how they were using jQ/etc., it blew up and made them hate their lives.

At the same time people were doing that, other people were using various organizing principles to tame their jQ/etc. soup, writing tests, and keeping a handle on the sprawl.

You can write shitty code in React, too. It imposes a certain set of conventions that make it harder to want to. Layer on Redux/etc. and it's even harder to want to. Layer on other various conventions and frameworks and you want to even less. But it doesn't stop you--just like jQ didn't stop you from using self-discipline before people smarter than me evolved client-side frameworks to where we are now.

While I wrote my share of jQ soup, I also worked on projects that were flexible, extensible, testable, and clean. The choice is always ours to make.

Re: React is mostly hype

#113

Earlier quoted context omitted.

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.

I know about this https://github.com/lhorie/mithril.js/issues/1090

Re: React is mostly hype

#114

Earlier quoted context omitted.

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…

A virtual dom is stupid about the view is only an algorithm that diff 2 trees. A data binding can create a graph of knowledge about the view and can create the best and fast mode for update the view. Library like ractive and vue are the best tools for create animations in svg or where there are many updates of view

...Which is why Mithril and React provide escape valves, for situations in which the VDOM abstraction is ill suited.

Re: React is mostly hype

#115

Earlier quoted context omitted.

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.

I said nothing about Ractive and Vue. Their 2 way binding is better, but with large quantities of bindings, it's still slow.

Re: React is mostly hype

#116

Earlier quoted context omitted.

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

Are you talking about Computed Values? Because Data Binding has nothing to do with that. Not really.

In any case, Computed values make 2 way binding more expensive, because you have to run a depgraph on all the vars that are part of the binding network, every time an event fires. This is O(n). This is only one reason why Computed Values, as implemented in JS, are a Bad Idea. If you have to update a var on event fire, okay, but leaving the things everywhere is slow and ungainly. If you instead change the var to a function call, you can optimize far better, because you only have to update when the value is read.

In conclusion, if you want to polymorphism between functions and variables, treat everything as a function, not as a variable.

At least, I think that's a response to your question. Your English is pretty broken, so it's hard to tell. Sorry.

Re: React is mostly hype

#117

Earlier quoted context omitted.

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.

No, the perf's pretty bad if you do a lot of binding, and the manual binding gives you a better sense of what your app is doing, the performance tradeoffs you're making, and more control over an area where you'll probably have to optimize.

Re: React is mostly hype

#118

Earlier quoted context omitted.

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

I know about this https://github.com/lhorie/mithril.js/issues/1090

That's only addressing perf on IE. It says nothing about perf overall.

Re: React is mostly hype

#119

Earlier quoted context omitted.

I know about this https://github.com/lhorie/mithril.js/issues/1090

That's only addressing perf on IE. It says nothing about perf overall.

Dom / component recycle and batch updates are about performance

Re: React is mostly hype

#120

Earlier quoted context omitted.

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.

No, the perf's pretty bad if you do a lot of binding, and the manual binding gives you a better sense of what your app is doing, the performance tradeoffs you're making, and more control over an area where you'll probably have to optimize.

Vue.js 2 is an hibrid between virtual dom and data binding.
Post reply on HN