React Desktop – React UI Components for OS X El Capitan and Windows 10
github.com
github.com
https://github.com/ptmt/react-native-desktop
Currently just "hacking weekend" level maturity. 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…
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!
Why does this exist? Is creating desktop programs out of HTML code really a good idea?
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)
Background: I'm the lead dev/UX on LXQt, a linux desktop environment (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.
QML appears to offer the best of both worlds - I don't understand why it isn't more popular?
I'm not advocating html-based desktop apps, but using native UI frameworks is not as straightforward as you make it sound and they are certainly not cross-platform. I just wish there was an easier way for developers to incorporate system behaviors into their apps. Even if it wasn't a cross-platform solution, being able to "opt-in" to these behaviors without having to adapt your whole app to a wonky framework would benefit everyone. I'd rather add native behavior to a custom opengl text input than having to deal with the web platform.
But I probably couldn't. And you might complain about "noobs," but the barrier to entry is probably one of the main reasons we get so much crappy software nowadays. On point: I just installed the latest Qt and opened a few QML example projects. The result? QML's text input won't recognize cmd-delete.
Guess that barrier is a little too high.
As for pitfalls, most languages also have pitfalls. The "this" convention in JS is downright weird, but I've actually used it to my advantage (admittedly only once). The only other thing I can really think of that is actively hostile is automatic coersion of various types.
The core of JS is actually quite small and elegant, though (IMHO). I really like the prototypical inheritance. Once you understand how it works, it is very flexible and easy to work with. It lacks a lot of explicit facilities, but it is usually very easy to implement them if you want.
The main thing JS lacks is decent standard library. The recent Ecma script standards are moving in the right direction, but it is slow progress (understandably).
I've worked professionally with FORTH, C, C++, Perl, C#, Java, Ruby, Go and probably a few more which I'm forgetting. When I'm programming in Coffeescript, I never feel like I'm missing out. When I'm programming in JS, I'm frustrated by all the parens and "function"s that I have to type, but otherwise quite content. I like types, though, so will probably checkout typescript or something similar one day.
>> "riddled with complex JS"
If you pick a technology by the aesthetics of the language, I'm pretty sure you'll make a bad decision no matter what. Not you like in you, but in principle. :)
The code is clean if you write it well. Ugly code comes in all parentheses positions.
What I meant:
> "JS is an ugly language, with way too many pitfalls."
IMHO it's ugly from 'within', just look at the JS truth table [1] and video I linked with the quote [2]. I just feel that I have no control of what I am doing with JS.
<rant>
It's quite a paradox, that new people to programming, can get start quick with JS, though are not repelled how easily you can shoot yourself in the foot with it. But maybe they just do not catch the errors..
</rant>
[1] https://dorey.github.io/JavaScript-Equality-Table/ [2] https://www.youtube.com/watch?v=20BySC_6HyY
> Moral of the story: > > Always use 3 equals unless you have a good reason to use 2.
Tools like ESLint make it easy to enforce this (and to only allow == in the few cases where those good reasons apply).
I understand your frustration with js, but let's not pretend it's objectively worse to learn to deal with its pitfalls instead of other languages'.
Go and Node seem to be heading back to static linking.
Meanwhile Australia is getting left further and further behind. Our internet speed isn't increasing, yet webpages, games, movies and applications are getting bigger and bigger. Help!
_ I used it on Windows, OSX and several Linux distros and really like the fact that the experience is the same everywhere.
_ No notable performance issues even with modest configs. It's been always usable in my experience.
_ Install size is on par with its competitors
_ Never noticed battery draining but I'll probably keep an eye out for this one now that you made me think about it :) I really doubt that a normal user would notice a difference.
Concerning code maintenance, it would be interesting to hear the opinion of someone who worked on such a complex desktop hybrid app.
This is my completely biased and highly selective history of events ;)
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!
True, but it definitely seems like they're only fixing the low-hanging fruit. They're never going to fix the insane 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 ;)
> Any application that can be written in JavaScript, will eventually be written in JavaScript
[0]: http://blog.codinghorror.com/the-principle-of-least-power/
That said, it'd be cool to have native code generation from this though.
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.
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.
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.
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
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.
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.
Mimicking native with CSS is only getting you to the uncanny valley of UX.
Anyway, I would love to see these come in native form like reactive-native.
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.
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.
sometimes you just want an app to look decent by default not unique.