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

31–40 of 93 posts

Re: React Implementation Notes

#31

Post by bostonvaulter2 »

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…

But the downside to learning react is learning the react ecosystem, redux, other flux frameworks, etc.

Re: React Implementation Notes

#32

Post by john_gaucho »

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…

Thanks for asking this question. I'm also a Rails dev, pretty much in the same situation. Some people are mentioning that if you want to do some server side rendering then things can get a bit more hairy.

Well I don't want my backend app to be just an API and the frontend to be a client. I'm not trying to argue whether or not that is the correct way to build web apps, but I don't want to do all the rendering on the frontend. The reason is that I think this would make smaller projects a good deal more complex. Maybe you can convince me I'm wrong. Again, I can imagine that if you are a big company this might be the way to go. But for building small to medium web apps I think Rails (and the Rails way of building apps) works well. What I'm trying to figure out is if I can incorporate React into my toolbelt and have it work well with standard rails apps.

Apologies for my grammar.

Re: React Implementation Notes

#33

Post by qudat »

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…

It really depends on what kind of apps you are building. If it's a complicated CRUD application that can be created without much heavy lifting javascript, then you'll probably be fine with vanilla js. However, once you start getting to the build where your front end application code gets larger and more complex, something like React will scale very well.

Re: React Implementation Notes

#34

Post by tmzt »

sim0n wrote: post #22
garrincha wrote: post #21

Earlier quoted context omitted.

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).

I've spent some time looking at the 'needs a JS runtime' part and am prototyping an isometric framework in rust which renders with natively compiled code on the server and generated JS on the client, both generated from the same source template and logic. The JS can also be cached and served statically.

The server-rendered page is then instanced in the browser and differential rendering can be performed. I have been interested in doing this concept using React but have decided to prototype with a simpler implementation called Incremental DOM.

My project is at github.com/tmzt/incrust.

Re: React Implementation Notes

#35

Post by redonkulus »

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…

This is basically everything that Dan Abramov has contributed. Good work by him!

Re: React Implementation Notes

#36

Post by jpolitz »

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.

The main difference is that all of the use cases I mentioned necessarily don't distinguish between calls/functions that may pause, and calls that don't (it's just the semantics of those languages that arbitrary calls might need to pause). So to use generators as a compilation target, every function has to be a generator, and every call a generator instantiation followed by yield*.

I actually don't know if that qualifies as "staggering". Your sibling comment has some truth; I can only speak generally about Gopherjs and Doppio, because I know them less intimately, but I know that Pyret and Whalesong were definitely started before generators had widespread adoption. Compiling to generators, rather than to the handwritten stack unwinding we have, is on my list of things to try and measure.

Maybe "significant" overhead would be more obviously true than "staggering," since I don't have clear numbers to back it up.

Does that make sense?

Re: React Implementation Notes

#37

Post by mrcactu5 »

this is really excellent

I am part of a meet-up of theorists who do build websites... but are also curious how frameworks like React work under the hood. What algorithms they use, frameworks, etc.

It's possible to build a nice web-site without knowing any code at all. Or knowing some code and algorirthms. In that case the code may become very difficult to control, or revise or share with your peers.

If you know some algorithms and code it's sometimes helpful to see what is under the hood.

Re: React Implementation Notes

#38

Post by eyan »

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…

Offtopic but... I'm cheering for pyret! And for the group behind it of course. :)

Re: React Implementation Notes

#39

Post by supergreg »

tmzt wrote: post #34
sim0n wrote: post #22

Earlier quoted context omitted.

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).

I've spent some time looking at the 'needs a JS runtime' part and am prototyping an isometric framework in rust which renders with natively compiled code on the server and generated JS on the client, both generated from the same source template and logic. The JS can also be cached and served statically. The server-rendered page is then instanced in the browser and differential rendering can be performed. I have been…

Nice. I was always wondering why no one was trying to do isometric stuff in other languages since every language and their mother seem to have a compile-to-js feature.

Re: React Implementation Notes

#40

Post by dcwca »

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…

When you separate the web app from the server and build it as a stand-alone React codebase, you can create applications that run in the browser, iOS, Android (via Cordova / reapp) and cross-platform desktop operating systems (via Electron).

Now wait a minute, you're going to say, I can do all of that with my server-side web application. And faster too. Sure, but does your application work when the user is offline? Does it have access to the client runtime's local storage for data persistence? Can it access client hardware like the camera, GPS, and accelerometer? Can it be distributed through Google Play and the Apple App Store? Can it be installed as a desktop application?

Post reply on HN