Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React Implementation Notes

facebook.github.io

Post reply on HN
Print view View original

61–70 of 93 posts

Re: React Implementation Notes

#61

Post by inimino »

bostonvaulter2 wrote: post #30
hathawsh wrote: post #20

Earlier quoted context omitted.

I understand your dilemma very well. I have experience building server-rendered web apps, web apps enhanced with jQuery, Angular apps, and React apps. I resisted React for a while, but I'm glad I finally tried it out. Compared with jQuery or purely server-rendered apps, React elevates what you can accomplish within a short time frame. A complex web form with async validation, client side calculations, and multiple br…

The virtual dom is an implementation detail, it doesn't make sense to sing its praises here.

React only needs a render method, not a render method and an update method for every state transition. Without the virtual dom this would destroy performance, so it is a rather key detail in understanding React's appeal.

Re: React Implementation Notes

#62

Post by danabramov »

guscost wrote: post #24
ggregoire wrote: post #10

Bravo to the React team for the work during the last few months! It's truly amazing, specially for the new users. Among other things: 1) Create-React-App[1]: Lets everyone starts a React app with Babel/Webpack (JSX, classes and import/export) without any knowledge about Babel/Webpack. 2) The new Contributing docs (Codebase Overview, Implementation Notes (discussed here) and Design Principles) offer a starting point t…

> 4) "You might not need Redux"[3] For some older projects I found a hand-built flux helper[0] of ~220 lines worked great and didn't require any toolchain modifications. The switching costs to some of the ES6 stuff was too high in that case, but it's also a potentially leaner app if you don't need the advanced features of Redux and ES6. The Redux architecture is so nice though. [0] https://github.com/guscost/simple-f…

Redux is about 100 lines if you remove some development warnings. ;-)

Re: React Implementation Notes

#63

Post by danabramov »

ZenoArrow wrote: post #52
bostonvaulter2 wrote: post #30

Earlier quoted context omitted.

The virtual dom is an implementation detail, it doesn't make sense to sing its praises here.

The Virtual DOM is a central part of how React works, so it does make sense to mention it when appraising React.

FWIW we are trying to avoid "virtual DOM" in the new docs. The thing you create in render() and that describes the tree has been called "a React element" for many versions by now. "Virtual DOM" was more of a marketing term and I find it misleading because it doesn't make sense with e.g. React Native, and also makes React seem like a performance trick. React is not a performance trick. That elements get compared by React DOM renderer is its implementation detail. React is abstraction for dividing UI into predictable pieces, not a performance optimization.

Re: React Implementation Notes

#64

Post by amelius »

jpolitz wrote: post #11

Part of these notes, Fiber [0], reminds me of a half-joking "corollary" to Greenspun's Tenth Rule (credit @shriramkmurthi): Any sufficiently complicated JavaScript program contains an ad hoc, informally-specified, bug-ridden, slow implementation of delimited continuations. Control over continuations and the stack is our main compiler and runtime engineering hurdle in Pyret. Projects like Doppio [1], WeScheme [2] and…

Interesting. Do you also address scheduling? I.e., giving some computations priority over others? And do you address the implicit transfer of those priorities based on a dependency graph?

Re: React Implementation Notes

#65

Post by verletx64 »

ggregoire wrote: post #25
garrincha wrote: post #17

Earlier quoted context omitted.

Thanks a lot. This was already very helpful. I'm still somewhat scarred from the time I invested a ton of time into Angular. Not sure you would be able to answer this, but is React something that works well with Rails out of the box? For instance, I found that Angular (when I was learning it) required a fair bit of shoehorning to get it to work well with rails.

Angular and React are like black and white when we talk about time of learning. Simply because : - Angular is a full framework including html templating, directives, components, controllers, services, router, xhr abstractions ($http and $resource), dependency injection, two-way data binding by default, one-way data binding if you want (to fix performance issues) and the list can continue. Plus, you need to set and le…

This is pretty misleading as a comparison, yes you can learn React itself very shortly, but the ecosystem around it will probably bring you much closer to Angular learning times, and that's also without the AngularJS documentation which is top notch.

I prefer React to AngularJS but I don't think it's fair to tell half the story when comparing them.

Re: React Implementation Notes

#66

Post by kwood »

garrincha wrote: post #17
andreasklinger wrote: post #16

Earlier quoted context omitted.

the obvious case: consider a complex submission form with updating state eg you want to show uploaded images while editing parts of it etc the realistic case: if you have a rails app and do frontend "interactive stuff" you end up w/ some js frontend framework - let's say backbone - or even if it's just jquery send as ejs - you will have some sort of dynamic updates, maybe even frontend duplication of templates, you w…

Thanks a lot. This was already very helpful. I'm still somewhat scarred from the time I invested a ton of time into Angular. Not sure you would be able to answer this, but is React something that works well with Rails out of the box? For instance, I found that Angular (when I was learning it) required a fair bit of shoehorning to get it to work well with rails.

I was in quite the same situation, Angular 1.x was quite hard to grok at first. But React just "clicked" instantly.

For integration with Rails, I found https://github.com/reactjs/react-rails to be quite useful. It integrates the Babel transformer for JSX into the asset pipeline and brings a couple of helper functions, so no additional setup needed.

You start writing your components, "mount" them via the helpers in standard .erb templates (or even without the template directly from a controller action), done.

Re: React Implementation Notes

#67

Post by talldan »

cel1ne wrote: post #57
guscost wrote: post #24

Earlier quoted context omitted.

> 4) "You might not need Redux"[3] For some older projects I found a hand-built flux helper[0] of ~220 lines worked great and didn't require any toolchain modifications. The switching costs to some of the ES6 stuff was too high in that case, but it's also a potentially leaner app if you don't need the advanced features of Redux and ES6. The Redux architecture is so nice though. [0] https://github.com/guscost/simple-f…

I think redux got 50% right and 50% wrong. 1. good: having a sideeffect-free, serializable application state. That concept can also be used in mobile apps for easy pause/resume. 2. good: being able to render that state from one parent, because you don't need to manage two separate statemachines (the UI and the business logic) anymore. 3. bad: shoe-horning all state-transition into functions/reducers. Fp is awesome, b…

Unless something has changed very recently, you don't have to use Immutable.js and redux together. Redux advises against mutating your state, but doesn't prescribe a way to do that.

Re: React Implementation Notes

#68

Post by cel1ne »

talldan wrote: post #67
cel1ne wrote: post #57

Earlier quoted context omitted.

I think redux got 50% right and 50% wrong. 1. good: having a sideeffect-free, serializable application state. That concept can also be used in mobile apps for easy pause/resume. 2. good: being able to render that state from one parent, because you don't need to manage two separate statemachines (the UI and the business logic) anymore. 3. bad: shoe-horning all state-transition into functions/reducers. Fp is awesome, b…

Unless something has changed very recently, you don't have to use Immutable.js and redux together. Redux advises against mutating your state, but doesn't prescribe a way to do that.

True, I did applications with redux and without immutable too, even wrote my own syntax magic for that: https://www.npmjs.com/package/babel-plugin-check-data-access

What redux misses as well are derived/computed properties, I think mobX has them: https://mobxjs.github.io/mobx/

Re: React Implementation Notes

#69

Post by jpolitz »

amelius wrote: post #64
jpolitz wrote: post #11

Part of these notes, Fiber [0], reminds me of a half-joking "corollary" to Greenspun's Tenth Rule (credit @shriramkmurthi): Any sufficiently complicated JavaScript program contains an ad hoc, informally-specified, bug-ridden, slow implementation of delimited continuations. Control over continuations and the stack is our main compiler and runtime engineering hurdle in Pyret. Projects like Doppio [1], WeScheme [2] and…

Interesting. Do you also address scheduling? I.e., giving some computations priority over others? And do you address the implicit transfer of those priorities based on a dependency graph?

My conjecture: Scheduling with priority is pretty easy across these systems. The dependency graph transfer would be outside the scope of what they already tackle, and require new engineering.

In Pyret, I prototyped virtual threads at one point, and each thread had the same amount of "fuel" before yielding (at the top of every compiled function in Pyret, there's a decrement to a "fuel" counter, and when it reaches zero, the stack is unwound). That could easily be configured on each start/restart of a thread to provide different amounts of fuel, or to re-order the restarts based on typical thread-scheduling policies.

Whalesong does the same thing with fuel, so I imagine it could be extended similarly.

I don't know how Doppio and GopherJS do scheduling in detail, but here's where I'd start looking:

1. GopherJS looks like it's a simple queue based on the code around https://github.com/gopherjs/gopherjs/blob/master/compiler/pr... (goroutines push themselves onto a list when they pause, then the next one starts up again)

2. Doppio implements a thread pool abstraction, so you can simulate JVM threads in the browser: https://github.com/plasma-umass/doppio/blob/master/src/threa...

Re: React Implementation Notes

#70

Post by ZenoArrow »

danabramov wrote: post #63
ZenoArrow wrote: post #52

Earlier quoted context omitted.

The Virtual DOM is a central part of how React works, so it does make sense to mention it when appraising React.

FWIW we are trying to avoid "virtual DOM" in the new docs. The thing you create in render() and that describes the tree has been called "a React element" for many versions by now. "Virtual DOM" was more of a marketing term and I find it misleading because it doesn't make sense with e.g. React Native, and also makes React seem like a performance trick. React is not a performance trick. That elements get compared by Re…

> "React is abstraction for dividing UI into predictable pieces, not a performance optimization."

Why can't it be both?

Post reply on HN