
Proton Native – React Native for the desktop - zengid
https://proton-native.js.org/
======
WaltPurvis
>You can create a GUI using something like Qt, but the code to make it is
messy and unorganized.

It doesn't serve the author well to make this comparison. Saying it's less
messy to manage Proton/React source code files and the associated Node/JS/etc
infrastructure is an extremely dubious claim. One of the things I like best
about Qt is how non-messy Qt development is. Most everything (source files,
resources, etc.) lives in a well-organized project that is easily managed
using the Qt Creator IDE. The project structure is well-documented and
standardized.

It's also quite strange to compare React code to code using the Python binding
for Qt. That's not how most Qt apps are written. Most Qt apps these days use
QML, which is based on regular old JavaScript. Besides being a more accurate
representation of the way Qt development is normally done, it would also be
more interesting to compare one JavaScript-based framework to another.
(Although I recommend not making the comparison at all, since I don't believe
a fair comparison would favor Proton.)

~~~
jeena
And if we want to compare the syntax then this would be the QML equivalent:

    
    
      import QtQuick 2.9  
      import QtQuick.Controls 1.3  
      
      ApplicationWindow {  
        title: "Example"  
        visible: true  
        width: 300  
        height: 300
    
        Button {  
            text: "Button"  
            anchors.centerIn: parent  
            onClicked: console.log('Hello')  
        }  
      }

~~~
WaltPurvis
Thank you for posting an example. I was going to.

I may be biased, but to me the QML code is _much_ cleaner and clearer than
JSX.

~~~
space_fountain
Something I would be curious about is what happens when you try to change the
view. Like what if you want to make a counter. For me that was always the best
thing about react.

~~~
WaltPurvis
I'm not sure what you're asking, but the answer to what I _think_ you're
asking is that views change by way of bindings. They can also be changed
directly/procedurally, but I'll give an example of a binding.

(Think of an Item as a visual component, which can either be referred to by an
id or, as I've done here, referred to by its children as "parent".)

    
    
        Item {
            property int count: 1
    
            Button {
                height: 30; width: 80
                onClicked: parent.count++
            }
    
            Text {
                height: 20; width: 30
                text: parent.count
            }
        }
    

The text will update every time you click the button.

~~~
diroussel
Can you have higher order components? In react this is a function that returns
a component, often taking another component as a parameter.

What's nice about react is that the JSX syntax is just sugar that converts to
function calls.

~~~
jcelerier
> Can you have higher order components? In react this is a function that
> returns a component, often taking another component as a parameter.

The standard way to do this in QML is using the Loader object:
[http://doc.qt.io/qt-5/qml-qtqml-component.html](http://doc.qt.io/qt-5/qml-
qtqml-component.html)

You can also go full-eval of course: [http://doc.qt.io/qt-5/qtqml-javascript-
dynamicobjectcreation...](http://doc.qt.io/qt-5/qtqml-javascript-
dynamicobjectcreation.html)

------
zengid
This runs on libui-node, which is a binding to the libui library.

[https://github.com/parro-it/libui-node](https://github.com/parro-it/libui-
node)

[https://github.com/andlabs/libui](https://github.com/andlabs/libui)

~~~
flukus
Nice to see this project is still alive, it shows a lot of promise but
appeared abandoned for a while.

Have they got the data grid API's working yet?

~~~
parro-it
Hi, libui-node author here. I'm glad for your appreciation. The project is
well alive now, proton-native give me new motivational energy

The data grid has still problems on macOS unfortunately, but @andlabs is
working on it...

~~~
andlabs
No, the data grid has problems on Windows, as that code is being contributed
by someone else. I already have it on macOS and Linux, and have for years
now... Hopefully soon the Windows code will be merged in and we can keep
going.

~~~
parro-it
Ah yes, sorry @andlabs

~~~
andlabs
Also (for the benefit of the rest of HN) s/as/but/ — I had problems on
Windows, and someone is proposing a solution I just need to merge in once the
mega-PR that added it and a bunch of other things are split into more
manageable chunks that won't merge conflict as easily with what I am
independently doing to stabilize the build.

------
roberttod
Using Electron, you are rendering each window in Chrome, with some added OS
hooks. With Proton, you are using JavaScriptCore with hooks to the native
MacOS UIs and APIs.

Seems to me that this should use far fewer resources (especially memory) and
make it easier to make an App look more 'MacOS'y. Very eager to give it a go!

~~~
crashride
Isn't it running on Node?

~~~
roberttod
Thanks for pointing that out, I commented with a correction.

------
vintagedave
> You can create a GUI using something like Qt, but the code to make it is
> messy and unorganized. Having made a very large GUI myself, it gets very
> cumbersome to manage all of that.

Haven't we moved past writing UIs in code about twenty years ago? I see your
code samples, and all they look like is an improved version of the code UI
creation we had in OWL, MFC, and other UI frameworks on other platforms.

Starting about 1995 we had a better way: form designers that streamed objects
(note: not even auto-generated versions of code, which is not much better, but
object streaming.) Your UI is then designed and manipulated largely as a
graphical UI -- that's what it is -- and manually written code is reduced to
tweaks or state changes.

For example: Delphi (the prototype of all modern UI frameworks); C++Builder;
others. WPF may count although the generated text is ugly as :) - but it
carries the concept. A NIB file on macOS. You get the idea.

~~~
matchbok
NIBs in macOS/iOS are horrible for development and code review.

Using a UI to build UI is slow and clunky. There is no "moving past" it.
That's a bad way to develop stuff. We don't do it with HTML, do we? No.

~~~
RubenSandwich
Absolutely, most big mobile development teams I know do not use storyboards or
NIBs because they are not easily human reviewable. (A small change will
rearrange sections for seemlying no reason.)

~~~
matchbok
Same. I wonder how anyone uses them, honestly.

~~~
yoz-y
Oh come on. For most parts of an application Interface Builder is just fine.
Sure, for the stuff that actually matters the code is necessary because IB is
not turing complete anyways.

But to arrange the view controllers and segways + some static tables it is
mighty fine.

------
freedomben
It's pretty fascinating how tech tends to spread and influence. We spent years
trying to make the web more like traditional UI dev, and now we're making
traditional UI dev like web. I would never have believed this if you'd told me
about it in 2010.

~~~
whowouldathunk
> and now we're making traditional UI dev like web

It's been like that on Windows since 2006 with XAML. In fact, if you squint at
typical JSX, it looks like XAML.

Disclosure: I work at Microsoft.

~~~
mstade
Or MXML, which most certainly was influenced if not entirely derived from
XAML. Everything old is new again!

~~~
osteele
I’ll put in a plug for my former employer’s OpenLaszlo, introduced in 2002
(preview) and 2003 (version 1.0).

OpenLaszlo was most immediately inspired by HTML and (for data binding) XSLT.
I looked at Mozart for ideas on constraints, but we ended up rolling our own
design — mostly because constraints were never supposed to be a feature, so
they were designed and developed incrementally, in discretely releasable baby
steps.

Adobe did due diligence of the company sometime around 2002-2003 too, but that
deal fell through. An Adobe PM also signed up for our beta program, initially
under a pseudonym, but he eventually came clean. I’ve always been curious
whether Flex/MXML was related to either of those encounters.

[1]
[https://en.wikipedia.org/wiki/OpenLaszlo](https://en.wikipedia.org/wiki/OpenLaszlo)

[2] [https://ssl.weepee.org/lps-4.6.1/docs/developers/program-
dev...](https://ssl.weepee.org/lps-4.6.1/docs/developers/program-
development.html#program-development.data-binding)

~~~
underwater
Adam Wolff, former Chief Software Architect of Open Lazlo, is now the Director
of Product Infrastructure at Facebook, and oversees React and React Native.

~~~
osteele
Adam developed the initial runtime implementation of data binding and
constraints — with additional help from Max Carlson, and, later, P. Tucker
Withington and Henry Minsky — while I did the compiler work and language
design[1][2]. Adam et al wrote the runtime constraint resolution mechanism,
which initially had an API for the procedural creation of constraint graphs. I
was trying to make constraints and data binding look like JavaScript
expressions, that were automagically recomputed when a subexpression value
changed, by extracting dependency graphs from the source and packaging them
for runtime use. (All this on the Flash 5 bytecode interpreter, which was slow
as the dickens, even for the time — so there was a lot of optimization: in the
compiler, in the runtime, and in the interstices. Although nothing like we did
later for [3].)

This was the bottom of a slippery slope, where the designers and developers
_using_ the platform were exploring the kinds of applications it was possible
to write (single-page web applications were relatively new in the early oughts
— except for some pioneering Explorer-only DHTML work by Microsoft, which we
should have looked at but didn’t — and we were all making up interaction
patterns and software design idioms as we went along), and we were adding the
platform features to enable some capabilities and golf others.

For a while Adam ran Laszlo’s Professional Services. He succeeded me as CSA
when I left Laszlo.

It wasn’t Flex/MXML or XAML that killed Laszlo/OpenLaszlo, it was IMO first-
gen dynamic frameworks such as Prototype and Scriptaculous, that could be
gradually integrated into a page without placing a big rewrite-your-app bet.
Also that we were about a year late in adding HTML as a second back end. (HTML
wasn’t sufficiently standardized or practical to use for cross-browser single-
page applications in 2001 when we started work on the Laszlo platform
implementation, but it was by 2005-6.) Or, closer to the root cause: sales and
strategy issues that made it difficult to keep investing much in the platform
once it was starting to get traction; the product feature omissions are how
those resource constraints played out.

[1]
[https://patents.google.com/patent/US20050039165A1/](https://patents.google.com/patent/US20050039165A1/)

[2]
[https://patents.google.com/patent/US20050038796A1/](https://patents.google.com/patent/US20050038796A1/)

[3]
[https://patents.google.com/patent/US20050114871A1/](https://patents.google.com/patent/US20050114871A1/)

------
ilurkedhere
The example in the getting started section comparing Python Qt isn't very
convincing.

~~~
freedomben
I tend to agree. I did years of Qt dev and I would never write something like
that, nor have I seen it written like that.

It works I suppose, but it's very clearly written to be an easy-to-compare
example, not a realist example. To really get an idea of what it would be like
to use proton native v. Qt I'd like to see a small but complete project.

~~~
rhodysurf
Not only that... but maybe its the fact that I use Qt everyday at work (C++)
or that I'm not really a front end web dev, but the Python example is easier
to grasp on first look.

------
mstade
> It is not only shorter, it is also easier to read and to edit, and can
> easily utilize the power of the state.

Easier to read and edit is obviously subjective, but _shorter_ is not and that
front page is just straight up lying. The Qt example is most definitely
shorter. What am I missing?

~~~
kusti8
Hey. I'm the author. It's hard to find a simple example that everyone
understands but can show capabilities. If you're used to Qt then you're going
to like Qt better, but I mainly developed this for people who want to use
React. You are obviously free to use whatever you want.

But if you have any suggestions let me know!

~~~
mstade
I have zero experience with Qt, but I'm pretty sure I can follow along with
the examples anyway. (I do have experience with React, JS, and Python.)

It seems to me you're making a syntax comparison and using _shorter_ as an
argument _for_ Proton Native, yet the example is obviously not shorter so it's
factually incorrect. My suggestion is you don't use _shorter_ as an argument.
Aside from being incorrect, it's probably not very useful since a few
characters here and there doesn't necessarily mean one is more or less
complicated than the other – which I presume is what you're _really_ trying to
convey.

I'd probably refrain from using syntax comparison (mostly a matter of
preference and familiarity anyway) and instead show why Proton Native is
obviously less complex than Qt (or other options, if that matters.)

~~~
kusti8
Yeah I'll reword that. My bad.

------
dilap
Sort of tangential, but does anyone know of a _good_ React Native app?
Everything I've tried would clearly have been a better product if they'd just
done native development. Like, you're sacrificing product quality for
development ease.

~~~
a13n
You might recognize a few on this list: [http://facebook.github.io/react-
native/showcase.html](http://facebook.github.io/react-native/showcase.html)

~~~
saagarjha
None of those are apps I particularly enjoy using or would want to use.

~~~
symlinkk
Facebook? Instagram? Airbnb? We're talking about some of the most popular apps
in the world. What exactly is your problem with them?

~~~
Benjammer
I mean, do you realize that most of the big names on that list have a hybrid
solution where they prove concepts, A/B test, and rapidly iterate-on/release
new features using React Native, and then they have a native dev team for each
platform that goes back and re-implements most of the core features natively?

~~~
prophesi
Discord is the most impressive one to me. They definitely didn't have those
resources when they wrote their iOS app[0].

The Android version is just RxJava, iirc, because of some performance issues
they couldn't get around.

[0] [https://blog.discordapp.com/using-react-native-one-year-
late...](https://blog.discordapp.com/using-react-native-one-year-
later-91fd5e949933?gi=9cca25724807)

~~~
realusername
At that time when they released, the React Native Android was probably still
in a kind of beta state.

~~~
orbitur
RN Android still feels like beta.

~~~
tazard
How so? I run into the occasional hiccup an iOS and Android, but overall both
have been pretty smooth for me.

------
Etheryte
Without having used Proton Native myself, comparing your product to React
Native is not something you would want to do, honestly. React Native has
insanely huge growing pains, still going, even though it's been out since
2015. The last time I checked there was still no reasonable, scalable way to
do complex navigation on the platform. Most third-party components are
unusable six months in due to API changes. The list goes on. On the tin, React
Native, and in the same way, Proton Native, look very promising, but for
anything that's more complex than a demo application, my personal
recommendation is to steer far away. You're free to disagree, of course, but
having extensively tried to use the "write once run everywhere", my personal
experience is that it always ends up more along the lines of "write once, then
patch all the bugs separately on all the platforms".

~~~
RubenSandwich
I'm sorry but this seems overstated. There is already two highly competitive
navigation libraries:

[https://github.com/wix/react-native-navigation](https://github.com/wix/react-
native-navigation)

[https://reactnavigation.org](https://reactnavigation.org)

Edit: Replaced the word FUD with overstated, to not seem like I'm attacking
the author personally.

~~~
Etheryte
As I stated above, it's my personal opinion on the matter. I've used both of
those libraries in a medium-sized project and they don't work well. Simply
linking to libraries and saying they exist is hardly making a point.

~~~
RubenSandwich
I have used both of those navigation libraries in medium sized projects as
well. This is the section that struck me as overstated:

"The last time I checked there was still no reasonable, scalable way to do
complex navigation on the platform. Most third-party components are unusable
six months in due to API changes."

The links are counterpoints to the complex navigation issue. Showing that
libraries exist and can handle complex navigation. If you want to argue that
they are going over rapid change, which is true, then that is another thing.
But I'm gonna disagree with the blanket statement of "there was still no
reasonable, scalable way to do complex navigation on the platform" as
overstated.

As for the second point. I assume what you mean by 'third-party components',
is actually third-party native modules. In which I agree the API for them
doesn't seem to have stabilized yet so there is a lot of churn in native
modules. But a lot of third-party components I have seen continue to work in
newer versions of React Native.

------
BillinghamJ
I don't totally understand why this exists to be honest. React Native for
desktop is... React Native. It isn't mobile-specific in any way. In fact, it
is already possible to make Windows (UWP) and macOS apps with it.

If this project was about formalising proper stable support for Windows and
macOS within React Native, that would totally make sense. But it seems more
like it's trying to be an alternative, under a different name, different
branding, etc.

Surely it's better to remain as one widely compatible project?

~~~
jscholes
> React Native for desktop is... React Native. It isn't mobile-specific in any
> way. In fact, it is already possible to make Windows (UWP) and macOS apps
> with it.

And what if you want to make a non-UWP app for accessibility or other reasons?
Just your standard, straight forward Win32 GUI. Bringing the power of React to
that space will still appeal to many.

~~~
com2kid
React-Native for WPF already exists. Same repro as React Native for UWP.

~~~
jscholes
> React-Native for WPF already exists.

WPF and Win32 are not the same thing.

~~~
com2kid
Your original comment indicated non-UWP or Win32.

------
WorldMaker
Other than Linux support, does this offer anything more than React Native's
existing macOS and Windows forks/bindings?

~~~
kusti8
I've tried to improve documentation and make it ready for use. Also all the
forks is are platform specific while this is cross platform.

------
mmgutz
The advantage of this over Qt is the licensing. React is an advantage if you
are familiar with it over QML.

One thing to note, the naming convention of props differs from React Native
which is a bummer. [https://github.com/kusti8/proton-
native/issues/9](https://github.com/kusti8/proton-native/issues/9)

IIRC the project is a light mapping from libui-node project to React.

~~~
latortuga
The issue you linked to seems to indicate that they are going to transition to
React-idiomatic naming.

------
tshannon
Hm. Proton's are heavier that electrons...

~~~
cpburns2009
Electron should have been named Lead or maybe Uranium.

BTW: It should be "protons" without an apostrophe.

------
carloscr
I like react on the web, but sometimes I find it cumbersome all that sending
props down and passing functions to update global state. When I'm almost done
with an app and then I decide that it will be nicer to open a modal window to
ask the user 2 or 3 parameters is when I miss the most the desktop paradigm of
just call a method that opens a small window and returns an object with the
collected data

~~~
a13n
I have a ModalContainer that passes down this.context.openModal.

[https://reactjs.org/docs/context.html](https://reactjs.org/docs/context.html)

------
djhworld
The website and github README could do with a lot more examples/screenshots

------
c-smile
Am I the only one who think that this:

    
    
        class Example extends Component {
          render() {
            return (
              <App>
                <Window title="Example" size={{w: 300, h: 300}} menuBar={false}>
                  <Button stretchy={false} onClick={() => console.log('Hello')}>
                    Button
                  </Button>
                </Window>
              </App>
            );
          }
        }
    
        render(<Example />);
    

is using too many artificial parsing layers ?

1) Like run JS, then there 2) parse JSX that will build virtual DOM, then 3)
interpret that vDOM to 4) create physical window.

Why not just

    
    
        let app = Application({params});
        let window = app.window({url:"content.xml",
                                 type: "frame" });

~~~
crooked-v
JSX _is_ JS. While there's technically 'parsing' involved, it's fundamentally
just syntactic sugar:

    
    
        import { createElement as e } from 'whatever'
    
        return e(App, {}, [
          e(Window, { title: 'Example', size: { w: 300, h: 300 }, menuBar: false }, [
            e(Button, { stretchy: false, onClick: () => console.log('Hello') }, [
              'Button'
            ])
          ])
        ])

~~~
c-smile
"JSX is JS"

It is not, [https://facebook.github.io/jsx/](https://facebook.github.io/jsx/)

It is handled by transpiler - one more parsing layer in loading sequence of
your application.

~~~
azerothian
sounds like you have your project configured wrong, transpiling should impact
compilation not the loading aspect of your application

------
ratsimihah
Is this created and maintained by a single developer (kusti8?), community, or
corporation?

~~~
kusti8
I'm one highschooler with not enough time. Ideally this would come from
someone who can maintain this full-time like a corporation, but so far no one
has done it.

~~~
zengid
Wow that's awesome; you really are still in highschool.. When I read your
gitHub profile where it said _" A sophmore at High Technology High School"_ I
thought you were being sarcastic!

~~~
ratsimihah
Impressive indeed :D

------
pdxandi
I'm curious how the documentation for this site was created. It resembles
Vue.js and I really like it; would love to use a similar template for my
projects.

~~~
wishinghand
The Vue team also just released VuePress, a static site generator based around
making documentation sites with Markdown.

------
lazerwalker
I wonder why this is called Proton Native and advertises itself as "using the
same syntax as React Native" instead of just _being_ React Native.

There's already plenty of prior art for RN-compatible projects that target
non-mobile devices (e.g. react-native-web, a half-dozen different AR and VR
projects).

------
bitwize
Neat. Will keep this in mind for future desktop projects, assuming it has legs
(i.e., long term maintenance).

------
jeremiep
I found about proton-native earlier this week! Sadly it doesn't have a
`<video>` element thats required for the project I'm building :(

------
tuananh
i've been quite impressed with Yue [0] and it's first real world demo app Wey
[1] - a Slack client. It's way more robust than any Electron apps i've used.

[0]: [https://github.com/yue/yue](https://github.com/yue/yue)

[1]: [https://github.com/yue/wey](https://github.com/yue/wey)

------
triptych
"On mobile, it used to be hard to build beatiful cross-platform apps" might
want to run a spell checker on your docs.

------
aurailious
What is this site written in? I've seen this style for a couple others. Is it
a github wrapper or something?

~~~
rhinoceraptor
Based on the page source, it looks like it's docsify:

[https://docsify.js.org](https://docsify.js.org)

~~~
aurailious
Oh weird, I was just looking at docsify this morning, that's why it must be so
familiar to me.

~~~
rohan1024
Synchronicity!

------
memonkey
This is super cool. Are there any demonstrations comparing performance between
electron and your app?

~~~
caspervonb
It seems to runs on "UI" from andlabs, which is a fairly lightweight C wrapper
around the the Windows, Cocoa and Gtk API's.

Sidenote as for why a UI library would wrap another UI wrapping library, Gtk
is what is considered "native" on Gnome based distros.

So weight-wise, it's basically comes at the cost of native node module which
is not bad compared to Electron's crazy IPC bridge back and forth
communication nonsense.

~~~
zengid
> _So weight-wise, it 's basically comes at the cost of native node module_

And now with NAPI [1] it should be easier than ever to make node modules!

[1]
[https://nodejs.org/api/n-api.html#n_api_n_api](https://nodejs.org/api/n-api.html#n_api_n_api)

~~~
parro-it
Some days ago I started a N-API version of the bindings:
[https://github.com/parro-it/libui-napi](https://github.com/parro-it/libui-
napi)

Is still really incomplete compared to libui-node, but just in case someone
wants to help

~~~
zengid
Is it a pretty simple re-write or something that requires a lot of c wizardry?

~~~
parro-it
Not a simple rewrite, but neither a task that require a C wizard... The
current version of libui-node implements C++ classes that wraps libui C
function. They are exposed directly to JS. This experiment implements N-API C
functions that wraps libui C function. Then, a set of JS classes wrap them,
offering the same public API as libui-node.

Currently, I implemented windows, boxes, and multiline entry. I have to
compare this experiment with the curent implementation in terms of erformance,
memory consuption etc. before to decide to continue with N-API or not.

~~~
parro-it
FYI, I just wrote the comparison I was speaking above:
[https://github.com/parro-it/libui-napi/issues/11](https://github.com/parro-
it/libui-napi/issues/11)

~~~
zengid
Pretty impressive results!

~~~
parro-it
Yes, N-API seems to be superior. And it's a particular good fit because libui
itself has a C API

------
tym0
Without Yoga and style attribute, it is a lot less interesting than react
native.

------
plaguuuuuu
Installation steps didn't work for me in Windows. Otherwise seems cool.

------
gremlinsinc
The website isn't very responsive, can't resize on hn reader app on Android
and still see text on right pane.

------
profalseidol

        );
      }
    }

------
a13n
React Native isn't just for iOS / Android, it also works for macOS and
Windows. React Native is React Native for the desktop.

~~~
notheguyouthink
What do you mean? Can you provide some links for building OSX apps with
ReactNative? Only iOS/Android are listed as targets on the documentation
website _(under getting started)_.

~~~
scottmf
[https://github.com/Microsoft/react-native-
windows](https://github.com/Microsoft/react-native-windows)

[https://github.com/ptmt/react-native-macos](https://github.com/ptmt/react-
native-macos)

~~~
notheguyouthink
But aren't those 3rd party react native for desktop implementations, just like
Proton Native? Does Proton Native differ in some meaningful way that OP was
referring to?

We're in a thread _about_ a React Native for desktop implementation.. saying
"React Native is React Native for Desktop" is confusing; hence my question.

