[com2kid]

So much fighting over how best to draw the UI that will launch various instances of the Chrome engine.

Want to know why everything is written in Electron or as a web app? Because literally every desktop platform over the last decade has decided to play design and engineering games instead of just make a really solid stable base to write apps on top of.

[kelnos]

I don't think that's really the reason for Electron's popularity. While GTK and Qt are cross-platform, my (limited, to be fair) experience with building for multiple platforms was that it was a huge pain in the ass, and Windows and macOS platform integration often felt clunky and out of place.

The big draw for Electron is that we have way way way more web developers out there these days than native-code desktop UI developers, so it's easy to leverage those people and get results fairly quickly, even if the resulting apps don't really conform to any desktop's standard look-and-feel (which I guess avoids the uncanny valley effect of cross-platform toolkits that try to be native, but fail in subtle and not-so-subtle ways). People can even just (sorta) repackage their existing webapp, and end up with more or less a single code base for all desktop platforms + web.

I do agree with you that most of the desktop platforms are pretty annoying to develop for if you want a solid, stable base, but I don't think that's the prevailing reason for Electron's uptake.

[charcircuit]

My experience of building an electron application for multiple platforms was similarly painful. When you are writing native specific code, you have to write native specific code regardless of if you use Qt or electron. Something has to interface with the operating system. Either you use someone else's code that is cross platform, or you write your own cross platform code.

[bayesian_horse]

It's way easier to develop and customize a user interface with the building blocks found in a browser, rather than doing the same with Gtk or QT. To the extent that those have gotten easier, they are emulating html+js+css.

[lapser]

I don't know about Qt but at least GTK's docs are terribly bad. Even more so when you want to develop using a language that isn't C.

[alxlaz]

I'm not sure how they've kept up, as I haven't used Qt in some time, but back in the 4.x days the documentation was absolutely stellar. Extremely thorough and almost every non-trivial feature came with code samples. I couldn't for the life of me understand why anyone was using GTK at the time.

[bayesian_horse]

My point is not about lack of usability or documentation. Rather that the nature of HTML+CSS+JS lets you do things you can't do as easily in either GTK or QT. In the latter, yes you can easily achieve a certain kind of UI, but not deviate from it, and even formatting/displaying a significant amount of information that doesn't fit into one of the classic widgets can be a bit of a pain.

[alxlaz]

That depends a lot on what you're used to. It takes me far less time to implement a custom widget that can format/display a significant amount of information that doesn't fit into one of the classic widgets than it takes me to fiddle with CSS to get it to center things correctly ¯\_(ツ)_/¯.

[ensiferum]

Qt also has QML which allows you to do things similar to what you would have with the combination of HTML,CSS and JS

[kaba0]

Have you tried creating a custom date picker in those? I am fairly sure web tech would come out last with the infinite amount of divs here and there.

[skeletal88]

Qt docs are excellent, one of the best I have used. They have high level overviews, examples and everything you ever want

[smegsicle]

a big part of why browser engines are so unwieldy is the implied compatibility with every website ever, right?

but the "way way more web developers" you mention are not, at least in the context of electron apps, interested in that feature except tangentially..

so while everyone knows a full web-ready browser engine is impractical to design from scratch, maybe a simplified engine that supports a conservative subset of best-practices web-style design is in order?

[jitl]

There are a bunch of “small subset of HTML” UI toolkits already. The first that comes to mind is Sciter: https://sciter.com/ which bundles QuickJS interpreter, built in support for React-like syntax, and a HTML/CSS like markup and rendering environment. You’ll see on the homepage how it’s used in many products you might have heard of.

The issue here is re-use - Sciter is small and very fast, but won’t run an arbitrary existing web app that targets Chrome. Maybe you could argue for a middler-ground, add more HTML features to Sciter until it can run “most” things… but you’ll end up back to having the whole banana.

[wffurr]

That's a really interesting idea, but in practice you might find that the "conservative sunset" ends up being different for every toolkit and developer.

Maybe something a bit opinionated, like a React Native-only runtime, could fit the bill here.

Or in a sense, is this what Flutter is?

[exfascist]

TCL/TK is still both easier than electron and will produce nicer apps. I think the Electron thing is the result of the popularity of web development more than native API failures (other than mobile development being an incredible pain in the ass.)

[morsch]

And then the calculator app, which is native, is wrapped up in some sort of isolating container that makes it take as long to start up as an electron app.

[schipplock]

I sometimes, by accident, launched LibreOffice Calc. It launched faster than the calculator app :). I believe they changed that. The calculator app isn't shipped in a snap package anymore.

[sph]

You're using the wrong isolating container ;) There's only one that is quite slow at startup, the other isn't.

[nix23]

Just imagine you need a container for the calculator.....

[rollcat]

OpenBSD went that route, and when they introduced pledge(2) and later unveil(2), they've applied these to every single program in the base system (over the course of a single release cycle!).

There's absolutely zero reason for bc(1) to accept network connections, or for grep(1) to execve(2) into arbitrary programs. But both of these programs need to process and interpret arbitrary input, which makes them potential targets for exploits.

You don't technically "need" security, just like you don't "need" seatbelts... until you actually are in an accident.

https://man.openbsd.org/pledge; https://man.openbsd.org/unveil

[nix23]

you really compare something like pledge and unveil with flatpack and snap's? Completely different goal's...

[rollcat]

I don't think the security goals are that different, but you've asked why would I want to sandbox a calculator. Well - why would I not want that?

[anthk]

OpenBSD's pledge and unveil are intrinsic while Linux crappy sandbox it's extrinsic...

[sph]

Just imagine getting pwned by malware bundled in a calculator...

[nix23]

What is the connection here? Why would you install the calculator not coming from your distribution?

[sph]

Because there is a push for software developers to be able to package directly for end users. Without devolving into the usual flame war of whether it's a good idea or not, once you install any piece of software you incur some security risks. It's not like distro maintainers are a 100% guarantee there won't be a backdoor in the binary, and compiling software from source doesn't free you from risks either, unless you code-review everything you install.

My point is, containerisation on Linux isn't necessarily slow—in fact it's unnoticeable if implemented correctly—and I prefer to default to having a decent amount of security by containerising as much software as I can, whatever the origin. Including, and especially software like the calculator, since it should not be able to do anything more than show a GUI and add numbers together.

[wander_homer]

In my particular case: I don't want to wait months or even years for updates to arrive in my distribution. With the Flatpak version I get updates usually on the same day they are published, since the Flatpak is also maintained by the calculator developers, and I also get a calculator which can't access my ssh keys or the internet, due to sandboxing. And in case of any breakage, I can also quickly roll back to the last version.

Without flatpak I'd need to use some rolling release distribution, where not just a few applications get updated quickly, but also the rest of the system, which I'm not interested in.

[ducktective]

username checks out ;)

[supramouse]

you mean snap packages? I think the calculator is written in vala was pretty performant when I've used it the past

[imtringued]

I once installed Linux with Gnome 3 on a USB stick and used that as my primary operating system for six months. My number one application was a web browser. I don't think I ever bothered installing anything other than code editors, language runtimes/compilers and steam. Gnome works just fine.

The only annoyance was the breakage that Wayland introduced in 2016. Suddenly you couldn't screen capture the whole screen anymore. It's kinda the same issue as switching from python 2 to 3 but the difference here is that it is a major upgrade that is worth the effort. The reasons why python 3 isn't backwards compatible are incredibly petty for the most part. However, firefox has received Wayland support for screensharing and some people developed a plugin for OBS. Wayland works just fine now too.

[skeletal88]

Qt has stayed the same and KDE has been excellent, this is a probleem with GTK and Gnome based desktops

[Bancakes]

Rhetorical question? It's cheap and quick. Can be outsourced to the lowest lifeform that legitimately describes itself as a programmer.