[tracker1]

Create a cross-platform UI toolkit that is easy to use, has all the accessibility features of the browser built in, and has a UI control toolkit as rich as say mui.com ... Support SVG as well as stylized layout similar to html+css.

It's not an easy task, and it's not something that anyone has really done. There are plenty of single platform examples, and Flutter is about as close as you can get in terms of cross platform.

There are also alternatives that can use the engine of an installed OS browser. Tauri is a decent example for Rust. Also, Electron isn't to blame for the issues with Teams. VS Code pretty much proves you can create a relatively responsive application in a browser interface.

[CyberDildonics]

it's not something that anyone has really done

It has been done many times.

Not only that, if you want to use a web page for a GUI, then do it by making a local web server back end and just use the web browser.

This idea that electron is somehow the only way to get cross platform GUIs is some sort of bizarre twilight zone where a bunch of people who only know javascript ignore that last three decades of software.

[tracker1]

Okay, care to name some of these many cross-platform, easy to use UI toolkits that include the accessibility that the browser has?

Also, I never said Electron was the only way... I specifically mentioned Tauri in my comment as an example of a browser renderer. And it doesn't need to use a local web server either.

[CyberDildonics]

Qt, FLTK, WxWidgets

And it doesn't need to use a local web server either.

Shipping an entire browser so someone can pop up a single window is not a positive. Again, if you want html as your interface, use html and let people use their own browser so that the entire program is 400KB instead of 400 MB

[tracker1]

Qt, open-source only or expensive licensing. C++ only bindings... wouldn't call it "easy to use"

FLTK, no accessibility features

WxWidgets, really limited theming, not even close to html+css. Cross platform compatibility is hit and miss, usually requiring a lot of one-off platform corrections.

Also, as I said, you don't need to ship the entire browser... not once, but twice... try reading slower.

[CyberDildonics]

Qt, open-source only or expensive licensing

It's LGPL, lots of programs use it like qTorrent, VLC and much more. You can make up criticisms but it has been a backbone of GUIs for decades.

FLTK, no accessibility features

What exactly do you need and do you need it for every GUI you make? If you want a web page, use a web page.

WxWidgets, really limited theming,

Suddenly theming is your deal breaker.

not even close to html+css

Thankfully, because that is often not a good way to make a GUI.

as I said, you don't need to ship the entire browser...

No, you said "it doesn't need to use a local web server either." Also 'entire web browser or not' electron programs end up being hundreds of megabytes for a simple window use hundreds of megabytes of RAM.

The bottom line here is not that electron is necessary. It is that you want to use javascript even though your users will hate it.

[mwcampbell]

> What exactly do you need and do you need it for every GUI you make?

A GUI toolkit that has no support for screen readers, or other assistive technologies that require accessibility APIs, should be a non-starter for most applications IMO. We need more options that meet that criterion without going all the way to a web page.

[Narishma]

Qt has been LGPL for ages. You can use it for free just fine in proprietary apps, as long as you don't modify Qt itself.

[tracker1]

Sorry, I had forgotten.

[MagicMoonlight]

We need linux to add electron or an equivalent directly to the OS. Cut out the browser and the bullshit. Allow meme developers to write in meme languages but still get good performance.

[qball]

>We need linux to add electron or an equivalent directly to the OS.

Almost like some kind of... web OS?

To think we almost had it, but Palm made some bad decisions back in 2009 and the dream of app-as-browser + Node.JS + consistent application styling and syscalls through a provided JS framework (Enyo) is, sadly, probably dead forever.

[tracker1]

Tauri, Photino, DeskGap and others have this.. it's not as consistent, and does vary by development language and platform. It has been relatively approachable however. Electron is of course a bit more popular and does bring a bit more to the mix.

[mike_hearn]

It's been done many times. HTML/DOM is a very primitive UI toolkit by any measure, even with extensions like mui.com beating it is not all that difficult. Are a few open source hackers going to manage - no. Can other companies manage it, yes. Especially accessibility really isn't as hard as people sometimes make out on this forum, and HTML isn't that good at it (because it lacks a lot of semantic information by default).

Consider the feature set of JavaFX when used in combination with the AtlantaFX theme/widget pack. It isn't well known, but is maintained and has an active open source community today.

- All the same controls as mui.com shows and more advanced ones too, like a rich text editor, a way more advanced table view, tree views, table tree views, etc.

- Media and video support.

- 3D scene graph support. HTML doesn't have this! If you want to toss some 3D meshes into your UI you have to dive into OpenGL programming.

- When using FXML, semantic markup (<TabView> etc)

- Straightforward layout management.

- A dialect of CSS2.something for styling, a TextFlow widget for styling and flowing rich text.

- Fully reactive properties and collections, Svelte style (or moreso).

- Icon fonts and SVG works.

- Sophisticated animations and timelines API.

And so on. It's also cross platform on desktop and mobile, and can run in a web browser (see https://jpro.one where the entire website is a javafx app), and can be accessed from many different languages.

Flutter is actually not quite as featureful in comparison, for example there's no WebView control or multi-window support on desktop, though Flutter has other advantages like the hot reload feature, better supported mobile story. The community is lovely too.

Then you have AppKit, which is also very feature rich.

So it's definitely a task that people have done. Many of these toolkits have features HTML doesn't even try to have. The main thing they lack is that, well, they aren't the web. People often find out about apps using hypertext and being able to have a single space for documents and apps is convenient. When you're not heavily reliant on low friction discovery though, or have alternatives like the app stores, then web-beating UI toolkits aren't that big of a lift in comparison.

> Electron isn't to blame for the issues with Teams. VS Code pretty much proves you can create a relatively responsive application in a browser interface

Electron is great, but most apps aren't VS Code. On my 2019 Intel MacBook Terminal.app starts in <1 second and WhatsApp starts in about 7 seconds. Electron is Chrome and Chrome's architecture is very specifically designed for being a web browser. The multi-process aspect of Chrome is for example not a huge help for Electron where the whole app is trusted anyway, though because HTML is so easy to write insecurely, sandboxing that part of it can still be helpful even with apps that don't display untrusted data. That yields a lot of overhead especially on Windows where processes are expensive.

[mwcampbell]

> Especially accessibility really isn't as hard as people sometimes make out on this forum

Just to make sure I'm not being one of those people: What AccessKit [1] has now, across Windows, macOS, and Linux, took roughly six person-months of work. We still need to support more widget types, especially list views, tables (closely related), and tree views, but we do already have text editing covered on Windows and macOS. Perhaps it helps that I'm an accessibility expert, especially on Windows. Anecdotally, it seems that implementing UIA from scratch is daunting for non-experts. But I guess in the big picture it's really not that hard.

[1]: https://github.com/AccessKit/accesskit

[tracker1]

The jpro.one website looks like it's rendering in the browser to me, are you sure the "standalone" and "cross-platform" options aren't also using a browser render surface?

I also said, "Flutter is about as close as you can get" regarding coming close to what I was referring to.

AppKit is NOT cross-platform. Beyond this, you have other means of embedding a browser-ui application without all of chrome included, see Tauri as one example.

[mike_hearn]

JPro runs the app server side, but the UI is rendered to a stream of commands that are then interpreted by the client in the browser to draw using divs, SVG and browser text. The result is that scrolling, text rendering, fills etc are done by the browser but all the actual app logic is server side. However event handling is all server side. If you run the same app on the desktop then it uses its own rendering stack.