I was pretty active in the Raspberry Pi community around 4 years ago. Playing YouTube easily was a big problem and I tried making a lot of packages to solve this. I would also build Chromium to add widevine support for DRM content.

I also helped the Raspberry Pi Foundation around 4 years ago building and packaging their patched version of Chromium. What they essentially did was directly modify the Chromium source to add HW decoding specifically for the Pi with MMAL. Then, an extension would be auto installed to enable H264 on YouTube instead of VP9. This was released back when they launched the Pixel desktop.

This obviously had some problems, because the patch needed to be manually changed for every release of Chromium, which come pretty often. It couldn't also be easily upstreamed. Looking at it now, it seems it hasn't been updated in about a year, and I'm curious what the Foundation's roadmap for this is in the future, after having been out of the loop for so long.

FWIW Rockchip video decode/encode is not in a much better space.

There is the BSP, id est Rockchip's hacked together fork of the 4.4 kernel, which works. But on the mainline kernel h264 is just now getting added (maybe in 5.10), and userspace is still going to take some time to adapt.

I really hope that one day I can actually use the Pinebook Pro webcam for video chats without my CPU spinning while trying to encode (at least) one stream and decode N streams.

It also doesn't help that youtube has almost complete dropped h264 these days either, every new video I've seen has been vp9 and av1 only lately.

There must be h264 version available somehow for devices that don't do vp9/avi right?

> youtube has almost complete dropped h264 these days either

Only really true for VOD, and only really true for channels with 300k+ subs.

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.

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

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

Hello, as a long time proton-native follower, I was thrilled to see ~40 issues closed today for v2 when I woke up in the morning :-)

Congratulations for the v2 release!! I still couldn’t try out right away as I’m on macOS + node v13... but I’ll gonna install nvm as fast as I can :-) Thanks for your great work, it’s super useful for everybody.

I’m still kinda sad about the fate of libui— it was a great project to implement UIs, but Qt was a reasonable point, I think. I’m very looking forwards to the wxWidgets backend...for the true native widgets and the benefit it provides.

Thanks again for your great work on proton-native!!

This is incredible! Last semester I had my undergraduate software engineering class make Electron apps as group projects but I've been looking for alternatives. I'll try this out and let you know how it goes!

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

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

Any chance of supporting a library agnostic approach, such that developers could use vanilla JS or a framework of their choice?

The library is already built to be largely library agnostic. To add a new library, just add a file that translates my calls to the library calls. This is how I achieved both Qt and wxWidgets backends.

First off, well done, this looks like a good initiative and you've clearly worked hard on it!

My main question is about app size. Once one has fully built an app and is ready to distribute it to users... how does the file size compare to an Electron app?

The only thing that meaningfully contributes to the size of the app is the size of the GUI library libraries. It currently bundles both Mac and Windows, so you can build packages for each and remove the libraries you don't need. It should be around 50 MB maximum.

Thanks for the feedback! I'm not a Qt dev, so I wasn't aware of the practices. I'll revise it and remove the Qt code.

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.

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.

From my experience, you won't have more time than you do now, it's just a matter of what is a priority. Cool project.

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!

Impressive indeed :D

Very nice work man! Keep at it! =)

Currently no. That's one thing that I want to test sometime, but right now I'm busy improving it.

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!

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

Yeah I'll reword that. My bad.

Oh, I forgot – it's probably worth considering using examples written in the same programming language as well.

Here's your Hello World in real Qt code for reference:

    import QtQuick 2.7
    import QtQuick.Controls 2.2
    ApplicationWindow
    {
        title: "Example"
        Button {
            height: 300
            width: 300 
            x: 50
            y: 50 // not represented in the react code for some reason

            onClicked: console.log("Hello")
        }
    }

I guess just drop the comparison with Qt or other similar things. Just highlight that you can build native applications using React syntax. This alone is a good argument, no point on comparing, really. Only if you want to compare performance, etc.

The tech sounds fantastic but as you’re learning in this thread you should never criticize the competition. Framing your work as easier to read/write (or whatever) than Qt does nothing but pull yourself and the project into the mud. Just delete all references to Qt on the homepage and focus on what your project does and does well. You’ll find that approach does a much better job of communicating what you actually want to get across to people.

I think the 'easier to read' is unfair considering that you didn't use QML fur the Qt example. For me QML is easier to read than JSX (and quantitatively it is less verbose)

Is QML declarative?

As declarative as JSX

Menu {

  title:qsTr("File")

  MenuItem {

    text: qsTr("&Open")

    onTriggered: console.log("Open action triggered");

  }

}

Aren't all markup languages declarative by definition?

QML isn't only about markup, it also support property binding directly in the language - it's a full-fledged reactive environment.

Probably?

Because I forgot. I updated the page. My bad.

I don't really understand what you mean. To get data from a server, you can just use normal nodejs to send a http request. Usually you'll have it so that it works when a callback is triggered, such as a button press.

Looks like the answer is yes- I haven't done desktop developing, so I wasn't sure how it worked in these Javascript-wrapped-as-native apps.

It's not totally ready for production because the GUI library that I'm using is not totally polished. My part I would say is Beta, and the GUI library is versioned as alpha. For most tasks it will work fine. For more complex stuff you will obviously want something more robust.

With Windows, the .dll is compiled on npm install, and that works perfectly. Currently I don't think libui supports icons.

I chose libui because it is the only GUI library for JS that I could find. It is nice and fits well with React, but it does have some holes. The author is going to continue development soon, so some of the problems should be fixed in the future.

A MSI can be generated using an installer such as NSIS.

How is the memory usage compared to Electron?

Memory usage is a lot less. Electron has a full webbrowser running to display the page, which this uses Gtk on Linux or cocoa on Mac etc.

I'd love to see some benchmarks when you have a chance to update it.