
React Native for OS X - BafS
https://github.com/ptmt/react-native-desktop
======
xenadu02
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.

~~~
hartmel
Am I the only one who see the same story repeated again ?

We have now Facebook, a major actor on the web, who is developping a cross-
platform toolkit for application development, using OS native widgets. XUL, I
miss you :) And now others try support different OS.

Mozilla created everything and they just failed to "market" it. It s at the
same time a pain and a joice to see real JS applications, shadow dom, custom
components, CSS based styling being the core of a toolkit while we saw
XUL/XBL/CSS/native calls from Mozilla be killed a few months ago. It had its
flaws, but it s a serious (but really difficult) way to go : Qt did it, Gnome
did it, Microsoft did it, even Adobe tried to do. Mozilla and people involved
in previous ideas and implementations deserve a special mention for their
work.

We _really_ need such technologies, and that Mozilla killed theirs was a
really sad choice for me. Creating software with "simple" markup, "simple"
styling rules, "simple" event/user interaction handling should be a concrete
goal of decades of languages/compilers/interpreters researches.

It has a price : performance, sometimes native look&feel not perfectly
accurate, supported platform must have similarities. We may hopefully reach a
level where a <button> tag will cost 1% of overhead against a native call and
this will be a great day. I hope these new implementations will succeed, and
that the actual overcomplexity in the web developpement will not land in
though.

~~~
pjmlp
> We may hopefully reach a level where a <button> tag will cost 1% of overhead
> against a native call and this will be a great day.

Also known as XAML and QML.

~~~
hartmel
I wish it to be true :)

Disclaimer: I didn't feel the user experience you described. (and have a lot
more experience with XUL than QML)

What I experienced is that actual performances of crossplatform "runtimed"
toolkits are enough for desktops and acceptable for mobile devices, but the
global overhead (compared to a binary using native OS widgets) exists,
beginning with startup cost, memory consumption, i/o latency. In fact, the
same constraints that VM-based languages have. And even more : the underlying
GUI toolkit may be used in an unexpected way, strange GPU driver behaviours
may pop up, how not to be bothered by OS fragmentation. And then an
application may run flawlessly on a device with a given OS while on another it
performs not that good.

While I think it's correct to say that VM-based languages does not have to
blush in front of compiled programs when talking about raw computing
performance, my experience (as an ex XUL-lover, I may be biased) make me think
that this is still not true when UI is involved. Java has maybe the oldest
(and most optimized ?) runtimed UI, and it does not convince me. OK, this may
be a bad example : Java UIs are "runtimed" at a different layer. but seeing
the length of the QML performance wiki page is a bit scary :)

Maybe the "1% overhead" is an unreachable dream, and maybe the native apps
will become deprecated, but I think there are a place for improvements. How
many attempts of crossplatform UI runtime exists ? Not that much. With
hardware improvements, the overhead will be more and more acceptable. It s a
huge work, and previous errors should be looked at (rant time : Mozilla: you
should not have stopped to use native widgets - Adobe: Flex - QML: mimicking
web dev like XUL did is nice !).

Though, I am really impressed by Qt and .Net SDKs and I would really love to
see more free software and linux surprises from Microsoft with the Xamarin
acquisition.

And, let's be utopic, the future is maybe about a standard API à-la POSIX for
end-user applications, where OS vendors will agree on an app, and natively
implement their own <button>, their own <menu>, their own <video>. They do if
for the browser, for the "webassembly", why not for the OS ? Or the browser
will be deeply integrated in OS and the "web" apps will replace all native
applications. Or they'll still coexist for years.

OK, anything but embedding a webview would please me :)

~~~
pjmlp
I got lost at the VM references.

XAML engine is native C++ code, no VM. Since Windows 8 there isn't also a VM
as such on the .NET side, given the AOT compilation support.

Similarly QML is only interpreted in the free version. Commercial Qt compiles
QML into native code.

~~~
hartmel
Yes, the java comparison is not really good, I wanted to make a "runtime"
analogy. I didn't know for compiled QML.

~~~
pjmlp
You can read about the QML compiler here

[http://doc.qt.io/QtQuickCompiler/](http://doc.qt.io/QtQuickCompiler/)

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

~~~
mattlutze
The update message I've not generally seen before, but nearly every app I've
used asks for at least the first two individually. The modals to allow
notifications, location access, and other granular permissions on iOS is a
good-practice pattern.

~~~
Cthulhu_
Good onboarding will however prepare the user for the appearance of those
dialogs, or ideally only present them when the user performs an action that
requires access to e.g. location services or push messages.

~~~
mattlutze
Agreed entirely, if it's just blasting them out on first-use then they could
definitely tighten that up.

------
PeCaN
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
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
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
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)

~~~
hellofunk
Several academic papers on functional reactive programming specifically
discuss QML implementation, so I suspect a comparison to WPF is superficial.
You may want to take a look at QML before dismissing it. I've seen react
developers who have used QML say that the experience is very similar.

~~~
Sir_Cmpwn
That's why I included the disclaimier that I hadn't actually used QML. Thanks,
I'll check it out.

------
justsaysmthng
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
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
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
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/...

~~~
pjmlp
> 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/...

The day it offers something like Expression Blend, Qt Creator, Netbeans
Matisse, Scene Builder, Storyboards ... I will believe it.

------
girvo
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!

~~~
vmasto
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
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
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
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
[https://github.com/facebook/react-
native/releases/tag/v0.18....](https://github.com/facebook/react-
native/releases/tag/v0.18.0)

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

~~~
Mikushi
Thanks for sharing, scary perspective though.

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

~~~
justncase80
[http://cordova.apache.org/](http://cordova.apache.org/)

or

[http://electron.atom.io](http://electron.atom.io)

~~~
BinaryIdiot
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.

------
jorams
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
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)

------
api
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
And are there Windows and Linux ports being developed?

------
pbreit
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)

------
inglor
And - for windows [https://github.com/joemcbride/react-native-
wpf](https://github.com/joemcbride/react-native-wpf)

------
justncase80
Why would you use this instead of Electron?

~~~
Sir_Cmpwn
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.

~~~
eudox
>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.

~~~
boomlinde
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.

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

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

~~~
conradev
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/contribu...](https://github.com/ptmt/react-native-
desktop/graphs/contributors)

so very few of the 5.5k commits came from the OS X port

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

~~~
pluma
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
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'.

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

------
elchief
up next: React Native ncurses

~~~
ergothus
It's not quite ncurses, but....

[https://github.com/Yomguithereal/react-
blessed](https://github.com/Yomguithereal/react-blessed)

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

~~~
timgws
It does have access to a camera. Check out react-native-webrtc.

~~~
andrewshatnyy
[http://stackoverflow.com/questions/29309970/how-do-i-
access-...](http://stackoverflow.com/questions/29309970/how-do-i-access-the-
phones-camera-with-react-native-ios)

I've tried few plugins and there's no production support yet.

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

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

------
elwell
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
Slack is electron based

~~~
desireco42
Oh man, that explains so much!

------
nickyyo
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
Some web view based apps forced me to take the battery out to regain control
of my smartphone...

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

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

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

------
mrdrozdov
Does this mean Facebook is building a native desktop app?

~~~
kcorbitt
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.

------
sunasra
Awesome - Might be replacement of Electron

~~~
ponyous
If you care only for OSX yeah.

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

------
alex_duf
So we're back to Mozilla XUL ?

------
striletskyy
Looking forward to it in action.

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

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

~~~
dschep
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.

~~~
mrsteveman1
Transmission on OS X uses native UI components[1] rather than GTK. In fact
they seem to have 3 sets of UI code (AppKit, GTK+, Qt), plus the web
interface, plus whatever they're using on Windows (might be GTK+ or Qt
there?).

[1] [https://www.transmissionbt.com/images/screenshots/Mac-
Large....](https://www.transmissionbt.com/images/screenshots/Mac-Large.png)

