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

71–80 of 195 posts

Re: First Impressions Using React Native

#71

Post by marcosdumay »

driverdan wrote: post #10
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…

> It is a terrible language As Douglass Crockford says, JS is a great language with some terrible parts. I don't understand why some people can't get past that.

Except that it's not.

Having many different parts by itself is enough to make a language bad. The fact that some of the most important of those parts are basic makes it terrible.

Re: First Impressions Using React Native

#72

Post by azakai »

aikah wrote: post #67
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…

Is playcanvas using emscriptem or is it written directly in js? nice project by the way. Also what does the worker do? does it have access to the canvas context or it just does some calculations and communicate with the main thread via serialized data.

Playcanvas is written directly in JS, but does use an emscripten-compiled physics engine (bullet/ammo).

Serialized data. Workers currently can't have access to canvas contexts.

Re: First Impressions Using React Native

#73

Post by jordwalke »

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…

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.

Re: First Impressions Using React Native

#74

Post by jlongster »

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 subset, and remove everything else, there main thread can focus on really smooth performance.

React Native even performs the flexbox layout on a 3rd thread, and tells the main thread where to absolutely position stuff.

Obviously we want to re-use as much of HTML as we can, but there might be some crazy ways to remove stuff from the main thread.

EDIT: It should be noted that Mercury, a React-inspired library (https://github.com/Raynos/mercury), has examples of running in a web worker. It is pretty cool, but I think it needs to be fleshed out more.

Re: First Impressions Using React Native

#75

Post by pjmlp »

jsprogrammer wrote: post #61
pjmlp wrote: post #56

Earlier quoted context omitted.

> I think this can either already, or very soon, be replicated on the web, a platform which holds tremendous advantages that native will likely never be able to catch up to. Looking at what HTML 5 offers and what any native platform from desktops to mobiles OS offers, I would rather stay with the disadvantages of native platforms. > while the real momentum is going the other way (native -> Web) Really? Is WebGL OpenG…

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

Re: First Impressions Using React Native

#76

Post by untog »

azakai wrote: post #70
untog wrote: post #63

Earlier quoted context omitted.

IIRC, Web Workers have a really limited subset of functionality available to them, which adds a whole load of gotchas to anything like this.

It is somewhat limited, but using message passing to the main thread, you can render a UI or even use WebGL or Web Audio or anything else. See the link for an example with WebGL.

Oh, I know. But it's rare that a webapp does things computational enough that it's worth the extra overhead - most lagginess is actually at the UI level, in my experience (and why virtual DOMs are so popular now).

I've seen Web Workers used in things like graphing libraries, though.

Re: First Impressions Using React Native

#77

Post by johnpmayer »

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…

Regarding moving script code off the main thread: I wrote a cooperative FRP engine that multiplexes signal graph update recalculation onto Web Workers. UI updates like virtual DOM would live on the main thread.

https://github.com/Johnpmayer/liquid-thorium

Re: First Impressions Using React Native

#78

Post by nwienert »

jordwalke wrote: post #73
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…

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.

Re: First Impressions Using React Native

#79

Post by nwienert »

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…

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.

Re: First Impressions Using React Native

#80

Post by swanify »

As someone who has developed many apps using Appcelerator Titanium, I am looking forward to getting my hands on this to see where the differences lie.

I know that it has taken Titanium years to mature, so I wonder if it will take a similar amount for React to iron out the bugs - I'll be surprised / pleased if they hit the ground running.

Hopefully they'll hurry up and make it public!

Post reply on HN