And to pre-empt any replies; your proposed solution must support Windows, Linux (X11 and Wayland), MacOS, iPhone, Android, Chromium and Firefox.
If you are a website, that’s easy, you are actually making the correct choice with Electron insofar that you want a browser.
If you’re doing an application not a webpage, then we’re walking W+L+Mac+Phones, that’s more tricky. I’m assuming for a second you want a usable UI (otherwise we’d be using Electron again :P ) so we’re talking two applications at least, one for mobile, one for desktop + maybe iPads.
And then it’s usually already too pricey to bother:
Web frontend devs are far cheaper than application developers.
Might as well just do a website, runs in everything. Only need to develop once.
Updating is immediate with a website, don’t have to do any deployment/upgrade/downgrade plans.
As Communism said, yeah I was ment a web application. No need to spend dev time working on a different version of your app if you can just reuse the web version.
WebAssembly is becoming more popular, which lets you run code written in languages other than JavaScript in a browser. It’s not possible to do everything yet, so you still need some JS code and a bridge between the WASM and JS, but it’s getting there. Emulators that run in the browser often use it.
I don’t think, there’s currently any plans to introduce a non-JS API for accessing the DOM. It would just take an insane amount of implementation work + documentation.
But frameworks can generate access code for you, so you don’t actually need to write any JS yourself. Rust is quite far ahead in this regard, thanks to the wasm-bindgen library.
I know the guy working on makepad is trying to solve this problem along with vr headsets, Apple tv, etc. It’s really painful because of dependency bloat messing with build times so he ended up rewriting a bunch of things 🤷♂️.
A pile of HTML + JS is the only cross platform GUI toolkit that’s practical to deploy.
I’m not really happy about it myself, but realistically there’s not any other option than just bundling a website into a wrapper.
And to pre-empt any replies; your proposed solution must support Windows, Linux (X11 and Wayland), MacOS, iPhone, Android, Chromium and Firefox.
Java, of course. /s
3 billion devices can’t be wrong!
Real talk; if Java didn’t have their head up their own arses, it would have been the real solution. But Oracle does what Oracle does.
Do not anthropomorphize Larry Ellison.
If you are a website, that’s easy, you are actually making the correct choice with Electron insofar that you want a browser.
If you’re doing an application not a webpage, then we’re walking W+L+Mac+Phones, that’s more tricky. I’m assuming for a second you want a usable UI (otherwise we’d be using Electron again :P ) so we’re talking two applications at least, one for mobile, one for desktop + maybe iPads.
And then it’s usually already too pricey to bother:
I think Flutter and Avalonia both tick all those boxes.
Does Avalonia support Wayland? Last time I checked it wasn’t complete yet.
Just checked, and unfortunately no, Wayland is still in preview.
Why is Firefox a ‘platform’? I’m assuming chromium is for chromeOS devices, but I don’t know of any device that just runs Firefox.
they probably meant web versions of the app that run both on chromium and gecko (firefox) browser engines
As Communism said, yeah I was ment a web application. No need to spend dev time working on a different version of your app if you can just reuse the web version.
deleted by creator
If you count browser engines, don’t forget Webkit.
Avalonia and Uno Platform if you are working with C#
Chromium and Firefox are web browsers, of course they only support HTML+JS. That’s what they were designed for.
WebAssembly is becoming more popular, which lets you run code written in languages other than JavaScript in a browser. It’s not possible to do everything yet, so you still need some JS code and a bridge between the WASM and JS, but it’s getting there. Emulators that run in the browser often use it.
I don’t think, there’s currently any plans to introduce a non-JS API for accessing the DOM. It would just take an insane amount of implementation work + documentation.
But frameworks can generate access code for you, so you don’t actually need to write any JS yourself. Rust is quite far ahead in this regard, thanks to the
wasm-bindgenlibrary.Raylib.
I know the guy working on makepad is trying to solve this problem along with vr headsets, Apple tv, etc. It’s really painful because of dependency bloat messing with build times so he ended up rewriting a bunch of things 🤷♂️.
qt?
JUCE is weirdly capable of non-audio related UIs and runs on all these platforms.