Shameless plug: We're developing the Boden Framework [0] which kind of shares that vision.

I like the idea of a protocol and that is pretty much what Boden attempts to achieve in the end. Having said that, the more I work on this project the more I come to believe that, at a certain point (level of detail), attempts at the unification of real native UX on different platforms become virtually impossible. To achieve real native cross-platform UX, you need to embrace and take care of the different aspects, behaviors, and quirks of each platform. Boden attempts to make that as easy as possible (and without forcing you to write JS).

[0] https://www.boden.io

> To achieve real native cross-platform UX, you need to embrace and take care of the different aspects, behaviors, and quirks of each platform.

I 100% agree. My recent comment[0] mentions the same thing.

I'll look into Boden, sounds promising! With that said, I don't see any mention of desktop builds. Is that on Boden's roadmap? Would love to try it with Rust some time.

[0]: https://news.ycombinator.com/item?id=20275885

Yes, Desktop builds are on the roadmap. We don't have a fixed release date for those yet. An experimental macOS build is already available in the mainline repo.

>I don't want to be forced to write a JS app to get benefits here.

Although most major Electron apps are written in node, it's pretty easy to have a backend in another (compiled) language. You can simply use the subprocess module in node and build your own bridge, for example to a Go CLI that accepts events from electron and does whatever you want it to do. It's a workaround for sure, but the point is you could do it in a pretty stable way.

>After all, with ReactNative, it's basically a process RPC to a bunch of widgets

>Yet I can't help but wonder why so many people are focused on solving UI issues with very narrow solutions like Electron, ReactNative, ProtonNative and so forth

I've used React Native in the past and I'm working on a Flutter app now. The problem with RN is that every platform has its own unique widgets. It's neat that you have one codebase, but you still need to build a separate UI (at least for certain pages) for Android and iOS. It just doesn't look right otherwise.

Flutter gets away with this because it owns the drawing layer as well as the widget layer. I know that something drawn in Flutter is going to look exactly the same no matter where I run it. This means that widgets fail gracefully by default - in RN, things just straight up break or look weird. The worst that can happen in Flutter is that the user has to deal with an iOS picker on Android or vice versa.

Electron is more akin to Flutter than RN in this way. It controls the drawing/rendering because of Chromium. Slack on Mac looks exactly like Slack on Windows. That's more enticing than needing to build new UIs for every platform you want to support.

The only way to solve this is to basically invent another cross platform drawing layer. But why bother? HTML/CSS already exists. There's effort and tooling and docs and community and everything else you'd need for a successful framework. It's not worth the effort.

I think the best solution will be just embedding Electron at the OS layer, so apps don't have to bring along their own Chromium runtime. This way it runs closer to the metal, which should help alleviate RAM and storage concerns (these seem to be the only major concerns most people have with it).

> The only way to solve this is to basically invent another cross platform drawing layer. But why bother? HTML/CSS already exists. There's effort and tooling and docs and community and everything else you'd need for a successful framework. It's not worth the effort.

That's assuming we want that though. TBH I'm tired of web apps. I pay for a bunch of OSX native applications because it just feels better. I want to minimize friction for creating truly native apps. Not just for performance, but for visual consistency, OS features, etc.

I disagree that RN just breaks or looks weird. It does, yes, if you're trying to ignore platform widgets and make your own unicorn. I however am mainly speaking as a user. I want applications that feel like they are on my platform of choice, not some UI designers HTML page thrown into every OS.

You're right in cases where app devs are trying to make cross platform apps without actually making what I view as an application. They're just wanting to put their webpage onto the users computer. However I'm not wanting that. Luckily for them they already have that; It's Electron, and it works great for them. You're right we can minimize how awful Electron is, but I want native apps to feel good, feel native. I pay for apps that are more than just HTML.

Lastly, I think you sell RN's design short. Making two separate apps with RN involves a lot of code reuse. It's the same codebase, with two different binaries effectively. You can abstract a lot of logic to a unified layer, the majority duplication ends up being layout and widget choices. You're in the same language the entire time, using all your helper libraries and in general it feels identical (speaking from my experience, at least). Compare this to writing an Android app and a iOS app using their native languages. RN's developer overhead is miniscule by comparison. This gives users a native feel with a minimal amount of developer work.

I'm saying we need a RN-like solution to minimize effort for developers who desire to give users a native experience. I also greedily hope that in a world where this exists, HTML on my desktop won't be used as much.

> Flutter gets away with this because it owns the drawing layer as well as the widget layer. I know that something drawn in Flutter is going to look exactly the same no matter where I run it.

Isn't this pretty unfriendly to users? As an iOS user, I occasionally encounter apps written with Material guidelines in mind, and it's a bit jarring because they don't fit the guidelines of the device I'm using.

These are all great solutions for developers, but for consumers, it all kind of sucks to varying degrees.

> Isn't this pretty unfriendly to users? As an iOS user, I occasionally encounter apps written with Material guidelines in mind, and it's a bit jarring because they don't fit the guidelines of the device I'm using.

Personally I care a lot more about what app I'm using than what OS it's running on; I'd far rather have Slack look the same on my phone as it does on both my computers than have Slack on one computer look like apps on that computer but different from Slack on the other computer. Sometimes we forget that the OS exists to facilitate the apps, not the other way around.

> Sometimes we forget that the OS exists to facilitate the apps, not the other way around

For OS where the base operating system didn't offer much functionality to apps beyond the basic API for building controls and so on, this might be true.

For Apple's systems, especially macOS and iOS/iPadOS, this isn't quite true. On iOS, apps need to be built according to system conventions and standards in order to be able to take advantage of a lot of services that the OS provides (such as accessibility, automation, i10n).

When a macOS or iOS ignores system conventions, the result can range from completely unnoticeable, a slight inconvenience, or the app being next to unusable after the OS updates due to underlying features being changed without the developer having updated their (needless) custom code to account for it.

I notice this with the Sensibo app which follows Material design guidelines. It took me a long time to figure out how to edit a particular bit of information because the icons that the app used were not what I was expecting. On iOS, an editable table view should be accompanied by a button at the top right that says "Edit"; Sensibo instead provided a pencil icon. After I finished editing, I wasn't sure what to do — on iOS, I expect to see a "Done" or "OK" button where the Edit button was; instead, Sensibo required me to click on the pencil again even though it was greyed out and looked inactive.

When an app doesn't conform to the guidelines and I have a choice about whether or not to use that app, I'll generally prefer to find something else where I'm not expected to memorise how to use it.

Sometimes we forget that apps exist to facilitate getting tasks done, not forcing us to remember their deliberately-included inconsistencies compared to every other app on the system (including third party ones).

The problem with HTML/CSS is the meteoric levels of baggage they bring. If Electron was based around a super lightweight web engine that outright dropped support for anything older than HTML5, CSS3, and latest versions of JS it would be a dramatically better solution than it is now.

Better in what sense? It would still consume similar amounts of memory and the interface will look like web apps.

i really loved xul form mozilla. i build a lot of tiny apps with it, unfortunately it's no longer supported.

I also used it to build the kind of bridge you mention, it was for dynamically build gui for cli apps that did job processing (but it was a basic bridge with few functionality), and also some crud form from the database schema.