There's nothing "good" about electron. Hell, there are even easier ways of getting high performance cross platform software out there. Electron was used because it's a default, defacto choice that nobody bothered with even researching or testing if it was the right choice, or even a good choice.
"It just works". A rabid raccoon mashing its face on a keyboard could plausibly produce a shippable electron app. Vibe-bandit development. (This is not a selling point.) People claiming to be software developers should aim to do better.
You might as well tell reality to do better: The reality of physics (water flows downhill, electricity moves through the best conductor, systems settle where the least energy is required) and the reality of business (companies naturally move toward solutions that cost less time, less money, and less effort)
I personally think that some battles require playing within the rules of the game. Not to wish for new rules. Make something that requires less effort and resources than Electron but is good enough, and people will be more likely to use it.
Using electron and doing things shittily is a choice. If you're ever presented with a choice between doing something well and not, do the best you can. Electron is never the best choice. It's not even the easiest, most efficient choice. It's the lazy, zero effort, default, ad-hoc choice picked by someone who really should know better but couldn't be bothered to even try.
Windows' Metro/Modern UI was pretty good from different perspectives, but didn't have enough effort put into it to make it a universal thing fit for multiple purposes (half of the Windows settings was still in Control Panel for quite some time), wasn't familiar for users (so they hated it) and wasn't familiar for developers (so they created hideous apps).
In the opposing Linux camp, GNOME made Gtk 4 with Libadwaita UI library with "everything is a phone app" mindset that not every app can adopt. For example, there's no application menu (a line with File, View, Edit, etc.) component shipped by default, you should make it yourself or get it somewhere. So now GIMP is developed using Gtk 3 (not modern 4) because it has all the components GIMP needs. Trying to get GNOME developers to implement some stuff outside of their vision is a futile effort.
The same search incidentally turned up that Qt requires a paid license for commercial projects, which is surprising to me and obviously makes it an even less attractive choice than Electron. Being less useful and costing more isn't a great combo.
You can with WASM (but you shouldn't).
> Qt requires a paid license for commercial projects
It doesn't, it requires paid license if you don't want to abide with (L)GPL license, which should be fair deal, right? You want to get paid for your closed-source product, so you should not have any reservations about paying for their product that enables you to create your product, right? Or is it "money for me, but not for thee"?
> Being less useful and costing more isn't a great combo.
Very nice, but now explain why you are talking about using Qt to create apps, whereas grandparent talks about experience with apps created with Qt.
It should go without saying that the requirements of the LGPL license are less attractive than the MIT one Electron has, fairness doesn't really come into it. Beyond the licensing hurdles that Qt devotes multiple pages of its website to explaining, they also gate commercial features such as "3D and graphs capabilities" [1] behind the paid license price, which are more use cases that are thoroughly covered by more permissively licensed web projects that already work everywhere.
On your last point I'm completely lost; it's late here so it might be me but I'm not sure what distinction you're making. I guess I interpreted dmix' comment generally to be about the process of producing software with either approach given that my comment above was asking for details on alternatives from the perspective of a developer and not a user. I don't have any personal beef with using apps that are written with Qt.
[0] https://doc.qt.io/qt-6/wasm.html#accessibility-and-screen-re...
[1] https://www.qt.io/development/qt-framework/commercial-qt
But the author of a comment I originally replied to has:
> I might hate Qt apps more than I hate Electron
therefore it is your insertion about dev experience and license costs of Qt vs MIT-licensed web frameworks that makes me lost.
Plus I use Mac these days and Qt apps just never looked right on that platform.
At least web apps looks like web apps.
https://github.com/jart/cosmopolitan
Cosmopolitan can be used to bundle up any gui package, and your code, and a team of professional software devs should be able to cope with it just fine. You end up with a native executable with a slightly bigger package to ship, since it's carrying executables for various platforms, but you'd effectively have the same code and behavior everywhere. A few extra megabytes, instead of whatever the hell electron is doing. They could also use Java, or even one of the electron type clones that attempt to be better, like Tauri.
The point isn't that electron is so awful. It's that the company with the purportedly best coding AI and one of the best overall AI models in the world chose to do the absolute tawdriest, cheapest, even laziest thing without any consideration of what the right thing to do might be, or what thing they could do that demonstrated their excellence and mastery of craft, or at a bare minimum, the advanced capabilities of the AI.
Cursor used claude to build a browser from scratch; it's not like their AI couldn't do it.
Who’s got the rebuttal to this?
React was an instant hit because it had the facebook brand behind it and everyone was tired of angular. But ultimately, react has worse outcomes for developers, users, and businesses. On the web, react websites are bloating. They run slower, their javascript payloads are larger, and they take longer to load.
Your suggestion -- that it works and then it gets more efficient later -- would make sense if we lived in a world where react moved off the virtual dom model. A virtual dom is a fine first attempt or prototype but we can do better. We know how. Projects like SolidJS do do better. React has not caught up, but it is still very popular. This whole "It worked badly, but it worked. Later came efficiency" thing is complete nonsense.
And there are loads of businesses that started off with an angular app, started to migrate to react, then started to migrate to react hooks, now switching to whatever the latest methodology is. Time and again you find these products, always endlessly migrating to the new thing, most of them never finishing a migration before beginning a new one. So these products end up being a chimera of four different frameworks held together with pain.
This isn't a good outcome for businesses, or for users, and it's not a good developer experience. react is stagnant and surviving off of being the default or the status quo and supported by tech companies that have long since stopped innovating and subsist on rent seeking. Developers choose react because nobody was ever fired for buying IBM and because they can look busy at their job, and because they buy a new phone and laptop every year with the latest hardware that can compensate for the deteriorating software they ship.
Ok, but why was everyone tired of Angular? Sure, web frameworks are examples of Fad Driven Development to the extreme, but Angular.js, was pure unmitigated ARSE.
Made ten bindings on a page? That's 100 cross connections. Made 100 two-way bindings? that's 10000 connections.
Clicked one way through fields A, B then started typing, they show same data. Clicked through fields A and C, now they are bound but B isn't. Clicked B then C, congrats all three of your bindings suddenly start filling in.
It was a combination of shitty performance scaling and unintuitive Angular data flow that primed everyone for React to take over.
It is better for something to not exist than for a shitty version to exist. Software doesn't get better over time, it gets worse. If you make a bad, suboptimal choice today chances are that solution becomes permanent. It's telling that all of your examples of increasing efficiency are not software.
If are aren't going to do it well, don't do it.
The UI wrapper then could be Electron, or something a little more platform-native you hand off to some junior engineers.
Are you sure it wasn't just an unfamiliarity with Java errors in general?
Clojure popped out of the _senior_ Java camp. It often lives within that mindshare.
In my opinion that is the true reason why the old native software was developed to such a high standard. But then once online stores and shrink wrap agreements made it impossible to return buggy software, then the financial incentives shifted towards shipping a partially broken product.
Who cares about pleasing with good performance when you can instead keep customers hostage?
The first thing you need when you make something new is making it work, it is much better that it works badly than having something not working at all.
Take for example the Newcomen engine, with an abysmal efficiency of half a percent. You needed 90 times more fuel than an engine today, so it could only be used in the mines were the fuel was.
It worked badly, but it worked. Later came efficiency.
The same happened with locomotives. So bad efficiency at first, but it changed the world.
The first thing AI people had to do is making it work in all OSes. Yeah, it works badly but it works.
We downloaded some Clojure editor made in java to test if we were going to deploy it in our company. It gave us some obscure java error in different OSes like linux or Mac configurations. We discarded it. It did not work.
We have engineers and we can fix those issues but it is not worth it. The people that made this software do not understand basic things.
We have Claude working in hundreds of computers with different OSes. It just works.