> It's a worse experience for the user but it's not bad enough to be a major barrier to adoption in most cases.
One thing I don't quite get is why giant companies with zillions of dollars of recurring revenue just keep using Electron (other than the obvious reason that it's there and it works already), when they could massively improve the user experience & make themselves significantly less vulnerable to competition by building native applications.
I mean, I get that making native applications is really hard, and trying to keep feature parity between version is a huge challenge (indeed, the the point of TFA). But it's obviously possible & some large organisations do it despite the difficulty (indeed, even some open source projects run by volunteers have it figured out).
I think about this every time I use Slack & feel the janky horribleness every time I click around the interface and have to deal with all the latency of waiting for it to update. I get that average users might not notice this but anyone who grew up with native applications surely can "feel" it and despair.
They do it because coding a large UI project is brutally hard and money doesn't help that much. Building a new UI team is hard, hiring is hard, managing is hard, designing is hard, it's all brutal. Now do that 2-3X in parallel and manage that efficiently and ship new features on time.
Couple that with the fact that web devs are much easier to recruit than devs for any native platform and it's easy to see why they don't bother with native.
The real choice is (1) be single-platform (Mac only, Windows only, etc) or (2) use a cross-platform UI with Electron being the easiest to adopt.
I think a big part of what people perceive as being Electron’s fault actually comes down to how the app code is written.
Beyond the regrettable (but hard to avoid) baseline memory usage, startup time, and bundle size, at the end of the day it’s just a browser. Native code might be faster than JS on benchmarks but at the level of clicking a button to perform an action, there’s no technical reason that the latency should be any different, certainly not at the level of 100s of milliseconds. It’s just slow UI code at that point. I daresay the bigger problem is the huge prevalence of slow UI code.
It reminds me of this article on why NetNewsWire (a native Mac RSS reader) is fast - turns out it takes a lot of work beyond just being native! (and a bunch of these strategies have analogs in the JS world too)
https://inessential.com/2020/05/18/why_netnewswire_is_fast
But the blame frequently lies with the bloated frameworks developers choose to use. Developers choose these frameworks because web development is pretty complex.
When done properly, light-weight responsive web apps can be smooth as butter and an amazing user experience.
I do think that it requires a higher degree of technical expertise and more development effort to achieve this on the web vs native, though.
In some cases, depending on the business model and audience, it's worth it.
Just the other day I did an experiment while writing a new Electron app. I created a Hello World -- once using React, and another with just static HTML & Vanilla JS. The React version, literally just the default Hello World page, was already noticeably slower and jankier at startup than the static HTML version.
Tack onto that experience however many NPM packages the average React app imports, maybe some hastily written synchronous calls that play fast and loose with your main thread, and it's not difficult to see why Electron and web apps in general get a bad wrap. It's not unavoidable, it's just lazy practices.
Yeah, and honestly I don't think it's even down to the framework all the time either, but some frameworks make it easier than others.
React, for instance, is famously the opposite of bloated ("it's just the V in MVC") and leaves it up to the user to shape it how they like. I think the trouble is that it's not really fast by default. You end up needing to be pretty careful to avoid excessive rendering, which in practice means thinking about referential equality a lot, and trying to make sure renders only happen when you mean them to. React can be plenty fast though, with care.
I think Svelte does a better job of being fast by default, and part of that is because it's more truly "reactive". Change a variable, and that specific part of the page is updated; if other variables depend on that one, then those parts are re-rendered too. It needs a lot less babysitting to avoid extra CPU cycles.
I've thought about this a bunch because I'm building a video editor with Svelte and Tauri. (Tauri is a Rust-based alternative to Electron that uses the system webview instead of Chromium). Of the things I'd expect to be hampered by being web-based, "video editor" is pretty high on that list! But I've yet to run into a performance problem that came down to the browser being just too slow. It has so far been something under my control, whether that's needing to optimize some canvas drawing, or finding the most efficient way to get video frames on the screen, or minimizing the messages I'm sending between Rust and the UI.
There are certainly inefficiencies that wouldn't be a problem with a native app, but it's been possible to work around them so far. And as the sole developer on the project, it's nice to be able to serve a larger market without having to keep 2 code bases in sync.
Slack used to feel better than it does now, and from my outside perspective it feels like most of the slowness that's started to happen comes down to lazier caching and slower back-end requests (loading conversations, etc)
One thing I don't quite get is why giant companies with zillions of dollars of recurring revenue just keep using Electron (other than the obvious reason that it's there and it works already), when they could massively improve the user experience & make themselves significantly less vulnerable to competition by building native applications.
I mean, I get that making native applications is really hard, and trying to keep feature parity between version is a huge challenge (indeed, the the point of TFA). But it's obviously possible & some large organisations do it despite the difficulty (indeed, even some open source projects run by volunteers have it figured out).
I think about this every time I use Slack & feel the janky horribleness every time I click around the interface and have to deal with all the latency of waiting for it to update. I get that average users might not notice this but anyone who grew up with native applications surely can "feel" it and despair.