Live data from Hacker News

First Impressions Using React Native

jlongster.com

191–195 of 195 posts

Re: First Impressions Using React Native

#191
post #81

Earlier quoted context omitted.

React doesn't have a good pattern for passing information up the tree other than Flux. Prior to Flux they told everyone to pass functions through props which is fine up until a certain point but it doesn't scale to large apps. Flux does solve it, and is a generally good idea, but the singleton pattern breaks when applied to the server.

Ah, I see. I don't really agree, because I think the enforced unidirectional data flow is one of the best parts of React, but that's certainly a valid point of view. I just want to emphasize again that Flux is entirely possible without singletons, and works just as well on the server if you create new instances for every request. Flummox does it, Fluxible does it (at least for stores). It's just a shame Facebook push…

Honestly I think FB put the flux pattern out before that idea had become fully developed looking for feedback from the community. The flux repo explicitly states that none of the examples are used by facebook or even resemble facebook (client-side) code. The dispatcher, which was released months after they announced flux, is the only component in the flux they admit to using. Immediately after it's release (even before the dispatcher) we began writing client-side javascript code based on arbitrary examples meant to demonstrate a concept.

I also think flux's real-world implementation came from the necessity to build React components within pre-built apps, where they simply didn't have the ability to pass down props because they had to create complete separate components.

Re: First Impressions Using React Native

#192

The code style really reminds me of ExtJS circa 2.x (not sure what it's like now), which was pretty good at what it set out to do. However, React Native requires compiling down to various different platforms which means having to maintain multiple compatibility layers to continually shift to keep up with the native vendors. You're also pretty much stuck with proprietary distributors as well. Fun. Fun. This does look…

I agree with the "swimming the wrong way" sentiment, in my own very biased opinion. I'm working on reapp.io to solve just that. What's funny is react actually makes it possible to make hybrid a real option.

Very interesting looking! One thing though is that the back button looks a little wonky in the Kitchen Sink demo.

Re: First Impressions Using React Native

#193

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

Basically if you want to prevent reflowing you end up making everything a texture and that leads you to making many many CSS transform changes on every frame. 60fps is easy to hit on a modern desktop, but mobile performance requires more effort to achieve an effect that feels natural. The problem with the marshalling is that it is comparatively expensive and a blocking operation, which is not conducive to buttery smooth graphics performance on all platforms.

Re: First Impressions Using React Native

#194
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…

I am not a maintainer and I just tried it briefly so I am not 100% sure of the allegations they make on their front-page, but it seems like http://gridstylesheets.org are using Workers to run their layout algorithm (Cassowary Constraint Solver) and absolute-position elements (using 3D transforms).

EDIT: Searching for "Worker" right now didn't bring any mention, but it seems it is a very recent edit (cf https://github.com/gss/gss.github.io/commit/d6a931e3629d4b5d...).

Re: First Impressions Using React Native

#195

Earlier quoted context omitted.

I think you're not being specific enough. I am claiming they can perfectly be recreated in JS, just not within a mobile browser at the moment.

I do mean within a mobile browser. We have a pretty large app inside Cordova, and I've yet to get stuck where there's something I can't recreate. Would be interesting to see an example where a mobile browser falls short.

Right, but then you're susceptible to animation stutter and you have to reinvent the look-and-feel of the platform, which is extremely difficult.
Post reply on HN