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

First Impressions Using React Native

jlongster.com

Post reply on HN
Print view View original

121–130 of 195 posts

Re: First Impressions Using React Native

#121

Post by gnrlbzik »

nwienert wrote: post #79
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…

Me me! I'll be exploring this soon and I'm sure I'll reach out for help before I get too far. Could do a lot of stuff off thread, from data to layout calcs. My profile should have some info related to the hybrid stuff.

oh nice, thanks for mentioning this.

Re: First Impressions Using React Native

#122

Post by serve_yay »

jenius wrote: post #120
serve_yay wrote: post #118

Earlier quoted context omitted.

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.

You're really just complaining about the phrasing of it and saying that it should have been worded in a mealy-mouthed way. That's silly, it's just an expression of an opinion.

Re: First Impressions Using React Native

#123

Post by jlongster »

larsberg wrote: post #116
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.

That's amazing. I hadn't even though about Servo in light of all of this.

In current browsers, JavaScript runs in the same thread as the UI, right? In Servo, how do you do interaction with the DOM like `clientHeight`? It just pauses the entire JS engine while it goes and talks to the UI thread?

Maybe we should be thinking of all of this in terms that map well to Servo's current architecture.

EDIT: What's really exciting about Servo is that hopefully the architecture's parallelism is really sound, even if certain properties of the current web restrain it. Then we can work on ways to remove those properties, and in Servo it's a simple switch to turn on more and more parallelism.

Re: First Impressions Using React Native

#124

Post by jordanlev »

danabramov wrote: post #68
jordanlev wrote: post #52

Earlier quoted context omitted.

I can't seem to find it now, but I remember seeing something a few months back about support for some HTML tag being added to react. I could be wrong about that, though (which would be great). I guess my question is this: can React/JSX render any kind of well-formed arbitrary markup? Like if next week there is a html tag I want to use, will it work? Or would react have to be updated to "support it" somehow?

>I remember seeing something a few months back about support for some HTML tag being added to react. It's just due to React https://github.com/facebook/react/pull/2830 There's still an attribute whitelist, and that's a trickier problem to solve: https://github.com/facebook/react/issues/140

Ah, that makes sense. Thanks!

Re: First Impressions Using React Native

#125

Post by jordwalke »

larsberg wrote: post #116
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.

I'm also interested in Servo as well. With React Native, we had the liberty to restrict certain paradigms that don't map well to building a parallelizable pipeline of operations. So the JS thread can't synchronously query for layout, which happens in the next stage, and the layout stage can't synchronously block on reading main thread (UIKit etc) values.

By restricting what the programmer can do, it naturally formed a pipeline where layout can be performed in the second stage while JS is determining the next UI update and so on. I'm not sure the extent to which this benefits us right now, but even mobile devices are beginning to have four cores so it seems like a nice property to maintain as long as it doesn't cause problems.

Servo sounds cool, and I'm curious how it takes advantage of a similar architecture but while the programmer has free reign to "clog the pipeline" by synchronous queries on layout etc. I'm sure they've thought of it, I'd just like to hear what they came up with.

Re: First Impressions Using React Native

#127

Post by mhd »

eliperkins wrote: post #102
mhd wrote: post #99

So if this is native widgets etc., the main point is being able to write this in JavaScript, right? Anything in it for those who don't consider this inherently beneficial? Souns a lot like GWT, s/Enterprise "architects"/Web "ninja"/ to me.

It's not about "Write once, run everywhere" but rather about "Learn once, write everywhere". React-Native encourages better design patterns for UI, especially on iOS. This blog post summed it up perfectly for me: https://joshaber.github.io/2015/01/30/why-react-native-matte...

I don't get the "better design pattern" from that. And even worse, adding yet another piece on top of the stack (a "better language" transpiling to JS) instead of just doing "react" in the native environment?

Re: First Impressions Using React Native

#128

Post by peterhunt »

jordwalke wrote: post #115
malandrew wrote: post #93

Earlier quoted context omitted.

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

Blowing out texture memory accidentally was also a big deal when I was measuring this stuff.

Re: First Impressions Using React Native

#129

Post by peterhunt »

azakai wrote: post #111
nwienert wrote: post #98

Earlier quoted context omitted.

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.

If you're interested in doing it with React, here's a video explaining how to do a custom backend: https://www.youtube.com/watch?v=eNC0mRYGWgc

You basically need to change BackendIDOperations and ReactEventListener to send/receive messages vs talking to the real APIs. It's already set up in the codebase to do this (because it actually worked at one time).

Webpack, per usual, already thought of this and has an answer for you :) https://github.com/webpack/worker-loader

Re: First Impressions Using React Native

#130

Post by jordwalke »

jlongster wrote: post #106
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?

Sweet. I'll watch out for wherever you guys end up. Might be worth reading one of the react native devs about why animations might still be hard: http://jlongster.com/First-Impressions-using-React-Native#co... This idea is also why I hooked up the css-layout project ( https://github.com/facebook/css-layout ) to a live demo to play around with: http://layout.jlongster.com/

Yes, in browsers, JS animations are still hard (I might even say impossible to do well for large apps with a lot going on). One anecdote: I spent a month trying to build a 60fps scrolling list view in JS from scratch (JS driving all the animations). No matter how hard I tried, I couldn't make it work on the web. I believe it was image decoding interfering but it's difficult to say why. Then I took that same example, which by that point was optimized, and ported it to React Native in a few hours(where we have off-thread image decoding and timers I can trust) and the example was like butter.

Now of course, I had hand optimized the performance, but my point is that on the web, there was nothing I could do, and with React Native, there was something I could do to make animations smooth. This is not to say you should be doing animations in JS, but if you want highly customizable interactions that can be immediately stopped by a touch processed in JS, you should try it out and see how it feels. For things that are "fire and forget", or platform specific, you should try using CoreAnimation/keyframes etc which protects the animation from your business logic.

Post reply on HN