A Deep Dive on React Native [video](youtube.com)
youtube.com
A Deep Dive on React Native [video]
https://www.youtube.com/watch?v=7rDsRXj9-cU
71 comments
I'm very excited about this, but can someone please write something down? The videos are nice an all, but information-wise they're incredibly low-density. If I have an hour to spend on React Native, I'd rather read for 10 minutes and experiment for the remaining 50...
From watching the talk, it seems they have rushed a bit and are not in a good place to release code, docs, etc. The speaker implied that fundamental pieces are still changing rapidly. In all that rush, I doubt anybody has the hours necessary to write a nice blog post.
It's interesting that they are making a private repo available to attendees. I suppose they want to get some feedback and start some hype but also want to ensure a smooth initial public release.
Perhaps some community members with access to the private repo will blog their own impressions, if that's not discouraged?
It's interesting that they are making a private repo available to attendees. I suppose they want to get some feedback and start some hype but also want to ensure a smooth initial public release.
Perhaps some community members with access to the private repo will blog their own impressions, if that's not discouraged?
If you have to watch a video though, try increasing the playback speed (it's in the little settings gear on the YouTube player).
I normally listen for a few minutes at double speed, then drop down to 1.5 if necessary.
I normally listen for a few minutes at double speed, then drop down to 1.5 if necessary.
Did you try that with this video? I had enough trouble with the speaker rushing words in a thick accent at normal speed (not even meant as a criticism...just one of those things you come across at these conferences).
Sometimes speeding up just isn't a viable option. I'm glad I had the time to watch the whole video last night, but I too am looking forward to blog posts, documentation, and code releases. Way easier for me to digest quickly, and at my own pace.
Sometimes speeding up just isn't a viable option. I'm glad I had the time to watch the whole video last night, but I too am looking forward to blog posts, documentation, and code releases. Way easier for me to digest quickly, and at my own pace.
I actually don't find him that difficult to understand at 1.5x. But it's probably a matter of exposure -- as a German living in Europe I'm used to all kinds of European accents in English and common mispronunciations, whereas I'd probably barely be able to keep up if it was an Indian accent, for example.
I watched it at 1.5x and it's perfectly understandable, although it's probably because, like @pluma, I'm also a non native english speaker living in Europe.
Completely agree - speeding up only really works with certain accents and presenting styles.
Well, if you weren't watching the talk in person you're going to have to wait for them to release React native in earnest. Fortunately the talk is only 30 minutes so you've got another 30 minutes to do something else?
I'm curious about animations. That is one thing React hasn't really figured out on the web. I think the last experiment I saw was to do all the animations manually using component state. I wonder if this is the same on Native?
Ideally a cross pollination of ideas about animations would make both ecosystems better.
Ideally a cross pollination of ideas about animations would make both ecosystems better.
I've done a bit of work on React Native animations. We are mostly working on two experimental animation APIs.
One is implemented fully in JS and is used when we need to implement gestures and respond to ongoing touch interactions. This is tricky because we need to be very careful to keep our JS frames very short and fast during the gesture, avoiding expensive allocations and making sure we don't try to process too much data in Relay.
The other API is much more magical. You configure the animation for your component immediately before a setState. The new layout is computed normally, but instead of directly updating the native views, we use POP[1] to animate to them on the main thread. This is a really easy-to-use API, but there are a few caveats.
We're still developing, stabilizing, and cleaning up these tools. It's great to hear your interested in this, we'll try to open something up before too long!
[1] https://github.com/facebook/pop
One is implemented fully in JS and is used when we need to implement gestures and respond to ongoing touch interactions. This is tricky because we need to be very careful to keep our JS frames very short and fast during the gesture, avoiding expensive allocations and making sure we don't try to process too much data in Relay.
The other API is much more magical. You configure the animation for your component immediately before a setState. The new layout is computed normally, but instead of directly updating the native views, we use POP[1] to animate to them on the main thread. This is a really easy-to-use API, but there are a few caveats.
We're still developing, stabilizing, and cleaning up these tools. It's great to hear your interested in this, we'll try to open something up before too long!
[1] https://github.com/facebook/pop
yes, this is a good question. I still have to implement drag and drop in a react project, and it seems the way to go is do this all through state? Which means none of the existing drag and drop solutions will work (any DOM manipulation without react knowing about it will cause trouble), and since react is relatively new there is seems there is still a need for good reusable animation components/mixins, and in the mean time, it's all a bit more manual work.
> Which means none of the existing drag and drop solutions will work (any DOM manipulation without react knowing about it will cause trouble)
Um, we totally use jquery-ui's drag and drop in a React component in production and nothing bad happens.
Um, we totally use jquery-ui's drag and drop in a React component in production and nothing bad happens.
Ah, ok. Good to know. You just listen to the drop events and then update the state of react?
Yup, but it's not necessarily UI state that gets updated, just something that maps draggables to where they've been dropped.
yes, like updating the position in a sorted list you mean right. And did you also get it to work with touch events on mobile? I have an open question about that on SO http://stackoverflow.com/questions/27837500/drag-and-drop-wi...
Simply adding jquery-ui.touch-punch[0] monkey patched jquery-ui without us having to do anything else.
[0]: http://touchpunch.furf.com/
[0]: http://touchpunch.furf.com/
On over/drop you update your state and the view updates as appropriate yeah. Presumably some css transitions could make it pretty, I just went with straight updates as in my case it was only for personal use.
React Native is a cool project, but the deafening hype is slightly puzzling.
Creating and calling native UI components from JavaScript is nothing special in itself. It's obviously possible to do it from JS just as well as from any other language -- you just need to provide the API. There you have two choices: either a bridge that translates the native API directly, or a wrapper class hierarchy.
Examples of bridges include Xamarin's Mono that lets you build iOS user interfaces in C# code, and RubyMotion that lets you build Mac UIs in Ruby. Because these are bridges, the entire Cocoa API is exposed. The downside is that the bridge does nothing to smooth over platform differences: you can write in C# on all platforms, but you still have to learn Cocoa.
A prominent example of a wrapper API is Titanium Appcelerator that lets you build cross-platform mobile apps. Another good example is GTK+ for desktop apps: it's smart enough to leverage native Windows components where possible, but the GTK+ API is higher level than that of native Win32.
React Native is primarily in the latter category. Based on jordwalke's comment in another HN thread, they currently have cross-platform wrappers for View and Image:
https://news.ycombinator.com/item?id=8965044
But it appears you can also create platform-specific views, and for that they presumably have some kind of bridge. (It could also be that they provide manually written wrappers for platform-specific views, e.g. UIMapView becomes a <Map> and so on.)
In sum: React Native doesn't magically translate your JS+HTML app into a cross-platform native app. They're a long way off from having a full cross-platform API (unless your app is so simple that it can be described in terms of <View> and <Image>). And, like all wrapper APIs, there is a degree of impedance mismatch between the underlying platform implementation and the cross-platform interface on top.
There's a lot to like about React Native, though. The layout model and binding logic seems cool. The React team's accomplishments in the browser environment are impressive. With time, React Native could become for mobile what Qt is on the desktop -- and that's high praise in my books.
Creating and calling native UI components from JavaScript is nothing special in itself. It's obviously possible to do it from JS just as well as from any other language -- you just need to provide the API. There you have two choices: either a bridge that translates the native API directly, or a wrapper class hierarchy.
Examples of bridges include Xamarin's Mono that lets you build iOS user interfaces in C# code, and RubyMotion that lets you build Mac UIs in Ruby. Because these are bridges, the entire Cocoa API is exposed. The downside is that the bridge does nothing to smooth over platform differences: you can write in C# on all platforms, but you still have to learn Cocoa.
A prominent example of a wrapper API is Titanium Appcelerator that lets you build cross-platform mobile apps. Another good example is GTK+ for desktop apps: it's smart enough to leverage native Windows components where possible, but the GTK+ API is higher level than that of native Win32.
React Native is primarily in the latter category. Based on jordwalke's comment in another HN thread, they currently have cross-platform wrappers for View and Image:
https://news.ycombinator.com/item?id=8965044
But it appears you can also create platform-specific views, and for that they presumably have some kind of bridge. (It could also be that they provide manually written wrappers for platform-specific views, e.g. UIMapView becomes a <Map> and so on.)
In sum: React Native doesn't magically translate your JS+HTML app into a cross-platform native app. They're a long way off from having a full cross-platform API (unless your app is so simple that it can be described in terms of <View> and <Image>). And, like all wrapper APIs, there is a degree of impedance mismatch between the underlying platform implementation and the cross-platform interface on top.
There's a lot to like about React Native, though. The layout model and binding logic seems cool. The React team's accomplishments in the browser environment are impressive. With time, React Native could become for mobile what Qt is on the desktop -- and that's high praise in my books.
I think the hype is partly because many people (myself included) really like, even love React (and Flux). So being able to use it for native apps is great news for us.
Exactly this. I don't care about cross platform development. But I'd love to be able to develop UI's on Android using a similar paradigm I can do on the web with React. The main downside for me is that it's JS, not Java.
My day-to-day is very heavily skewed to app development rather than web development, but in my off-time I've been messing with React/flux. I have no issues with writing the objective-c, but the unidirectional style of React has been a real joy to work with and I've been thinking "How can I best imitate that while working natively?"
This could be the answer to that, and I wouldn't need to hack my own idioms together.
This could be the answer to that, and I wouldn't need to hack my own idioms together.
> but the deafening hype is slightly puzzling.
> With time, React Native could become for mobile what Qt is on the desktop -- and that's high praise in my books.
Sounds like maybe you're not so puzzled after all?
I'm not sure what you're hearing is hype. I think it's just excitement. Nobody is declaring this as The One True Way just yet, but a lot of people (you and I included, it seems) are cautiously optimistic that it could make mobile development a lot better.
> With time, React Native could become for mobile what Qt is on the desktop -- and that's high praise in my books.
Sounds like maybe you're not so puzzled after all?
I'm not sure what you're hearing is hype. I think it's just excitement. Nobody is declaring this as The One True Way just yet, but a lot of people (you and I included, it seems) are cautiously optimistic that it could make mobile development a lot better.
The excitement I've witnessed has been more of the "One True Way", "completely unprecented", "cross-platform mobile solved for good" type.
People are talking about how they'll use React Native for new apps without any regard for whether it makes sense in the particular case or not. So I tried to calm down those expectations a bit.
People are talking about how they'll use React Native for new apps without any regard for whether it makes sense in the particular case or not. So I tried to calm down those expectations a bit.
Really? i find that odd considering they said it's not a cross platform tool really, you will still have to write platform specific apps. Just have a mostly one way to do it.
React is not necessarily novel, but the combination of techniques might be: React addresses so many issues/smells that were so common and unaddressed by other frameworks that its getting a lot of well deserved mindshare.
React Native doesn't presume to know how to build cross-platform apps. But we want to enable people to do that.
That results in two different classes of Native components:
- Cross-platform components that are nearly identical on each platform- Eg. <View>, <Text>, <Image>, <TextInput>, <ListView>. There will not be many more of these
- Platform-specific components- When there is not an identical API and feature-set, we provide bridged components which can take full advantage of the platform. There will be a lot of these, but we currently only have a handful.
The real power comes from React's component-driven declarative programming style. The asynchronous batched bridge is well designed, but it's nothing special.
That results in two different classes of Native components:
- Cross-platform components that are nearly identical on each platform- Eg. <View>, <Text>, <Image>, <TextInput>, <ListView>. There will not be many more of these
- Platform-specific components- When there is not an identical API and feature-set, we provide bridged components which can take full advantage of the platform. There will be a lot of these, but we currently only have a handful.
The real power comes from React's component-driven declarative programming style. The asynchronous batched bridge is well designed, but it's nothing special.
Keep in mind that this is NOT (primarily) about cross platform application development. As the developers say, "Learn once, write anywhere".
It's about building native applications in the React style (declarative, componentised), with very rapid turnaround because much of your logic and layout is defined in JavaScript. Instead of recompiling your app's native code all the time, you're just reloading JavaScript within it.
It's possible that some components could be shared between platforms, but ultimately I think most of them will be different, reflecting the UI structure of the target environment. There's probably more scope for sharing higher level non-UI-element components.
It's about building native applications in the React style (declarative, componentised), with very rapid turnaround because much of your logic and layout is defined in JavaScript. Instead of recompiling your app's native code all the time, you're just reloading JavaScript within it.
It's possible that some components could be shared between platforms, but ultimately I think most of them will be different, reflecting the UI structure of the target environment. There's probably more scope for sharing higher level non-UI-element components.
All of this looks great and I'll give it a try as soon as I get some spare time, but there are a couple of things I didn't understand.
1) Is this cross platform or are you still going to have separate code bases for the UIs of iOS and Android? Looking at the code in the demo there are components like View, Text and Image. As basic as they are, are they the same on iOS and Android (same behaviour, same arguments)? It was pretty clear from the first minutes of the video that View is build on top of the native view of iOS (he showed the objC code). Is that React code building for Android?
2) I guess that one must still be proficient in iOS and Android, unless they make the monumental job of rewriting all the iOS and Android documentation for the React components they implemented. I expect to have to reference the native docs to understand the meaning of the arguments and do the job of mapping React to native. That has always been a pain point in many UI abstraction layers.
1) Is this cross platform or are you still going to have separate code bases for the UIs of iOS and Android? Looking at the code in the demo there are components like View, Text and Image. As basic as they are, are they the same on iOS and Android (same behaviour, same arguments)? It was pretty clear from the first minutes of the video that View is build on top of the native view of iOS (he showed the objC code). Is that React code building for Android?
2) I guess that one must still be proficient in iOS and Android, unless they make the monumental job of rewriting all the iOS and Android documentation for the React components they implemented. I expect to have to reference the native docs to understand the meaning of the arguments and do the job of mapping React to native. That has always been a pain point in many UI abstraction layers.
View, Text and Image should be cross-platform, and might even be targeted for web at some point. And more components could be. But they emphasised that you should be able to _choose_ how much code you want to re-use cross-platform, and that you should always put energy in targeting and perfecting for specific platforms
About 1) They specified yesterday the goal is not "write once, run everywhere" but "learn once, write everywhere". They are also working on the Android version. Of course I guess a cross platform framework built on top of that would be possible.
This looks really nice. One question that I've found conflicting information about - is JavaScriptCore JITed on iOS 8? I know it isn't on iOS 7 and earlier, my understanding was that it was on iOS 8 but it's hard to find a definitive answer. Anyone know?
The new webkit view (WKWebView) is JITed. I'm not sure about using JavaScriptCore independently of it though.
JavaScriptCore isn't JITed, even on iOS 8.
Pretty sure I heard them say exactly that it was at WWDC. I wrote it down in my notes anyway. ~04:30 in the WWDC video "Introducing the Modern WebKIT API"
It was stated it used 4th tier LLVM JIT (FTL) [0]. Do you have evidence to the contrary? What did you do to test? If you can outline what you did I will be happy to help out and investigate.
[0]: https://www.webkit.org/blog/3362/introducing-the-webkit-ftl-...
It was stated it used 4th tier LLVM JIT (FTL) [0]. Do you have evidence to the contrary? What did you do to test? If you can outline what you did I will be happy to help out and investigate.
[0]: https://www.webkit.org/blog/3362/introducing-the-webkit-ftl-...
Sorry, you probably misunderstood me – WKWebView runs in a separate process and does have a JIT (discussed in that video); JavaScriptCore runs in the same process and does not.
The 5-minute demo at the end (22:24) is incredibly impressive: http://youtu.be/7rDsRXj9-cU?t=22m24s
That just seems SO much easier, quicker, and more efficient than storyboarding and coding UIViews. I am very much looking forward to being able to play around with this and discover downsides, because there have to be some...right?
That just seems SO much easier, quicker, and more efficient than storyboarding and coding UIViews. I am very much looking forward to being able to play around with this and discover downsides, because there have to be some...right?
I see that they're using display:flex for layout, for all elements, which makes things like inline styles impossible or extremely inconvenient.
http://jsfiddle.net/u8wd8kdL/5/
If I am wrong, please provide me an example of how to layout that text with display:flex.
http://jsfiddle.net/u8wd8kdL/5/
If I am wrong, please provide me an example of how to layout that text with display:flex.
I think it's worthwhile to note that they aren't using CSS, they're using a CSS-like syntax as a constraint solver. This means they're able to define new properties or reinterpret things to suit the native platforms they're building for.
I'm definitely interested in seeing what React, and React Native, can do, but I have to say these people cheering like Ofrah just gave them a free car are kind of turning me off.
"This is a native component". "WOOOOOOOOH!!!" "YEAH!!" <high fives>
"This is a native component". "WOOOOOOOOH!!!" "YEAH!!" <high fives>
It's a speech. People cheer during speeches. Also, it's pretty mind blowing that they're actually calling native components from JS if you ask me.
It is rendered native (described in js) not in a webview. Otherwise they should call it web components.
They picked a great timing for the announcement because I needed to use native components with a React app, similar to how Ejecta (http://impactjs.com/ejecta) reimplemented the WebGL API to run js apps without DOM/WebView) but had settled with Cordova plugins because it would have taken probably too long to implement otherwise, so I have high hopes for React Native :)
Since I already know ObjC & Swift, the most interesting part of this is at 8:17. "What if we could server-side run native apps? ...we could do it".
Hmmmm.
An interesting idea, however Apple might have something to say about that (App Store Review Guidelines):
2.7 Apps that download code in any way or form will be rejected
2.8 Apps that install or launch other executable code will be rejected
Still...I like the idea of pushing the boundaries of native iOS development.
Hmmmm.
An interesting idea, however Apple might have something to say about that (App Store Review Guidelines):
2.7 Apps that download code in any way or form will be rejected
2.8 Apps that install or launch other executable code will be rejected
Still...I like the idea of pushing the boundaries of native iOS development.
JavaScriptCore executes javascript embedded in the app, it's not like a webview that would download an arbitrary webpage/script, so it wouldn't conflict with the guidelines
Yeah thats how the Groups app works now, but I was referring to his forward thinking "server-side run native apps". Thats way different.
[deleted]
They just need to send the UI "state" (and after that just the state diff would do it). I think it's actually much like HTML for a browser.
The executable code limitation is likely geared toward security. For all other purposes, it's just data.
Well yeah, both are for security. But if you had a native "app server", that just fed JS to a shell of an app that had ReactNative in it....you could completely change the app, remotely. Not just styling too, but actual functionality. Its the promise of "real" native A/B testing, but clearly violates app store review guidelines.
We submitted an app a while back (mid 2012 I think) that ran a dynamically interpreted language developed in-house. The objective-c codebase was fairly small, nearly the entire app was written in this language stored in external files. Right before submission we decided not to risk being rejected for the reasons cited, and instead baked-in the scripting files, but clearly kept open possibility of remote load for future submissions. We got accepted without issue, but that app ended up being decommissioned and we haven't revisited the approach. Sometimes I wonder if Apple would have let our original submission through if we remote loaded the code instead.
Has anyone who's seen the actual code comment?
From what I understood on the video, this is going to be distributed via a repo that is essentially already an iOS or Android template?
There wasn't much talk about the compilation process. Maybe the details (for the open source version) haven't been ironed out?
From what I understood on the video, this is going to be distributed via a repo that is essentially already an iOS or Android template?
There wasn't much talk about the compilation process. Maybe the details (for the open source version) haven't been ironed out?
I've been down on "cross platform native apps" because they're always the lowest common denominator of the language and platform, but this looks intriguing.
The next logical step here is that this gets wrapped by an Om-like and then we are writing native apps in clojure! That is pretty exciting to me.
The one thing that's prevented me from using flex-box is browser support.
Because flex-box has been re-implemented in JS, does this mean that the css-layout project [1] will provide flex-box support for older browsers?
I looked, but I couldn't find a "compatibility" section anywhere in the repo.
[1] https://github.com/facebook/css-layout
Because flex-box has been re-implemented in JS, does this mean that the css-layout project [1] will provide flex-box support for older browsers?
I looked, but I couldn't find a "compatibility" section anywhere in the repo.
[1] https://github.com/facebook/css-layout
From what I can tell, it can support older browsers, since the CSS output is very primitive.
My current issue is how to measure text sizes: https://github.com/facebook/css-layout/blob/master/src/__tes...
My current issue is how to measure text sizes: https://github.com/facebook/css-layout/blob/master/src/__tes...
He mentioned in the video how what they've implemented is a subset of css. Sounds like 'CSS the good parts' and may be renderable on older browsers.
https://www.infinum.co/the-capsized-eight/articles/running-j...
This article have lot of details about how JS is getting executed on the Native platform. Lot of components are provided by Apple like JS VM
This article have lot of details about how JS is getting executed on the Native platform. Lot of components are provided by Apple like JS VM
I get that people are excited, but it seems like time and time again these abstractions fail to solve the underlying problems.
It's like how we never got a fix for making cross platform applications. And regardless how much people wants the new way of doing things to work, the results speak for themselves. Atom, the editor, can't even handle window re-sizing smoothly.
It's like how we never got a fix for making cross platform applications. And regardless how much people wants the new way of doing things to work, the results speak for themselves. Atom, the editor, can't even handle window re-sizing smoothly.
Did you watch the video? They're taking a genuinely new approach here. It's not "lowest common denominator" like Xamarin, Qt, etc, and it's also not a WebView like Atom or Ionic (Cordova).
It's actual native components, with the intent that you "learn once, write everywhere" rather than try to jam iOS and Android into the same codebase.
It's actual native components, with the intent that you "learn once, write everywhere" rather than try to jam iOS and Android into the same codebase.
To be fair, Xamarin isn't "lowest common denominator" either.
It's all native and even with xplat Xamarin.Forms you can customize code for each platform.
It's all native and even with xplat Xamarin.Forms you can customize code for each platform.
[deleted]
Seems like the time has come for the synergy of native + JavaScript. React.js are not the only ones working on it... Tabris.js works on a similar principle (combine the best of native and web) and offers features like instant debugging of JavaScript on your device. It's currently invite only.
I'm not sure I got how the Javascript code executing? For the case of Android, is the library spinning up a WebView to get access to the V8 engine?
Doubtful, they can just include a compiled JavaScript runtime.
I thought JavaScript was interpreted? Seriously, are there Linux JavaScript compilers existing - which don't depend on Node or any other JIT-compiler, and which can be integrated in Android projects?
I meant compile an open source java script interpreter and bundle it, not compile the javascript.
I'm guessing it would package up Rhino and use that on Android.
i'm not using react for the web so maybe this is a silly question, but how do you pass data from your obj-c controllers ( or any native object) to those reactjs views ?
Also, the constraint solver could be a good riddance but is there going to be any support for uikit dynamics ?
Also, the constraint solver could be a good riddance but is there going to be any support for uikit dynamics ?
This looks really exciting. The fast code edit to relanch time is a really big deal to me.