5 ms·

Every recent new app I can remember installing in the last year is Electron. Native UI is dead. It's more work and all it really buys you is the privilege of be

by api 9y ago

Every recent new app I can remember installing in the last year is Electron. Native UI is dead. It's more work and all it really buys you is the privilege of being tied forever to one platform or having to code your UI multiple times. The effort of writing your UI three times to use three different proprietary UIs would be better spent optimizing Electron for less resource use. In the long term web will totally replace desktop UI. This could have been avoided if Apple, MS, and Linux would have agreed on a common desktop UI API 5-10 years ago but the ship sailed.

gsich 9y ago
One could have used e.g Qt.
sametmax 9y ago
Or you use qt. Which is cross plateform, native, fast and open source.
- api 9y ago
  Ask yourself why more people don't use Qt: (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 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.
  - mwcampbell 9y ago
    > 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.
  - badsectoracula 9y ago
    > 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).
  - jerf 9y ago
    "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.
khedoros1 9y ago
> Every recent new app I can remember installing in the last year is Electron. Native UI is dead. In terms of Electron, I have installed: Slack and VS Code (although I later uninstalled VS Code, and will have to put Slack on a machine with more memory than the VM it's in now). I can usually spare the memory, at least on my non-crap machines, but I haven't really had the need to.

by api 9y ago

gsich 9y ago

One could have used e.g Qt.

sametmax 9y ago

Or you use qt. Which is cross plateform, native, fast and open source.

api 9y ago
Ask yourself why more people don't use Qt: (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 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.
- mwcampbell 9y ago
  > 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.
- badsectoracula 9y ago
  > 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).
- jerf 9y ago
  "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.

khedoros1 9y ago

> Every recent new app I can remember installing in the last year is Electron. Native UI is dead. In terms of Electron, I have installed: Slack and VS Code (although I later uninstalled VS Code, and will have to put Slack on a machine with more memory than the VM it's in now). I can usually spare the memory, at least on my non-crap machines, but I haven't really had the need to.