
React Desktop – React UI Components for OS X El Capitan and Windows 10 - dalailambda
https://github.com/gabrielbull/react-desktop
======
dgreensp
The widgets aren't native, which would be about a thousand times cooler. They
are fakes made out of CSS.

~~~
douglasheriot
Here’s a real reactive-native for desktop OS X Cocoa I found:

[https://github.com/ptmt/react-native-desktop](https://github.com/ptmt/react-
native-desktop)

Currently just "hacking weekend" level maturity.
[https://github.com/facebook/react-
native/issues/247#issuecom...](https://github.com/facebook/react-
native/issues/247#issuecomment-147086155)

I have never actually tried it, but this one is real native controls. It’s on
my TODO list…

~~~
voltagex_
Do you have any idea how the native bridge works? I wonder if it could be done
for Windows - what's the equivalent UI toolkit?

~~~
sebslomski
Is that even necessary for windows? Doesn't windows already have this
abstraction layer with windows.js?

~~~
voltagex_
Good point - [https://github.com/winjs/react-
winjs](https://github.com/winjs/react-winjs)

------
eykanal
Please forgive the simple question, but...

Why does this exist? Is creating desktop programs out of HTML code really a
good idea?

~~~
voltagex_
Because NodeJS is popular and desktop apps were getting small and efficient so
we crammed a 30MB Chrome runtime in there.

~~~
trymas
+1

With all respect to leichzeit0 comment, IMHO, JS is an ugly language, with way
too many pitfalls [0]. Even big boys [1] use CoffeScript to transpile into JS.

JS for cross platform desktop development may be an easy thing to manage,
though it can become unusable and clunky super fast. You can spot JS desktop
apps, just by the size of executable, which is at least 5-10 times bigger than
you could expect (Spotify - 130MB). They have poorer performance, can drain
your battery faster, and some OS native features/guidelines must be
implemented in a custom way, or could not be implemented/used at all. Sorry,
for my critical and conservative view, but it's just my opinion (probably due
to annoyance of overflow of laggy (web)apps, riddled with complex JS, where it
could be avoided).

Probably it's the price of 'cross-platformity'.

[0]
[https://www.youtube.com/watch?v=20BySC_6HyY](https://www.youtube.com/watch?v=20BySC_6HyY)
(original site does not load for whatever reason)

[1] [https://github.com/basecamp/trix](https://github.com/basecamp/trix)

~~~
scrollaway
I'm going to elaborate on your comment a bit because this infuriates me and I
don't think people truly understand the reasons behind why web-apps-for-
desktop generally suck and there's nothing _you_ can do to fix it in yours.

Background: I'm the lead dev/UX on LXQt, a linux desktop environment
([http://lxqt.org/](http://lxqt.org/)).

First one that comes to mind is accessibility and consistency of interactions.
Apps that do not respect a host of user settings because the devs don't even
know they exist -- but on desktop frameworks, you get these for free. You find
this on the web, too. People hijacking scrolling behaviour on websites,
without a damn clue that not everybody is on a fucking iphone. You don't
respect smoothscroll options, you don't respect autoscroll, you don't respect
lines-per-tick, it's _infuriating_. Zooming? What's that? Let me disable it
for whatever hacky performance reason. Who zooms anyway, people who can't see
well? FUCK EM!

There's a lot of those examples. Maybe one day I'll write about all of them.
They infuriate me as both a user (who is used to some specific behaviour) and
a UX guy.

Second reason is the performance. Both in executable size and general runtime
performance, as you yourself mentioned. We, as engineers, spent a lot of time
and effort working around all the design flaws of js and the web because it
was the most pragmatic thing to do. But if you bring these problems with you
on the desktop, you are doomed to lowering the quality of the experience we
have on our machines. And the user won't understand why their battery now
drains at twice the rate - they'll blame it on Lenovo's shitty hardware, so
you can get away with it. _sighs_

And the final one is the direct consequence of lowering the barrier of entry.
You often deal with worse quality code. Because of the reasons I cited above,
serious devs work with different languages when dealing with the desktop.

There are better ways, that's the worst thing. Qt and QML are extremely
productive, work well on mobile and don't have all of these issues. They also
work on more platforms than you'd be able to enumerate. Don't get me wrong, I
am a proponent of lowering the barrier of entry, and I want to bring the
_advantages_ of the web to the desktop. But you can't just move the web there,
lest you get its serious flaws and throw away decades of good engineering and
UX.

~~~
david_ar
This! I don't particularly care what technology people use to write apps, _so
long as it works well_. As others in this thread have said, you can
immediately spot a web-app-pretending-to-be-native because _it doesn 't work
well_.

QML appears to offer the best of both worlds - I don't understand why it isn't
more popular?

~~~
girvo
Qt's C++ heritage, I'd assume. That, and I really didn't like Qt Creator, when
I last tried to play with it a few years ago. In addition, "package
management" for libraries as per `npm` and it's ilk is a non-starter, though I
believe there was something on HN attempting to fix that for Qt recently.

~~~
david_ar
Qt's C++ heritage isn't any more relevant than WebKit's C++ heritage. I agree
that the ecosystem needs to improve, but it's a bit of a chicken and egg
problem.

------
bengotow
Man it's great to see effort being put into a platform-sensitive React
component set. We've been working on React components for N1, and it'd be cool
to swap them out for an open source set one day. The thing is, I'm not sure
100% native appearance is the way to go. I think Spotify nailed a cross-
platform desktop experience using a UI that is distinctly non-native.

For folks just learning about Electron / web-based desktop UI — we gave a talk
about UI considerations at the Bay Area ElectronJS meetup last month:
[https://www.youtube.com/watch?v=JIRXVGVPzn8](https://www.youtube.com/watch?v=JIRXVGVPzn8)

~~~
pjc50
Didn't we go round this with Java?

Round 1: AWT. Uses the native widgets. Therefore the layout is slightly
different on different platforms.

Round 2: Swing. Cross-platform identical, and therefore looks nothing like
native apps. You could 'skin' it, at which point it would look native but
behave subtly differently.

Round 3: SWT. Back to native widgets for Eclipse.

Round 4: Everyone throws up their hands in despair and stops writing desktop
applications.

~~~
david_ar
Not that I'm a big fan of Java, but it really feels like people threw Java
under the bus only to reinvent it all in JavaScript.

~~~
pjc50
Java was captured by "Enterprise", lending it an air of radioactive
uncoolness. So people are very reluctant to look at it and risk learning
something from its successes and failures.

------
BinaryIdiot
The components look nice but they're not really native like I had initially
thought. Are these necessarily better or different than existing styles that
reproduce these components?

Anyway, I would love to see these come in native form like reactive-native.

~~~
octref
Do you mean react-native, or is there a reactive-native I'm unaware of?

~~~
ludbb
react-native is for iOS/Android, so I would say more like a react-native for
OSX/Windows that generates native code (e.g. Cocoa for OSX).

------
protomyth
On OS X, how will these components interact with the accessibility features?

~~~
trymas
I would guess that it does not interact with accessibility now.

These components are just bunch of styles to make it look like a 'native'
widget, though it's not a real native widget of OS.

Though, it leaves me with a question, how can you set up OS X accessibility
features, in your web app/UI, that it could be used by OS X? I would guess you
can't, and it's all left to the browser.

~~~
_jsn
WebKit supports ARIA attributes. If you aren't using them in your web code
already, VoiceOver can probably navigate your page just fine, but it's subpar
compared to a document that has been marked up with rich accessibility
information.

------
kristiandupont
It's cute and I can see the appeal but I think that even if you are making a
"desktop app" that has its own executable, you are better off just using nice
HTML. It will be cross-platform, it will probably look nicer (imo, the
desktop-style looks somewhat dated). And most importantly, it won't confuse
users when it doesn't behave as expected. Getting hotkey behavior etc right is
hard, if not impossible -- some things change with international settings and
some key combinations are unavailable to the browser anyway.

------
andrewrothman
We've seen these countless times before. Trying to recreate native UI in web
technologies is a lost cause in my book.

I think what you've got here for an OS X implementation is pretty good, but I
can still tell that it isn't really native, and if an OS update changes
anything in regard to the standard UI components forget about it.

Why not design and develop your own UI? That way you can control how it is
supposed to work given the drawbacks and advantages of web technologies and
not have to ask the user for forgiveness of minor quirks in your
reimplementation.

------
shoover
As long as we're just talking about skins and not true native desktop
behavior, I'd like to see someone port such nice styles to FLTK [0] boxes.
FLTK moves you back to C++ bindings relative to an Electron-based solution,
but you'd get the same "looks native but not really" and layout portability
tradeoffs in a tiny, undeniably mature library.

[0] - [http://www.fltk.org/index.php](http://www.fltk.org/index.php)

------
jasonjei
I could see this being used in a desktop app using Chrome Embedded Framework
or some embedded browser framework. Even if you are using HTML to generate
views for your Desktop app, it could be very useful to use native-looking
widgets to blend in.

------
jlebrech
this looks like a continuation of the work cappuccino was/is doing.

sometimes you just want an app to look decent by default not unique.

