React Native for Android(code.facebook.com)
code.facebook.com
React Native for Android
https://code.facebook.com/posts/1189117404435352/
246 comments
At last. Now I can dig in...
That could really be a game changer in mobile development.
Abstractions like these always target the least common denominator. But React has the "component" advantage so i'm not dismissing its usefulness. it's good for a category of projects.
Do you consider a facebook production app a least common denominator?
Do you really believe the facebook production app is built 100% with React Native ?
yeah
> Facebook Ads Manager is built entirely using React Native.
https://code.facebook.com/posts/1014532261909640/react-nativ...
> Facebook Ads Manager is built entirely using React Native.
https://code.facebook.com/posts/1014532261909640/react-nativ...
Ads Manager =/= Facebook app for "users"
I think I see where the confusion is, muzmath said 'a' facebook app (i.e. Ads Manager), not 'the' facebook app. Main FB app is definitely not using 100% react native.
That being said, Ads Manager users are still mostly just "users". I know a middle aged woman using it to manage ads for her side business for example, regular people are using 100% React Native apps daily.
That being said, Ads Manager users are still mostly just "users". I know a middle aged woman using it to manage ads for her side business for example, regular people are using 100% React Native apps daily.
Your right, when I say a facebook app, I literally mean an application, developed by facebook.
Did you read the article before downvoting me?
Let me spell this out for you...
A Facebook app, is an app made by facebook, which obviously i'm referencing the one that they are talking about in the article your commenting on. And yes, it was made using React Native. Any more questions before you read the article?
Let me spell this out for you...
A Facebook app, is an app made by facebook, which obviously i'm referencing the one that they are talking about in the article your commenting on. And yes, it was made using React Native. Any more questions before you read the article?
I totally understand why you'd feel like this, but I think there are two big reasons why this is only true to a lesser extent with RN:
1) There are a ton of native APIs that accomplish exactly the same things, but have different APIs because different people built them and there's no pressure to make them consistent. Examples: layouting (just calculate x, y, width, height's of a view tree), animation, storage, networking, touch handling, the list goes on... it's a waste to have to learn the implementation specific quirks of each platform.
2) We've focused on making sure we can make apps at least as good as the native ones for the platform. Specifically this has meant exposing platform specific apis (e.g. Android's material touch ripple, iOS's gaussian blurs, etc), allowing arbitrary new ones to be added, and encouraging designers to still design their apps for each platform individually.
1) There are a ton of native APIs that accomplish exactly the same things, but have different APIs because different people built them and there's no pressure to make them consistent. Examples: layouting (just calculate x, y, width, height's of a view tree), animation, storage, networking, touch handling, the list goes on... it's a waste to have to learn the implementation specific quirks of each platform.
2) We've focused on making sure we can make apps at least as good as the native ones for the platform. Specifically this has meant exposing platform specific apis (e.g. Android's material touch ripple, iOS's gaussian blurs, etc), allowing arbitrary new ones to be added, and encouraging designers to still design their apps for each platform individually.
When porting a React Native app to android 85% of the iOS version was reused:
"At the time of shipping Ads Manager for Android, that approach yielded around 85 percent reuse of app code."
"At the time of shipping Ads Manager for Android, that approach yielded around 85 percent reuse of app code."
Yeah, the promise is not "write once, run everywhere". It's 1) write in a familiar way and 2) reuse a substantial amount.
Which is unlike using Ionic Framework, where I've gotten about 98% code reuse between platforms.
The only place that I usually end up making platform-specific changes is where Ionic has an iOS-specific layout change that breaks the look of a custom component on iOS. That and sometimes native-only features like Push Notifications that need to be handled slightly differently on each platform. But the latter is about a half dozen lines of stock code that take the iOS result and hand it to a common handler.
I'm probably sticking with Ionic for now, though I'm planning to try out Meteor for my next project that has backend requirements. Meteor can install the Ionic SCSS as a plug-in, so you CAN get the best of both worlds.
The only place that I usually end up making platform-specific changes is where Ionic has an iOS-specific layout change that breaks the look of a custom component on iOS. That and sometimes native-only features like Push Notifications that need to be handled slightly differently on each platform. But the latter is about a half dozen lines of stock code that take the iOS result and hand it to a common handler.
I'm probably sticking with Ionic for now, though I'm planning to try out Meteor for my next project that has backend requirements. Meteor can install the Ionic SCSS as a plug-in, so you CAN get the best of both worlds.
If you want the exact same app on both platforms, you can do that on React Native too. The Facebook apps don't do that because we believe it gives a worse user experience.
[deleted]
Ionic does not give you the exact same app on both platforms.
There are dozens of platform-specific styles in the CSS that make each target behave more like a native app. A custom-styled native app, but one that follows platform conventions.
I also absolutely abhor the fact that React mixes HTML with JavaScript. It just feels so completely wrong to me.
There are dozens of platform-specific styles in the CSS that make each target behave more like a native app. A custom-styled native app, but one that follows platform conventions.
I also absolutely abhor the fact that React mixes HTML with JavaScript. It just feels so completely wrong to me.
I have had performance issues using Ionic myself, and I have been intensely dissatisfied with Cordova & its ecosystem. In addition, I have had some pain with Ionic when trying to implement special behavior, mainly due to how the internals work.
React Native is much more a step in the right direction IMO, although the Ionic team's work on Ionic 2 with Angular 2 could provide an interesting paradigm to compete on that front.
React Native is much more a step in the right direction IMO, although the Ionic team's work on Ionic 2 with Angular 2 could provide an interesting paradigm to compete on that front.
I haven't had performance issues with Ionic; Angular certainly has known issues with too-many-listeners, though Ionic offers a workaround for the most serious case (long list views).
> Which is unlike using Ionic Framework, where I've gotten about 98% code reuse between platforms.
Ionic is using HTML widgets , not actual IOS or Android widgets like React Native , Titanium or others. So you are basically developping an HTML client inside a webview and calling it an APP. Of course you'll be able to reuse 98% of the code that ran into a web browser. But it will look like an HTML website.
Ionic is using HTML widgets , not actual IOS or Android widgets like React Native , Titanium or others. So you are basically developping an HTML client inside a webview and calling it an APP. Of course you'll be able to reuse 98% of the code that ran into a web browser. But it will look like an HTML website.
> But it will look like an HTML website.
This is simply not true anymore. For simple CRUD apps, our customers can't tell the difference between a native app and an Ionic app. The ionic team has done a great job simulating the native animations and interactions of iOS and Android.
If you don't believe it just try it. It costs 30 secs to install Ionic via npm and deploy one of the demo apps to an Android or iOS device.
For more complex apps I'd consider using a native framework tho. As usual it all depends on the use case.
This is simply not true anymore. For simple CRUD apps, our customers can't tell the difference between a native app and an Ionic app. The ionic team has done a great job simulating the native animations and interactions of iOS and Android.
If you don't believe it just try it. It costs 30 secs to install Ionic via npm and deploy one of the demo apps to an Android or iOS device.
For more complex apps I'd consider using a native framework tho. As usual it all depends on the use case.
Started out building our apps in Ionic, but switched to React Native as soon as it was released. The Ionic app just didn't feel native. Not even close.
React Native has been absolutely amazing so far. So excited for Android!
React Native has been absolutely amazing so far. So excited for Android!
Ionic has started to feel native only recently, but I agree that React Native for iOS (and now Android) sounds like a superior alternative. I'm very tempted to try it in my next project.
One realization I had when designing the API of React Native is that if you want to be able to share any component you need to have the lower level primitives to be shared. So I went on making them: View, Text and Image. I also realized that the same layout engine was required so implemented a shared layout which ended up being flexbox.
What amazed me the most during this journey is that most platforms have actually very similar low level building blocks but unfortunately slightly incompatible in many ways.
The 85% number is mind blowing, it turns out that those few building blocks are actually a large part of what it takes to build a high quality mobile app.
What amazed me the most during this journey is that most platforms have actually very similar low level building blocks but unfortunately slightly incompatible in many ways.
The 85% number is mind blowing, it turns out that those few building blocks are actually a large part of what it takes to build a high quality mobile app.
> What amazed me the most during this journey is that most platforms have actually very similar low level building blocks but unfortunately slightly incompatible in many ways.
I've been looking at porting a React application to React Native, and was somewhat concerned about this myself. I have several custom components that make up the UI, which might not have a 1:1 translation between HTML/CSS to native components or may behave slightly differently across platforms. A different route I've considered is using Crosswalk as a shell around the application and exposing Android/iOS APIs through JavaScript with Crosswalk extensions. It may not feel perfectly native but it would be more consistent across platforms.
I'm a novice in this area, so I'm curious if anyone else has looked into the different approaches and the conclusions they've drawn.
I've been looking at porting a React application to React Native, and was somewhat concerned about this myself. I have several custom components that make up the UI, which might not have a 1:1 translation between HTML/CSS to native components or may behave slightly differently across platforms. A different route I've considered is using Crosswalk as a shell around the application and exposing Android/iOS APIs through JavaScript with Crosswalk extensions. It may not feel perfectly native but it would be more consistent across platforms.
I'm a novice in this area, so I'm curious if anyone else has looked into the different approaches and the conclusions they've drawn.
Why are there only iOS screenshots in an Android blog post? I want to see the results of creating an Android app.
EDIT: screenshots were added :)
EDIT: screenshots were added :)
There's a video with the Android app in the section Shipping an Android version.
We've updated the post with a comparison of screenshots, sorry about that!
Thanks!
Not to nitpic, but could you edit it to put the screenshots of the same thing next to each other? So I can see side by side what the iOS version of a screen looks like next to the Android version of a screen?
The general feeling on HN is that it is better to focus on Native development on both platforms because Cordova hybrid apps have a overall bad user experience. Is this still the case with React Native or is it becoming the most effective option?
React Native apps compile into native apps. That is, no Cordova.
My understanding is not that. They don't "compile into" anything. They're run as JavaScript on the phone. The difference is react native calls into native components -- it isn't a universal write once run anywhere. You'll have to craft different JavaScript for android versus iOS. Hopefully most of your code is business logic or other things than UI components.
Well yes, the JavaScript is not converted into Objective C, it is bundled into the app bundle that you submit to the App Store. I guess it depends on whether you consider the ultimate bundling of the application to be compiling.
Anyway, the point is that it doesn't run in a WebView. The JavaScript is executed by JavaScriptCore.
Anyway, the point is that it doesn't run in a WebView. The JavaScript is executed by JavaScriptCore.
The issue is the developer. React-Native as a tool allows you to make poor design decisions, but it does nothing wrong itself. We need to be vigilant and remember to stick to native interactions.
could you elaborate on what poor decisions rn allows you to make over native ios/android?
With Native ios/android, you get a selection of UI components to use. If your designs don't fit any of those components, you either have to build something from scratch or alter to the design to fit the Native UI language. Usually the prospect of 'building from scratch' is enough to deter people from building components that don't fit the device's interface. So you generally end up with apps that all fit the native design language.
With React-Native, it's really easy to be lazy. If you want to be on Android, but you don't want to change your designs to fit Android's UI standards, screw it, just write a wrapper around some of the iOS components and call it a day.
With React-Native, it's really easy to be lazy. If you want to be on Android, but you don't want to change your designs to fit Android's UI standards, screw it, just write a wrapper around some of the iOS components and call it a day.
so rn makes it easy to create components that may not fit in the platform's UI standards?
Yes. But it also makes it easy to create components that do fit the platform, thus "the issue is the developer."
An app built with React Native is indistinguishable from a "real" native app, unlike cordova apps it doesn't run in the browser (or in a webview).
That's not categorically true.
For example, I believe that both the navigator components for React Native in iOS currently suffer from either bugs or performance issues. The more native one has an open issue related to UI flicker, and the JavaScript-based one drops frames when subviews are complex.
That statement might not be true tomorrow or next week, because the ecosystem is developing quickly. Generally I am very happy with React Native.
For example, I believe that both the navigator components for React Native in iOS currently suffer from either bugs or performance issues. The more native one has an open issue related to UI flicker, and the JavaScript-based one drops frames when subviews are complex.
That statement might not be true tomorrow or next week, because the ecosystem is developing quickly. Generally I am very happy with React Native.
Yup, being indistinguishable from native has been the absolute priority for the project. We think we managed to do it for the apps we built but we took shortcuts in the process. The two open source versions of navigator definitely don't meet that promise and it is driving me crazy. We're working on solutions for those but it takes time :)
I believe Cordova apps being associated with a "bad user experience" is related to the amount of effort developers put into their Cordova app. I've seen some terrible Cordova apps. I've also seen a couple good ones. I've been developing a Cordova app using Ember.js and it works well in Cordova. There are a couple places in my app that need to be better optimized for Android, but overall, a non-discerning user would likely never know the app was a Cordova app. One trap that I've seen many apps do is to try to emulate the UI of native apps. Emulating a native UI rarely succeeds in execution. Make the UI your own. There are ways of delivering a good user experience with Cordova. It depends on the app you're building, and how the app is developed.
> One trap that I've seen many apps do is to try to emulate the UI of native apps.
This is one of the strengths of React Native. Don't emulate the native UI - use it, just access it via JavaScript.
This is one of the strengths of React Native. Don't emulate the native UI - use it, just access it via JavaScript.
I'm excited to try React Native for that reason alone. I love Ember.js, but developing good mobile applications with ember and Cordova (while possible) is not easy.
Having used RN and, years ago, PhoneGap, I can say RN is way better. With PhoneGap you were constantly making things feel more native, and I had to do a hacky thing to speed up touch responses. With RN you actually use the native elements. RN is the real deal and I expect more and more companies to use it for new projects due to its significant advantages.
My interest in this when it was iOS only was about >< this big, but now I may actually start skimming into things and see if this is something we'd want to use at work :)
Yes! I've been working with React-Native on a side project for a few weeks now. WHAT A GODSEND! Before this, I was using Titanium, which is heavy, slow, and difficult to integrate with. React-Native felt like home.
On a related note; Why is it up to Facebook to develop something like this? Why aren't Apple and Google making it this easy to develop apps? ObjC is a nightmare, 90% of apps out there don't need that level of control.
On a related note; Why is it up to Facebook to develop something like this? Why aren't Apple and Google making it this easy to develop apps? ObjC is a nightmare, 90% of apps out there don't need that level of control.
Why aren't Apple and Google making it this easy to develop apps?
Apple has no incentive to make it easier for app developers to port their code to other platforms.
Apple has no incentive to make it easier for app developers to port their code to other platforms.
But it does have incentive for app developers on other platforms to port code to their own platform.
They incentivize people porting to iOS by being a great platform with tons of customers, many of which are willing to pay. That's why so many apps launch on iOS first (much to my dismay as a diehard Android user).
Why Google hasn't done this, I don't know. Seems like it is in their best interest and something they're already doing internally. They use the shared web/Android/iOS code concept for Inbox (but not HTML/JS)[1] and probably other projects.
[1] http://arstechnica.com/information-technology/2014/11/how-go...
Why Google hasn't done this, I don't know. Seems like it is in their best interest and something they're already doing internally. They use the shared web/Android/iOS code concept for Inbox (but not HTML/JS)[1] and probably other projects.
[1] http://arstechnica.com/information-technology/2014/11/how-go...
Dont they use this j2objc? https://github.com/google/j2objc
Apple probably doesn't concern itself with any developers that don't want to be on their platform. In fact they probably find the notion so inconceivable that they wouldn't see any value in that developer's app.
Are there any "unicorn" apps that are Android only and intend to stay that way?
Are there any "unicorn" apps that are Android only and intend to stay that way?
> Are there any "unicorn" apps that are Android only and intend to stay that way?
Chrome? Also Gmail, Google Now, and Facebook Messenger on iOS are garbage compared to Android.
Chrome? Also Gmail, Google Now, and Facebook Messenger on iOS are garbage compared to Android.
Chrome?
I could be wrong but I am pretty sure I am typing this response in Chrome on a Windows box right now, so maybe not the best example of an Android only app.
I could be wrong but I am pretty sure I am typing this response in Chrome on a Windows box right now, so maybe not the best example of an Android only app.
I figured we were talking in the context of Android vs. iOS.
Fair enough. But even Chrome missing from iOS is mostly just an annoyance to tech types. Nobody is trading in their iPhone for a Nexus just to get Chrome, it's not the same as when Instagram was iOS only.
Chrome is available on iTunes:
https://itunes.apple.com/us/artist/chrome/id15979771
It's just stuck being the Chrome around UIWebView instead of fully featured Chrome, which is unfortunate.
It's just stuck being the Chrome around UIWebView instead of fully featured Chrome, which is unfortunate.
Chrome is available on the App store, friend.
Absolutely and I don't think any other company could think in this way and succeed as wildly as Apple have.
Torque Pro[1] -- it's the reason I bought my first Android phone. On the flip side, there's ForeFlight[2].
[1] https://play.google.com/store/apps/details?id=org.prowl.torq... [2] https://itunes.apple.com/us/app/foreflight-mobile/id33325263...
[1] https://play.google.com/store/apps/details?id=org.prowl.torq... [2] https://itunes.apple.com/us/app/foreflight-mobile/id33325263...
Sure, but that works in reverse. People could easily port their code TO iOS.
Unfortunately everyone writes iOS first nowadays because rich people overwhelmingly own iOS devices.
You could probably replace "rich" by "people willing to pay money for apps". Although even on iOS this is less and less true.
That, and because development is way easier.
I'm curious why you say that.
You have to learn a whole new Apple-only programming language to do iOS (Swift or Objective-C) in addition to the iOS framework/libraries. Not to mention buying a Mac and paying Apple $100 for a developer account.
Android, on the other hand, was pretty straightforward to get started with for me as someone with Java experience.
You have to learn a whole new Apple-only programming language to do iOS (Swift or Objective-C) in addition to the iOS framework/libraries. Not to mention buying a Mac and paying Apple $100 for a developer account.
Android, on the other hand, was pretty straightforward to get started with for me as someone with Java experience.
Getting started is one thing, completing a product is another. It's not an uncommon metric to apply a 1.5x or 2x multiplier to the development time of an iOS app to obtain the time to develop the Android one.
I would also argue that from the same starting point (no java experience and no Swift experience) the learning curve is way smoother on iOS, with more fine tuned APIs and better tools (interface builder can be picked up easily by a designer with no coding background).
Perhaps, but most studies show that they start on iOS to begin with.
Has Apple ever chosen a non-native app for its annual design awards?
was there ever non-native app worth a reward?
You mean not including the vast number of Unity based games that are there?
Lock-in.
Google is working on it:
https://github.com/domokit/sky_engine and https://github.com/dart-lang/fletch
https://github.com/domokit/sky_engine and https://github.com/dart-lang/fletch
This looks like more of a side project than something Google is going to put its weight behind. I am pretty excited for Fletch though - I hope it turns into something like React Native, which would be much improved using Dart and Dart tools instead of JavaScript IMO.
Right now Fletch looks pretty awkward/painful to use though. Writing views completely natively (ObjC/Swift/Java) and then calling into a DartVM for business logic doesn't sound like a fun way to develop to me. I could be wrong, I haven't tried to use Fletch - just read some examples, but right now I don't see the benefit.
Sky is basically Cordova as far as I can tell. It dumps native looking views into a webview and calls it a day. The demo app on Google Play (https://play.google.com/store/apps/details?id=org.domokit.sk...) does not make me terribly excited for it :(
Right now Fletch looks pretty awkward/painful to use though. Writing views completely natively (ObjC/Swift/Java) and then calling into a DartVM for business logic doesn't sound like a fun way to develop to me. I could be wrong, I haven't tried to use Fletch - just read some examples, but right now I don't see the benefit.
Sky is basically Cordova as far as I can tell. It dumps native looking views into a webview and calls it a day. The demo app on Google Play (https://play.google.com/store/apps/details?id=org.domokit.sk...) does not make me terribly excited for it :(
Sky is in early stages, but I think it has good potential and in active development. I think they made the app on Google play quite some time ago during dart summit as a demo, so maybe examples in the repository is a better place to look.
Also, looks like they will name it as Flutter: https://flutter.github.io/getting-started/
Also, looks like they will name it as Flutter: https://flutter.github.io/getting-started/
I'd be really curious to hear what makes Dart tools awesome. I haven't played with Dart, but JS has some of the best tooling I've used. Have you tried webpack and hotloading? Have you tried npm (with webpack to generate client-side bundles) as your dependency manager?
Is sky engine a Google project?
It is an open source project, but check the contributors, you will see Adam Barth, Ian Hickson, Eric Seidel and other Chrome engineers.
It's already damn easy to develop apps. Objective-C is just fine.
The only reason you think it's not easy is because you're using Titanium, and not embracing the different platforms' native toolkits.
The only reason you think it's not easy is because you're using Titanium, and not embracing the different platforms' native toolkits.
It really isnt hard to write iOS or Android apps. I think you just like Javascript.
I don't think the argument is whether or not iOS or Android apps are more difficult to write. But coming from the perspective of an early stage startup, React Native is an absolute game changer. Our same two engineers can build our iOS, Android, and web app. Code can be reused. Cuts dev costs significantly. Amazing.
The developers of those platforms created distinctive OSs with distinctive features. They would certainly dispute that "90% of apps out there don't need that level of control." Their point of view is that they are innovating in the OS, and apps that take advantage of features unique to a platform will have an advantage over those that don't. On Android, there is no cross-platform equivalent to Android IPC and RPC mechanisms. No Android Wear or Android Automotive. No Android TV UI. No cross-platform printing. Etc.
If you don't need to push the features envelope of the mobile platforms you are targeting, and if you are OK with having L&F that isn't native, and if you are OK with the pace at which your cross-platform tools chase the native platforms, then cross-platform tools like React Native can be fine for you.
If you don't need to push the features envelope of the mobile platforms you are targeting, and if you are OK with having L&F that isn't native, and if you are OK with the pace at which your cross-platform tools chase the native platforms, then cross-platform tools like React Native can be fine for you.
Objective-C is fine, and Swift even more so. If you don't know the platform sure, it is difficult, but that applies to any platform. When you learn native, all those web-tech monstrosities have zero appeal.
iOS development will always be native for me, the tools are not perfect, but they feel right, I can get stuff done in no time. Android on the other hand... I can't express how much I loathe the tools and language. So much that I stopped caring. React native might be an alternative.
"Today, we're happy to release React Native for Android."
https://github.com/facebook/react-native/commit/42eb5464fd8a...
This comes in time for Facebook to meet its pledge.
http://www.reactnativeandroid.com/
https://github.com/facebook/react-native/commit/42eb5464fd8a...
This comes in time for Facebook to meet its pledge.
http://www.reactnativeandroid.com/
Big props to the person that bought the domain and setup the countdown. It stimulated the team to actually meet this deadline :)
What was there before and why? (I'd assume a countdown, but it's not in the web archive)
It was counting down from 6 months. I think it had got down to about 3 weeks before this announcement came. The countdown was originally set based on a comment that vjeux made in a blog post when React Native for iOS was released, where he asked for 6 months of patience from the community before releasing the Android version. the reactnativeandroid.com website wasn't exactly the most patient reaction, but count me among those who are glad that it served to motivate the team to get their great work out the door. :)
Thank you! I'm glad it dit!
What was the context for this? I assume someone at Facebook previously committed to having it available by Fall 2015 or similar?
It's the 'blogpost' link in this page, http://facebook.github.io/react/blog/2015/03/30/community-ro...
Interestingly, they seem to be using JavaScriptCore instead of V8 as their JavaScript interpreter: https://github.com/facebook/react-native/blob/42eb5464fd8a65...
As I recall, they announced that alongside React Native in January. I believe it was to avoid subtle differences between the JS executed on various platforms (e.g. to prevent a component from using a feature supported in V8 but not JSC).
There are a bunch of other benefits of this, e.g. we use same API on both platforms to hook up profiling. We definitely want to experiment with other JS VMs in the future though.
We designed React Native to run with any JS engine: jsc, v8, (wk)webview, inside of Chrome/Safari/Firefox, inside of Node, ... We released it with JSC today mostly for convenience: we had JSC setup from iOS and it works. But we're open to ship with a different engine if there are performance benefits.
[deleted]
This is exactly what I needed right now. <3 <3 <3
I don't think I've been this excited for a platform release.
I don't think I've been this excited for a platform release.
Has anyone done a comparative analysis of appcelerator vs react native? I might be up for it if anyone would like to join.
I've used both but I'm not part of the Appcelerator cult like most people who have invested in it apparently. Appcelerator is bad. Their OSS license is sketchy last I checked. But that's not its only problem. The community is driven by a module marketplace, which means a ton of okay-quality modules now cost $5 each. Not necessarily a bad thing, but React Native developers are releasing way more modules as FOSS, which is important to keep the community growing and active. Another thing that doesn't generally seem possible in my time with Appcelerator is being able to build a view hierarchy using native UI components. That is, I can't for example create a camera viewfinder as a background element and throw my UI inside of that element.
React Native in comparison has taken the path that is best for FOSS developers at every step of the way, which makes me very happy about the future of the platform.
React Native in comparison has taken the path that is best for FOSS developers at every step of the way, which makes me very happy about the future of the platform.
[deleted](1)
I was googling to find out if this had come out late, late last night. Found the countdown site and figured it'd be here within a month, so might as well start laying down some wireframes and plans for the app I've been wanting to build with it. Lo and behold, this morning...
Suffice to say I am very excited for this. I've been really impressed with React and what it has done for frontend development, and I can't wait to see how it translates.
Suffice to say I am very excited for this. I've been really impressed with React and what it has done for frontend development, and I can't wait to see how it translates.
Question for everybody doing some sort of cross platform mobile dev.
How common is it to have NO experience with a platform's native libraries? In other words you didn't go from ObjC or Java to React Native/Cordova/Xamarin to try and re-use code but because you know JS or C# and weren't concerned about learning the native platform.
For any that started out with no native platform knowledge did you start to dip into it as you got more experience with the cross platform tool and started bumping up against any potential limitations?
I've been flirting with Swift when I have some (rare) downtime, to get a foundation, but maybe that's not even necessary anymore given the effort companies like Facebook/Xamarin/Telerik* are putting into abstracting away the native platforms.
[*] I intentionally left Cordova off that list as "native" native and "phonegap" native are two different things.
How common is it to have NO experience with a platform's native libraries? In other words you didn't go from ObjC or Java to React Native/Cordova/Xamarin to try and re-use code but because you know JS or C# and weren't concerned about learning the native platform.
For any that started out with no native platform knowledge did you start to dip into it as you got more experience with the cross platform tool and started bumping up against any potential limitations?
I've been flirting with Swift when I have some (rare) downtime, to get a foundation, but maybe that's not even necessary anymore given the effort companies like Facebook/Xamarin/Telerik* are putting into abstracting away the native platforms.
[*] I intentionally left Cordova off that list as "native" native and "phonegap" native are two different things.
I would love to see some discussion around this as well. I have been playing with Apache Corodova and Windows 10 SDK lately and they look very promising. Being a web developer, I found them to be easy to get started.
Are there complex apps built using phonegap/swift/cordova? What are the limitations? I know Facebook tried with a 'web app' approach and reverted back to native solution. But that was years ago.
Are there complex apps built using phonegap/swift/cordova? What are the limitations? I know Facebook tried with a 'web app' approach and reverted back to native solution. But that was years ago.
Using Cordova, you will always be behind any and all Mobile Safari WebKit et al bugs. This not a big deal when pushing layout around a webpage, but it can be crippling for app development as the app grows in complexity and you crave native-quality interactions. Mobile Safari's Webkit implementation has a staggering list of severe bugs. Developing under it can become a nightmare of hacks and backpedaling. Been working on Cordova nearly full time for two years now. So much wasted time. React Native is a big deal, and is very different.
More accurately: with Cordova, you will always be behind on iOS.
I don't know about React Native, but Telerik's open source project NativeScript promises to always have 0 day support of all native platform features since it's reflecting over the native platform's libraries to expose to its own API.
React Native and NativeScript seem to have all the upside of Cordova (transference of web dev skills to native platforms) with none of the downsides (lag in new OS feature implementation, webview wrapped apps), I wonder if Cordova's days of relevance are numbered.
React Native and NativeScript seem to have all the upside of Cordova (transference of web dev skills to native platforms) with none of the downsides (lag in new OS feature implementation, webview wrapped apps), I wonder if Cordova's days of relevance are numbered.
Speaking as a web developer, this is sad, but true.
However, what's even sadder to me is the fact this continues to be true despite the fact that, believe it or not, the web has been the platform where most of the innovation in UI development paradigms has been taking place in the past few years. And I don't just mean in terms of the sheer number of new things coming out.
The web community pioneered UI development paradigms involving functional programming techniques and immutable data, and have brought its benefits to other platforms (through projects like React Native). I personally would never want to go back to the old way of building UIs. And I suspect I'll feel the same way about client-centric data fetching when I get to try out Relay/GraphQL, Falcor, Om Next, etc in production.
I really want Firefox OS to be successful for this exact reason. I don't want to have to make compromises between the best experience for my users and the best experience for myself as a developer. With a platform that makes web the native UI technology, we shouldn't have to make this compromise in theory, but Firefox OS's execution thus far has left much to be desired.
However, what's even sadder to me is the fact this continues to be true despite the fact that, believe it or not, the web has been the platform where most of the innovation in UI development paradigms has been taking place in the past few years. And I don't just mean in terms of the sheer number of new things coming out.
The web community pioneered UI development paradigms involving functional programming techniques and immutable data, and have brought its benefits to other platforms (through projects like React Native). I personally would never want to go back to the old way of building UIs. And I suspect I'll feel the same way about client-centric data fetching when I get to try out Relay/GraphQL, Falcor, Om Next, etc in production.
I really want Firefox OS to be successful for this exact reason. I don't want to have to make compromises between the best experience for my users and the best experience for myself as a developer. With a platform that makes web the native UI technology, we shouldn't have to make this compromise in theory, but Firefox OS's execution thus far has left much to be desired.
I don't believe it.
As someone with lots of native UI experience, that has to occasionally support web projects, the web is just plain clunky and playing catch up with the RAD tooling we enjoy since the mid-90 on native platforms.
As someone with lots of native UI experience, that has to occasionally support web projects, the web is just plain clunky and playing catch up with the RAD tooling we enjoy since the mid-90 on native platforms.
I was mostly referring to development paradigms and methodology in my original post, but in terms of tooling, I personally haven't see any tooling on the native side even approach the increased productivity provided by the instantaneous feedback loops that countless hot-reload implementations can offer for the web.
https://github.com/gaearon/babel-plugin-react-transform/
http://gaearon.github.io/react-hot-loader/
https://github.com/bhauman/lein-figwheel
https://github.com/gaearon/babel-plugin-react-transform/
http://gaearon.github.io/react-hot-loader/
https://github.com/bhauman/lein-figwheel
I've done similar with inotify (dnotify before that) and Python now for over a decade, and it is an interface than can automate anything. I use it with doc generators also.
I believe I used something similar called fam in the 90's but that may have only been on SGI.
I believe I used something similar called fam in the 90's but that may have only been on SGI.
Filesystem watching is only part of the equation though. Live reload has been available for the web and various other platforms for a long time, but the traditional approach to live reloading does not preserve application state.
These new hot reload implementation allows your app to be reloaded with your new changes without affecting the state of the application, and is not practical unless your application has been developed with a focus on functional techniques and careful management of application state.
This probably doesn't sound like a significant difference, but in practice, it is a huge boost to productivity, especially in a non-trivial app where reloading the entire app and then reproducing the app state manually with every file change can become quite tedious.
These new hot reload implementation allows your app to be reloaded with your new changes without affecting the state of the application, and is not practical unless your application has been developed with a focus on functional techniques and careful management of application state.
This probably doesn't sound like a significant difference, but in practice, it is a huge boost to productivity, especially in a non-trivial app where reloading the entire app and then reproducing the app state manually with every file change can become quite tedious.
Sounds neat, I do love a rapid feedback loop, although I may have done similar with a debugger and the reload built-in come to think of it.
In the types of apps I think we're talking about, typically most state is in the database and not much is going on in the client.
In the types of apps I think we're talking about, typically most state is in the database and not much is going on in the client.
That's why Common Lisp / CLOS has functionality like
* CHANGE-CLASS (change the class of an object to a different class),
* update-instance-for-different-class (updating the object after a class change, one can provide methods which will be lazily called when needed),
* update-instance-for-redefined-class (updating the object after redefining a class, one can provide methods which will be lazily called when needed),
* LOAD (load source or machine code),
* EVAL (eval expressions)
* COMPILE (compile code in memory to memory), ...
Which can be really cool, but has its downsides:
Hey cool, I can change these classes live!
Let's solve this tricky problem by changing the class at runtime. Cool, it works, now on to the next problem.
2 years later...
What's causing this super-weird bug? It's like the code isn't doing what it says at all.
1 week of debugging and head-banging later...
Oooh, something got screwed up in that runtime class change code. Fixed.
2 years later, repeat...
Hey cool, I can change these classes live!
Let's solve this tricky problem by changing the class at runtime. Cool, it works, now on to the next problem.
2 years later...
What's causing this super-weird bug? It's like the code isn't doing what it says at all.
1 week of debugging and head-banging later...
Oooh, something got screwed up in that runtime class change code. Fixed.
2 years later, repeat...
Is that something you've experienced?
Android has JRebel for Android for hot reloads...
https://zeroturnaround.com/software/jrebel-for-android/
https://zeroturnaround.com/software/jrebel-for-android/
I was not aware of this, so thanks for bringing it up.
It's a pretty amazing technical feat that this works at all, but I have a hard time imagining this would work well in practice for changes to anything other than maybe method bodies and templates though. Java's style of object orientation generally means there's plenty of tight-coupling between application state and operations on the application state, which would probably make life very difficult for any hot-reload implementation.
But regardless, it does exist and apparently works well for a lot of people. It looks like I was just ignorant when it comes to native tooling.
It's a pretty amazing technical feat that this works at all, but I have a hard time imagining this would work well in practice for changes to anything other than maybe method bodies and templates though. Java's style of object orientation generally means there's plenty of tight-coupling between application state and operations on the application state, which would probably make life very difficult for any hot-reload implementation.
But regardless, it does exist and apparently works well for a lot of people. It looks like I was just ignorant when it comes to native tooling.
Its definitely hard, but JRebel has had 7 years to figure this stuff out and so far seems to work just as well on Android.
Only one way to find out tho :) Trying it out for oneself.
Only one way to find out tho :) Trying it out for oneself.
You mean like development with Smalltalk and commercial Common Lisp environments?
Or designing GUIs WYSIWYG with Delphi, XAML with Blend, the UNIX 4GL in the 90?
Or designing GUIs WYSIWYG with Delphi, XAML with Blend, the UNIX 4GL in the 90?
Yes, Smalltalk and Common Lisp environments probably did offer similar experiences.
Tooling for web development has probably been heavily inspired by the tooling available for CL and Smalltalk, but I don't think it's fair to say it's still playing catch up. The tooling ecosystem for the web has long since caught up to the best native ever had to offer, and is now advancing the state of the art faster than any other tooling ecosystem out there today.
Tooling for web development has probably been heavily inspired by the tooling available for CL and Smalltalk, but I don't think it's fair to say it's still playing catch up. The tooling ecosystem for the web has long since caught up to the best native ever had to offer, and is now advancing the state of the art faster than any other tooling ecosystem out there today.
I was pleasantly surprised that the latest Chrome for Android delivers push notifications for Facebook due to a new W3C API, and Facebook's mobile web interface has been in good shape for some time, so right now Facebook's native app is completely optional. Which is a good thing, given how many permissions Facebook's app requires. Apparently this was announced back in April, but I just noticed it, due to Facebook being updated: http://blog.chromium.org/2015/04/reaching-and-re-engaging-us...
Along with other things such as the app manifest, Chrome on Android is leading the pack in terms of making the mobile web feel native. Previously this title belonged to iOS Safari, unfortunately Apple dropped the ball a long time ago.
I've been a long time Firefox user and I'm using Firefox on Android as well. But I do think they could do a better job, I mean I'm all for Firefox OS and what that means for Mozilla, but I feel their Android effort is subpar and that's a shame, given that Android is the modern Windows and there's plenty of room for Firefox on it. I mean right now Firefox is the only app I have that wasn't updated for the material design guidelines and they didn't even try to fake it. And that would be OK, but I've been waiting for things to get fixed ever since forever, like the Add to Homescreen functionality which is completely broken.
But anyway, people that bemoan web interfaces are usually ignorant of present day web interfaces that people use.
You can't name an email client that's more usable than GMail's web interface. And surprisingly FastMail on a mobile browser is almost as usable as native GMail, being all web. Facebook and Google Maps are 2 other example of having awesome mobile web interfaces. Of course, people focus on shiny rather than utility. But I don't care how usable or shiny your iMessenger or your FaceTime is, because I don't own an iOS device, not anymore. And your native app might be great, but if it doesn't have a web presence, I personally don't care much about it because I change devices often.
Along with other things such as the app manifest, Chrome on Android is leading the pack in terms of making the mobile web feel native. Previously this title belonged to iOS Safari, unfortunately Apple dropped the ball a long time ago.
I've been a long time Firefox user and I'm using Firefox on Android as well. But I do think they could do a better job, I mean I'm all for Firefox OS and what that means for Mozilla, but I feel their Android effort is subpar and that's a shame, given that Android is the modern Windows and there's plenty of room for Firefox on it. I mean right now Firefox is the only app I have that wasn't updated for the material design guidelines and they didn't even try to fake it. And that would be OK, but I've been waiting for things to get fixed ever since forever, like the Add to Homescreen functionality which is completely broken.
But anyway, people that bemoan web interfaces are usually ignorant of present day web interfaces that people use.
You can't name an email client that's more usable than GMail's web interface. And surprisingly FastMail on a mobile browser is almost as usable as native GMail, being all web. Facebook and Google Maps are 2 other example of having awesome mobile web interfaces. Of course, people focus on shiny rather than utility. But I don't care how usable or shiny your iMessenger or your FaceTime is, because I don't own an iOS device, not anymore. And your native app might be great, but if it doesn't have a web presence, I personally don't care much about it because I change devices often.
I disagree... They've removed functionality from the mobile web interface. Specifically, I'm unable to tag friends when sharing a post. When I share a video link (youtube, etc) it no longer creates a thumbnail or embeds the link as it does on desktop web. I'm unable to tag friends inside new/shared posts, only in comments.
I won't use the full client because it eats my battery, and they separated the messenger interface requiring yet another app with battery eating features.
I won't use the full client because it eats my battery, and they separated the messenger interface requiring yet another app with battery eating features.
[deleted]
> This not a big deal when pushing layout around a webpage,
> but it can be crippling for app development as the app
> grows in complexity and you crave native-quality
> interactions
I realize people really like the theoretical write-once behavior that you get for simple apps when using a javascript platform, but I've been waiting for years for web-based interactions to provide native quality - and I begin to suspect we'll never get there.
If you want native-quality interactions, the only solution is a native application and not common tooling via a javascript layer that runs atop the already not-as-performant-for-UI browser level. This makes your life harder as a developer, but gives your users the best possible experience for their platform.
Alternatively, if you're willing to give your users a good-but-less-than-native-quality experience, that's the niche filled by those tools.
> Even on the fastest phones, web-based (including wrapped web components) simply don't offer the native experience. They come close, but there's always a slight but perceptible performance difference
Honestly I used to believe this, but not after the release of the iPhone 5 and 6. Though there is no perceptible difference, it takes a lot of work to mimic the UI in terms of animations, opacity, and response actions, so most apps just use the default web technology which include things like a built-in 300ms delay, no response to clicking a link, etc.
Honestly I used to believe this, but not after the release of the iPhone 5 and 6. Though there is no perceptible difference, it takes a lot of work to mimic the UI in terms of animations, opacity, and response actions, so most apps just use the default web technology which include things like a built-in 300ms delay, no response to clicking a link, etc.
> it takes a lot of work to mimic the UI in terms of animations, opacity, and response actions,
Which is already done for you in Ionic -- including disabling the 300ms delay.
Which is already done for you in Ionic -- including disabling the 300ms delay.
I'd like to believe that, but can you cite some web-app or webview-based example applications?
I used to think same way, but 99% of your user won’t feel that way.
My hacker news app is a hybrid app. Available on iOS/Android/Windows/Mac and web, and I harldy see any one compalining about not being native.
There are some legit issues and peole think only way to fix is go native. Only reason I have not fixed those issues because I don’t have time, or I don’t use that functinality.
My hacker news app is a hybrid app. Available on iOS/Android/Windows/Mac and web, and I harldy see any one compalining about not being native.
There are some legit issues and peole think only way to fix is go native. Only reason I have not fixed those issues because I don’t have time, or I don’t use that functinality.
I use the app on Android and it's the best HN app on Android but at times it is obvious that it is not native and it has some issues as you said. What I have encountered are
1. I get an error message "Unable to load xxxx" at times (forgot the exact message) and the app closes.
2. If I switch between article/comments it always reloads
3. At times clicking on the comments icon doesn't work when you are in article mode.
4. I can't long press on links in comments to share it to browser/pocket etc
Compared to reddit apps like Relay, the HN app does feel much more basic.
1. I get an error message "Unable to load xxxx" at times (forgot the exact message) and the app closes.
2. If I switch between article/comments it always reloads
3. At times clicking on the comments icon doesn't work when you are in article mode.
4. I can't long press on links in comments to share it to browser/pocket etc
Compared to reddit apps like Relay, the HN app does feel much more basic.
Also the slide animations when I push the back button feels sluggish in my phone
Sworkit was supposed to be an example of a complex app for ionic, not sure what else is out there. I've used that app and can say it seems pretty solid (no crashing, locking up my phone, etc.)
http://blog.ionic.io/built-with-ionic-sworkit/
I did a pet project using the vibration feature and it worked pretty well, but haven't tried on an iphone.
I can't speak for pushing the limits of the hardware though.
http://blog.ionic.io/built-with-ionic-sworkit/
I did a pet project using the vibration feature and it worked pretty well, but haven't tried on an iphone.
I can't speak for pushing the limits of the hardware though.
Game developers do it all the time with C++ using things like Marmalade.
To my experience if all your apps do is showing tables of information and forms to put the information back in (classic WinForms app) any of the cross-platform stuff will work for you. Obviously React is rendering in native and I would prefer it.
But if your app is more advanced like a drawing app you should not use these cross platform stuff.
But if your app is more advanced like a drawing app you should not use these cross platform stuff.
or for iOS, any type of advanced animations. i like the idea of these platforms but if you building a mobile only app (like instagram when it launched) i cant imagine starting off with cross-platform tech stacks
Not sure how common it is, but I've worked on a few Cordova apps and have no native experience whatsoever.
I have ran into some roadblocks that required stepping into native development to fix up issues with Cordova Plugins (specifically for background operation), but I suspect that won't be necessary for a large majority of apps out there.
Personally, I find the Hosted Web App spec a very promising alternative to Cordova for app development with web technologies. You simply use the open web APIs (notifications, geolocation, camera, etc) for features that would normally require messing with plugins in Cordova, and they would just work.
https://developer.mozilla.org/en-US/Marketplace/Options/Host...
It's such a shame that the biggest players (Android and iOS) probably have no plans to support it natively since it would greatly reduce developer lock-in. In the meantime, the ManifoldJS project can provide Cordova-based polyfills for your Hosted Web App, but then you'd have to resort to messing with plugins all over again for the only two mobile platforms that really matter...
http://manifoldjs.com/
I have ran into some roadblocks that required stepping into native development to fix up issues with Cordova Plugins (specifically for background operation), but I suspect that won't be necessary for a large majority of apps out there.
Personally, I find the Hosted Web App spec a very promising alternative to Cordova for app development with web technologies. You simply use the open web APIs (notifications, geolocation, camera, etc) for features that would normally require messing with plugins in Cordova, and they would just work.
https://developer.mozilla.org/en-US/Marketplace/Options/Host...
It's such a shame that the biggest players (Android and iOS) probably have no plans to support it natively since it would greatly reduce developer lock-in. In the meantime, the ManifoldJS project can provide Cordova-based polyfills for your Hosted Web App, but then you'd have to resort to messing with plugins all over again for the only two mobile platforms that really matter...
http://manifoldjs.com/
If you're going cross platform, the key is to know in detail the limitations of this approach, even if it takes longer to make that initial decision about what path to take.
Different cross-platform tools have different approaches, but as a concrete example take Corona SDK. You need no native platform knowledge and your app runs inside the Corona runtime, which makes some difficult things easy but some easy things -- third-party SDK integration, install source tracking -- difficult. And if the creator of the cross-platform environment has chosen not to support certain things, you're out of luck (and you're probably always going to be lagging even for things that are supported). On the other hand, you have only a single codebase to maintain and single-click builds for a lot of platforms.
As for Cordova, we spent some time testing if the performance was sufficient when building an early version of Recent News (https://recent.io -- v1.0 just released three days ago!). We concluded it was not. Boot times were slow, the UI felt very non-native, and overall performance didn't meet our requirements. Now that was a while ago and Cordova may have improved, and hardware performance certainly has improved, so maybe it's a better option today.
Different cross-platform tools have different approaches, but as a concrete example take Corona SDK. You need no native platform knowledge and your app runs inside the Corona runtime, which makes some difficult things easy but some easy things -- third-party SDK integration, install source tracking -- difficult. And if the creator of the cross-platform environment has chosen not to support certain things, you're out of luck (and you're probably always going to be lagging even for things that are supported). On the other hand, you have only a single codebase to maintain and single-click builds for a lot of platforms.
As for Cordova, we spent some time testing if the performance was sufficient when building an early version of Recent News (https://recent.io -- v1.0 just released three days ago!). We concluded it was not. Boot times were slow, the UI felt very non-native, and overall performance didn't meet our requirements. Now that was a while ago and Cordova may have improved, and hardware performance certainly has improved, so maybe it's a better option today.
the key is to know in detail the limitations of this approach
There's the rub. If you don't know anything about the native platform then you "don't know what you don't know". The NativeScript demo shows how to pull in a native ObjC function (a string related method I think), but if you start with no background in the native libraries how would you even know when you could be leveraging a native library function instead of trying to recreate a sub-optimal approximation in JS. But if you have the foundation and know the native platform, why jump ship to JS at all? And then I'm right back where I started :)
There's the rub. If you don't know anything about the native platform then you "don't know what you don't know". The NativeScript demo shows how to pull in a native ObjC function (a string related method I think), but if you start with no background in the native libraries how would you even know when you could be leveraging a native library function instead of trying to recreate a sub-optimal approximation in JS. But if you have the foundation and know the native platform, why jump ship to JS at all? And then I'm right back where I started :)
> But if you have the foundation and know the native platform, why jump ship to JS at all?
I'm a (native) Android and JS developer. The primary reason I'm excited about React Native is that I don't have to go through the tedious compile-install cycle for every little UI change. React Native will make prototyping/iterating on Android as easy as it is on the web. However my reasoning assumes that there will be almost no friction in terms of creating complex views in React Native. I'm curious to see if that pans out.
I'm a (native) Android and JS developer. The primary reason I'm excited about React Native is that I don't have to go through the tedious compile-install cycle for every little UI change. React Native will make prototyping/iterating on Android as easy as it is on the web. However my reasoning assumes that there will be almost no friction in terms of creating complex views in React Native. I'm curious to see if that pans out.
Not having used ReactNative before, how would that change? Wouldn't you still have to at least redeploy the app to the phone if you change the JS?
> Wouldn't you still have to at least redeploy the app to the phone if you change the JS?
No, that's the beauty of it. All you need to do is shake your phone and tap the "Reload JS" option. Those JS files are served by some sort of a server that starts up on your dev machine when you first deploy the app. See https://facebook.github.io/react-native/docs/tutorial.html#d... (search for "reload js").
No, that's the beauty of it. All you need to do is shake your phone and tap the "Reload JS" option. Those JS files are served by some sort of a server that starts up on your dev machine when you first deploy the app. See https://facebook.github.io/react-native/docs/tutorial.html#d... (search for "reload js").
I assume this is only in dev mode, as opposed to release mode?
Actually no, POCs have been made which allow you to deploy setups which allow for live updating apps in production. Apple even allows RCE as long as it's executed in the JS engine.
Got any sources for that? I've not found a single example of a react android app that shows "live updating apps in production". I'm talking about things like loading code seamlessly in the background from a CDN. There are examples for iOS though
[deleted]
Quite right. It's true that if you don't have a background using the native libraries it's going to be difficult, so one approach would be talking to developers who do and doing research like reading blogs and discussions like this one...
I got into native development with no experience in the iOS/Android APIs, coming from a web dev background. I did know Java and C from working on side projects, and read up on Objective-C before, though. At my previous company, all the developers doing native work had no prior experience w/ mobile development (i.e. they primarily had backend C# experience)
I dabbled w/ Cordova and friends before, and did some work to wrap webapps in thin native shells earlier on, but there was always a very strict separation between the "sandboxed" webapp and the native code, if any.
Webapps can and do work just fine for CRUD applications, but right now, I'm of the opinion that if you want to really leverage the hardware APIs or the native ecosystem, you're better off learning the native platform, because you get no syntax mismatch friction on Stack Overflow etc, compared to Xamarin / React Native / Ambly / whatever
Also, this opinion might be unpopular among the js devs who like lightweight text editors (disclaimer: I'm one), but the heavy IDEs for Java/ObjC/Swift are actually immensely useful once you get familiar w/ their features. The static typing provided by those languages helps a lot in large refactors, in API discoverability/autocompletion and in reasoning about the codebase in general.
I dabbled w/ Cordova and friends before, and did some work to wrap webapps in thin native shells earlier on, but there was always a very strict separation between the "sandboxed" webapp and the native code, if any.
Webapps can and do work just fine for CRUD applications, but right now, I'm of the opinion that if you want to really leverage the hardware APIs or the native ecosystem, you're better off learning the native platform, because you get no syntax mismatch friction on Stack Overflow etc, compared to Xamarin / React Native / Ambly / whatever
Also, this opinion might be unpopular among the js devs who like lightweight text editors (disclaimer: I'm one), but the heavy IDEs for Java/ObjC/Swift are actually immensely useful once you get familiar w/ their features. The static typing provided by those languages helps a lot in large refactors, in API discoverability/autocompletion and in reasoning about the codebase in general.
We are a startup that went the React Native route. We initially started with Ionic, but then switched to React Native. You can read about our experiences here: https://tmail21.com/blog/why-our-startup-chose-react-native-...
You'll be limited by the widgets/apis whatever abstraction gives you. Sometimes it is enough, often it is not.
I have zero native development experience on any mobile platform and write apps abstracted away in Scheme https://github.com/part-cw/lambdanative/wiki/Getting-Started
After you write/run a lot of tests to make sure the app does what it's supposed to (there's paid services for this kind of testing too) http://googletesting.blogspot.ca/2013/08/how-google-team-tes...
This React abstraction can use Chrome Developer Tools for debugging though, that's pretty awesome.
After you write/run a lot of tests to make sure the app does what it's supposed to (there's paid services for this kind of testing too) http://googletesting.blogspot.ca/2013/08/how-google-team-tes...
This React abstraction can use Chrome Developer Tools for debugging though, that's pretty awesome.
If you stick with the tools which actually don't abstract the native platforms (e.g. RoboVM and Xamarin), I think you will learn native development quite easily. I've taken this approach, and I've had no trouble using documentation/StackOverflow to write equivalent code in Java/C#. Since pretty much all the APIs in these tools are 1-1 with the native APIs, I've also had no trouble going in the reverse direction and writing Swift/Objective-C/Java. You will still need to learn the languages, but you won't need to re-learn the APIs (which is the time consuming part).
Personally, I see little to no disadvantage with using these particular types of tools, especially if it means you can use languages like Scala, C#, and F# instead of Objective-C and Java.
Personally, I see little to no disadvantage with using these particular types of tools, especially if it means you can use languages like Scala, C#, and F# instead of Objective-C and Java.
I started serious app dev with Xamarin before I ever touched ObjC. After having implemented a ton of apps I am able to move between Xamarin/RoboVM/ObjC/Swift/Java quite easily. I dabbled with Cordova and Titanium before that a bit but that was not a good experience for me.
I like this. I tried Ionic, didn't like the complexity or the fact that one of the downsides of the "write once, run everywhere" approach is that my app looked too identical and didn't respect the design conventions of the platform it's running on.
It's interesting how you work with views named after their phone counterparts. Makes it far easier for a fairly experienced phone developer to make the switch.
I'm going to have to give this a try. I have a little side-project, a Golang hacker news clone, that I think deserves a mobile app.
It's interesting how you work with views named after their phone counterparts. Makes it far easier for a fairly experienced phone developer to make the switch.
I'm going to have to give this a try. I have a little side-project, a Golang hacker news clone, that I think deserves a mobile app.
Wow, I was literally looking at this today to see if Android was announced yet. I'm working on a little side project and I was using C++ as the common language across both iOS and Android platforms. While I do, in fact, like C++ it just doesn't have the same support as more dynamic languages to do even basic things (even string splitting or trimming requires separate libraries or rolling your own code; how does a standard string library not include such things?). This looks pretty good.
I'm going to look into this. I'm mostly curious about how building works and how easy it is to setup, say, a single (or two) build script(s) that can package for either platforms and grab the necessary, common JavaScript. I'm also curious as to how easy (or difficult) it is if you wish to create custom UI components for either platform.
I'm going to look into this. I'm mostly curious about how building works and how easy it is to setup, say, a single (or two) build script(s) that can package for either platforms and grab the necessary, common JavaScript. I'm also curious as to how easy (or difficult) it is if you wish to create custom UI components for either platform.
Are any businesses avoiding using React because of the power it gives Facebook - where they can sue you however if they infringe on your copyright or patents or other then you can't sue them because you'll lose the license to use React - along anything else they've released?
You can say it is a fair practice for a private company, however I am wondering what business operations and founders are thinking.
You can say it is a fair practice for a private company, however I am wondering what business operations and founders are thinking.
I'm not a lawyer, but you might have missed this clause in the patent grant:
> Notwithstanding the foregoing, if Facebook or any of its subsidiaries or corporate affiliates files a lawsuit alleging patent infringement against you in the first instance, and you respond by filing a patent infringement counterclaim in that lawsuit against that party that is unrelated to the Software, the license granted hereunder will not terminate under section (i) of this paragraph due to such counterclaim.
Also consider that most open-source licenses make no mention of patents at all, so you have no assurance that the company won't come after you for patents in their software.
> Notwithstanding the foregoing, if Facebook or any of its subsidiaries or corporate affiliates files a lawsuit alleging patent infringement against you in the first instance, and you respond by filing a patent infringement counterclaim in that lawsuit against that party that is unrelated to the Software, the license granted hereunder will not terminate under section (i) of this paragraph due to such counterclaim.
Also consider that most open-source licenses make no mention of patents at all, so you have no assurance that the company won't come after you for patents in their software.
Your example is solely if THEY initiate a lawsuit then you're allowed to respond, not if they do something against you that warrants suing them first.
Edit: E.g. They can copy your whole business, design and all, and if you're using React and sue them - then they can use that against you / you'd have to immediately cease using it; I'm not actually sure what the outcome would be if a license automatically expires.
Edit: E.g. They can copy your whole business, design and all, and if you're using React and sue them - then they can use that against you / you'd have to immediately cease using it; I'm not actually sure what the outcome would be if a license automatically expires.
Your example is solely if THEY initiate a lawsuit then you're allowed to respond, not if they do something against you that warrants suing them first.
Note that this is specifically regarding a patent assertion; i.e. the patent grant is not revoked if you bring legal action against Facebook for another reason, including trademark or copyright issues.
Edit: E.g. They can copy your whole business, design and all, and if you're using React and sue them - then they can use that against you
See above – this would specifically only apply to patents.
you'd have to immediately cease using it
This is not necessarily true – it just means that you lose your patent grant to React. There is no assertion here that Facebook hold any patents on React. It's obvious why this would be the case – if you bring a patent suit against Facebook, then they revoke any patent license they've granted you. I would expect any patent license – for open-source software or otherwise – to be the same.
Granted, this does nothing to affect the wider issue of a broken patent system.
Note that this is specifically regarding a patent assertion; i.e. the patent grant is not revoked if you bring legal action against Facebook for another reason, including trademark or copyright issues.
Edit: E.g. They can copy your whole business, design and all, and if you're using React and sue them - then they can use that against you
See above – this would specifically only apply to patents.
you'd have to immediately cease using it
This is not necessarily true – it just means that you lose your patent grant to React. There is no assertion here that Facebook hold any patents on React. It's obvious why this would be the case – if you bring a patent suit against Facebook, then they revoke any patent license they've granted you. I would expect any patent license – for open-source software or otherwise – to be the same.
Granted, this does nothing to affect the wider issue of a broken patent system.
This is no longer true. It was at one point, but Facebook have since amended their patent grant as a result of public pressure.
I'm fairly sure you're mistaken. They changed it so it was better, however you still can't sue them or take any acton against them or the license is revoked.
Edit: > The license granted hereunder will terminate, automatically and without notice, if you (or any of your subsidiaries, corporate affiliates or agents) initiate directly or indirectly, or take a direct financial interest in, any Patent Assertion: (i) against Facebook or any of its subsidiaries or corporate affiliates, (ii) against any party if such Patent Assertion arises in whole or in part from any software, technology, product or service of Facebook or any of its subsidiaries or corporate affiliates, or (iii) against any party relating to the Software.
Edit: > The license granted hereunder will terminate, automatically and without notice, if you (or any of your subsidiaries, corporate affiliates or agents) initiate directly or indirectly, or take a direct financial interest in, any Patent Assertion: (i) against Facebook or any of its subsidiaries or corporate affiliates, (ii) against any party if such Patent Assertion arises in whole or in part from any software, technology, product or service of Facebook or any of its subsidiaries or corporate affiliates, or (iii) against any party relating to the Software.
Do note that the clause you quote applies only to patent assertions. This means that your patent license is revoked if you bring a patent action against Facebook (or if you sure someone else for using React), but not if e.g. you sue them for infringing your copyright, or any other matter.
This does seem like it would be a standard clause for any patent agreement with another party, but IANAL.
This does seem like it would be a standard clause for any patent agreement with another party, but IANAL.
really excited to dig into this, though i don't know much javascript or React. I'm curious to see how material design comes across in these types of apps and how easily it will be to tell apart a native app and the "react" version.
Yeah, it's a bit unfortunate the 'Facebook Ads' app does not appear to use Material conventions like ripples or a pretty transition when the FAB is pressed.
I hope support for, well, the Android support library is in the works! Android apps without Material flourishes are starting to look out of place.
I hope support for, well, the Android support library is in the works! Android apps without Material flourishes are starting to look out of place.
Can I work on React Native Android apps on Linux?
The article also seems to indicate that their repository strategy is not properly set up for something like this.
Most people, I think, would initially set up a separate repository for iOS and for Android, given that they are different codebases, and you wouldn't want commit history pollution. But if you're planning on reusing a lot, like in this project, it might make sense to have them both in one repo. Or have a third for shared code, and include that in each individual one?
Most people, I think, would initially set up a separate repository for iOS and for Android, given that they are different codebases, and you wouldn't want commit history pollution. But if you're planning on reusing a lot, like in this project, it might make sense to have them both in one repo. Or have a third for shared code, and include that in each individual one?
We've had two separate repos for iOS and Android and we're merging to a common one. It's much easier to manage, especially when sharing C++ and now React Native JS code between iOS and Android apps (e.g. the Ads Manager).
This might be a stupid question, but, would it make sense to have React Native also for Windows, Linux, OS X, etc.?
it probably makes most business sense for FB to only continue supporting web and mobile, as these are the platforms facebook runs on
I think this is a potential use case of electron http://electron.atom.io/
Running in node, you already have pretty good access to native apis via native node libraries.
Running in node, you already have pretty good access to native apis via native node libraries.
It's certainly possible, but for now you could just write an app in plain React and wrap it in a web-to-native app wrapper, using something like Electron or MacGap (which Slack uses for their Mac app).
http://electron.atom.io/
https://github.com/MacGapProject/MacGap1
http://electron.atom.io/
https://github.com/MacGapProject/MacGap1
There's no reason you couldn't implement it to work on desktop, but I doubt Facebook will spend the time. I hope the open source community implements this, though, because I'd love to have a truly native cross-platform framework that also works on desktop.
That would totally make sense. At Fb, we're focused on iOS and Android, but the community is absolutely welcome to step up and implement RN for the desktop platforms.
Jordan Byron already contributed a port of React Native to Apple TV: https://github.com/facebook/react-native/issues/2618#issueco...
Jordan Byron already contributed a port of React Native to Apple TV: https://github.com/facebook/react-native/issues/2618#issueco...
At least for Windows 8/10, I'm not sure if something like React Native is really necessary, since the platform itself already has built-in support for making "native" apps in HTML/JS.
All you would need is a React wrapper around the UI controls, like this one: https://github.com/winjs/react-winjs
All you would need is a React wrapper around the UI controls, like this one: https://github.com/winjs/react-winjs
No please - Linux and Windows as dev environments first!
A sort of strange question. Has anyone tried Qt as a cross platform toolkit for mobile? What was your experience with it?
I ask this because I'm thinking about creating a cross platform app, desktop + mobile and I'm wondering which would be the best way forward. Qt? ReactJS + web browser + React Native? Something else?
I ask this because I'm thinking about creating a cross platform app, desktop + mobile and I'm wondering which would be the best way forward. Qt? ReactJS + web browser + React Native? Something else?
Qt is less than optimal on mobile. It uses QML mostly and the widgets do not look native to iOS or Android out of the box.
I write mobile apps natively in my spare time, but use Qt at work I wish that Qt was more solid for this.
I write mobile apps natively in my spare time, but use Qt at work I wish that Qt was more solid for this.
Really exciting to see an effective way to do cross-platform mobile dev, this has been a long time coming.
Shameless plug for my own project, AppHub: https://apphub.io
React Native makes it easy to write cross-platform JavaScript, we're trying to make it just as easy to deploy to every platform.
Shameless plug for my own project, AppHub: https://apphub.io
React Native makes it easy to write cross-platform JavaScript, we're trying to make it just as easy to deploy to every platform.
We're using AppHub to update our React Native app. It's amazing. Bringing one of the biggest benefits of the web to native!
I have a fair amount of experience developing native Android apps in Java, and have an app for work that I'm developing/maintaining right now. I've also used React in a couple of medium-sized web apps.
I'm extremely excited about the possibility of developing future functionality for our Android app using React Native. It's not about the language (I find using dynamically typed languages for large systems frustrating, despite how expressive they can be) or even the iOS/web reusability for me -- it's the fact that the React way of seeing the world just makes so much sense. Describing views as a (pure, as long as you're careful) function of state feels so clean to me.
I'm extremely excited about the possibility of developing future functionality for our Android app using React Native. It's not about the language (I find using dynamically typed languages for large systems frustrating, despite how expressive they can be) or even the iOS/web reusability for me -- it's the fact that the React way of seeing the world just makes so much sense. Describing views as a (pure, as long as you're careful) function of state feels so clean to me.
>I find using dynamically typed languages for large systems frustrating, despite how expressive they can be
Maybe you can find a middle ground in TypeScript ? I think it's really best of both worlds solution when it comes to JS.
I think they are working on JSX integration in the latest version.
Maybe you can find a middle ground in TypeScript ? I think it's really best of both worlds solution when it comes to JS.
I think they are working on JSX integration in the latest version.
Slightly off topic but I'm curious about using React Native vs WebView with native wrapper and components.
I'm a developer who primarily codes in Ruby. I'm working on a side project that will be mostly CRUD and have no DOM updates. The application will need to support web, mobile, and tablet. I'm considering using React so I can use React Native but I'm afraid I'm adding a level of unnecessary complexity.
Originally, I was planning to use web views and wrapping them in native components (navigation, specific ui elements) like Basecamp does (described here: https://signalvnoise.com/posts/3743-hybrid-sweet-spot-native...).
I'm proficient with Java and Javascript. My experience with js frameworks is mostly with jQuery and Angular but I've created toy apps in React.
Time is a limiting factor since this is a side project. My goal is to turn this side project into a business, not learn new technical skills. Ruby and Rails is very comfortable for me.
What do you think? Should I learn RN or just stick with Rails?
I'm a developer who primarily codes in Ruby. I'm working on a side project that will be mostly CRUD and have no DOM updates. The application will need to support web, mobile, and tablet. I'm considering using React so I can use React Native but I'm afraid I'm adding a level of unnecessary complexity.
Originally, I was planning to use web views and wrapping them in native components (navigation, specific ui elements) like Basecamp does (described here: https://signalvnoise.com/posts/3743-hybrid-sweet-spot-native...).
I'm proficient with Java and Javascript. My experience with js frameworks is mostly with jQuery and Angular but I've created toy apps in React.
Time is a limiting factor since this is a side project. My goal is to turn this side project into a business, not learn new technical skills. Ruby and Rails is very comfortable for me.
What do you think? Should I learn RN or just stick with Rails?
learn RN for the skillset. But MVPs should always be done as soon as possible so use RoR and ship it.
I would just make the project a webapp, and make sure that the site works well on mobile. Later on, when you have traction, and probably users, you can code up a native app for it (or if you have a lull of things to do and get bored :P)
I think you're right. I'll just do this.
> Later on, when you have traction, and probably users, you can code up a native app for it (or if you have a lull of things to do and get bored :P)
Maybe. Maybe not. Nowdays it's all "mobile first" so I'm not sure a web app is necessarily the base way to gauge user engagement.
Maybe. Maybe not. Nowdays it's all "mobile first" so I'm not sure a web app is necessarily the base way to gauge user engagement.
Noob question - is it possible to learn React and build mobile apps for someone who is a web developer and has no knowledge/experience in mobile development?
It's possible to learn anything :) I'm in the same boat - I haven't done any mobile development - and from what I have seen it does not look like a large amount of education will be needed.
It is possible to build an app purely in JS. The Facebook Ads Manager was built by a team where some people had mobile development experience and several people only had JS experience.
Anyone got the Android skeleton working? I'm getting a red page "unable to download JS bundle" despite having the dev server running.
I'm using a 2013 Moto X on Android 5.1.
I'm using a 2013 Moto X on Android 5.1.
Make sure your phone can connect to your machine: check https://facebook.github.io/react-native/docs/running-on-devi...
Indeed, I had to input the local IP of my machine with "Debug server host for device". Thank you!
Then I got a NPE:
[21:36:12] <START> request:/index.android.bundle?platform=android TypeError: Cannot read property 'root' of null at /Volumes/Devdisk/Perso/ErwanReact/node_modules/react-native/packager/react-packager/src/DependencyResolver/crawlers/index.js:16:84 at tryCallOne (/Volumes/Devdisk/Perso/ErwanReact/node_modules/react-native/node_modules/promise/lib/core.js:37:12) at /Volumes/Devdisk/Perso/ErwanReact/node_modules/react-native/node_modules/promise/lib/core.js:103:15 at flush (/Volumes/Devdisk/Perso/ErwanReact/node_modules/react-native/node_modules/promise/node_modules/asap/raw.js:50:29) at doNTCallback0 (node.js:408:9) at process._tickCallback (node.js:337:13)
I was able to fix it by replacing this line:
https://github.com/facebook/react-native/blob/master/package...
By this:
Then I got a NPE:
[21:36:12] <START> request:/index.android.bundle?platform=android TypeError: Cannot read property 'root' of null at /Volumes/Devdisk/Perso/ErwanReact/node_modules/react-native/packager/react-packager/src/DependencyResolver/crawlers/index.js:16:84 at tryCallOne (/Volumes/Devdisk/Perso/ErwanReact/node_modules/react-native/node_modules/promise/lib/core.js:37:12) at /Volumes/Devdisk/Perso/ErwanReact/node_modules/react-native/node_modules/promise/lib/core.js:103:15 at flush (/Volumes/Devdisk/Perso/ErwanReact/node_modules/react-native/node_modules/promise/node_modules/asap/raw.js:50:29) at doNTCallback0 (node.js:408:9) at process._tickCallback (node.js:337:13)
I was able to fix it by replacing this line:
https://github.com/facebook/react-native/blob/master/package...
By this:
return fileWatcher.getWatchers().then(([watcher]) => !!(watcher.watchProjectInfo && watcher.watchProjectInfo.root));`adb reverse tcp:8081 tcp:8081` works like a charm for me
I can't believe people (especially computer scientists) are buying into the React craze. They took an O(1) algorithm, and turned it into an O(N) heuristic, and popularized it by portraying it first as an O(N^3) problem [1]
[1] https://facebook.github.io/react/docs/reconciliation.html
[1] https://facebook.github.io/react/docs/reconciliation.html
Can you explain the assertion that DOM rendering is O(1)?
Of course. For example, suppose that there is a button in your UI that changes color whenever you click on it. Changing the color of that button in response to a click can be done in a simple Javascript function that takes O(1) time. However, doing it the React way, all buttons on the screen have to be traversed, O(N), and diff/patched into a new DOM, which is heuristically O(1). However O(N+1) = O(N), so React takes O(N) time for something that can be done in O(1) time.
Now, while React may still be fast enough in practice, I can't understand why computer scientists find the situation acceptable. It feels like using bubble sort instead of quicksort or mergesort because you expect your problem space to never grow.
Now, while React may still be fast enough in practice, I can't understand why computer scientists find the situation acceptable. It feels like using bubble sort instead of quicksort or mergesort because you expect your problem space to never grow.
I think its because there are tradeoffs for managing the complexity yourself. Using this same argument most abstractions which have performance overhead should be unacceptable. There are tradeoffs everywhere and I guess this is one that a lot of people have accepted.
It's because anyone who has done any complex web app development knows that you don't have one button changing color. You have 100+ UI components whose state may depend on one another, and as the DOM nodes composing those UI elements get state attached to them, it's EXTREMELY easy for them to both (1) get out of sync, and (2) thrash and re-render entire trees of the DOM unnecessarily. This is a real thing that happens frequently and is why people think JavaScript causes pages to be slow and janky.
React lets developers pretend they CAN just re-render entire DOM trees from scratch without those consequences, as if they were serving up a fresh server-side render of the page.
Also, suggesting that before React, web apps were updating all their DOM nodes in O(1) time is insane – even if it's not the absolute fastest, why does it compare so favorably in actual tests, then?
React lets developers pretend they CAN just re-render entire DOM trees from scratch without those consequences, as if they were serving up a fresh server-side render of the page.
Also, suggesting that before React, web apps were updating all their DOM nodes in O(1) time is insane – even if it's not the absolute fastest, why does it compare so favorably in actual tests, then?
Yes, I understand all of this. It can work for small websites. However, the technique cannot uphold for larger systems. For example, consider writing a word-processor using this style of programming. If the user is writing a 10-chapter book, and every character entered by the user requires a visit of all characters in the book, that is not very usable. So even from a practical viewpoint (not just theoretical) it is not workable.
Also, consider adding items in a streaming fashion (one-by-one). If there are N items to be added, then the amount of items visited by this scheme is 1+2+3+...+N, which amounts to O(N^2). This is quite ridiculous.
Also don't forget about power consumption, which is of course very important for mobile applications.
Finally, The solution is not satisfactory from an intellectual viewpoint. Instead of trying to be smart, we are lazy, and abuse abstractions to make our lives easier, and at the same time our software behave slower (especially now that progress in speedwise performance in hardware seems to have stopped).
Also, consider adding items in a streaming fashion (one-by-one). If there are N items to be added, then the amount of items visited by this scheme is 1+2+3+...+N, which amounts to O(N^2). This is quite ridiculous.
Also don't forget about power consumption, which is of course very important for mobile applications.
Finally, The solution is not satisfactory from an intellectual viewpoint. Instead of trying to be smart, we are lazy, and abuse abstractions to make our lives easier, and at the same time our software behave slower (especially now that progress in speedwise performance in hardware seems to have stopped).
> For example, consider writing a word-processor using this style of programming.
Quip uses React.
Quip uses React.
To be fair, nobody will choose React because of the virtual dom. The virutal dom is just a tool to make React perform faster.
You should choose React because it makes building reusable (web)components for applications much easier.
You should choose React because it makes building reusable (web)components for applications much easier.
Google has been working with the alternative already: https://flutter.github.io/ . Probably usable in some months.
It uses Dart. Which despite looking like a nice language, approximately nobody knows. So I'm not sure this is really an viable alternative.
In fairness, if you know JavaScript then you wouldn't be long picking it up. Not compared to say Objective C or C++ or even Java. Its dynamically typed with objects and lambdas etc.
Don't underestimate the hate of Java developers for JavaScript, they would do anything to not to touch it (including learning dart, which is a nicer language than both).
That seems like it's going to be a tough sell seeing as it uses Dart instead of JS when JS devs already have React Native, NativeScript, Titanium and Cordova to choose from. But I'm a firm believer in a rising tide lifts all ships, so bring it on Google!
One advantage of React Native is that facebook uses it and hence they will keep developing it. Unless Google apps start using Flutter, it may not gain traction/resources.
Except if they find out that it doesn't scale and abandon it. They have engineering resources to rewrite their app from the ground-up in whatever new technology they want.
Do you?
Not trying to discourage the use of it - just that "Facebook uses it in production" isn't really a big sell for me.
Do you?
Not trying to discourage the use of it - just that "Facebook uses it in production" isn't really a big sell for me.
I think the best part of this article was the small link to the F8 2015 "Big Code" video [0] where they go into detail about switching from Git to Mercurial, building their own IDE around Atom, and detailing their continuous integration process. It's a long video but it's very watchable using the YouTube speed multiplier. :)
[0] https://www.youtube.com/watch?v=X0VH78ye4yY
[0] https://www.youtube.com/watch?v=X0VH78ye4yY
> it's very watchable using the YouTube speed multiplier.
Good catch. Didn't know this feature, thanks!
Good catch. Didn't know this feature, thanks!
Congrats on shipping on schedule! My experience with React Native for iOS has been pretty pleasant so far given how young the libraries are. My main frustrations so far have been with the Navigator component (both the 'fully native' and the 'emulation native' versions) and some inconsistent documentation, though the latter I suspect is the result of rapid API changes. Pretty short learning curve, though, and the results have performed well, so I'd recommend anyone with moderate experience with React to check it out. Looking forward to diving in to the Android version soon.
A question for the devs:
If somone writes a React Native component, that doesn't touch native APIs, its usable across platform am I right? From what you've seen/built, how likely is it for components not to use native APIs?
Do you expect seeing components named react-native-ios-sidebar?
If somone writes a React Native component, that doesn't touch native APIs, its usable across platform am I right? From what you've seen/built, how likely is it for components not to use native APIs?
Do you expect seeing components named react-native-ios-sidebar?
> Do you expect seeing components named react-native-ios-sidebar?
Take a look at components in sidebar here: http://facebook.github.io/react-native/docs/getting-started....
Take a look at components in sidebar here: http://facebook.github.io/react-native/docs/getting-started....
Are there any high-profile apps using React Native other than those from FB? Native dev here, but considering an Android port, so wondering if maybe RN would be better.
Not too many, you can see a showcase here http://facebook.github.io/react-native/showcase.html
I believe larger companies are currently working towards React Native apps though.
I believe larger companies are currently working towards React Native apps though.
There was a lot of hesitation around ReactNative iOS because people are not sure when the Android version is coming out. Now, it is finally here!!! So excited....
Let's meetup to learn it together: http://www.meetup.com/SF-React-Native-Meetup/events/22536022...
Let's meetup to learn it together: http://www.meetup.com/SF-React-Native-Meetup/events/22536022...
I don't see how you can make a single cross-platform experience from a single JS / JSX file. The sample has two different main.js files, one for each platform:
I wonder why the team decided not to abstract the functionality a bit, like Xamarin did with Forms, so something as common as tab view could be constructed in a cross-platform manner? I understand the urge to keep the platforms feeling native, but a little abstraction could go a long way.
// iOS
var React = require('react-native');
var { TabBarIOS, NavigatorIOS } = React;
// Android
var React = require('react-native');
var { DrawerLayoutAndroid, ProgressBarAndroid } = React;
I wonder why the team decided not to abstract the functionality a bit, like Xamarin did with Forms, so something as common as tab view could be constructed in a cross-platform manner? I understand the urge to keep the platforms feeling native, but a little abstraction could go a long way.
That is by design. React native isn't intended to be write-once, run-anywhere. iOS and Android UIs are just too different for that to work well.
Instead, React Natives gives you a place (javascript) where logic can be shared between iOS and Android, and a common approach to rendering that leads to lots of shared code.
Instead, React Natives gives you a place (javascript) where logic can be shared between iOS and Android, and a common approach to rendering that leads to lots of shared code.
- You can determine the platform with React.Platform -- eg:
var React = require('react-native');
var { Platform } = React;
if (Platform.OS === 'ios') {
Android also has a `Version` property on `Platform`.
- Certain features are not idiomatic on both platforms: where you might use TabBar on iOS you are going to use a Drawer on Android. NavigatorIOS is a wrapper around UINavigationController that is not maintained as part of the core React Native project, but is a community effort -- nobody at Facebook uses it, and nobody who makes any serious apps with React Native use it either; instead, they use the cross-platform Navigator component, written entirely in JS. Similarly, if you really want to use a TabBar on Android, there exists at least one excellent JS implementations of this that you can use: https://github.com/exponentjs/react-native-tab-navigator
- This is still a very early release! In fact, it is the first day it is released. There are plans to bring the APIs together where it makes sense. For example, SwitchAndroid and SwitchIOS will be brought together under a Switch component that has the same API on both platforms but uses their underlying native implementations.
var React = require('react-native');
var { Platform } = React;
if (Platform.OS === 'ios') {
// lol steve jobs
// lol robutts
Android also has a `Version` property on `Platform`.
- Certain features are not idiomatic on both platforms: where you might use TabBar on iOS you are going to use a Drawer on Android. NavigatorIOS is a wrapper around UINavigationController that is not maintained as part of the core React Native project, but is a community effort -- nobody at Facebook uses it, and nobody who makes any serious apps with React Native use it either; instead, they use the cross-platform Navigator component, written entirely in JS. Similarly, if you really want to use a TabBar on Android, there exists at least one excellent JS implementations of this that you can use: https://github.com/exponentjs/react-native-tab-navigator
- This is still a very early release! In fact, it is the first day it is released. There are plans to bring the APIs together where it makes sense. For example, SwitchAndroid and SwitchIOS will be brought together under a Switch component that has the same API on both platforms but uses their underlying native implementations.
Great to see that some Cordova plugins are available for react-native (Background geo location). I think it is just a matter of weeks before this becomes the main stream for web developers who would like to write native apps. Don't know how Ionic can even compete with this, considering Angular2, which can render anything and not just the DOM. By the time Angular2 is stable and out of dev-preview react-native would have perfected native-rendering. Its going to be Angular2 + React-native for native apps in future.
"OS X - Only OS X is currently supported"
Why is this becoming popular ?
Why is this becoming popular ?
There's unfortunately a lot of non-overlapping work so we decided to release what we have finished incrementally. Most of the team uses OS X for development so it was a natural first choice. We're planning on adding the missing Windows and Linux support soon!
Do you want to give us a time-frame so we can go create http://www.reactnativeandroidforwindows.com/ and put a countdown timer on there?
Any idea when? I'm not sure what the full build stack is, so it's hard to have an idea on what has to be ported.
Thank you for your reply, you should add this information somewhere because right now there is now way to know you're working on it.
Yeah, it made me really sad. This is not a comment on this project specifically, but it seems to be the way the world is going - so many platform specific dependencies that even a cross-platform project is made specifically with one development platform in mind and that is considered normal.
I've been in Windows for a long time and it uses to be the opposite a long time ago - everything would be released on Windows only and Macs were left abandoned - so I guess I'm seeing the other side now. Not a super fan of Microsoft, but still annoyed I'll have to eventually switch just because of stuff like this.
I've been in Windows for a long time and it uses to be the opposite a long time ago - everything would be released on Windows only and Macs were left abandoned - so I guess I'm seeing the other side now. Not a super fan of Microsoft, but still annoyed I'll have to eventually switch just because of stuff like this.
Possibly naive question: How does this compare to qml/qtquick?
I'm sorry for the stupid question, but I'm in a hurry: I don't really want to write the whole app logic in JavaScript. Is it possible in an easy way to have a React Native UI on top of a common C/C++ code base? I don't know React yet, but it gets very interesting now and I'd like to give it a try. Maybe it could completely replace Qt for me.
I'm not exactly sure of your circumstances, but this sounds doable.
The public React Native API allows you to expose arbitrary pre-existing Views and expose new native functionality in modules accessible from JS. These can be written in java (or in C/C++ and exposed via JNI -- and if you structure your code properly you can also share that native module with an iOS RN app if you'd like).
We also support having just part of the app, e.g. some of the screens, written with React Native. This is what we do with the Groups app.
The main thing to be aware of is that splitting app logic and data management between JS and native will mean that you need to be careful with cache consistency between the two.
The public React Native API allows you to expose arbitrary pre-existing Views and expose new native functionality in modules accessible from JS. These can be written in java (or in C/C++ and exposed via JNI -- and if you structure your code properly you can also share that native module with an iOS RN app if you'd like).
We also support having just part of the app, e.g. some of the screens, written with React Native. This is what we do with the Groups app.
The main thing to be aware of is that splitting app logic and data management between JS and native will mean that you need to be careful with cache consistency between the two.
Thank you very much for your detailed answer. That really helps and I will finally learn React now.