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

91–100 of 195 posts

Re: First Impressions Using React Native

#91

Post by azakai »

jlongster wrote: post #84
nwienert wrote: post #79

Earlier quoted context omitted.

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.

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?

Re: First Impressions Using React Native

#92

Post by pothibo »

spicyj wrote: post #88
pothibo wrote: post #69

I'm assuming React Native can load external JS files over the network? If that's the case, then I understand why Facebook is building this. They could have control of their application and behavior and make even more changes than before without re-submitting to the App Store.

There's no technical reason it couldn't work, but we have no plans to load code over the network.

I would have thought it would bring new A/B testing possibilities that would have been otherwise impossible. Oh well, thanks.

Re: First Impressions Using React Native

#93

Post by malandrew »

jlongster wrote: post #74
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…

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

- triggering reflow

- marshalling data across interfaces (serialization/deserialization of native types into strings and back again).

That last one is an absolute killer when it comes to applying 3D matrix transforms. Basically, you're taking an array of floats, serializing them into a string to do an element.style property assignment, so that the browser can then take that stringified representation and convert it back into an array of floats that it can apply. Huge perf hit here.

Re: First Impressions Using React Native

#94

Post by jsprogrammer »

pjmlp wrote: post #75
jsprogrammer wrote: post #61

Earlier quoted context omitted.

There will likely always be uses for the native platforms, especially on the desktop/power machines. I don't think React Native is targeting any of what you're talking about though. What the web has going for it (and what native will never catch up to) is having solved the distribution problem. Fact is, I can deploy to more machines, faster, and more securely than native (at least if there remain fragmented vendors)…

> What the web has going for it (and what native will never catch up to) is having solved the distribution problem. apt-get, yum, app stores, click once, web start, ...

Right: fragmented, environment dependent, user learning curve, etc.

Web: URL + links

Re: First Impressions Using React Native

#95

Post by akrymski »

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've been thinking about this as well yesterday, but to be honest I'm not sure where the benefits are. In theory the browser is doing the rendering in a separate thread anyway, i.e. CSS layout and things like scrolling are handled by the browser. If you're doing a long algorithmic (CPU-intensive) computation in JS then you should probably do that in a WebWorker anyway. Otherwise I'm not sure the overhead is worth it, for example the dragging / touch events should be invoking such a tiny amount of javascript that you shouldn't see much benefit in moving that logic to a separate thread.

Would be interested to see real examples of where this is makes sense.

Disclosure: we're developing an email client using Cordova and purely web tech using our own framework: https://github.com/techlayer/espresso.js

Re: First Impressions Using React Native

#96

Post by Ronsenshi »

danabramov wrote: post #2

Declarative UI is boss. I know Andy (former UIKit team) was quoted in the intro thread but I'll do it again: >I say with confidence as a former UIKit author: React's model for the UI layer is vastly better than UIKit's. React Native is a huge deal. https://twitter.com/andy_matuschak/status/560511204867575808 If you're averse to React because of JSX, “mixing templates and views” and similar superficial “best practices…

I've been against mixing logic and views for the longest time and I still wouldn't mind if separation would have been introduced, but recently I gave up.

Either I'll be unnecessary stubborn and miss this awesome new tech or I'll shovel my opinion aside and do try working with this approach.... or at least until someone else introduces new framework that comes with code separation.

It's not the end of the world.

Re: First Impressions Using React Native

#97

Post by Yahivin »

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…

You can now transfer typed array data using the newest postMessage API. http://updates.html5rocks.com/2011/12/Transferable-Objects-L...

Re: First Impressions Using React Native

#98

Post by nwienert »

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?

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-there-a-way-t...

Edit: webpack + webwoker: https://github.com/webpack/webpack/tree/master/examples/web-...

Re: First Impressions Using React Native

#99

Post by mhd »

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.

Re: First Impressions Using React Native

#100

Post by nwienert »

akrymski wrote: post #95
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've been thinking about this as well yesterday, but to be honest I'm not sure where the benefits are. In theory the browser is doing the rendering in a separate thread anyway, i.e. CSS layout and things like scrolling are handled by the browser. If you're doing a long algorithmic (CPU-intensive) computation in JS then you should probably do that in a WebWorker anyway. Otherwise I'm not sure the overhead is worth it,…

Exactly. I think moving everything but React into the web worker is enough. But that itself isn't easy as far as my limited knowledge, you need to have separate script files. Perhaps a webpack plugin that manages that for you?
Post reply on HN