[injuly]

I feel that we would've had better tooling for writing performant GUI apps today if electron JS never took off.

It certainly has its place, and I laud the authors for their efforts, but seeing how every startup is using electron for their native applications, I have little hope for lean software.

At the end of the day, developers need to finance their projects. No other toolchain out there [1] is going to give you the flexibility, development speed, and freedom to develop beautiful looking desktop apps using the muscle memory you trained while writing webpages. Of course, you can write the same application in Qt, GLFW, whatever, but I don't think anyone will disagree that it's much slower to build and prototype responsive UIs with these tools.

[1] Wry and Tauri (https://tauri.app/) might be noteworthy, but I don't know how much of a difference they make, as the runtime is still JavaScript, HTML, and CSS.

[alwayslikethis]

I have another feeling that while what you say is likely true, in a world without Electron, we would have a lot less common software available on Linux with companies opting for native UI toolkits on Windows and Mac only. Qt, though better than electron, isn't that lean [1], and is available under only LGPL or an expensive commercial license. I also don't think Electron is entirely responsible for the slowness in many applications (Slack), but rather the bloated web design itself.

1. https://federicoterzi.com/blog/why-electron-is-a-necessary-e...

[guappa]

A lot less software on linux without electron?

I have been using linux for 20 years and I've yet to use one electron based software.

There is no problem with LGPL. From your link: " QT is free to use as long as you release your code as GPL"

That is false. It is free as long as you don't statically link qt, and you distribute your eventual changes to qt itself (which aren't needed in most cases).

Of course if we spread misinformation, we might draw different conclusions, which is why it is important to start from correct non-made-up premises.

[palata]

I agree, LGPL is totally fine.

But I also believe that most devs are not comfortable with linking/packaging/dependency management, and therefore don't really know how to handle LGPL (or to say it in a more politically correct manner: "don't have time to handle it properly"). Which is obviously a pity.

[rubymamis]

> most devs are not comfortable with linking/packaging/dependency management

Using `macdeployqt`, `windowsdeployqt` and `linuxdeployqt` takes care of that in mostly one click. I used to look at other open source apps workflows to figure it out. Now, others can look at my app's workflows for a complete packaging experience for Windows, Linux, and macOS[1]. Huge credit to contributors for my OSS app for implementing and perfecting it.

[1] https://github.com/nuttyartist/notes/tree/master/.github/wor...

[nottorp]

> At the end of the day, developers need to finance their projects. No other toolchain out there [1] is going to give you the flexibility, development speed, and freedom to develop beautiful looking desktop apps using the muscle memory you trained while writing webpages.

Why do you restrict yourself to only knowing how to write webpages?

> Of course, you can write the same application in Qt, GLFW, whatever, but I don't think anyone will disagree that it's much slower to build and prototype responsive UIs with these tools.

Maybe because you don't have the "muscle memory" to write Qt?

But since you mentioned Qt, one of the greatest hits to developing cross platform applications was the Nokia/Microsoft disaster.

Nokia bought Qt from Trolltech and made it LGPL, because their plan was to make money from the hardware not the software. Then they died, for reasons that have been commented on endlessly.

From the ashes of Nokia rose Digia or whatever it's called this week, a company that maintains Qt badly and thinks it's a good idea to threaten developers that download their LGPL product.

RIP Qt, RIP cross platform development.

[injuly]

Web programmers massively outnumber systems programmers. The market has been this way for quite some time now. I'm not a web programmer myself, at least not professionally, but it is far too easy to prototype with Electron/Electrino/Tauri/whatever than any other toolchain out there. I've used Xamarin, Qt, ImGui (not the same league, I know), and several other lower-level rendering libraries like SDL, SFML, raylib, GLFW. Nothing comes close to the vast expanse of features that CSS exposes with - often - a single attribute like `transform` or `object-fit`. Of course you can do it with any other language/framework, but it'll be dozens more lines of code. More time. This is assuming equal proficiency in both tech stacks.

JavaScript might be a disaster of a language, but it is faster to make a UI with CSS. I can totally see why startups pick web programming to ship desktop apps.

[rubymamis]

Qt is definitely not dead, rather alive and kicking. I've built my latest note-taking app[1] in Qt C++ and QML and it's been one of my best decisions. What the Qt Company need to focus on is hunting bugs (there are many of those) and reduce their license fee (at least for indie developers), it's just too expensive[2].

[1] https://www.get-plume.com/

[2] https://www.qt.io/pricing

[nottorp]

Have they given up on asking you 3 times if you are absolutely truely sure that you can comply with the license terms when you download the LGPL version?

With that attitude I can't recommend it to any entity that can't afford a full time legal team.

[guappa]

If you install via apt you get no prompt whatsoever.

[nottorp]

Heh, that's not the point. I was asking if they changed their attitude towards LGPL use or not.

[rubymamis]

What's wrong with LGPL use? From what I gather, if you don't link Qt statically and don't modify Qt's source code, and your app's license doesn't impose restrictions that conflict with the LGPL, you are good to go. Most apps would fall under these criteria.

[Gigachad]

> Why do you restrict yourself to only knowing how to write webpages?

That’s just how the market is. If you want to build your app with electron, you’ll find mountains of skilled developers everywhere. If you use QT, you’ll either have to pay an absolute fortune for the 10 people that know it, or accept hiring people that have never used it before.

[guappa]

It's not that hard to use.

Possibly easier to use a framework that includes a lot of things, rather than a language with no standard library that requires a soon-to-be-compromised dependency for every string function that QString already offers.

[nottorp]

I didn't ask why you hire, but why you knowingly restrict what you know.

[presentation]

We'd be in a better place if web APIs to access system resources didn't suck or weren't intentionally gimped by companies like Apple. Tauri seems like a way out, but can't say without having tried it.

The web is the best cross-platform environment we have as evidenced by the fact that developers flock to stuff like Electron at all, but then you end up needing to ship your own entire browser engine to achieve a reasonable level of control. If PWAs didn't threaten App Store business models we'd probably be in a better place RE web app distribution (just use the browser you're already using anyway).

Doesn't address the issue that web app development is flooded with bad choices and opinions that lead people to decide that the whole ecosystem is overcomplicated and bloated, but that's not an opinion I hold very dear as someone who feels pretty comfortable with web tech stacks and understand where they came from.

I do think the skill bar is too high right now, where most engineers are likely to do a bad job RE performance and security with what we have unfortunately. But I'm not confident your average engineer would do any better if it were a different ecosystem.

[guappa]

> The web is the best cross-platform environment we have as evidenced by the fact that developers flock to stuff like Electron at all

I suspect that web developers who only know web development flock to electron because they think it's easier than learning a new technology.

In my professional experience, it is perhaps easier for a web developer who only knows JS to get a prototype working, but when you want a nice application you end up having to re-implement a number of things that any regular widget toolkit would already offer. So on the long term I don't think it's cost efficient at all, but at that point you've already spent resources on your electron GUI so you keep going forever.

[stakhanov]

Lack of toolchain is one problem, although I think that there are alternative toolchains out there that are quite feature-rich and could definitely achieve feature-parity with the web ecosystem, if only there was enough interest in using them.

JavaFX, even though it's outdated, is quite up to the job of replacing most Electron-based UIs. Qt is definitely extremely powerful, but has the drawback of being tied into the C++ ecosystem which seems rather dated now. Even some hobbyist efforts are worth mentioning in this category: AvaloniaUI (in the C# ecosystem), HaxeUI & FeathersUI (both in the Haxe ecosystem and building on game engines).

I think, the bigger problem is sourcing developers. Web developers are comparatively cheap and abundant, so a commercial entity is always going to have trouble justifying hiring a comparatively expensive and difficult-to-find developer in the C#, ObjC/Swift, or Java ecosystem, when the job can also be accomplished by a web developer.

[brabel]

You know, I thought I was a fool for writing my apps in JavaFX... but after trying many other things, it seems it's up there with the best of the bunch.

My non-trivial app can be built with jlink to be a no-dependencies on JVM binary for all Operating Systems.... each of which sits at just 30MB... and when run, it needs around 60MB of RAM, which is a lot but I am yet to find a multiplatform UI toolkit that delivers much less than that... except for some toy frameworks which can't really be used for realworld apps.

[lawgimenez]

Look at Telegram, all their apps are written in native. Still one of the best, and still getting better every release.

[Gigachad]

Telegram is quite good but I honestly don’t notice it being any better than discord. Telegram isn’t exactly light either. It frequently sits at about 400mb memory usage.

[rubymamis]

Their Desktop app is written in Qt C++[1].

[1] https://github.com/telegramdesktop/tdesktop

[saagarjha]

Telegram's apps, at least on Apple platforms, are not what one typically would call "native" since they roll their own widgets for basically everything.

[geraldhh]

not to dispute the point (i am cherishing tg for their native apps on all plattforms) but not sure about what is getting better

[politelemon]

I'm more cynical in this. I think another bloated foundation would have taken off in another language. A lot of it comes down to accessibility to the masses. JavaScript for all of its horrors, and the self fulfilling cycle of its horrors, has a low barrier to entry. Think of anything else that's similarly easy and that's where I think effort and attention would have gone. So, if not js, I'm thinking probably in python.

[ogoffart]

With Slint (https://slint.dev) we're trying to make a lightweight toolkit that doesn't use HTML/CSS. And that you can program either from low level languages such as C++ or Rust. As well as with higher level language such as JavaScript, and we want to extend to python too. We hope to make it easy to develop desktop UI without using HTML.

[rubymamis]

Hi there! I would love to see a demo on the website that doesn't look intended for embedded/enterprise devices, maybe a simple Todo app? Best of luck with Slint!

[petabyt]

A while ago I compared the memory usage of Electron and Tauri/Webview, and Electron did same if not better in RAM usage.

[Aerbil313]

That’s normal and expected since they both use the same browser. Difference is when you have multiple apps open. All Tauri apps, along with your browser use the same libraries and binaries loaded into the memory. Meanwhile every electron app loads another browser into the memory.

Ofc I’m simplyfying a bit since if you use Firefox as your browser and Tauri uses Chromium that’s two browsers worth of memory usage, but still not 5 or 10.

[geraldhh]

> Meanwhile every electron app loads another browser into the memory.

this will become a problem once the systray clock becomes it's own (electron based) app

[MikusR]

Has somebody actually compared same applications running on electron vs tauri? With sandboxing enabled.