35 ms·

React Native for OS X

637 points by BafS 11y ago

desireco42 11y ago
Really loving simplicity of react on a desktop. It is possible to do with electron, this is more versatile. I have a sense that there should be more versatile components for desktop, I guess once it takes off, there will be those. Thank you.
girvo 11y ago
I'm in love with React Native. We're delivering the Android & iOS application we've been working on for the last three months this week, and it's been a phenomenal experience. Far more stable, and far more powerful than I expected going in to it; combined with Redux (though react-redux needed npm 3 and some tweaks to get it working due to name collisions under the packager) we built out a real cross platform app faster than I ever though possible. Applying that to native desktop application development has me so excited its not even funny!
- sn0v 11y ago
  As someone who's never used React, would you mind expanding on what your app does? Also, have you noticed any slowdowns at all vis-a-vis fully native apps? Thanks.
  - girvo 11y ago
    It's a "parent portal" for an existing child care centre management service. It allows the guardians to manage their child's bookings, communicate with (and from) the CCC, pay their bills and other features; so it's not crazy fancy, but does use a large amount of React Native's features!
    - vinnymac 11y ago
      That is a great use case. I have used React for administration and management services at my office as well. Being able to get the app working across so many platforms so quickly is a huge selling point for the library.
- mrdrozdov 11y ago
  This is great news! What sort of app have you built? Have you noticed any distinct differences between Android & iOS?
  - girvo 11y ago
    See my reply here[0] :) The biggest difference is that for real cross-platform support you need to be careful which APIs you choose to use; some have cross platform equivalents, but not all. In addition, we didn't want to just render the iOS UI on Android, so we replaced some of the components, about 10% or so to get a more native Android feel. Because the iOS version is more mature, we started with it and migrated it to Android a few weeks ago. The biggest thing, and this is not even React Native specific, is to ensure that the components are implemented with flexbox correctly and the layout adapts properly between screen sizes. Because Android has such a disparate set of screen sizes and devices (and iOS lets you "cheat" a bit because the set is so much smaller, letting you hardcode sizes/layout that you shouldn't), some discipline is needed. Lastly, your top-level container component will likely use padding on iOS to not overlap the status bar, don't forget to remove that on Android, because it renders it the way you'd expect: below the status bar, not underneath! [0] https://news.ycombinator.com/item?id=11386731 https://news.ycombinator.com/item?id=11386731
- vmasto 11y ago
  I wonder is there any way to reuse your already existing React Native app within Electron so that you can also achieve both OSX and Windows support?
  - girvo 11y ago
    If you implemented your "business logic" in, say, Redux or some other Flux implementation then you could share a massive amount of code between the two; however because React Native acts as a fork of React, having both in the same project (same package.json) will run into issues as far as I'm aware; so you could share code, but not have a single project that compiles to both, at this point in time EDIT: See below, this is no longer the case as of the latest versions?
    - kcorbitt 11y ago
      As of one or two releases ago React Native no longer ships with a forked version of React, and just depends on the upstream "React" library like any other project. So it's compatible with most things in the ecosystem now that don't depend on a DOM being available.
      - girvo 11y ago
        Oh really? What version is that at, we've been upgrading at every release, but I could've sworn we still ran into issues even with npm v3 with external libraries installing React when installed, rather than relying on the upstream that should already exist. Might need to upgrade again! Edited to add: We're running v0.21.0 here, and I know there were still issues with certain libraries causing conflicts even running up to v0.20.0 -- we've not had any issues since upgrading mind you.
        kcorbitt 11y ago
        https://github.com/facebook/react-native/releases/tag/v0.18.0 https://github.com/facebook/react-native/releases/tag/v0.18....
  - 11y ago
- vbit 11y ago
  How mature are the Android and iOS ports? Would you recommend them for production use?
  - RickS 11y ago
    Depends highly on your use case. For e.g. a forum reader/ news app, absolutely. For a game/something that involved a lot of robust animation and fancy graphics/transitions, not really. We've been working on a banking app, and most of the rough edges we run into are not dealbreaking (limited transition types, weak animation support, etc) and can be worked around either with native patches or are expected to be solved as the platform matures
  - girvo 11y ago
    iOS: Rather mature Android: Not as mature, but with some careful choice of libraries (effectively eschewing native libraries and sticking to Javascript implementations where possible) we had basically no issues. Tooling for Android isn't as nice as iOS in my opinion (specifically the simulator even with Intel's fancy extensions sucked compare to the iOS simulator), but because we lived mainly in Javascript-land this was rarely an issue. Debugged and tested on real Android devices (this is one thing that worked really nicely with little effort). This is a real production app for a software-as-a-service product, though it's getting a small controlled rollout to begin with. I'll be writing up a blog post or two on our experience, so keep an eye out on my website over the next few weeks/month or two -- I'm not expecting any issues though, as our beta testing has gone brilliantly :)
    - st3v3r 11y ago
      The Android simulator has always sucked, so that's not a React issue. If you're going to be working on something for Android, you should have a device.
travjones 11y ago
This is very cool. I admire all of the hard work from the react team and open source contributors that make this tech possible. <3
jonesb6 11y ago
I don't use or develop for OS X, but I know it has a reputation for some pretty bad desktop applications. Do people think React Native might lower the barrier enough to improve on this problem? Thinking of getting a Mac soon and am curious.
- stouset 11y ago
  This is completely the opposite of the case, in my experience. People complain about some things like Mail and iTunes, but overall software for OSX is typically head and shoulders above its Windows and/or Linux counterparts. For a recent example, having gotten used to Transmission (BitTorrent client on Mac), I was absolutely floored at how absurdly complicated and ad-ridden Windows alternatives are.
  - pmalynin 11y ago
    Yeah, the BitTorrent thing on Windows blows. I switched to qBittorrent which seems to be pretty reasonable -- and its GPL.
  - karlshea 11y ago
    I have to echo this. I really wonder where you got that impression because it's the opposite of both the reputation I hear and my own experience. There are very few applications that I miss from Windows. Most big cross-platform applications like Photoshop (or even SourceTree) are almost identical, but the majority of Mac-only apps that I try are fantastic. Reeder (RSS client), Fantastical 2 (calendar), Tower (git client), iTerm 2, 1Password, Transmit (FTP/SCP client) and TextWrangler/BBEdit are just a couple of examples of apps I use every day that I think really show off what Mac developers can do.
  - dschep 11y ago
    Can't you just use Transmission on windows? It's a GTK app and they're better on Windows than MacOS. Or you can always use it's web interface on Windows.
    - morgante 11y ago
diegorbaquero 11y ago
What!? This is a thing :O And I didn't know. Great work! over 5.5k commits already.
- conradev 11y ago
  It's actually just a fork of React native: https://github.com/facebook/react-native/graphs/contributors https://github.com/facebook/react-native/graphs/contributors https://github.com/ptmt/react-native-desktop/graphs/contributors https://github.com/ptmt/react-native-desktop/graphs/contribu... so very few of the 5.5k commits came from the OS X port
mrdrozdov 11y ago
Does this mean Facebook is building a native desktop app?
- kcorbitt 11y ago
  The React Native for OSX fork is being developed by a developer outside of Facebook, and as far as I'm aware Facebook hasn't put any resources into it. I'm sure they're super pumped about it though -- the core team is very enthusiastic about efforts to apply React/RN outside of just iOS and Android, they just don't have time to work on more than that at the moment.
elwell 11y ago
Interesting to have the same chronology of ecosystem hacks that iOS had: Fully Native --> Wrap JS app in WebView [0] --> React Native [0] - E.g., PhoneGap apps on iOS & Slack app on OSX
- justncase80 11y ago
  Slack is electron based
  - desireco42 11y ago
    Oh man, that explains so much!
lewisl9029 11y ago
Anyone aware of anything similar for Universal Windows Platform? That would seem like another logical extension to the existing Android/iOS targets.
- justncase80 11y ago
  http://cordova.apache.org/ http://cordova.apache.org/ or http://electron.atom.io http://electron.atom.io
  - BinaryIdiot 11y ago
    Those are not quite the same however. Those actually render the HTML / CSS / JavaScript in an web view of sorts but React Native actually uses the real, native components under the hood. I hope it's extended to Windows eventually.
  - freewizard 11y ago
    or http://nwjs.io http://nwjs.io
  - pluma 11y ago
    React is an abstraction on top of the underlying APIs (in the case of ReactDOM that's the JS API for the DOM, in the case of React Native that's JS wrappers around the native APIs). Cordova and Electron (and nwjs) are just ways to bundle apps running in a stripped down browser rendering HTML and CSS.
- flipchart 11y ago
  https://github.com/winjs/react-winjs https://github.com/winjs/react-winjs
PeCaN 11y ago
As someone who quite likes Qt, why should I prefer this over Qt5+QML? This whole React Native thing just feels like "let's reinvent Qt but slower and much less mature". Note: I really don't mean this in an inflammatory way; it just feels like people are rediscovering the cool stuff about Qt and reimplementing it but worse.
- Sir_Cmpwn 11y ago
  Have you drunk the react kool-aid for the browser yet? I have, and I was initially skeptical. Performance can be plenty fast but more importantly, your UI and your application as a whole is more testable, reliable, and easier to reason about if you use React (and importantly, the functional mindset that the React ecosystem comes with). I've made many desktop UIs without this sort of thing and they can be fiddly little bastards to get all of the interactions right, but React makes it effortless and reliable. I'd love to see React and Qt talking to each other.
  - hellofunk 11y ago
    QML on Qt is also a declarative and reactive technology, it behaves very similarly to React for the browser, but for native widgets. I think that is what the question is about, and I'm curious too... how does React differ? Qt's QML automatically updates UI elements based on state changes. I use React for web programming and they seem like similar concepts, so I'd be curious for anyone to shed light on their differences. Qt falls more into the "reactive" domain, whereas, name aside, React is not a reactive tool, technically, but the use-case is similar for both, no?
    - Sir_Cmpwn 11y ago
      I would disagree with this. I haven't worked with QML, but I have worked with WPF which also supports two-way data bindings in a manner that I would guess is similar to Qt. The major difference between the approaches is that React embodies the functional approach. By describing your UI as a pure* function of your application state, you get a lot of important benefits. * https://en.wikipedia.org/wiki/Pure_function https://en.wikipedia.org/wiki/Pure_function
MBCook 11y ago
Oh good, another was to half-ass port things to Mac. Lovely. There's a reason people like native interfaces. "No it's not like Java this time!" "It's not like Carbon!" "It's not Flash!" "Don't worry, it's no X11!" If you care about the platform, go native. Learn the rules and look and feel. If you don't care that much? Maybe you should reconsider the port. You can't "click this checkbox for OS X", it doesn't feel right.
- karlshea 11y ago
  It doesn't really look like that's what this is, it's just a different way to wire up native UI components. You're still writing Objective C and using Cocoa.
- pluma 11y ago
  I don't think you understand what React Native is. It's just a way to use the underlying native UI. It's not a bunch of emulated components with a pluggable "look and feel". They're the real thing, just wrapped in a JS API.
  - MBCook 11y ago
    No, I understand it generates native components. But if you're writing generic UI code and deploying it on a Mac without following platform conventions (about the menus, ways of doing things, etc) it will still feel 'wrong'.
kin 11y ago
This is pretty awesome. They're really proving that you can learn once build anywhere. For OS X though if I were to get into a project I'd go the Electron route.
justncase80 11y ago
Why would you use this instead of Electron?
- Sir_Cmpwn 11y ago
  Because Electron provides an awful UX. It ships with an entire web stack for applications that could be 1/100th the size and 100x the performance if they used a native toolkit instead of a web view. Electron apps also get none of the native L+F that you get if you use an actual toolkit properly. Electron is to the desktop as hybrid apps are to mobile.
  - ex3ndr 11y ago
    OSX UX libraries are always was slower than chrome-based. If your chrome-based app is slow then this is problem in your code, not in chrome itself.
  - eudox 11y ago
    >Electron apps also get none of the native L+F that you get if you use an actual toolkit properly. This is a selling point. CSS can make an app look beautiful, native look-and-feel is always atrocious, everywhere.
    - IMcD23 11y ago
      Key word can. It's also important to give users a familiar feel across the apps on their platform. The UX must make sense to them.
    - lucian1900 11y ago
      Is it atrocious? At least on OS X, iOS and Android, the native UI is quite good.
    - boomlinde 11y ago
      The obvious advantage to native look and feel is that it will be familiar to users, and that consistency in itself might make for an overall more beautiful look. If I use 5 applications and they all look entirely different, it will not look beautiful, and each time I swap to a different application I have to re-familiarize with whatever the UI designer thought was a good idea for that application.
api 11y ago
Oh yeah... once we have Windows and Linux we will finally have a single paradigm for GUIs. It's enough to make me actually love Facebook.
- igravious 11y ago
  And are there Windows and Linux ports being developed?
swaroop 11y ago
Reminds me of "Facebook will eat everything with React Native" - https://www.quora.com/What-is-mobile-development-going-to-look-like-in-2-5-years/answer/Jeff-Meyerson?srid=pvSi https://www.quora.com/What-is-mobile-development-going-to-lo...
- Mikushi 11y ago
  Thanks for sharing, scary perspective though.
kevindeasis 11y ago
When you think about it, using react with electron is kinda like react-native for cross-browsers. It'll be hilarious when someone writes a wrapper that let's you do cross browser with react Let me know if you guys know of one
pbreit 11y ago
Did "Building MacOS apps with JavaScript" ever get any traction? http://tylergaw.com/articles/building-osx-apps-with-js http://tylergaw.com/articles/building-osx-apps-with-js
xenadu02 11y ago
I sympathize with cross-platform development woes (we have this problem too) but I can't say I've ever been impressed with a cross-platform app developed using React Native (or anything else cross-platform). A React Native app isn't horrible or bad (nothing like Java Swing) but it also isn't delightful to use. Technically you have animations and things like the cross-platform navigator. In reality, you have a lot of performance issues and strange incompatibilities due to attempting to execute animation keyframes on the JS thread (or replace the system-provided navigation bar in the case of Navigator). It isn't terribly easy on battery life either. I'd rather write my sync and offline storage system in JS and share that across platforms while leaving the entire view layer as native code. That stuff is far harder to get right for non-trivial apps, it just isn't sexy and most web devs ignore it completely because hey - the web browser is always online! I'm biased though. Our customers download 5-10 GB projects with millions of objects in them because when you're building a hospital the MRI room is a literal faraday cage. No such thing as internet access in there and telling the user they can't pull up plans or engineering specs because they're offline is a non-starter.
- Benjamin_Dobell 11y ago
  Agreed. If people want to use reactive programming for their view layer on iOS or OS X then ReactiveCocoa is probably a nicer fit.
  - dhruvtv 11y ago
    React != reactive programming.
    - vinnymac 11y ago
      To add to this, for anyone who is interested in using javascript to do reactive programming lookup rxjs or baconjs.
    - Benjamin_Dobell 11y ago
      I didn't say it did...? EDIT: I mentioned "reactive programming" because React is typically used in conjunction with reactive programming. Mentioning something related to something else is pretty standard communication. To elaborate on why I made my initial comment... Reactive programming is a paradigm, it has advantages (and disadvantages). Paradigms are higher level than implementations (libraries), or even a programming languages. When people start a new project they come up with requirements; continuous integration, easily testable etc. These requirements are mostly satisfied by a paradigm, not a implementation, nor even a programming language. If you've decided you like React, you probably like it for various reasons, most of which are probably because you're following the reactive programming paradigm - and perhaps because you like JavaScript. Nonetheless, when you start a new project (e.g. you've decided you want a native Mac app) it's your job as a competent software developer to determine the best fit for the project. This means you should really do your best to make a well rounded assessment of the situation - that means being educated about the subject matter. My comment merely agreed with the parent comment's description of the disadvantages of a (near) pure JS solution, and proposed ReactiveCocoa as an alternative that provides many of the advantages and familiarities of React, minus the disadvantages the parent post pointed out. Of course, you can't use JS to write your app - that may well be deemed by your team as a sufficient enough disadvantage to avoid ReactiveCocoa as a solution.
xueshandemao 11y ago
I'm learning electron. But, React Native launch the Desktop.May i give up it?
elchief 11y ago
up next: React Native ncurses
- ergothus 11y ago
  It's not quite ncurses, but.... https://github.com/Yomguithereal/react-blessed https://github.com/Yomguithereal/react-blessed
- hamburglar 11y ago
  This exists. It sits on a curses-type lib for node called blessed. I keep meaning to try it out.
sunasra 11y ago
Awesome - Might be replacement of Electron
- ponyous 11y ago
  If you care only for OSX yeah.
andrewshatnyy 11y ago
Last time I checked "native" didn't have access to camera. Not sureif...
- timgws 11y ago
  It does have access to a camera. Check out react-native-webrtc.
  - andrewshatnyy 11y ago
    http://stackoverflow.com/questions/29309970/how-do-i-access-the-phones-camera-with-react-native-ios http://stackoverflow.com/questions/29309970/how-do-i-access-... I've tried few plugins and there's no production support yet.
dean_mcpherson 11y ago
Here's a bit about my experience with React Native. I've been using React Native on iOS in production since last November for http://townske.com/app http://townske.com/app, Over that period, I did hit some performance issues, but the vast majority of those were implementation flaws (i.e. my fault), not framework flaws. Real user feedback has been overwhelmingly positive, including being featured in the app store multiple times. I just launched another app for iOS and Android last weekend (https://curbitapp.com https://curbitapp.com) that was built with React Native in a few weeks, and shares about 80% of the codebase. I haven't spent any time optimising these apps for performance, other than following standard react best practices and see sufficient performance on both iOS and Android. For someone who has a web background, React Native is a no brainer. 60fps native UI is generally attainable, you can use the exact same tooling (good dev tools, hot reloading), and you have the ability to pick up a large chunk of your code and put it on Android, or web, or now potentially OSX.
- blub 11y ago
  I have to admit it's better than most web apps I've seen. However... After downloading Townske I get hit by three modal dialogs one after the other: * notifications * location access * query about installing an update, even though I've just downloaded the app. If I select install, nothing happens, no progress bar or anything. Developing for a platform is more than having native-looking widgets, it also means taking conventions and user expectations into consideration. I am referring to things like the tab bar which has a back button, having a next button and also page swiping in the intro, not throwing popus at the customer, etc.
  - Loque 11y ago
    I am pretty sure these things can be obtained, and will be easier to achieve as it matures. As well as devs following good practice with modal dialogues. I used Titanium to build a cross-platform app, and once I understood what it is writing with my JS, I could ensure native/performant UI elements and animations were being rendered. Really excited to see how this pans out :`)
  - mattlutze 11y ago
justsaysmthng 11y ago
Maybe it's just me, but as an C++, Objective-C and Swift programmer, React Native doesn't really appeal to me that much. At least on the iOS and Mac, I don't really want to give up on Swift in favor of Javascript. I like React on the web. In my view, conceptually it's the most interesting framework out there and that's saying a lot, given the jungle of JS frameworks populating the web. But I also like UIKit and the other native frameworks, now that I've spent so much time learning to use them right. I'll give it a try anyway, I'm sure there's something to like about it and probably something to learn too..
- on_and_off 11y ago
  As a Java, Kotlin & Rust programmer, React Native does not appeal to me either. The main appeal seems to be that web devs can continue to use js for most of their work, it does not really appeal to a mobile dev..
  - LeoNatan25 11y ago
    Web developers should remain on the web, or put enough time to learn new technologies. For a good developer, moving to another language and framework is not really that difficult. Just means to a goal. If, however, the mere thought of learning Swift or Java scares the living hell out of a "developer", then that "developer" is better left outside of my ecosystem as a mobile apps user.
    - neoeldex 11y ago
      The thing about React Native vs other frameworks is that it is cross platform. There aren't many proper cross platform frameworks which allow for 1 app, to be web-based and have native siblings in 1 codebase. I'm not scared of Swift or Java, But I am frigthened of their ux. Even big apps like eclipse put me off, due to their bloat. Also frameworks like QT don't offer the same ease of development. Remember React-Native is currently on version 0.22, and over a year old. IMO it currently offers much better ux than TK/Swing/Qt/...
hellofunk 11y ago
There seems to be some common misconceptions about the technology behind both React and FRP, and unfortunately this is compounded by the fact that FB called it "React" when it is not technically using reactive technology or functional reactive programming. I'd love to hear from any experts on the matter what the key technical distinctions are between React and FRP and where Qt's QML, which is declarative and reactive, fits into this picture in comparison. I've recently skimmed several papers on general reactive programming, and many of them cite QML in their examples, while none of them mentioned React -- perhaps because React is newer. In any case, these are interesting paradigms that could use some dumbed-down explanations.
chinchang 11y ago
If this still requires me to install xcode...then I would rather go with ReactJS + electron!
inglor 11y ago
And - for windows https://github.com/joemcbride/react-native-wpf https://github.com/joemcbride/react-native-wpf
striletskyy 11y ago
Looking forward to it in action.
alex_duf 11y ago
So we're back to Mozilla XUL ?
jimothyhalpert7 11y ago
What are your experiences using RN with Angular? It's interesting to see that the Angular team are in some way endorsing RN.
jorams 11y ago
I'm a bit confused by this. I thought the entire point of making things "native" was that the app would feel like it belongs on the platform. Native interfaces have certain details that might not be immediately noticeable, but that massively improve the experience. This... does not. The screenshots look like webapps that try hard to look native, despite actually being native. The text in the top-left textbox in the first and second screenshots looks weird, because its baseline is too high. The box around it in the second screenshot has weird corners, etc. Now, I'm not an OSX user, but with all the talk about OSX having the most polished interface, I highly doubt weird things like this are common.
- potomushto 11y ago
  Good point, thank you. Some things look in that weird way only because my (unfinished) implementation. You could use the exact same control as you would use in vanilla Cocoa app, you just need to write a correct wrapper (ViewManager). Most of the current controls are ported from iOS, I certainly should improve some of them. Also, UIExplorer also a ported app, and being not a great example, should be rewritten to achieve more OSX look and feel. Update. Filled the issue https://github.com/ptmt/react-native-desktop/issues/52 https://github.com/ptmt/react-native-desktop/issues/52
sigzero 11y ago
I am less interested that is "looks" like everything else as long as it "works" like everything else and does what I want it to do.
nickyyo 11y ago
At the end of the day.. The customer doesn't care about your code... they just want a smooth running App, so, here React Native wins.
- pjmlp 11y ago
  Some web view based apps forced me to take the battery out to regain control of my smartphone...
nickyyo 11y ago
At the end of the day.. The customer doesn't care about your code... they just want a smooth running App, so, here React Native wins.

637 points by BafS 11y ago

Really loving simplicity of react on a desktop. It is possible to do with electron, this is more versatile. I have a sense that there should be more versatile components for desktop, I guess once it takes off, there will be those. Thank you.

girvo 11y ago

I'm in love with React Native. We're delivering the Android & iOS application we've been working on for the last three months this week, and it's been a phenomenal experience. Far more stable, and far more powerful than I expected going in to it; combined with Redux (though react-redux needed npm 3 and some tweaks to get it working due to name collisions under the packager) we built out a real cross platform app faster than I ever though possible. Applying that to native desktop application development has me so excited its not even funny!

sn0v 11y ago
As someone who's never used React, would you mind expanding on what your app does? Also, have you noticed any slowdowns at all vis-a-vis fully native apps? Thanks.
- girvo 11y ago
  It's a "parent portal" for an existing child care centre management service. It allows the guardians to manage their child's bookings, communicate with (and from) the CCC, pay their bills and other features; so it's not crazy fancy, but does use a large amount of React Native's features!
  - vinnymac 11y ago
    That is a great use case. I have used React for administration and management services at my office as well. Being able to get the app working across so many platforms so quickly is a huge selling point for the library.
mrdrozdov 11y ago
This is great news! What sort of app have you built? Have you noticed any distinct differences between Android & iOS?
- girvo 11y ago
  See my reply here[0] :) The biggest difference is that for real cross-platform support you need to be careful which APIs you choose to use; some have cross platform equivalents, but not all. In addition, we didn't want to just render the iOS UI on Android, so we replaced some of the components, about 10% or so to get a more native Android feel. Because the iOS version is more mature, we started with it and migrated it to Android a few weeks ago. The biggest thing, and this is not even React Native specific, is to ensure that the components are implemented with flexbox correctly and the layout adapts properly between screen sizes. Because Android has such a disparate set of screen sizes and devices (and iOS lets you "cheat" a bit because the set is so much smaller, letting you hardcode sizes/layout that you shouldn't), some discipline is needed. Lastly, your top-level container component will likely use padding on iOS to not overlap the status bar, don't forget to remove that on Android, because it renders it the way you'd expect: below the status bar, not underneath! [0] https://news.ycombinator.com/item?id=11386731 https://news.ycombinator.com/item?id=11386731
vmasto 11y ago
I wonder is there any way to reuse your already existing React Native app within Electron so that you can also achieve both OSX and Windows support?
- girvo 11y ago
  If you implemented your "business logic" in, say, Redux or some other Flux implementation then you could share a massive amount of code between the two; however because React Native acts as a fork of React, having both in the same project (same package.json) will run into issues as far as I'm aware; so you could share code, but not have a single project that compiles to both, at this point in time EDIT: See below, this is no longer the case as of the latest versions?
  - kcorbitt 11y ago
    As of one or two releases ago React Native no longer ships with a forked version of React, and just depends on the upstream "React" library like any other project. So it's compatible with most things in the ecosystem now that don't depend on a DOM being available.
    - girvo 11y ago
      Oh really? What version is that at, we've been upgrading at every release, but I could've sworn we still ran into issues even with npm v3 with external libraries installing React when installed, rather than relying on the upstream that should already exist. Might need to upgrade again! Edited to add: We're running v0.21.0 here, and I know there were still issues with certain libraries causing conflicts even running up to v0.20.0 -- we've not had any issues since upgrading mind you.
      - kcorbitt 11y ago
        https://github.com/facebook/react-native/releases/tag/v0.18.0 https://github.com/facebook/react-native/releases/tag/v0.18....
- 11y ago
vbit 11y ago
How mature are the Android and iOS ports? Would you recommend them for production use?
- RickS 11y ago
  Depends highly on your use case. For e.g. a forum reader/ news app, absolutely. For a game/something that involved a lot of robust animation and fancy graphics/transitions, not really. We've been working on a banking app, and most of the rough edges we run into are not dealbreaking (limited transition types, weak animation support, etc) and can be worked around either with native patches or are expected to be solved as the platform matures
- girvo 11y ago
  iOS: Rather mature Android: Not as mature, but with some careful choice of libraries (effectively eschewing native libraries and sticking to Javascript implementations where possible) we had basically no issues. Tooling for Android isn't as nice as iOS in my opinion (specifically the simulator even with Intel's fancy extensions sucked compare to the iOS simulator), but because we lived mainly in Javascript-land this was rarely an issue. Debugged and tested on real Android devices (this is one thing that worked really nicely with little effort). This is a real production app for a software-as-a-service product, though it's getting a small controlled rollout to begin with. I'll be writing up a blog post or two on our experience, so keep an eye out on my website over the next few weeks/month or two -- I'm not expecting any issues though, as our beta testing has gone brilliantly :)
  - st3v3r 11y ago
    The Android simulator has always sucked, so that's not a React issue. If you're going to be working on something for Android, you should have a device.

travjones 11y ago

This is very cool. I admire all of the hard work from the react team and open source contributors that make this tech possible. <3

jonesb6 11y ago

I don't use or develop for OS X, but I know it has a reputation for some pretty bad desktop applications. Do people think React Native might lower the barrier enough to improve on this problem? Thinking of getting a Mac soon and am curious.

stouset 11y ago
This is completely the opposite of the case, in my experience. People complain about some things like Mail and iTunes, but overall software for OSX is typically head and shoulders above its Windows and/or Linux counterparts. For a recent example, having gotten used to Transmission (BitTorrent client on Mac), I was absolutely floored at how absurdly complicated and ad-ridden Windows alternatives are.
- pmalynin 11y ago
  Yeah, the BitTorrent thing on Windows blows. I switched to qBittorrent which seems to be pretty reasonable -- and its GPL.
- karlshea 11y ago
  I have to echo this. I really wonder where you got that impression because it's the opposite of both the reputation I hear and my own experience. There are very few applications that I miss from Windows. Most big cross-platform applications like Photoshop (or even SourceTree) are almost identical, but the majority of Mac-only apps that I try are fantastic. Reeder (RSS client), Fantastical 2 (calendar), Tower (git client), iTerm 2, 1Password, Transmit (FTP/SCP client) and TextWrangler/BBEdit are just a couple of examples of apps I use every day that I think really show off what Mac developers can do.
- dschep 11y ago
  Can't you just use Transmission on windows? It's a GTK app and they're better on Windows than MacOS. Or you can always use it's web interface on Windows.
  - morgante 11y ago

diegorbaquero 11y ago

What!? This is a thing :O And I didn't know. Great work! over 5.5k commits already.

conradev 11y ago
It's actually just a fork of React native: https://github.com/facebook/react-native/graphs/contributors https://github.com/facebook/react-native/graphs/contributors https://github.com/ptmt/react-native-desktop/graphs/contributors https://github.com/ptmt/react-native-desktop/graphs/contribu... so very few of the 5.5k commits came from the OS X port

mrdrozdov 11y ago

Does this mean Facebook is building a native desktop app?

kcorbitt 11y ago
The React Native for OSX fork is being developed by a developer outside of Facebook, and as far as I'm aware Facebook hasn't put any resources into it. I'm sure they're super pumped about it though -- the core team is very enthusiastic about efforts to apply React/RN outside of just iOS and Android, they just don't have time to work on more than that at the moment.

elwell 11y ago

Interesting to have the same chronology of ecosystem hacks that iOS had: Fully Native --> Wrap JS app in WebView [0] --> React Native [0] - E.g., PhoneGap apps on iOS & Slack app on OSX

justncase80 11y ago
Slack is electron based
- desireco42 11y ago
  Oh man, that explains so much!

lewisl9029 11y ago

Anyone aware of anything similar for Universal Windows Platform? That would seem like another logical extension to the existing Android/iOS targets.

justncase80 11y ago
http://cordova.apache.org/ http://cordova.apache.org/ or http://electron.atom.io http://electron.atom.io
- BinaryIdiot 11y ago
  Those are not quite the same however. Those actually render the HTML / CSS / JavaScript in an web view of sorts but React Native actually uses the real, native components under the hood. I hope it's extended to Windows eventually.
- freewizard 11y ago
  or http://nwjs.io http://nwjs.io
- pluma 11y ago
  React is an abstraction on top of the underlying APIs (in the case of ReactDOM that's the JS API for the DOM, in the case of React Native that's JS wrappers around the native APIs). Cordova and Electron (and nwjs) are just ways to bundle apps running in a stripped down browser rendering HTML and CSS.
flipchart 11y ago
https://github.com/winjs/react-winjs https://github.com/winjs/react-winjs

PeCaN 11y ago

As someone who quite likes Qt, why should I prefer this over Qt5+QML? This whole React Native thing just feels like "let's reinvent Qt but slower and much less mature". Note: I really don't mean this in an inflammatory way; it just feels like people are rediscovering the cool stuff about Qt and reimplementing it but worse.

Sir_Cmpwn 11y ago
Have you drunk the react kool-aid for the browser yet? I have, and I was initially skeptical. Performance can be plenty fast but more importantly, your UI and your application as a whole is more testable, reliable, and easier to reason about if you use React (and importantly, the functional mindset that the React ecosystem comes with). I've made many desktop UIs without this sort of thing and they can be fiddly little bastards to get all of the interactions right, but React makes it effortless and reliable. I'd love to see React and Qt talking to each other.
- hellofunk 11y ago
  QML on Qt is also a declarative and reactive technology, it behaves very similarly to React for the browser, but for native widgets. I think that is what the question is about, and I'm curious too... how does React differ? Qt's QML automatically updates UI elements based on state changes. I use React for web programming and they seem like similar concepts, so I'd be curious for anyone to shed light on their differences. Qt falls more into the "reactive" domain, whereas, name aside, React is not a reactive tool, technically, but the use-case is similar for both, no?
  - Sir_Cmpwn 11y ago
    I would disagree with this. I haven't worked with QML, but I have worked with WPF which also supports two-way data bindings in a manner that I would guess is similar to Qt. The major difference between the approaches is that React embodies the functional approach. By describing your UI as a pure* function of your application state, you get a lot of important benefits. * https://en.wikipedia.org/wiki/Pure_function https://en.wikipedia.org/wiki/Pure_function

MBCook 11y ago

Oh good, another was to half-ass port things to Mac. Lovely. There's a reason people like native interfaces. "No it's not like Java this time!" "It's not like Carbon!" "It's not Flash!" "Don't worry, it's no X11!" If you care about the platform, go native. Learn the rules and look and feel. If you don't care that much? Maybe you should reconsider the port. You can't "click this checkbox for OS X", it doesn't feel right.

karlshea 11y ago
It doesn't really look like that's what this is, it's just a different way to wire up native UI components. You're still writing Objective C and using Cocoa.
pluma 11y ago
I don't think you understand what React Native is. It's just a way to use the underlying native UI. It's not a bunch of emulated components with a pluggable "look and feel". They're the real thing, just wrapped in a JS API.
- MBCook 11y ago
  No, I understand it generates native components. But if you're writing generic UI code and deploying it on a Mac without following platform conventions (about the menus, ways of doing things, etc) it will still feel 'wrong'.

kin 11y ago

This is pretty awesome. They're really proving that you can learn once build anywhere. For OS X though if I were to get into a project I'd go the Electron route.

justncase80 11y ago

Why would you use this instead of Electron?

Sir_Cmpwn 11y ago
Because Electron provides an awful UX. It ships with an entire web stack for applications that could be 1/100th the size and 100x the performance if they used a native toolkit instead of a web view. Electron apps also get none of the native L+F that you get if you use an actual toolkit properly. Electron is to the desktop as hybrid apps are to mobile.
- ex3ndr 11y ago
  OSX UX libraries are always was slower than chrome-based. If your chrome-based app is slow then this is problem in your code, not in chrome itself.
- eudox 11y ago
  >Electron apps also get none of the native L+F that you get if you use an actual toolkit properly. This is a selling point. CSS can make an app look beautiful, native look-and-feel is always atrocious, everywhere.
  - IMcD23 11y ago
    Key word can. It's also important to give users a familiar feel across the apps on their platform. The UX must make sense to them.
  - lucian1900 11y ago
    Is it atrocious? At least on OS X, iOS and Android, the native UI is quite good.
  - boomlinde 11y ago
    The obvious advantage to native look and feel is that it will be familiar to users, and that consistency in itself might make for an overall more beautiful look. If I use 5 applications and they all look entirely different, it will not look beautiful, and each time I swap to a different application I have to re-familiarize with whatever the UI designer thought was a good idea for that application.

api 11y ago

Oh yeah... once we have Windows and Linux we will finally have a single paradigm for GUIs. It's enough to make me actually love Facebook.

igravious 11y ago
And are there Windows and Linux ports being developed?

swaroop 11y ago

Reminds me of "Facebook will eat everything with React Native" - https://www.quora.com/What-is-mobile-development-going-to-look-like-in-2-5-years/answer/Jeff-Meyerson?srid=pvSi https://www.quora.com/What-is-mobile-development-going-to-lo...

Mikushi 11y ago
Thanks for sharing, scary perspective though.

kevindeasis 11y ago

When you think about it, using react with electron is kinda like react-native for cross-browsers. It'll be hilarious when someone writes a wrapper that let's you do cross browser with react Let me know if you guys know of one

pbreit 11y ago

Did "Building MacOS apps with JavaScript" ever get any traction? http://tylergaw.com/articles/building-osx-apps-with-js http://tylergaw.com/articles/building-osx-apps-with-js

xenadu02 11y ago

I sympathize with cross-platform development woes (we have this problem too) but I can't say I've ever been impressed with a cross-platform app developed using React Native (or anything else cross-platform). A React Native app isn't horrible or bad (nothing like Java Swing) but it also isn't delightful to use. Technically you have animations and things like the cross-platform navigator. In reality, you have a lot of performance issues and strange incompatibilities due to attempting to execute animation keyframes on the JS thread (or replace the system-provided navigation bar in the case of Navigator). It isn't terribly easy on battery life either. I'd rather write my sync and offline storage system in JS and share that across platforms while leaving the entire view layer as native code. That stuff is far harder to get right for non-trivial apps, it just isn't sexy and most web devs ignore it completely because hey - the web browser is always online! I'm biased though. Our customers download 5-10 GB projects with millions of objects in them because when you're building a hospital the MRI room is a literal faraday cage. No such thing as internet access in there and telling the user they can't pull up plans or engineering specs because they're offline is a non-starter.

Benjamin_Dobell 11y ago
Agreed. If people want to use reactive programming for their view layer on iOS or OS X then ReactiveCocoa is probably a nicer fit.
- dhruvtv 11y ago
  React != reactive programming.
  - vinnymac 11y ago
    To add to this, for anyone who is interested in using javascript to do reactive programming lookup rxjs or baconjs.
  - Benjamin_Dobell 11y ago
    I didn't say it did...? EDIT: I mentioned "reactive programming" because React is typically used in conjunction with reactive programming. Mentioning something related to something else is pretty standard communication. To elaborate on why I made my initial comment... Reactive programming is a paradigm, it has advantages (and disadvantages). Paradigms are higher level than implementations (libraries), or even a programming languages. When people start a new project they come up with requirements; continuous integration, easily testable etc. These requirements are mostly satisfied by a paradigm, not a implementation, nor even a programming language. If you've decided you like React, you probably like it for various reasons, most of which are probably because you're following the reactive programming paradigm - and perhaps because you like JavaScript. Nonetheless, when you start a new project (e.g. you've decided you want a native Mac app) it's your job as a competent software developer to determine the best fit for the project. This means you should really do your best to make a well rounded assessment of the situation - that means being educated about the subject matter. My comment merely agreed with the parent comment's description of the disadvantages of a (near) pure JS solution, and proposed ReactiveCocoa as an alternative that provides many of the advantages and familiarities of React, minus the disadvantages the parent post pointed out. Of course, you can't use JS to write your app - that may well be deemed by your team as a sufficient enough disadvantage to avoid ReactiveCocoa as a solution.

xueshandemao 11y ago

I'm learning electron. But, React Native launch the Desktop.May i give up it?

elchief 11y ago

up next: React Native ncurses

ergothus 11y ago
It's not quite ncurses, but.... https://github.com/Yomguithereal/react-blessed https://github.com/Yomguithereal/react-blessed
hamburglar 11y ago
This exists. It sits on a curses-type lib for node called blessed. I keep meaning to try it out.

sunasra 11y ago

Awesome - Might be replacement of Electron

ponyous 11y ago
If you care only for OSX yeah.

andrewshatnyy 11y ago

Last time I checked "native" didn't have access to camera. Not sureif...

timgws 11y ago
It does have access to a camera. Check out react-native-webrtc.
- andrewshatnyy 11y ago
  http://stackoverflow.com/questions/29309970/how-do-i-access-the-phones-camera-with-react-native-ios http://stackoverflow.com/questions/29309970/how-do-i-access-... I've tried few plugins and there's no production support yet.

dean_mcpherson 11y ago

Here's a bit about my experience with React Native. I've been using React Native on iOS in production since last November for http://townske.com/app http://townske.com/app, Over that period, I did hit some performance issues, but the vast majority of those were implementation flaws (i.e. my fault), not framework flaws. Real user feedback has been overwhelmingly positive, including being featured in the app store multiple times. I just launched another app for iOS and Android last weekend (https://curbitapp.com https://curbitapp.com) that was built with React Native in a few weeks, and shares about 80% of the codebase. I haven't spent any time optimising these apps for performance, other than following standard react best practices and see sufficient performance on both iOS and Android. For someone who has a web background, React Native is a no brainer. 60fps native UI is generally attainable, you can use the exact same tooling (good dev tools, hot reloading), and you have the ability to pick up a large chunk of your code and put it on Android, or web, or now potentially OSX.

blub 11y ago
I have to admit it's better than most web apps I've seen. However... After downloading Townske I get hit by three modal dialogs one after the other: * notifications * location access * query about installing an update, even though I've just downloaded the app. If I select install, nothing happens, no progress bar or anything. Developing for a platform is more than having native-looking widgets, it also means taking conventions and user expectations into consideration. I am referring to things like the tab bar which has a back button, having a next button and also page swiping in the intro, not throwing popus at the customer, etc.
- Loque 11y ago
  I am pretty sure these things can be obtained, and will be easier to achieve as it matures. As well as devs following good practice with modal dialogues. I used Titanium to build a cross-platform app, and once I understood what it is writing with my JS, I could ensure native/performant UI elements and animations were being rendered. Really excited to see how this pans out :`)
- mattlutze 11y ago

justsaysmthng 11y ago

Maybe it's just me, but as an C++, Objective-C and Swift programmer, React Native doesn't really appeal to me that much. At least on the iOS and Mac, I don't really want to give up on Swift in favor of Javascript. I like React on the web. In my view, conceptually it's the most interesting framework out there and that's saying a lot, given the jungle of JS frameworks populating the web. But I also like UIKit and the other native frameworks, now that I've spent so much time learning to use them right. I'll give it a try anyway, I'm sure there's something to like about it and probably something to learn too..

on_and_off 11y ago
As a Java, Kotlin & Rust programmer, React Native does not appeal to me either. The main appeal seems to be that web devs can continue to use js for most of their work, it does not really appeal to a mobile dev..
- LeoNatan25 11y ago
  Web developers should remain on the web, or put enough time to learn new technologies. For a good developer, moving to another language and framework is not really that difficult. Just means to a goal. If, however, the mere thought of learning Swift or Java scares the living hell out of a "developer", then that "developer" is better left outside of my ecosystem as a mobile apps user.
  - neoeldex 11y ago
    The thing about React Native vs other frameworks is that it is cross platform. There aren't many proper cross platform frameworks which allow for 1 app, to be web-based and have native siblings in 1 codebase. I'm not scared of Swift or Java, But I am frigthened of their ux. Even big apps like eclipse put me off, due to their bloat. Also frameworks like QT don't offer the same ease of development. Remember React-Native is currently on version 0.22, and over a year old. IMO it currently offers much better ux than TK/Swing/Qt/...

hellofunk 11y ago

There seems to be some common misconceptions about the technology behind both React and FRP, and unfortunately this is compounded by the fact that FB called it "React" when it is not technically using reactive technology or functional reactive programming. I'd love to hear from any experts on the matter what the key technical distinctions are between React and FRP and where Qt's QML, which is declarative and reactive, fits into this picture in comparison. I've recently skimmed several papers on general reactive programming, and many of them cite QML in their examples, while none of them mentioned React -- perhaps because React is newer. In any case, these are interesting paradigms that could use some dumbed-down explanations.

chinchang 11y ago

If this still requires me to install xcode...then I would rather go with ReactJS + electron!

inglor 11y ago

And - for windows https://github.com/joemcbride/react-native-wpf https://github.com/joemcbride/react-native-wpf

striletskyy 11y ago

Looking forward to it in action.

alex_duf 11y ago

So we're back to Mozilla XUL ?

jimothyhalpert7 11y ago

What are your experiences using RN with Angular? It's interesting to see that the Angular team are in some way endorsing RN.

jorams 11y ago

I'm a bit confused by this. I thought the entire point of making things "native" was that the app would feel like it belongs on the platform. Native interfaces have certain details that might not be immediately noticeable, but that massively improve the experience. This... does not. The screenshots look like webapps that try hard to look native, despite actually being native. The text in the top-left textbox in the first and second screenshots looks weird, because its baseline is too high. The box around it in the second screenshot has weird corners, etc. Now, I'm not an OSX user, but with all the talk about OSX having the most polished interface, I highly doubt weird things like this are common.

potomushto 11y ago
Good point, thank you. Some things look in that weird way only because my (unfinished) implementation. You could use the exact same control as you would use in vanilla Cocoa app, you just need to write a correct wrapper (ViewManager). Most of the current controls are ported from iOS, I certainly should improve some of them. Also, UIExplorer also a ported app, and being not a great example, should be rewritten to achieve more OSX look and feel. Update. Filled the issue https://github.com/ptmt/react-native-desktop/issues/52 https://github.com/ptmt/react-native-desktop/issues/52

sigzero 11y ago

I am less interested that is "looks" like everything else as long as it "works" like everything else and does what I want it to do.

nickyyo 11y ago

At the end of the day.. The customer doesn't care about your code... they just want a smooth running App, so, here React Native wins.

pjmlp 11y ago
Some web view based apps forced me to take the battery out to regain control of my smartphone...

nickyyo 11y ago

At the end of the day.. The customer doesn't care about your code... they just want a smooth running App, so, here React Native wins.