Comment by notepad0x90

Comment by notepad0x90 10 hours ago

It can run in your browser too.The electron part isn't the bloat but the web part. Web devs keep using framework on top of frameworks and the bloat is endless. Lack of good native UX kits forces devs to use web-based kits. Qt has a nice idea with qml but aside from some limitations, it is mostly C++ (yes, pyqt,etc.. exist).

Native UI kits should be able to do better than web-based kits. But I suspect just as with the web, the problem is consistency. The one thing the web does right is deliver consistent UI experience across various hardware with less dev time. It all comes down to which method has least amounts of friction for devs? Large tech companies spent a lot of time and money in dev tooling for their web services, so web based approaches to solve problems inherently have to be taken for even trivial apps (not that teams is one).

Open source native UX kits that work consistently across platforms and languages would solve much of this. Unfortunately, the open source community is stuck on polishing gtk and qt.

jenadine 8 hours ago

There are a bunch of new native UI toolkit as well, such as Slint [https://slint.dev]

Reply View 0 replies

knubie 4 hours ago

> The electron part isn't the bloat but the web part.

The bloat part is the bloat. Web apps can made to be perfectly performant if you are diligent, and native apps can be made to be bloated and slow if you're not.

Reply View 0 replies

Terr_ 9 hours ago

Sometimes I find myself wistfully thinking of Java Swing applets with native theme settings.

Reply View 3 replies

ksec 4 minutes ago

Same here. The write once run everywhere eventually did won but that was the web. And comparatively speaking, JVM is so much better today than it was 20 years ago.
I sometimes wonder if Chromium actually do any specific optimisation for Electrons related usage.

Reply View | 0 replies
notepad0x90 8 hours ago

They say nostalgia is always deceptive, but I miss ~java2 era UX.

Reply View | 1 reply
- Terr_ 8 hours ago
  
  I don't think it was Java itself, but many operating systems simply had a much stronger set of UX that was cohesively being followed.
  Yet here we are, in an era where you can encounter multiple choices and you don't know whether it's a single select versus a multi-select tick box. And then there's something with a boolean state, and it's not clear which color means it's currently active. Then you hit alt-F for the File menu order to quit your browser in frustration, but the web page blocks you because it has decided that means that you're going to "Favorite" whatever you're looking at.
  
  Reply View | 0 replies

Dalewyn 7 hours ago

>But I suspect just as with the web, the problem is consistency.

That is indeed the "problem" at its core. People are lazy, operating systems aren't consistent enough.

Operating systems came about to abstract all the differences of countless hardware away, but that is no longer good enough. Now people want to abstract away that abstraction: Chrome.

Chrome is the abstraction layer to Windows, MacOS, iOS, Linux, Android, BSD, C++, HTML, PHP, Ruby, Rust, Python, desktops, laptops, smartphones, tablets, and all the other things. You develop for Chrome and everyone uses Chrome and everyone on both sides gets the same thing for a singular effort.

If I were to step away from all I know and care about computers and see as an uncaring man, I have to admit: It makes perfect sense. Fuck all that noise. Code for Chrome and use by Chrome. The world can't be simpler.

Reply View 0 replies