
Show HN: Proton Native V2 – Create Cross Platform Desktop Apps with React - kusti8
https://proton-native.js.org/#/v2_changes?
======
kusti8
Proton Native is a way to make cross-platform desktop apps with React, without
using Electron or any sort of web browser. Your React code gets translated
into Qt or wxWidgets API calls and runs directly on the machine.

After a long time, Proton Native V1 was starting to show it's age. So I ended
up making a complete rewrite that includes a lot of the most requested
features including flexbox, styling, hot reloading, and components with the
same API as React Native.

For those of you who value native components, I've also been working on an
experimental wxWidgets backend. There are only a few components, but I hope to
implement all the components of the Qt backend soon.

Let me know of any questions you have and thanks!

Previous discussion:
[https://news.ycombinator.com/item?id=16978901](https://news.ycombinator.com/item?id=16978901)

~~~
rvz
> ...requested features including flexbox, styling, hot reloading, and
> components with the same API as React Native.

That sounds like the way to go for a near 1:1 port of a cross-platform desktop
app for React-based apps. Also the move from libui to Qt for the UI backend
sounds interesting for this project to be used as a lightweight alternative to
Electron.

To be a true alternative to Electron one must provide a simple migration path
for existing Electron apps to Proton Native which would change everything in
cross-platform desktop app development.

~~~
bobwaycott
> _To be a true alternative to Electron one must provide a simple migration
> path for existing Electron apps to Proton Native which would change
> everything in cross-platform desktop app development._

That only makes it an increasingly attractive alternative for those who
already have an app built on Electron, and has little to do with whether
Proton is a “true alternative”. If it can viably permit developing an app
without Electron, it’s a true alternative. How easy it is to migrate an app
_from_ Electron is a separate matter.

------
Klonoar
> But those components are not native, meaning they are drawn by Qt instead of
> using the components provided by the OS.

In the case of macOS, this is no longer true - when Apple finally kicked
Carbon fully, Qt (IIRC, in 5.13 or something? 5.12 and prior used HIThemes,
which was... showing age) switched to rendering true AppKit behind the scenes.
There's a few custom controls where they render their own, if no AppKit
equivalent exists, but otherwise it's AppKit all the way down.

As someone who used to decry Qt as not native, I'll be the first to admit it's
fine now - if something looks "off" on macOS, it's probably moreso the
implementing the author doing something different than the underlying
framework.

~~~
ptx
Hm, are you sure about that? The documentation[1] for 5.14 still says it uses
HIThemes for drawing:

"As with Cocoa and Carbon, Qt provides widgets that look like those described
in the Human Interface Descriptions. Qt's widgets use HIThemes to implement
the look and feel. In other words, we use Apple's own APIs for doing the
rendering."

I guess the documentation could be outdated, but changing over from drawing
native-looking widgets to wrapping native widgets (like wxWidgets, SWT and
libui) sounds like a big and fundamental (and likely incompatible) change,
especially since Qt doesn't do this on other platforms. The release notes[2]
don't mention any rewrite of the Mac widget implementation.

[1] [https://doc.qt.io/qt-5/macos-issues.html](https://doc.qt.io/qt-5/macos-
issues.html)

[2]
[https://doc.qt.io/qt-5/qt5-intro.html](https://doc.qt.io/qt-5/qt5-intro.html)

~~~
torarnv
You're right that we no longer use HITheme to render the macOS style for Qt
Widgets, we use AppKit. But it's used to render into pixmaps, so we're not
actually wrapping native NSViews.

~~~
Klonoar
Ah! Learn something new every day.

My knowledge of that came from digging through the source code over the course
of the changes. Great to hear from someone more involved with it - and also,
great job on the approach, really glad to see it!

------
stevesimmons
> Currently, Proton Native is headed by one high school senior with not enough
> time.

Well done!

------
tomduncalf
Impressive project, especially for a high schooler! Congratulations on the
release of v2!

I have been very impressed with how well an existing React Native app can be
ported to Electron via react-native-web - I’ve done this for a couple of apps
with quite bespoke UIs and it worked almost seamlessly - the main work was
tweaking some stuff which used “onTouchX” events to also support mouse.

That said, Electron of course comes with an overhead that may not be suitable
for every project, so it’s great to see work like this going on!

------
mariopt
Similar to [https://github.com/gabrielbull/react-
desktop](https://github.com/gabrielbull/react-desktop) but with Linux support,
that's great.

I hope this gets more traction than the react-desktop project.

Super curious: How does an app built with Proton Native fares against an
Electron base app when ti comes to RAM and CPU?

------
newsbinator
Well done! I'd love to see something like this for VueJs.

------
satvikpendem
I've been tinkering with React Native and it looks like you can do something
quite similar to Proton Native here, while also targeting mobile platforms.
Here is how you can cover the gamut of platforms:

\- iOS and Android - React Native \- Web - React Native Web \- macOS - Apple's
Project Catalyst (run iPad apps on macOS) \- Windows - React Native Windows by
Microsoft \- Linux - none yet, you could use Electron but that's undesirable

Perhaps one could instead use Proton Native for desktop and React Native for
mobile, I wonder what the code sharing capabilities are for that.

~~~
kusti8
The reason I did not add a renderer to React Native and went with my own
renderer and reconciler was because mobile and desktop behave differently. The
goal of the project is to make sure you can copy almost all your code from
React Native, but not hinder usability. For example, you can define multiple
windows in Proton Native and I intend to add more props to that soon.

~~~
cztomsik
I'm doing something similar (also in my free time), how about joining our
forces?
[https://github.com/cztomsik/graffiti](https://github.com/cztomsik/graffiti)

------
RMPR
Amazing work, I am very thrilled to see such an evolution. I remember being
frustrated during the early stages of the project and now it works seamlessly,
looking forward to the wxwidgets backend, will drop one PR or two if I have
time between school and my own personal project. Kudos to you.

------
kochthesecond
This looks like incredible work. Great job.

------
1MachineElf
Interesting how this and Valve's Proton[0] are both solutions to different
cross-platform compatibility issues.

[0]
[https://github.com/ValveSoftware/Proton](https://github.com/ValveSoftware/Proton)

------
sansnomme
See also: [https://github.com/tauri-apps/tauri](https://github.com/tauri-
apps/tauri)

~~~
jbverschoor
That uses webviews.

------
LeoNatan25
If this is qt and wxWidgets, how is this "native"? It's as much "native" as
React "Native" is on either iOS or Android.

"Native" means native to the ecosystem it runs on. The gifs on that link show
nothing like that. The amount of work that would be required to make even a
small app that truly feels native on macOS or Windows would be enormous.

~~~
zozbot234
wxWidgets _is_ native - it's simply a thin, cross-platform wrapper on the
actual UI from the underlying system. No interface controls are reimplemented
unless strictly necessary.

~~~
LeoNatan25
Please read the rest of what I wrote.

Simply using native widgets is not enough. A "native" app has to feel like a
first class citizen in the ecosystem it is running. Achieving something like
this with Proton is a tall order.

~~~
zozbot234
> Achieving something like this with Proton is a tall order.

That's kinda obvious since Proton just uses wine under the hood. But
everything else about what you're running will be native. With wxwidgets it
will use true Windows widgets as reimplemented by wine.

~~~
zamadatix
I don't think they were referring to Proton the compatibility layer by Valve
rather the Proton Native this post is about.

