Live data from Hacker News

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

github.com

61–70 of 74 posts

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

#61
post #22

Earlier quoted context omitted.

+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 - 1…

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/ ). First one that comes to mind is accessibility and consistency of interactions. Apps that do not respect a…

But you don't get native UI with QML, and even with Qt it's not exactly "free."

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.

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

#62
post #54
post #51

Earlier quoted context omitted.

The link you provided to demonstrate the problem also gives you the solution: > 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 think we are getting into deep rant, though I want to say, that even I know this rule of JS (always use 3 equals, unless you know why you need 2) why not make double equal work as triple one?

If we were to rewrite history, that'd probably happen. Now count the number of languages that wouldn't reconsider something if we were able to..

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

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

#63
post #4

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

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

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?

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

#64
post #40

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 d…

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 an…

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.

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

#65
post #63

Earlier quoted context omitted.

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

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?

Yeah, react-dom is a separate package now.

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

#66
post #54
post #51

Earlier quoted context omitted.

The link you provided to demonstrate the problem also gives you the solution: > 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 think we are getting into deep rant, though I want to say, that even I know this rule of JS (always use 3 equals, unless you know why you need 2) why not make double equal work as triple one?

Because JS makes a point of being backwards compatible. Which is great, because some people out there are still using IE6.

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

#67
post #22

Earlier quoted context omitted.

+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 - 1…

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/ ). First one that comes to mind is accessibility and consistency of interactions. Apps that do not respect a…

Out of interest, can you point me to some Qt apps that look and feel completely native on OS X? (In particular, I'd like to see ones that feel modern, and take full advantage of Core Animation for UI transitions.)

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

#68
post #20

Earlier quoted context omitted.

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.

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

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.

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

#69
post #40

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 d…

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 an…

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.

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

#70

Earlier quoted context omitted.

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/ ). First one that comes to mind is accessibility and consistency of interactions. Apps that do not respect a…

Out of interest, can you point me to some Qt apps that look and feel completely native on OS X? (In particular, I'd like to see ones that feel modern, and take full advantage of Core Animation for UI transitions.)

I'm not too familiar with OSX but on the "native" side you have Transmission, and on the "completely custom" spectrum you have various game launchers (such as the Battle.net launcher).
Post reply on HN