First Impressions Using React Native • Hacker News Board

Re: First Impressions Using React Native

#111

Post by azakai » Fri, Feb 06, 2015, 7:50 PM UTC

nwienert wrote: post #98

azakai wrote: post #91

Earlier quoted context omitted.

Me too. I'd love to chat more about this with both of you, this seems like a direction definitely worth exploring. Maybe we could set up a github project for it? Or talk in an issue on your existing repo, nwienert?

I'd like to see a github repo. You can hit me up on twitter, info in my profile. I think even just finding the right library to make using webworkers + npm + webpack would be great to start, because honestly its all the other stuff that slows down the thread. React can run on the main thread for the most part. Some reading: https://news.ycombinator.com/item?id=6982485 http://stackoverflow.com/questions/18056922/is-th…

Cool, I set up a repo and started a wiki on it,

https://github.com/kripken/worker-ui/wiki

Not familiar with webpack, will take a look.

Re: First Impressions Using React Native

#112

Post by jordwalke » Fri, Feb 06, 2015, 7:51 PM UTC

nwienert wrote: post #78

jordwalke wrote: post #73

Earlier quoted context omitted.

We did a bunch of experiments with running React in a web worker. Maybe we should revive them. Because it's React, it ends up being easy and is basically the same setup (serialized events etc) as what React Native does.

Why wasn't this explored more before going full out with React Native? I feel like this would be smart to compare the two: web + webworkers vs native. There was a lot of hype about hybrid apps "sucking", but I bet it doesn't once you get off the thread.

Trust me, we tried. But as long as image decoding blocks the main thread (Webkit), you are helpless to update the UI thread at a fast pace. We even tried decoding images in a web worker and sending the result back to the main thread - but decoding in JS is very slow so general application throughput suffers (not through fault of JS itself, but because JS lacks SIMD which image decoding algorithms use in order to decode images quickly).

But running React in a web worker is still a really great idea. There would just be a lot of little edge cases to handle (like when you click a link - you need to prevent default of navigation, then send that link click to the web worker to see if your app wants to prevent default, if not, force the redirect back on the main thread). Having tight control over text editing might be challenging as well. These are difficulties, but I suspect they are a fixed set of challenges that are worth the increased parallelism in an increasingly multicore world.

But are web workers currently The Solution To All Our Mobile App Needs? No, but they're a great tool that are highly underutilized by JS developers, and that React is uniquely positioned to take advantage of.

Re: First Impressions Using React Native

#113

Post by jenius » Fri, Feb 06, 2015, 7:54 PM UTC

> "This is solid engineering. And it completely reinforces the fact that React.js is the right way to build apps."

This just comes off as really weird to me. Why would any sane developer make a statement like this? It sounds preachy and brainwash-y and weird. If there's anything we learn as developers it's that there never is and never will be a single "right way" to do everything. Reading stuff like this makes me doubt the entire article.

There's a difference between writing objectively about something that's interesting that you enjoyed, and trying to lay down a dogma. TBH, the more of this article I read, the more my view of it's goals swayed towards the latter.

Re: First Impressions Using React Native

#114

Post by spicyj » Fri, Feb 06, 2015, 7:57 PM UTC

azakai wrote: post #91

jlongster wrote: post #84

Earlier quoted context omitted.

Very cool! I'll keep an eye on your work!

Me too. I'd love to chat more about this with both of you, this seems like a direction definitely worth exploring. Maybe we could set up a github project for it? Or talk in an issue on your existing repo, nwienert?

Also worth looking at some ideas we have for doing cross-thread component hierarchies in React:

https://github.com/reactjs/react-future/tree/master/05%20-%2...

Re: First Impressions Using React Native

#115

Post by jordwalke » Fri, Feb 06, 2015, 8:00 PM UTC

malandrew wrote: post #93

jlongster wrote: post #74

Earlier quoted context omitted.

You are speaking my language! I would love to see a prototype of this. I've been thinking about it since I saw React Native. I wonder if there's even value in something like an asm.js-compiled layout system, which absolutely positions elements. One of the insights of React Native is that to build apps, we really only need a small subset of the web's layout algorithms. Only flexbox, really. So if we recognize this sub…

We explored this at a previous company I worked at. The conclusion at the time was that the message passing model was not yet efficient enough at the time because of serialization/deserialization which nullified any performance gains. Transferrable objects at the time were really new. If the support for shared memory has improved, it might now make sense. The biggest problems with performance are: - GC pauses - trigg…

I haven't found serialization to be anywhere near the bottleneck. How long does it take to serialize/deserialize a 16 element array? I could see how this would be an issue if you had hundreds of them per frame. But for most purposes an entire 16 element array is overkill and you could probably come up with a more compressed description of the transforms (scale, rotate, translate) and consider adding a pooling layer.

People attribute pauses to GC, when it's sometimes just the browser container environment acting up and there's nothing we can do about it - so it's easy to write it off as GC. Not sure about today, but 1.5 years ago (i = new Image(), i.src="http...") could block the JS thread for as much as 19ms. In a larger app, it's easy to write that off as GC, but (at least on iOS) the performance tooling is really lacking and it's tough to find the culprit.

Reflowing is a big deal, I agree.

Re: First Impressions Using React Native

#116

Post by larsberg » Fri, Feb 06, 2015, 8:07 PM UTC

azakai wrote: post #60

I think it's a very strong point that moving script code off the main thread can help achieve smooth UIs. No more GC pauses, no more slowdowns if the JS engine hits a snag, etc. I think this is actually possible on the web as well. Someone could write a UI framework which runs JS in a Worker, and sends messages to the main thread, on which there is HTML and minimal JS to receive the messages and handle them. I'm surp…

> I think it's a very strong point that moving script code off the main thread can help achieve smooth UIs.

What, you mean like we do in Servo? https://github.com/servo/servo :-)

Our main thread (if you can call it that) just does compositing and handles dispatching UI events. Script, layout, resource loading, and the rest run concurrently in background threads.

Re: First Impressions Using React Native

#117

Post by cwp » Fri, Feb 06, 2015, 8:09 PM UTC

saosebastiao wrote: post #3

I love the concepts behind React, and I agree this is a huge deal...I just wish it weren't javascript. It is a terrible language, and the languages that compile to javascript are a poor substitute (bloated code sizes, interop issues, poor runtime performance, etc). For a framework that is all about state machines (a good thing! All UIs are state machines), I hate that there aren't better ways to model them in the lan…

That shouldn't be a big problem.

Since the JS execution is isolated on a single thread and communicates with the main thread via a bridge, it should be possible to implement the rendering code, vDOM diffing, bridge etc in any language you want. That might take some effort, but I can't see any fundamental reasons why it wouldn't work.

Re: First Impressions Using React Native

#118

Post by serve_yay » Fri, Feb 06, 2015, 8:19 PM UTC

jenius wrote: post #113

> "This is solid engineering . And it completely reinforces the fact that React.js is the right way to build apps." This just comes off as really weird to me. Why would any sane developer make a statement like this? It sounds preachy and brainwash-y and weird. If there's anything we learn as developers it's that there never is and never will be a single "right way" to do everything. Reading stuff like this makes me d…

I like having opinions. People can disagree with them, of course, as has always been the case.

Re: First Impressions Using React Native

#119

Post by peterhunt » Fri, Feb 06, 2015, 8:24 PM UTC

Bahamut wrote: post #107

peterhunt wrote: post #49

Earlier quoted context omitted.

There is an API-compatible XMLHTTPRequest so all libs that have those deps (Backbone) work. There is also localStorage (not in this release though), but it's not 100% compatible because it has an async API.

Is the localStorage going to be something similar to IndexedDB (or localForage perhaps?)

When I was at FB it was just getItem() and setItem() with a callback. The Relay stuff announced at React.js Conf is closer to what you're talking about (they run a local GraphQL engine which reconciles with the remote one iirc)

Re: First Impressions Using React Native

#120

Post by jenius » Fri, Feb 06, 2015, 8:27 PM UTC

serve_yay wrote: post #118

jenius wrote: post #113

> "This is solid engineering . And it completely reinforces the fact that React.js is the right way to build apps." This just comes off as really weird to me. Why would any sane developer make a statement like this? It sounds preachy and brainwash-y and weird. If there's anything we learn as developers it's that there never is and never will be a single "right way" to do everything. Reading stuff like this makes me d…

I like having opinions. People can disagree with them, of course, as has always been the case.

Look up the definition of the word "opinion" on google or a dictionary. Then look up the word "dogma". Then re-read my comment. Fair? It's not the opinion I'm objected to, it's the way of stating it.