5 ms·

> 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 compan

by trog 4y ago

> 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.

brundolf 4y ago
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)
api 4y ago
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.
- phist_mcgee 4y ago
  Bang on the money.
dceddia 4y ago
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 https://inessential.com/2020/05/18/why_netnewswire_is_fast
- claytongulick 4y ago
  I think this is the thing. Web apps get a bad rap, and justifiably so. 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.
  - robgibbons 4y ago
    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.
  - dceddia 4y ago

by trog 4y ago

brundolf 4y ago

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)

api 4y ago

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.

phist_mcgee 4y ago
Bang on the money.

dceddia 4y ago

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 https://inessential.com/2020/05/18/why_netnewswire_is_fast

claytongulick 4y ago
I think this is the thing. Web apps get a bad rap, and justifiably so. 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.
- robgibbons 4y ago
  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.
- dceddia 4y ago