5 ms·

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

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

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