React Desktop – React UI Components for OS X El Capitan and Windows 10 (opens in new tab)

We also almost managed to let blind and other impaired people use their computers via OS-level accessibility settings and features so now we need to throw all that away :)

+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 (original site does not load for whatever reason)

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

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

How about NodeJS bindings to a native desktop library of choice and a React.js backend to said library slipped in? They're decoupling the React API from the DOM, right?

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!

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

You clearly never programmed in Qt.

Did you mean the other way around?

Indeed. If cross-platform UI toolkits have shown us anything, it's that cross-platform UI toolkits are a bad idea.

You end up targeting the lowest common denominator, and a UI convention that works on Windows won't work on OS X, and vice versa.

One big error made by these toolkits is to base themselves on generic pixel-oriented layouts, instead of more abstract declarative ones. For example, if you need a dialog box with a small form and "OK" and "Cancel" buttons, you'd lay each component out on a form, and the layout would be identical on each platform. But this is such a common thing to do that it would be better to just declare what fields should be visible and what actions should be available, and have different, platform-specific, opinionated adapters that can wire together a native UI from this metadata (together with some platfomr-specific, CSS-like hinting: "on OS X this field needs to be at least 500px wide", etc.).

There's a wide selection of common idioms (dialog boxes, file dialogs, "wizards", preference panes, alerts, etc.) that fit into this scheme. The reason nobody did this is probably because developers overestimate how important it is to micromanage the UI, and don't think a system like this could support all variations that apps need. In truth, most UIs are quite pedestrian, and could benefit from being driven by a high-level description.

This is where React (and React Native) actually would help, because the component interface is separate from the component implementation. You can have a fairly high-level mostly-declarative description of your app that pulls in platform-specific versions of certain UI widgets where it makes sense to have one, but otherwise relies on generic ones.

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.

Came here to say this. For quite a few years in the bad old days around Y2K, people thought they would get a free cross-platform lunch by writing GUI applications in Java. This wasn't so bad in Xwindows, where every program did its own thing already, but it was terrible everywhere else. It took years for developers to get it, and there are probably still a few internal corporate applications using Java; I suspect the same will happen over the next 5-10 years with JS.

I think part of the reason that it might be different this time round is because using web technologies for desktop applications gives access to a much broader pool of UI/UX talent to help build something that works well and looks nice. Applications built with web technologies are already looking noticeably better than anything you get with a cross-platform UI toolkit without putting in a lot of effort.

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!

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?

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

I meant react-native and I couldn't update my comment when I noticed =/

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.