4 ms·

This is kind of an Ask HN: Is there actually a trend in the grand cycle of ideas where we're returning to native apps? If so, what's causing that? Is there som

by atonse 5y ago

This is kind of an Ask HN: Is there actually a trend in the grand cycle of ideas where we're returning to native apps? If so, what's causing that? Is there some tech that's making it easier? (Maybe easier memory management, big enough market on each platform, React Native on the desktop, or many native-mapping frameworks, or Swift UI on macOS) Maybe people are tired of Electron? I'm only talking about devs because many users won't really explicitly notice.

duxup 5y ago
I don't know if there is a trend, just developer folks talking about it. There are endless amounts of developer chatter about using / not using Electron. As a user ... I really don't care what they use, the app runs well or it doesn't and I don't care why.
- finiteseries 5y ago
  Users don’t consciously care about 99% of UI and UX, the entire field is at some level the art of ensuring they continue not to care, not to notice.
- jbverschoor 5y ago
  > As a user ... I really don't care what they use, the app runs well or it doesn't and I don't care why. Well, Facebook almost lost the game completely because they were using a hybrid app.. Users cannot articulate why something si ruining performance (maybe not their app, because it simply has a higher priority set..)
  - BackBlast 5y ago
    Facebook's initial offering was horrible because it was a horribly developed app, it wasn't the fault of the underlying technology whatever they claim. Lots of people have built similar apps on web views that don't suck. PWAs, for example, can have downloadable bundle sizes < 5 MB, run in < 50MB ram, and have plenty of headroom for lots of features. You only need electron with it's own copy of a browser if the browser sandbox is unacceptable for your use case.
    - jbverschoor 5y ago
      The maximum app size was 10MB (OTA). The iPhone 3G had 128MB ram. So exactly my point. Electron wouldn't even be able to run on it.
jbverschoor 5y ago
> I'm only talking about devs because many users won't really explicitly notice. They notice, but "devs" tell them that software just gets more complex so they need to buy beefier machines, which is actually shitty advice in a world where you can't upgrade ram or anything. devs are lazy, and don't care about the end users. "Works on my machine (64GB RAM and a zillion cores)" The bigger the audience, the more impact performant software has
- geodel 5y ago
  Exactly right. As a developer I could go further and say that a lot of devs are simply abusing trust of users by claiming their half-assed apps are the best/optimized/ergonomic solution possible.
treve 5y ago
No data to back this up, but I think there's no trend back at all. Electron-like apps will continue to be dominant and people will never stop disliking them. Building for Electron / Web is so much cheaper considering the frameworks, transferable knowledge and virtually free support for all platforms. People have never not hated on Electron though, and that's because it's also always going to be a worse experience.
zorr 5y ago
I made a similar observation when reading the Zas Editor thread. Lately some MacOS specific applications have been popping up here on HN and they all look really good which I think is mostly because of the polished controls that SwiftUI provides. While I haven't used SwiftUI directly (only reviewed some code recently) it looks like it makes it simple to build good-looking native desktop apps. Unfortunately SwiftUI is not very cross platform and the other toolkits (Gtk, Qt, Swing, etc) are lagging behind in terms of polish and controls. My general conclusion is: Native desktop applications are not dead yet as shown by the popularity of Electron and SwiftUI shows that if the toolkit is good, developers will build native desktop apps. Now it's up to the other (cross-platform) toolkits to step up their game and we can get rid of the electron-based memory hogs.
- SkeuomorphicBee 5y ago
  I've been noticing a somewhat similar boom of new good-looking apps in the GTK/Gnome world. Although those are mostly smaller projects (single developer free-time pet-projects) with very small scope (doing one very small thing well), but the sheer number of those good new projects is amazing compared to the status quo of a decade or so ago. And although you credited the MacOS specific applications boom entirely to the good toolkit, I think the GTK/Gnome app resurgence comes from a synergy of three factors: 1. The rise of more ergonomic programing languages (Rust, Go, ...) that make desktop app development more fun (GTK programing in C works, but it is like pulling teeth, soo much boilerplate). 2. The rise of new app distribution channels on Linux (e.g. Flathub) 3. And the improvements to the toolkit.
  - zorr 5y ago
    Do you have any examples of GTK/Gnome apps like this?
    - SkeuomorphicBee 5y ago
      I think the best examples are the ones Gnome recognize as sort of semi-official Gnome Circle [0]. But browsing Flathub there are plenty more. [0] https://circle.gnome.org/ https://circle.gnome.org/
yboris 5y ago
I have a production Electron application: Video Hub App and if I had a few hundred thousand dollars to waste, I could hire developers to write me Windows, Mac, and Linux native applications. But instead I spent a few months by myself and created an application that runs on the three OSes ¯\_(ツ)_/¯ It's not even a contest: unless you're a corporation making tons of money, you either pick an OS and write a native application ignoring other OSes, or you use Electron (or some alternative). I have 4,000 people who purchased the app and not one complained about RAM or some other nonsense people keep hurling as insults at Electron. https://videohubapp.com/en/ https://videohubapp.com/en/ & https://github.com/whyboris/Video-Hub-App https://github.com/whyboris/Video-Hub-App (MIT open source)
- bjornlouser 5y ago
  "... not one complained about RAM ... " Just curious, how much RAM does your app typically use?
  - yboris 5y ago
    I think it used to be around 130mb on Windows. I checked just now with the latest Electron 18 - and the ram seems to be around 30mb. The app consumes more RAM when it's extracting screenshots from videos (usually you do this once to build your "hub" - preview of your entire video collection).
    - codedokode 5y ago
      The numbers are suspiciously low. Electron binary itself weighs about 100 Mb, although of course it need not to be fully loaded. Are you using correct way to measure memory usage? I think that the correct way is to measure all physical memory mapped into all Electron processes (there are several of them), making discount for shared pages and adding swapped out pages (because they can potentially be loaded back into main memory). In Linux I usually add PSS and swap usage parsed from /proc, which should give correct numbers (PSS is an additive value). For example, all processes of Skype on my system take approximately 459 Mb in RAM and swap file. If you are only measuring one process memory instead of all and only private memory pages (excluding shared pages and swapped out) then you get the wrong number. I tried to search online what "Memory" column represents in Windows Task Manager and Mac Activity Monitor (which people often use to estimate memory usage), but couldn't find any information. So I cannot be sure that they show true values and that those values can be added to find total memory usage by several processes.
jonpurdy 5y ago
My personal anecdote as a long-time Mac user: there's a positive correlation between the number of Electron apps I have to use and the desire to retire from tech. Native apps feel and fit better and consume less resources. Unfortunately for people like me, market forces mean they'll remain niche relative to cross-platform apps.
mattgreenrocks 5y ago
I think the people writing native apps are using the native-ness as a selling point, and it resonates with HN users. I'm not sure there's a sea-change among most users, as much as I'd like that to be the case. I do think that we're starting to understand the costs of "write-once-run-anywhere," better, too.
- aejae 5y ago
  100%. We initially chose to write natively because we thought it was best for our users. But now that we're putting that work in, recruiting for a less comment skillset, don't have Windows or Linux clients yet, etc... we want to make the most of that selling point.
interleave 5y ago
I can only speak for myself on this. Yes, I picked up SwiftUI last year initially because Electron/JS/TypeScript just never felt fun. Yet, I wanted to build out a few desktop/work-related ideas. Then, after going through the Apple Developer tutorials I noticed how easy and satisfying working with SwiftUI actually is. So, oddly enough, native macOS with SwiftUI is now one of my go-to for most of what I want to build (that isn't web-first).
aejae 5y ago
As one of the codevelopers of Remotion, I sadly don't think there's a meaningful return to native macOS. Team communication tools like us are a non-starter if they don't support the entire team, and the vast majority of even mac-first teams have a Windows user somewhere. (E.g. Even iOS dev shop has finance person.) I hate to say it, but I think the tradeoffs often lean in favor of Electron. Taking RAM usage as an example, even if your app will consume 100s of MBs when running, if the user only has it open when they need it, it's workable. In our case, only the goals of building something often visible, that feels like a part of the os, usually running in background, sometimes running lightweight video & audio... gave us the rationale to build natively.

by atonse 5y ago

duxup 5y ago

I don't know if there is a trend, just developer folks talking about it. There are endless amounts of developer chatter about using / not using Electron. As a user ... I really don't care what they use, the app runs well or it doesn't and I don't care why.

finiteseries 5y ago
Users don’t consciously care about 99% of UI and UX, the entire field is at some level the art of ensuring they continue not to care, not to notice.
jbverschoor 5y ago
> As a user ... I really don't care what they use, the app runs well or it doesn't and I don't care why. Well, Facebook almost lost the game completely because they were using a hybrid app.. Users cannot articulate why something si ruining performance (maybe not their app, because it simply has a higher priority set..)
- BackBlast 5y ago
  Facebook's initial offering was horrible because it was a horribly developed app, it wasn't the fault of the underlying technology whatever they claim. Lots of people have built similar apps on web views that don't suck. PWAs, for example, can have downloadable bundle sizes < 5 MB, run in < 50MB ram, and have plenty of headroom for lots of features. You only need electron with it's own copy of a browser if the browser sandbox is unacceptable for your use case.
  - jbverschoor 5y ago
    The maximum app size was 10MB (OTA). The iPhone 3G had 128MB ram. So exactly my point. Electron wouldn't even be able to run on it.

jbverschoor 5y ago

> I'm only talking about devs because many users won't really explicitly notice. They notice, but "devs" tell them that software just gets more complex so they need to buy beefier machines, which is actually shitty advice in a world where you can't upgrade ram or anything. devs are lazy, and don't care about the end users. "Works on my machine (64GB RAM and a zillion cores)" The bigger the audience, the more impact performant software has

geodel 5y ago
Exactly right. As a developer I could go further and say that a lot of devs are simply abusing trust of users by claiming their half-assed apps are the best/optimized/ergonomic solution possible.

treve 5y ago

No data to back this up, but I think there's no trend back at all. Electron-like apps will continue to be dominant and people will never stop disliking them. Building for Electron / Web is so much cheaper considering the frameworks, transferable knowledge and virtually free support for all platforms. People have never not hated on Electron though, and that's because it's also always going to be a worse experience.

zorr 5y ago

I made a similar observation when reading the Zas Editor thread. Lately some MacOS specific applications have been popping up here on HN and they all look really good which I think is mostly because of the polished controls that SwiftUI provides. While I haven't used SwiftUI directly (only reviewed some code recently) it looks like it makes it simple to build good-looking native desktop apps. Unfortunately SwiftUI is not very cross platform and the other toolkits (Gtk, Qt, Swing, etc) are lagging behind in terms of polish and controls. My general conclusion is: Native desktop applications are not dead yet as shown by the popularity of Electron and SwiftUI shows that if the toolkit is good, developers will build native desktop apps. Now it's up to the other (cross-platform) toolkits to step up their game and we can get rid of the electron-based memory hogs.

SkeuomorphicBee 5y ago
I've been noticing a somewhat similar boom of new good-looking apps in the GTK/Gnome world. Although those are mostly smaller projects (single developer free-time pet-projects) with very small scope (doing one very small thing well), but the sheer number of those good new projects is amazing compared to the status quo of a decade or so ago. And although you credited the MacOS specific applications boom entirely to the good toolkit, I think the GTK/Gnome app resurgence comes from a synergy of three factors: 1. The rise of more ergonomic programing languages (Rust, Go, ...) that make desktop app development more fun (GTK programing in C works, but it is like pulling teeth, soo much boilerplate). 2. The rise of new app distribution channels on Linux (e.g. Flathub) 3. And the improvements to the toolkit.
- zorr 5y ago
  Do you have any examples of GTK/Gnome apps like this?
  - SkeuomorphicBee 5y ago
    I think the best examples are the ones Gnome recognize as sort of semi-official Gnome Circle [0]. But browsing Flathub there are plenty more. [0] https://circle.gnome.org/ https://circle.gnome.org/

yboris 5y ago

I have a production Electron application: Video Hub App and if I had a few hundred thousand dollars to waste, I could hire developers to write me Windows, Mac, and Linux native applications. But instead I spent a few months by myself and created an application that runs on the three OSes ¯\_(ツ)_/¯ It's not even a contest: unless you're a corporation making tons of money, you either pick an OS and write a native application ignoring other OSes, or you use Electron (or some alternative). I have 4,000 people who purchased the app and not one complained about RAM or some other nonsense people keep hurling as insults at Electron. https://videohubapp.com/en/ https://videohubapp.com/en/ & https://github.com/whyboris/Video-Hub-App https://github.com/whyboris/Video-Hub-App (MIT open source)

bjornlouser 5y ago
"... not one complained about RAM ... " Just curious, how much RAM does your app typically use?
- yboris 5y ago
  I think it used to be around 130mb on Windows. I checked just now with the latest Electron 18 - and the ram seems to be around 30mb. The app consumes more RAM when it's extracting screenshots from videos (usually you do this once to build your "hub" - preview of your entire video collection).
  - codedokode 5y ago
    The numbers are suspiciously low. Electron binary itself weighs about 100 Mb, although of course it need not to be fully loaded. Are you using correct way to measure memory usage? I think that the correct way is to measure all physical memory mapped into all Electron processes (there are several of them), making discount for shared pages and adding swapped out pages (because they can potentially be loaded back into main memory). In Linux I usually add PSS and swap usage parsed from /proc, which should give correct numbers (PSS is an additive value). For example, all processes of Skype on my system take approximately 459 Mb in RAM and swap file. If you are only measuring one process memory instead of all and only private memory pages (excluding shared pages and swapped out) then you get the wrong number. I tried to search online what "Memory" column represents in Windows Task Manager and Mac Activity Monitor (which people often use to estimate memory usage), but couldn't find any information. So I cannot be sure that they show true values and that those values can be added to find total memory usage by several processes.

jonpurdy 5y ago

My personal anecdote as a long-time Mac user: there's a positive correlation between the number of Electron apps I have to use and the desire to retire from tech. Native apps feel and fit better and consume less resources. Unfortunately for people like me, market forces mean they'll remain niche relative to cross-platform apps.

mattgreenrocks 5y ago

I think the people writing native apps are using the native-ness as a selling point, and it resonates with HN users. I'm not sure there's a sea-change among most users, as much as I'd like that to be the case. I do think that we're starting to understand the costs of "write-once-run-anywhere," better, too.

aejae 5y ago
100%. We initially chose to write natively because we thought it was best for our users. But now that we're putting that work in, recruiting for a less comment skillset, don't have Windows or Linux clients yet, etc... we want to make the most of that selling point.

interleave 5y ago

I can only speak for myself on this. Yes, I picked up SwiftUI last year initially because Electron/JS/TypeScript just never felt fun. Yet, I wanted to build out a few desktop/work-related ideas. Then, after going through the Apple Developer tutorials I noticed how easy and satisfying working with SwiftUI actually is. So, oddly enough, native macOS with SwiftUI is now one of my go-to for most of what I want to build (that isn't web-first).

aejae 5y ago

As one of the codevelopers of Remotion, I sadly don't think there's a meaningful return to native macOS. Team communication tools like us are a non-starter if they don't support the entire team, and the vast majority of even mac-first teams have a Windows user somewhere. (E.g. Even iOS dev shop has finance person.) I hate to say it, but I think the tradeoffs often lean in favor of Electron. Taking RAM usage as an example, even if your app will consume 100s of MBs when running, if the user only has it open when they need it, it's workable. In our case, only the goals of building something often visible, that feels like a part of the os, usually running in background, sometimes running lightweight video & audio... gave us the rationale to build natively.