(1) With web technologies you can write once and run everywhere including mobile to some extent. Writing a UI multiple times is monumentally expensive. Even huge companies don't like to do this, let alone indie efforts and startups. If Slack with its billion dollars doesn't do it what does that say?
(2) The ecosystem is far more active. The web is the largest open source ecosystem in history. There is code to do literally everything and an embarrassment of riches when it comes to libraries, frameworks, connectors, etc.
(3) Qt isn't that much less bloated than Electron, especially when you start styling it and get dynamic.
(4) Long build times mean that I have to wait a lot longer between dev/test. UI development tends to be a whole lot of iterative hack-test-hack-test. With web tech it's literally edit-refresh, which is much faster than edit-make-wait-launch.
(5) To make Qt look good you have to start styling and using its weird surprisingly web-like stylesheets, which takes you out of pure native mode and into a hybrid rendering mode. At that point I'm halfway to browser rendering.
(6) If you code UIs with web tech you also get the web, meaning your app could be run remotely in a browser as well as locally. This is the networked app promise of X11, Citrix, etc., and you get it for free.
Electron is popular because it delivers a ton of value in terms of cross-platform compatibility, reduced effort, rapid development, consistency, and ecosystem. Performance and memory use problems can be fixed.
It's a genuinely lightweight wrapper that looks really promising. Trouble is everyone I show it to says "ugly" as their first comment. Everyone wants styled apps today with polished UIs and that takes you down a path that looks increasingly like CSS whether you like it or not. I also have this strong feeling that if I wrote with it I'd be rewriting in 5 years after desktop UIs are abandoned in favor of 100% web technology everywhere. Of course web UIs shift a lot too. Maybe the fate with UIs is to rewrite every 5 years no matter what.
> Writing a UI multiple times is monumentally expensive.
I'm confused by this statement. The point of Qt is that you write the UI once. Your controller back-end might have platform-related pragmas, but not the UI.
> If Slack with its billion dollars doesn't do it what does that say?
When you give programmers freedom to choose what makes life easy for them, end-user experience suffers?
I really think all dev companies should have a lab of 'consumer-grade' laptops with 4GB of RAM and 20Mbit/sec networking. And QC shouldn't let anything ship until it runs adequately on those. Particularly for a company like Slack that is targetting corporate users, the bulk of whom aren't software architects with 2017 MBPs ( who make the choice ) but small-cogs with a five-year-old Dell.
You're right about my first statement. Was a bit of a thinko in that it's talking more about the conditions that lead people to choose Electron in general than responding to Qt specifically.
As others have pointed out in this thread: Qt is not really that much lighter than the web. It draws its own controls and even has css-like styling. I remember Qt apps being relatively slow on small machines... maybe not quite as slow as Electron but the latter could be tuned and improved and made competitive IMHO.
Your main point is valid, but you shouldn't be focusing your anger at Electron or at programmers for choosing it. You should be focusing your anger at desktop vendors for refusing to offer a better way to develop cross-platform apps in favor of an ultimately foot-blasting quest for platform lock-in. By refusing to play with each other desktop vendors have doomed all their platforms to obsolescence and abandonment.
> To make Qt look good you have to start styling and using its weird surprisingly web-like stylesheets, which takes you out of pure native mode and into a hybrid rendering mode.
Note that Qt does not have a pure native mode, it always draws its own controls - it just has a very good imitation of the native controls (especially on Windows).
"Qt isn't that much less bloated than Electron, especially when you start styling it and get dynamic."
Given how many smart people are working to make the browser techs as efficient as possible, and the way that things like QT get "bloated" as soon as they start trying to do what browsers do, I've pretty much arrived at the idea that once you have images and an engine that can reflow text and load fonts and so on, and you want this rather complicated functionality to perform at a reasonable level, you're looking at browser levels of resource consumption no matter what you do.
I mean, if you start working the math on what it looks like to have a bitmap of the screen in memory (which you may not literally have as a single flat plane, but we've got character caches, images, and all sorts of other things that add up to that pretty quickly, if not surpass it entirely very quickly), on a high-resolution display, a bit of extra memory left over from packing those resources, the dynamic scripting language space, the other support modules, various other bits of uncompressed media even if it's just windowed... you've gotten into the hundreds of megabytes pretty easily there. Maybe you could keep this below 100MB with a lot of work, but in a world where a single uncompressed 4K full-color image/framebuffer is running you at least 24 MB (for RGB, 32MB for RGBA), 10-50MB just isn't going to be an option.
I've got an emacs here with a couple dozen source code buffers loaded and it's running at about 60MB resident. That's a mere 1/5th of the Slack usage that everyone is incensed about, and while emacs can do a lot of things, it's still taking a pretty substantial capabilities hit vs. Electron to get that small.
Yes, I know emacs can have a web browser in it and such. And if I use eww to load news.ycombinator.com, emacs resident usage just jumped 15MB for what is, frankly, a terrible rendering. It isn't even rendering my jerf.org terribly well, which in modern terms is basically built by rubbing two sticks together and sending the resulting sparks down the wire. That's what 15MB on top of the already-loaded emacs bought me.
I agree with that to some extend, but the fact is, except for some very specific cases like vscode, I not only don't need "styling and dynamic", but I don't want it to be.
My OS has UI semantics. I want most of the apps to work the same everywhere. Your app is not special. Stop reinventing a "visual identity". Give me congruency and features.
"I agree with that to some extend, but the fact is, except for some very specific cases like vscode, I not only don't need "styling and dynamic", but I don't want it to be."
Actually, I'm not referring to things like colors or fonts. What I'm referring to is the fact that had the web-browser style layout algorithms not been already invented by web browsers, they would have been invented by the inexorable progression of the pressures and features in desktop toolkits by now. If the people using web toolkits want to be able to lay things out without having to laboriously bundle things into horizontal and vertical scaling groups and specify flexing ratios and all the other crappy layout mechanisms used in desktop toolkits since they first came out, but to use a simple (to use, not implement), powerful HTML-esque layout mechanism, you're going to pay for that on the resource consumption.
And the people writing these programs want that, and will use toolkits that offer that, and if that's bothering you, well, spend some time writing this stuff yourself and you'll stop being bothered, you'll happily spend 100MB of the user's RAM to make the pain end. As neat as it is in some ways, and as much as it has been made to sing and dance over the last 50 years, that style of layout really stinks to use.
> you'll happily spend 100MB of the user's RAM to make the pain end.
And users, at least the savvy ones who hang out here, are saying that this RAM isn't ours to spend. Is there no way that we could spend more resources on our dev machines instead, at build time, to take a piece of code that was pleasant to write and convert it into something that's frugal with resources on the user's machine? C++ and Rust promise abstractions with zero runtime cost compared to the best that you could hand-code. I wonder if the same can be applied to multi-platform GUI toolkits, perhaps through compile-time metaprogramming.
Modern UIs with support for themes, complex interactions, multiple screen and pixel formats, and every language spoken by Homo Sapiens since Gobekli Tepi was built are large and complex. It's not avoidable. That is the problem domain. If you're doing less than that you'll regret it when more and more users start requesting features you don't have or complaining that your product doesn't look right on X or with X language/font/etc. That's my problem with all these ultralight immediate mode UI libs like nuklear. It's like going back to MS-DOS or CP/M and saying "wow that's simple and fast!" Yeah but it lacks a lot of stuff you will need.
The web's rendering layer isn't perfect but it's better than many alternatives and isn't going anywhere, so putting a lot of effort into making it more efficient and robust is very logical.
> Trouble is everyone I show [libui] to says "ugly" as their first comment. Everyone wants styled apps today with polished UIs
I don't think I'll ever understand this. What about consistency between apps? Sticking to the OS's native widgets and style will get you that. Do people really like it when each app has its own look?
Of course, I'm no judge of aesthetics. Being visually impaired, my idea of a perfect UI is something with high contrast and large text.
Nr. 1 implies that they (or their users) don't care about efficiency. It doesn't tell us anything about native cross platform development being expensive.
(1) With web technologies you can write once and run everywhere including mobile to some extent. Writing a UI multiple times is monumentally expensive. Even huge companies don't like to do this, let alone indie efforts and startups. If Slack with its billion dollars doesn't do it what does that say?
(2) The ecosystem is far more active. The web is the largest open source ecosystem in history. There is code to do literally everything and an embarrassment of riches when it comes to libraries, frameworks, connectors, etc.
(3) Qt isn't that much less bloated than Electron, especially when you start styling it and get dynamic.
(4) Long build times mean that I have to wait a lot longer between dev/test. UI development tends to be a whole lot of iterative hack-test-hack-test. With web tech it's literally edit-refresh, which is much faster than edit-make-wait-launch.
(5) To make Qt look good you have to start styling and using its weird surprisingly web-like stylesheets, which takes you out of pure native mode and into a hybrid rendering mode. At that point I'm halfway to browser rendering.
(6) If you code UIs with web tech you also get the web, meaning your app could be run remotely in a browser as well as locally. This is the networked app promise of X11, Citrix, etc., and you get it for free.
Electron is popular because it delivers a ton of value in terms of cross-platform compatibility, reduced effort, rapid development, consistency, and ecosystem. Performance and memory use problems can be fixed.
I have been watching this project:
https://github.com/andlabs/libui
It's a genuinely lightweight wrapper that looks really promising. Trouble is everyone I show it to says "ugly" as their first comment. Everyone wants styled apps today with polished UIs and that takes you down a path that looks increasingly like CSS whether you like it or not. I also have this strong feeling that if I wrote with it I'd be rewriting in 5 years after desktop UIs are abandoned in favor of 100% web technology everywhere. Of course web UIs shift a lot too. Maybe the fate with UIs is to rewrite every 5 years no matter what.