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

131–140 of 195 posts

Re: First Impressions Using React Native

#131

Post by eliperkins »

mhd wrote: post #127
eliperkins wrote: post #102

Earlier quoted context omitted.

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?

Doing "react" in the native environment is hard, you have to fight UIKit really hard to get to a good place.

[ReactiveCocoaLayout](https://github.com/ReactiveCocoa/ReactiveCocoaLayout) is a good example of how much work it takes to get close to this pattern, but the view lifecycle as a whole (adding and removing subviews, layout passes, etc.) makes it hard.

From what I understand React-Native does this for you natively under-the-hood, but using JS as an implementation detail.

I really don't think that anyone is advocating for JS being the "better language", but rather one that has a framework (read: React.js) being used in practice which will work with native view as well.

Re: First Impressions Using React Native

#132

Post by pchristensen »

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…

Pedestal Client from Cognitect did this - see https://github.com/pedestal/app-tutorial/wiki/Parallel-Proce... and my notes at http://pchristensen.com/blog/articles/pedestal-tutorial-part... (under "Parallel Processing").

Too bad they stopped working on it.

Re: First Impressions Using React Native

#133

Post by abalone »

Probably the most useful way to get a read on this is to compare it to Titanium, also a JS-to-native framework that runs JS on a separate thread. The biggest problems with Titanium were not performance. A couple of the most common complaints:

1) You don't have full access to native SDK functionality (e.g. all the latest cool things in iOS8). You're going through a cross-platform API wrapper and limited to the choices of the framework architect. So it can be frustrating to go down this path only to find you still can't quite get the native experience you want.

2) Debugging is harder because the native toolchain (e.g. Xcode) doesn't understand the framework. You have to rely on tools provided by the framework.

AFAICS the author doesn't address these issues. He seems to focus largely on the (theoretical?) performance optimization of not crossing the JS-to-native bridge as much in React... by being even more isolated from the native APIs and doing more work in JS. But even if true, performance was not the chief complaint with the closest predecessor to this.

Re: First Impressions Using React Native

#134

Post by eitland »

serve_yay wrote: post #122
jenius wrote: post #120

Earlier quoted context omitted.

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.

> You're really just complaining about the phrasing of it

So far correct.

> and saying that it should have been worded in a mealy-mouthed way. That's silly, it's just an expression of an opinion.

Don't act like something is decided when it's not. Don't say something is 0.0 mm when you measure using using a ruler. Basics in politeness and engineering, isn't it?

Some might find it really annoying to discuss with people who use very strong statements after so short time.

Re: First Impressions Using React Native

#135

Post by jenius »

serve_yay wrote: post #122
jenius wrote: post #120

Earlier quoted context omitted.

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.

This is absurd. Are you serious? The way you express your opinions is enormously important. It could easily be the difference between getting a raise and getting fired. Expressing your opinions in a way makes sense to other people and they take well to is the farthest thing from silly ever, it's like a #1 essential skill for life. On top of that, phrasing informs the message, and in this case I was not just complaining about the phrasing, I was also complaining about the outrageous statement being made.

For example, saying "React is the best way to build all apps no matter what" vs. saying "Compared to building native UIs with objective C, react-native made for a much smoother experience for me because of X Y and Z" are not only phrased differently, they are communicating different things. The first one is an absurd overarching dogma declaring every other app-building technology to be inferior to react with no backing whatsoever, and the second one is a useful and specific analysis of react in one situation compared to an alternative.

I can't figure out if you're trolling or not, honestly.

Re: First Impressions Using React Native

#136

Post by jlongster »

jordwalke wrote: post #125
larsberg wrote: post #116

Earlier quoted context omitted.

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

I just asked pcwalton in #servo on mozilla and he said they want to introduce async versions of all of the DOM APIs like getBoundingClientRectAsync()

Re: First Impressions Using React Native

#137

Post by jordwalke »

jlongster wrote: post #136
jordwalke wrote: post #125

Earlier quoted context omitted.

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…

I just asked pcwalton in #servo on mozilla and he said they want to introduce async versions of all of the DOM APIs like getBoundingClientRectAsync()

Awesome. That's exactly what we have on React Native :D We want to make sure that when possible, we choose APIs compatible with the future of the web.

Re: First Impressions Using React Native

#138

Post by pcwalton »

jlongster wrote: post #123
larsberg wrote: post #116

Earlier quoted context omitted.

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

> 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?

Yes, but we'd like to experiment with new APIs in the future like `getBoundingClientRectAsync()` that will allow pages to do that kind of thing asynchronously.

Re: First Impressions Using React Native

#139

Post by aboodman »

xanadohnt wrote: post #104
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…

MS have been doing declarative UIs for literally 8 years (XAML).

That isn't declarative in the same way... that's markup. The kind of declarative that is used in React is more like functional programs. You write programs, using actual code, that compute ("declare") exactly what the UI should look like from top to bottom, given each possible input.

This is in contrast to a model where you mutate an existing UI model each time something interesting happens.

Re: First Impressions Using React Native

#140

Post by Touche »

jordwalke wrote: post #112
nwienert wrote: post #78

Earlier quoted context omitted.

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

As for events, have the worker send which events it is interested in rather than the reverse as you suggest.
Post reply on HN