9 ms·

React Desktop – React UI Components for OS X El Capitan and Windows 10

207 points by dalailambda 11y ago

BinaryIdiot 11y ago
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 11y ago
  Do you mean react-native, or is there a reactive-native I'm unaware of?
  - ludbb 11y ago
    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).
  - BinaryIdiot 11y ago
    I meant react-native and I couldn't update my comment when I noticed =/
eykanal 11y ago
Please forgive the simple question, but... Why does this exist? Is creating desktop programs out of HTML code really a good idea?
- tuananh 11y ago
  web-based apps; like Spotify?
- voltagex_ 11y ago
  Because NodeJS is popular and desktop apps were getting small and efficient so we crammed a 30MB Chrome runtime in there.
  - laichzeit0 11y ago
    Actually it's more like this: That ugly language called Javascript that everyone derided and said was "too shit and slow to ever write a Demo in" back in the 90s when all the "real developers" were writing server side scripts in Perl and left the frontend people to their own devices caught up with them. They kept pushing the boundaries, discovering things like XMLHttpRequest, and using that crap little language. Eventually big players like Google started throwing a lot of money at the problem and Javascript became usable enough to write apps in. The front end people that all the cool Perl kids derided needed something on the backend. They wern't going to touch Perl since by this time it was an old languishing dinosaur and there was a bad taste left in their mouth. And thus NodeJS was born. The frontend dev could write his server side stuff in the one language he knew. This is my completely biased and highly selective history of events ;)
    - voltagex_ 11y ago
      Yep. If this is the only thing stopping native apps from disappearing completely then it's probably a good thing.
    - jakejake 11y ago
      Except the perl kids weren't cool (I was one of them) because they didn't write c++, and they weren't cool because they didn't write assembly, and on on!
    - MichaelGG 11y ago
      Server-side JavaScript was a thing in the 90s with Classic ASP.
    - fyolnish 11y ago
      They discovered a documented browser feature? Hooray for that.
  - trymas 11y ago
    +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
- ludbb 11y ago
  I see it as an initial step towards actual native code generation. I would rather use that than the likes of Qt QML if it actually produced native code.
- evinism 11y ago
  This is the question I was going to ask. It seems like porting many of the poor decisions that were made in creating the web to native desktop.
  - marcus_holmes 11y ago
    But that's the point of React - providing an abstraction layer over the poor decisions that were made in creating the web. Apart from Javascript, of course. But that particular "bad decision" is getting modified with every version into something more acceptable ("now with classes!"). I guess the endpoint is that React + Javascript (+ Redux) becomes the defacto language for developing UIs in, and what implements that abstraction layer is immaterial. React-native all the things!
    - IshKebab 11y ago
      > But that particular "bad decision" is getting modified with every version into something more acceptable True, but it definitely seems like they're only fixing the low-hanging fruit. They're never going to fix the insane type system.
      - marcus_holmes 11y ago
        I know I'm a nutter, but I like the type system :) I like that there's "==" and "===", because that's exactly how I think. It fits my use case of "is this the same value as that?" or "is this really equal to that?" exactly. I like that types are fluid, flexible and never get in my way. But there's a religious war here that I think got won by the static type side, so I'm not going there again ;)
- Tehnix 11y ago
  Because working with things like GTK and QT is horrible compared to working with HTML/JS/CSS, for anything other than trivial things. That said, it'd be cool to have native code generation from this though.
  - discreteevent 11y ago
    Have you used Qt and QML? For me it's much more productive and straightforward than html/js/css. Delarative legible ui with built in dataflow/reactive properties. Performs straight out of the box without having figure out how to work with the mechanisms buried in this hugely complex and opaque machine called a browser. In fact its a relief to work with it. Could you say where you think its so 'horrible'.
    - jnbiche 11y ago
      Agreed. Assuming they took this to its full potential, and created native, cross-platform, desktop widgets for React, what they'd end up with would look startingly similar to QML, except without the easy C++ interop. I'm a fan of React, but I have no desire to use it outside of the web, and maybe mobile (still on the fence there). For desktop, we have QT, which is truly an awesome native widget toolkit, with many thousands of man-years work in it, excellent cross-platform desktop coverage, along with pretty good accessibility standards.
    - makecheck 11y ago
      Although I've never had to start from scratch, the Qt projects I've maintained have been prone to crashing. Maybe the Qt apps have legitimate bugs but the fact is that native environments like Objective-C, and most likely this JavaScript environment, would both handle those issues very cleanly compared to Qt.
    - lobster_johnson 11y ago
      Do you know of any modern OS X apps written with Qt that have a native look and feel that, in particular, take advantage of Core Animation for UI transitions? All the Qt apps I have touched (Google Earth comes to mind) have neither looked nor felt native on OS X, much like Swing and SWT apps don't at all feel native. Whereas all the best apps are written in native Cocoa.
- moretti 11y ago
  You're probably not familiar with Atwood's Law[0]: > Any application that can be written in JavaScript, will eventually be written in JavaScript [0]: http://blog.codinghorror.com/the-principle-of-least-power/ http://blog.codinghorror.com/the-principle-of-least-power/
dgreensp 11y ago
The widgets aren't native, which would be about a thousand times cooler. They are fakes made out of CSS.
- douglasheriot 11y ago
  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#issuecomment-147086155 https://github.com/facebook/react-native/issues/247#issuecom... I have never actually tried it, but this one is real native controls. It’s on my TODO list…
  - voltagex_ 11y ago
    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 11y ago
      Is that even necessary for windows? Doesn't windows already have this abstraction layer with windows.js?
      - voltagex_ 11y ago
        Good point - https://github.com/winjs/react-winjs https://github.com/winjs/react-winjs
  - Void_ 11y ago
    This is great stuff! Wonder if once Swift is open-sourced we'll see a library like that in Swift. Imagine writing React code in Swift and rebuilding that for Windows!
bengotow 11y ago
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
- eloisant 11y ago
  Either you go with a non-native look, or you use native components. Mimicking native with CSS is only getting you to the uncanny valley of UX.
- pjc50 11y ago
  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 11y ago
    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 11y ago
      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.
  - mhw 11y ago
protomyth 11y ago
On OS X, how will these components interact with the accessibility features?
- trymas 11y ago
  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 11y ago
    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 11y ago
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.
jlebrech 11y ago
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.
jasonjei 11y ago
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.
shoover 11y ago
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
andrewrothman 11y ago
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.

207 points by dalailambda 11y ago

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 11y ago
Do you mean react-native, or is there a reactive-native I'm unaware of?
- ludbb 11y ago
  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).
- BinaryIdiot 11y ago
  I meant react-native and I couldn't update my comment when I noticed =/

eykanal 11y ago

Please forgive the simple question, but... Why does this exist? Is creating desktop programs out of HTML code really a good idea?

tuananh 11y ago
web-based apps; like Spotify?
voltagex_ 11y ago
Because NodeJS is popular and desktop apps were getting small and efficient so we crammed a 30MB Chrome runtime in there.
- laichzeit0 11y ago
  Actually it's more like this: That ugly language called Javascript that everyone derided and said was "too shit and slow to ever write a Demo in" back in the 90s when all the "real developers" were writing server side scripts in Perl and left the frontend people to their own devices caught up with them. They kept pushing the boundaries, discovering things like XMLHttpRequest, and using that crap little language. Eventually big players like Google started throwing a lot of money at the problem and Javascript became usable enough to write apps in. The front end people that all the cool Perl kids derided needed something on the backend. They wern't going to touch Perl since by this time it was an old languishing dinosaur and there was a bad taste left in their mouth. And thus NodeJS was born. The frontend dev could write his server side stuff in the one language he knew. This is my completely biased and highly selective history of events ;)
  - voltagex_ 11y ago
    Yep. If this is the only thing stopping native apps from disappearing completely then it's probably a good thing.
  - jakejake 11y ago
    Except the perl kids weren't cool (I was one of them) because they didn't write c++, and they weren't cool because they didn't write assembly, and on on!
  - MichaelGG 11y ago
    Server-side JavaScript was a thing in the 90s with Classic ASP.
  - fyolnish 11y ago
    They discovered a documented browser feature? Hooray for that.
- trymas 11y ago
  +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
ludbb 11y ago
I see it as an initial step towards actual native code generation. I would rather use that than the likes of Qt QML if it actually produced native code.
evinism 11y ago
This is the question I was going to ask. It seems like porting many of the poor decisions that were made in creating the web to native desktop.
- marcus_holmes 11y ago
  But that's the point of React - providing an abstraction layer over the poor decisions that were made in creating the web. Apart from Javascript, of course. But that particular "bad decision" is getting modified with every version into something more acceptable ("now with classes!"). I guess the endpoint is that React + Javascript (+ Redux) becomes the defacto language for developing UIs in, and what implements that abstraction layer is immaterial. React-native all the things!
  - IshKebab 11y ago
    > But that particular "bad decision" is getting modified with every version into something more acceptable True, but it definitely seems like they're only fixing the low-hanging fruit. They're never going to fix the insane type system.
    - marcus_holmes 11y ago
      I know I'm a nutter, but I like the type system :) I like that there's "==" and "===", because that's exactly how I think. It fits my use case of "is this the same value as that?" or "is this really equal to that?" exactly. I like that types are fluid, flexible and never get in my way. But there's a religious war here that I think got won by the static type side, so I'm not going there again ;)
Tehnix 11y ago
Because working with things like GTK and QT is horrible compared to working with HTML/JS/CSS, for anything other than trivial things. That said, it'd be cool to have native code generation from this though.
- discreteevent 11y ago
  Have you used Qt and QML? For me it's much more productive and straightforward than html/js/css. Delarative legible ui with built in dataflow/reactive properties. Performs straight out of the box without having figure out how to work with the mechanisms buried in this hugely complex and opaque machine called a browser. In fact its a relief to work with it. Could you say where you think its so 'horrible'.
  - jnbiche 11y ago
    Agreed. Assuming they took this to its full potential, and created native, cross-platform, desktop widgets for React, what they'd end up with would look startingly similar to QML, except without the easy C++ interop. I'm a fan of React, but I have no desire to use it outside of the web, and maybe mobile (still on the fence there). For desktop, we have QT, which is truly an awesome native widget toolkit, with many thousands of man-years work in it, excellent cross-platform desktop coverage, along with pretty good accessibility standards.
  - makecheck 11y ago
    Although I've never had to start from scratch, the Qt projects I've maintained have been prone to crashing. Maybe the Qt apps have legitimate bugs but the fact is that native environments like Objective-C, and most likely this JavaScript environment, would both handle those issues very cleanly compared to Qt.
  - lobster_johnson 11y ago
    Do you know of any modern OS X apps written with Qt that have a native look and feel that, in particular, take advantage of Core Animation for UI transitions? All the Qt apps I have touched (Google Earth comes to mind) have neither looked nor felt native on OS X, much like Swing and SWT apps don't at all feel native. Whereas all the best apps are written in native Cocoa.
moretti 11y ago
You're probably not familiar with Atwood's Law[0]: > Any application that can be written in JavaScript, will eventually be written in JavaScript [0]: http://blog.codinghorror.com/the-principle-of-least-power/ http://blog.codinghorror.com/the-principle-of-least-power/

dgreensp 11y ago

The widgets aren't native, which would be about a thousand times cooler. They are fakes made out of CSS.

douglasheriot 11y ago
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#issuecomment-147086155 https://github.com/facebook/react-native/issues/247#issuecom... I have never actually tried it, but this one is real native controls. It’s on my TODO list…
- voltagex_ 11y ago
  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 11y ago
    Is that even necessary for windows? Doesn't windows already have this abstraction layer with windows.js?
    - voltagex_ 11y ago
      Good point - https://github.com/winjs/react-winjs https://github.com/winjs/react-winjs
- Void_ 11y ago
  This is great stuff! Wonder if once Swift is open-sourced we'll see a library like that in Swift. Imagine writing React code in Swift and rebuilding that for Windows!

bengotow 11y ago

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

eloisant 11y ago
Either you go with a non-native look, or you use native components. Mimicking native with CSS is only getting you to the uncanny valley of UX.
pjc50 11y ago
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 11y ago
  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 11y ago
    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.
- mhw 11y ago

protomyth 11y ago

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

trymas 11y ago
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 11y ago
  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 11y ago

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.

jlebrech 11y ago

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.

jasonjei 11y ago

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.

shoover 11y ago

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

andrewrothman 11y ago

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.