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

21–30 of 93 posts

Re: React Implementation Notes

#21

Post by garrincha »

sim0n wrote: post #15
garrincha wrote: post #14

I'm a Rails developer. I work on pretty standard web apps for a living. Some more complicated than others, but still, web apps. I still haven't found a person that was able to give me a concrete reason why someone like me should invest time and resources into learning React and using it in my projects. This is an honest question, I'm not trying to be sarcastic. It's just that there are so many frameworks that come ou…

For me, once I started declaring my UI as a series of components that simply render what they are provided (the common `v = f(d)` expression), it was hard to go back to the Backbone/jQuery way of mutating things all over the place and manually updating DOM nodes to try and reflect the current app state.

Out of curiosity, what do you usually use on the backend?

Re: React Implementation Notes

#22

Post by sim0n »

garrincha wrote: post #21
sim0n wrote: post #15

Earlier quoted context omitted.

For me, once I started declaring my UI as a series of components that simply render what they are provided (the common `v = f(d)` expression), it was hard to go back to the Backbone/jQuery way of mutating things all over the place and manually updating DOM nodes to try and reflect the current app state.

Out of curiosity, what do you usually use on the backend?

The backend where I work (Airbnb) runs on Rails but most of my projects use node on the backend since they usually just expose a REST API.

Since it only cares about UI, React is obviously not opinionated about your backend/server environment unless you're trying to do server rendering (then you need something in your stack capable of executing JS).

Re: React Implementation Notes

#23

Post by rukuu001 »

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.

React in its basic form is pretty simple, you'll grok it in a couple sessions of playing with it. And since it's 100% view, you can fit it over pretty much anything.

This is assuming you're prepared to do rendering in the browser. If you want to do server side rendering I think you'll be doing more shoehornig :)

Re: React Implementation Notes

#24

Post by guscost »

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-flux

Re: React Implementation Notes

#25

Post by ggregoire »

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.

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 learn a style guide [1] and some good practices because, if you have 2 developers, none of them will code in Angular in the same way.

=> it took me weeks to learn, and months to master.

- React is just a library to build views. You code 90% of your time in basic JS and 10% in React APIs (basically: states, props, lifecycle methods and that's it).

=> it took me 1 hour to learn, and 1 week to master.

If you want to learn React, you just need to read the official tutorial [2].

---

[1] https://github.com/johnpapa/angular-styleguide

[2] https://facebook.github.io/react/docs/tutorial.html

Re: React Implementation Notes

#26

Post by ilostmykeys »

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…

What about generators? I've built coroutines based on generators. CSP has been implemented in JS using generators. Not sure why those projects went thru "staggering amount of overhead" to get what we get for free with generators. Please educate.

Re: React Implementation Notes

#27

Post by 1propionyl »

ilostmykeys wrote: post #26
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…

What about generators? I've built coroutines based on generators. CSP has been implemented in JS using generators. Not sure why those projects went thru "staggering amount of overhead" to get what we get for free with generators. Please educate.

Because generators may be implemented with delineated continuations but they are not themselves the same thing.

Re: React Implementation Notes

#28

Post by matt4077 »

garrincha wrote: post #14

I'm a Rails developer. I work on pretty standard web apps for a living. Some more complicated than others, but still, web apps. I still haven't found a person that was able to give me a concrete reason why someone like me should invest time and resources into learning React and using it in my projects. This is an honest question, I'm not trying to be sarcastic. It's just that there are so many frameworks that come ou…

There are some impressive numbers (from google I think) about conversion/retention/bounce rates in relation to page load times. I believe it was about a 50% reduction for every extra second.

Page loads are mostly download (bandwidth-limited) and layout. For many actions, you can reduce drastically reduce data transfers if only the actual data that changes is transferred (no markup/images/content already loaded). Similarly, only a small part of the layout may change. That can result in anything from doesn't really matter (newspaper) to "this project wouldn't make any sense without it" (google docs).

Re: React Implementation Notes

#29

Post by ilostmykeys »

1propionyl wrote: post #27
ilostmykeys wrote: post #26

Earlier quoted context omitted.

What about generators? I've built coroutines based on generators. CSP has been implemented in JS using generators. Not sure why those projects went thru "staggering amount of overhead" to get what we get for free with generators. Please educate.

Because generators may be implemented with delineated continuations but they are not themselves the same thing.

Are you sure it's not because those frameworks/libraries were written before generators became available in the latest browsers?

:)

Re: React Implementation Notes

#30

Post by bostonvaulter2 »

hathawsh wrote: post #20
garrincha wrote: post #14

I'm a Rails developer. I work on pretty standard web apps for a living. Some more complicated than others, but still, web apps. I still haven't found a person that was able to give me a concrete reason why someone like me should invest time and resources into learning React and using it in my projects. This is an honest question, I'm not trying to be sarcastic. It's just that there are so many frameworks that come ou…

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.
Post reply on HN