5 ms·

I cannot describe how Bad an idea it is to try to rely on the OS-provided web browser. We chose Electron at Slack, partly because of the numerous unfixable bugs

I cannot describe how Bad an idea it is to try to rely on the OS-provided web browser. We chose Electron at Slack, partly because of the numerous unfixable bugs with Slack for Mac for people on downlevel operating systems, and that was just on macOS! Telling people, "You need to install a new OS" or even in the case of macOS on old devices, "You need to buy a new computer", in response to a user writing in with a bug in your app is a real uncomfortable conversation to have in Support Tauri even themselves are building their own embedded browser (based on Servo) because they too realize that using "whatever the OS happens to have" is fundamentally not Workable as a platform. This idea Just Does Not Work for production apps with Real amounts of users

saagarjha 2y ago
Ok, so not only do you want to use the lowest common denominator in terms of programming language and platform API, but you think it’s impossible to write apps if the web engine you’re using isn’t the exact same across every OS and version? Next you’re going to say that shipping VMs to users is the only way to deploy apps, lest people use different (or, gasp, out of date) OSes that might have bugs.
- quotemstr 2y ago
  > Next you’re going to say that shipping VMs to users is the only way to deploy apps, lest people use different (or, gasp, out of date) OSes that might have bugs. This, but unironically. Why not ship an app as a VM? Firecracker is super fast. The only thing really stopping is is that we don't have VM friendly APIs that let VM guests act like desktop apps. (Well, nested virtualization should be more supported.) Also, we're already in a world in which we ship apps as basically containers. Is that all that different? What should be the interface between an app and its host OS (and other apps)? At one extreme, we have "thick", "batteries included" interfaces like old win32, with tons of convenience APIs and OS-provided in-process code, and at the other extreme, we have VM-style "thin" interfaces with only the most essential OS services provided and apps (well, VM guests) expected to bring their own batteries --- things like a virtio framebuffer. Whether an app interfere is implemented as a VM hypercall virtio thing, IPC, or in-process client library is an implementation detail. What matters is the thickness of the API surface. We're in the middle of a secular trend from thick interface surfaces to thin ones. I don't see that as a bad thing. Thin, arms-length interfaces maximally decouple app and OS development. They encourage cooperation over explicit, stable, and versioned interfaces. They simplify the entire industry. The technological environment that generated the old thick interfaces doesn't exist anymore. Freed of its constraints, we can do better now.
  - saagarjha 2y ago
    Are you going to pay for the extra RAM I need to run your VM too?
    - quotemstr 2y ago
      The success of Electron tells us that memory usage concerns are overblown. Memory is seriously dirty cheap nowadays. Time to spend a bit more to simplify the ecosystem.
      - saagarjha 2y ago
        Ok, first of all, what is going to ship is not just Electron but a whole VM plus Electron. Just like how people run the JVM in Docker or whatever, because nobody trusts any layer of their stack to actually be abstracted enough that they can feel comfortable with what is underneath. That’s going to be truly awful. Second, the “success” of Electron is like the “success” of online advertising. Nobody really likes it and it’s basically a local optimum in a deep pit that it’s unfortunate we’re stuck in. It’s just that economic pressures have pushed the market to this being something people tolerate rather than actively desire.
      - hollerith 2y ago
        I consider it a little perverse to say "simplify" and Electron in one sentence. But my main point is that memory requires power so adding memory to a machine shortens battery life (or increases weight due to larger battery). So far AFAIK no laptop maker has made a laptop that can power off half the RAM to decrease demand on the battery when only half the RAM is needed. (Also, I do not like apps built on Electron and do not use any.)
  - synergy20 2y ago
    isn't that docker is for?
- anaisbetts 2y ago
  Here's a real, actual bug that we had in the old Slack for Mac app (which was Webkit-based, so effectively the same approach as Tauri et al) - some users, only on older versions of macOS, report that whenever they paste in a YouTube link, the embedded video has a pink tint. Tell me, how would you fix this bug?
  - saagarjha 2y ago
    (I assume you’re talking about loading Slack in the website? That’s the only WebKit surface you have that I know about.) Let me turn the question around for you: why do you think shipping Electron will save you? Sure, maybe WebKit has a broken video decoder this year. What will you do next time when it’s the GPU driver? You already know what the answer is: you diagnose it as far as you can, report it upstream, and communicate the best you can with your users. You seem to have the mindset that every bug exists to be fixed, and that’s not true at all. They are all a tradeoff. It’s easy to go “oh if we bundle everything ourself we can shift more control to ourselves to fix bugs because more of the components are ours”. First of all, you actually have to do that: turns out plenty of companies operating at scale are unable to do that (have you looked at how often Discord updates their dependencies?). And even when you’re committing to doing this and follow up, you have to understand that you’re unconditionally shipping a worse experience to all your users in the hopes of solving saving some time for some small fraction of them. This isn’t something that I am completely against (for example, I advocate for shipping debug symbols to users-but that’s another long argument) but you also have to look back at yourself and go “ok we’re shipping 98% of the same code across platforms and supporting macOS Mojave takes an extra 2 engineer-days a year, maybe this is an OK state of things” rather than being absolutist about something you’re not achieving anyway.
    - whartung 2y ago
      > why do you think shipping Electron will save you? All of the videos will be pink, not just the macOS ones on an older Safari. At worst someone could dig into the Webkit (Chome?) distro and fix it and they can release a custom build for the short term before it gets incorporated, fixing "everyone".
quotemstr 2y ago
The phenomenon you're discussing is part of a broader trend towards simplifying development and deployment by just vendoring all dependencies, dammit. Fewer dependencies, fewer headaches, both for app makers and OS vendors. The sky didn't fall when Android stopped providing openssl and libstdc++ with the OS. Sharing centrally managed dependencies made some sense in the days of infrequently-updated boxed software, but now? Brute force has made the size advantage of sharing irrelevant. (People complain about Electron memory use, but still use it.) Security advantages? App makers are perfectly capable of shipping their own security updates now that we have cloud auto-updating whenever we want it. I just don't think that there's still a real technical case for Debian-style dependency sharing in general purpose operating systems and that we can save ourselves a lot of time and pain by getting out of our 1990s shared library mindset. and it's taken a lot of time and a lot of retirements to change this mentality.
- lll-o-lll 2y ago
  > App makers are perfectly capable of shipping their own security updates now that we have cloud auto-updating whenever we want it. A large third-party dependency chain is, in my opinion, the most problematic security risk in modern software. Secondly, automatic updates are how we got cloud-strike. I’m not advocating Debian style dependency sharing, but I am advocating for tight control and auditing over your dependency chain (which will mean building more in house). And allowing IT departments to control update rollouts.
- 0x000xca0xfe 2y ago
  Centrally managed dependencies are invaluable for small/simpler apps. Not every program is backed by a company that provides continuous updates. And what happens if the updates stop? Yeah right you have a giant pile of half-broken, bug-ridden and outdated random libraries. I use some small Win32 and GTK+ utilities that weren't touched in years and they all just work, are nicely integrated into the system theme (even dark mode works without me lifting a finger) and use fresh and up-to-date dependencies courtesy of the OS.
deleted 2y ago
[deleted]
codelikeawolf 2y ago
You nailed it. Every time I see a new Electron replacement pop up that uses less resources, less disk space, etc., it's using the OS webview. I would argue that it's almost impossible to ship a reliable version of the app without resorting to polyfills and using only a fraction of the Web APIs available today. I tried Tauri out for a time tracking app that has a week input, and I ended up going back to Electron because the macOS webview (Safari) doesn't support it. If I use a framework that leverages the OS webview, can I use SharedWorkers? Nope. Atomics? Nope. WebGPU? Nope. You're kneecapped by the lowest common denominator (which is pretty much impossible to determine because there's no way to know the oldest version of the OS webview your users might have installed). Don't get me wrong, I applaud the efforts of the Photino devs, the Tauri devs, and the Wails devs. They're all very cool projects. But if you need to build something non-trivial with them, you're going to have a bad time. The resource usage and large binary size that comes with Electron is the price you pay for having a cross-platform app that doesn't break in weird and unexpected ways. I never see any kinds of warnings or caveats on these framework websites explaining the drawbacks of using the OS webview. Which means every time one of these comes out, I have to explain to the people that I work with why we can't just ditch Electron.
3836293648 2y ago
I can buy that using the OS-provided browser is a bad idea, but referencing slack is hardly confidence-inducing. Slack is by far the slowest and buggiest web app I've had the misfortune of being stuck with. And bundling it with chromium is an even worse idea given that the only way of getting half way decent performance with slack is opening the web version in Firefox (and specifically not Chrome). And yes, I've heard MS Teams is even slower, but I've never had to use it
- deleted 2y ago
  [deleted]
- throwup238 2y ago
  > I can buy that using the OS-provided browser is a bad idea, but referencing slack is hardly confidence-inducing. It would be worse. They could have said Microsoft Teams. > And yes, I've heard MS Teams is even slower, but I've never had to use it Oh, dear.
idle_zealot 2y ago
The way you capitalize words reminds me of the style used in newspapers and other writing from the 1800s. Is there a part of the world that still uses capitalization for... whatever you're doing? Or is that just a personal affectation?

saagarjha 2y ago

Ok, so not only do you want to use the lowest common denominator in terms of programming language and platform API, but you think it’s impossible to write apps if the web engine you’re using isn’t the exact same across every OS and version? Next you’re going to say that shipping VMs to users is the only way to deploy apps, lest people use different (or, gasp, out of date) OSes that might have bugs.

quotemstr 2y ago
> Next you’re going to say that shipping VMs to users is the only way to deploy apps, lest people use different (or, gasp, out of date) OSes that might have bugs. This, but unironically. Why not ship an app as a VM? Firecracker is super fast. The only thing really stopping is is that we don't have VM friendly APIs that let VM guests act like desktop apps. (Well, nested virtualization should be more supported.) Also, we're already in a world in which we ship apps as basically containers. Is that all that different? What should be the interface between an app and its host OS (and other apps)? At one extreme, we have "thick", "batteries included" interfaces like old win32, with tons of convenience APIs and OS-provided in-process code, and at the other extreme, we have VM-style "thin" interfaces with only the most essential OS services provided and apps (well, VM guests) expected to bring their own batteries --- things like a virtio framebuffer. Whether an app interfere is implemented as a VM hypercall virtio thing, IPC, or in-process client library is an implementation detail. What matters is the thickness of the API surface. We're in the middle of a secular trend from thick interface surfaces to thin ones. I don't see that as a bad thing. Thin, arms-length interfaces maximally decouple app and OS development. They encourage cooperation over explicit, stable, and versioned interfaces. They simplify the entire industry. The technological environment that generated the old thick interfaces doesn't exist anymore. Freed of its constraints, we can do better now.
- saagarjha 2y ago
  Are you going to pay for the extra RAM I need to run your VM too?
  - quotemstr 2y ago
    The success of Electron tells us that memory usage concerns are overblown. Memory is seriously dirty cheap nowadays. Time to spend a bit more to simplify the ecosystem.
    - saagarjha 2y ago
      Ok, first of all, what is going to ship is not just Electron but a whole VM plus Electron. Just like how people run the JVM in Docker or whatever, because nobody trusts any layer of their stack to actually be abstracted enough that they can feel comfortable with what is underneath. That’s going to be truly awful. Second, the “success” of Electron is like the “success” of online advertising. Nobody really likes it and it’s basically a local optimum in a deep pit that it’s unfortunate we’re stuck in. It’s just that economic pressures have pushed the market to this being something people tolerate rather than actively desire.
    - hollerith 2y ago
      I consider it a little perverse to say "simplify" and Electron in one sentence. But my main point is that memory requires power so adding memory to a machine shortens battery life (or increases weight due to larger battery). So far AFAIK no laptop maker has made a laptop that can power off half the RAM to decrease demand on the battery when only half the RAM is needed. (Also, I do not like apps built on Electron and do not use any.)
- synergy20 2y ago
  isn't that docker is for?
anaisbetts 2y ago
Here's a real, actual bug that we had in the old Slack for Mac app (which was Webkit-based, so effectively the same approach as Tauri et al) - some users, only on older versions of macOS, report that whenever they paste in a YouTube link, the embedded video has a pink tint. Tell me, how would you fix this bug?
- saagarjha 2y ago
  (I assume you’re talking about loading Slack in the website? That’s the only WebKit surface you have that I know about.) Let me turn the question around for you: why do you think shipping Electron will save you? Sure, maybe WebKit has a broken video decoder this year. What will you do next time when it’s the GPU driver? You already know what the answer is: you diagnose it as far as you can, report it upstream, and communicate the best you can with your users. You seem to have the mindset that every bug exists to be fixed, and that’s not true at all. They are all a tradeoff. It’s easy to go “oh if we bundle everything ourself we can shift more control to ourselves to fix bugs because more of the components are ours”. First of all, you actually have to do that: turns out plenty of companies operating at scale are unable to do that (have you looked at how often Discord updates their dependencies?). And even when you’re committing to doing this and follow up, you have to understand that you’re unconditionally shipping a worse experience to all your users in the hopes of solving saving some time for some small fraction of them. This isn’t something that I am completely against (for example, I advocate for shipping debug symbols to users-but that’s another long argument) but you also have to look back at yourself and go “ok we’re shipping 98% of the same code across platforms and supporting macOS Mojave takes an extra 2 engineer-days a year, maybe this is an OK state of things” rather than being absolutist about something you’re not achieving anyway.
  - whartung 2y ago
    > why do you think shipping Electron will save you? All of the videos will be pink, not just the macOS ones on an older Safari. At worst someone could dig into the Webkit (Chome?) distro and fix it and they can release a custom build for the short term before it gets incorporated, fixing "everyone".

quotemstr 2y ago

The phenomenon you're discussing is part of a broader trend towards simplifying development and deployment by just vendoring all dependencies, dammit. Fewer dependencies, fewer headaches, both for app makers and OS vendors. The sky didn't fall when Android stopped providing openssl and libstdc++ with the OS. Sharing centrally managed dependencies made some sense in the days of infrequently-updated boxed software, but now? Brute force has made the size advantage of sharing irrelevant. (People complain about Electron memory use, but still use it.) Security advantages? App makers are perfectly capable of shipping their own security updates now that we have cloud auto-updating whenever we want it. I just don't think that there's still a real technical case for Debian-style dependency sharing in general purpose operating systems and that we can save ourselves a lot of time and pain by getting out of our 1990s shared library mindset. and it's taken a lot of time and a lot of retirements to change this mentality.

lll-o-lll 2y ago
> App makers are perfectly capable of shipping their own security updates now that we have cloud auto-updating whenever we want it. A large third-party dependency chain is, in my opinion, the most problematic security risk in modern software. Secondly, automatic updates are how we got cloud-strike. I’m not advocating Debian style dependency sharing, but I am advocating for tight control and auditing over your dependency chain (which will mean building more in house). And allowing IT departments to control update rollouts.
0x000xca0xfe 2y ago
Centrally managed dependencies are invaluable for small/simpler apps. Not every program is backed by a company that provides continuous updates. And what happens if the updates stop? Yeah right you have a giant pile of half-broken, bug-ridden and outdated random libraries. I use some small Win32 and GTK+ utilities that weren't touched in years and they all just work, are nicely integrated into the system theme (even dark mode works without me lifting a finger) and use fresh and up-to-date dependencies courtesy of the OS.

deleted 2y ago

[deleted]

codelikeawolf 2y ago

You nailed it. Every time I see a new Electron replacement pop up that uses less resources, less disk space, etc., it's using the OS webview. I would argue that it's almost impossible to ship a reliable version of the app without resorting to polyfills and using only a fraction of the Web APIs available today. I tried Tauri out for a time tracking app that has a week input, and I ended up going back to Electron because the macOS webview (Safari) doesn't support it. If I use a framework that leverages the OS webview, can I use SharedWorkers? Nope. Atomics? Nope. WebGPU? Nope. You're kneecapped by the lowest common denominator (which is pretty much impossible to determine because there's no way to know the oldest version of the OS webview your users might have installed). Don't get me wrong, I applaud the efforts of the Photino devs, the Tauri devs, and the Wails devs. They're all very cool projects. But if you need to build something non-trivial with them, you're going to have a bad time. The resource usage and large binary size that comes with Electron is the price you pay for having a cross-platform app that doesn't break in weird and unexpected ways. I never see any kinds of warnings or caveats on these framework websites explaining the drawbacks of using the OS webview. Which means every time one of these comes out, I have to explain to the people that I work with why we can't just ditch Electron.

3836293648 2y ago

I can buy that using the OS-provided browser is a bad idea, but referencing slack is hardly confidence-inducing. Slack is by far the slowest and buggiest web app I've had the misfortune of being stuck with. And bundling it with chromium is an even worse idea given that the only way of getting half way decent performance with slack is opening the web version in Firefox (and specifically not Chrome). And yes, I've heard MS Teams is even slower, but I've never had to use it

deleted 2y ago
[deleted]
throwup238 2y ago
> I can buy that using the OS-provided browser is a bad idea, but referencing slack is hardly confidence-inducing. It would be worse. They could have said Microsoft Teams. > And yes, I've heard MS Teams is even slower, but I've never had to use it Oh, dear.

idle_zealot 2y ago

The way you capitalize words reminds me of the style used in newspapers and other writing from the 1800s. Is there a part of the world that still uses capitalization for... whatever you're doing? Or is that just a personal affectation?