8 ms·

At what point will the current trend to treat the browser and WebAssembly as a compile target for traditionally fat client applications raise the need for a bro

by zaphar 10y ago

At what point will the current trend to treat the browser and WebAssembly as a compile target for traditionally fat client applications raise the need for a browser package manager ala Apt or Yum? When will dynamic linking become a necessity because due to memory usage, disk space, and patches for 0day exploits in upstream libraries? It seems like the more the browser takes on the role of an OS the more it will need all the stuff that OS's have built up over the years to make it manageable.

pasta 10y ago
And the strange thing is: I can already start a VLC binary over the network via my file manager. A lot of people think we need to start rethinking the web. But as the poster points out: "but that’s what we have and here we go"
- zaphar 10y ago
  Yeah at some point we by default decided the benefits of just go to this URL as a way to install software outweighed the negatives. It wasn't even really a deliberate decision collectively. We solved problems in a locally optimal way but I suspect it's not the globally optimal solution.
jsight 10y ago
That is kind of the role filled by "npm" and "yarn". They are obviously a lot different from OS package managers, but ultimately they solve a parallel type of problem for the web.
- zaphar 10y ago
  Actually no. Those tools are development package managers not user package managers. Two very different use cases. A development package managers is part of how the developer builds the application. A user package manager is how the consumer of the application installs it while also managing all the shared libraries and installing security updates for each of the pieces.
  - jsight 10y ago
    You are absolutely right in a way. I guess my real point is that a "user package manager" isn't likely to be a thing that ever makes sense on the web.
matthewbauer 10y ago
The whole point of most of these projects I think is to avoid having to install anything. You want something to just show up without any user interaction. I think for the most part everything is just going to be statically linked.
bastawhiz 10y ago
We have (or had) that. Chrome is removing web app support (the Apps button on your favorites bar). Firefox removed their app support after FxOS died. Nobody wanted these things. Users didn't understand the idea. The APIs were clumsy. The framing of the apps added little value over a traditional web app. Portability was a joke. The best thing to happen to the web is service workers and the new world of "offline" APIs, like the push notification API. They allow pages to get the goodness of a desktop app without the downsides of installing a "native" app. (source: I helped build the Firefox Marketplace)
- zaphar 10y ago
  Those are more of an app store and less of a package manager. Apt and Yum solve a problem users don't know they have. The app stores solve the problem of obtaining and installing the application. They don't solve the problem of managing shared libraries and quickly updating those shared libraries. For an application like VLC this sort of thing become really important. More important than your typical email client or document editor.
  - bastawhiz 10y ago
    On the web though, you don't need the user to manage libraries. In the same way you don't install a web page, libraries are simple script tags pointing at URLs. Pages will never reference incompatible versions. Browser caching makes "sharing" of libraries transparent. What's there left to manage?
    - zaphar 10y ago
      Is this still true for an application like VLC compiling to WebAssembly that uses other downstream libraries? What if VLC uses downstream libx and Audacity also uses downstream libx and downstream libx has a critical 0day. I'm not super clear yet on how the WebAssembly build pipelines works. Is dynamic linking done through script tags? or are the binary blobs statically compiled? I'm genuinely curious here how this is all supposed to work. How does one ensure that downstream libx is updated for all of the WebAssembly applications that use them.

by zaphar 10y ago

pasta 10y ago

And the strange thing is: I can already start a VLC binary over the network via my file manager. A lot of people think we need to start rethinking the web. But as the poster points out: "but that’s what we have and here we go"

zaphar 10y ago
Yeah at some point we by default decided the benefits of just go to this URL as a way to install software outweighed the negatives. It wasn't even really a deliberate decision collectively. We solved problems in a locally optimal way but I suspect it's not the globally optimal solution.

jsight 10y ago

That is kind of the role filled by "npm" and "yarn". They are obviously a lot different from OS package managers, but ultimately they solve a parallel type of problem for the web.

zaphar 10y ago
Actually no. Those tools are development package managers not user package managers. Two very different use cases. A development package managers is part of how the developer builds the application. A user package manager is how the consumer of the application installs it while also managing all the shared libraries and installing security updates for each of the pieces.
- jsight 10y ago
  You are absolutely right in a way. I guess my real point is that a "user package manager" isn't likely to be a thing that ever makes sense on the web.

matthewbauer 10y ago

The whole point of most of these projects I think is to avoid having to install anything. You want something to just show up without any user interaction. I think for the most part everything is just going to be statically linked.

bastawhiz 10y ago

We have (or had) that. Chrome is removing web app support (the Apps button on your favorites bar). Firefox removed their app support after FxOS died. Nobody wanted these things. Users didn't understand the idea. The APIs were clumsy. The framing of the apps added little value over a traditional web app. Portability was a joke. The best thing to happen to the web is service workers and the new world of "offline" APIs, like the push notification API. They allow pages to get the goodness of a desktop app without the downsides of installing a "native" app. (source: I helped build the Firefox Marketplace)

zaphar 10y ago
Those are more of an app store and less of a package manager. Apt and Yum solve a problem users don't know they have. The app stores solve the problem of obtaining and installing the application. They don't solve the problem of managing shared libraries and quickly updating those shared libraries. For an application like VLC this sort of thing become really important. More important than your typical email client or document editor.
- bastawhiz 10y ago
  On the web though, you don't need the user to manage libraries. In the same way you don't install a web page, libraries are simple script tags pointing at URLs. Pages will never reference incompatible versions. Browser caching makes "sharing" of libraries transparent. What's there left to manage?
  - zaphar 10y ago
    Is this still true for an application like VLC compiling to WebAssembly that uses other downstream libraries? What if VLC uses downstream libx and Audacity also uses downstream libx and downstream libx has a critical 0day. I'm not super clear yet on how the WebAssembly build pipelines works. Is dynamic linking done through script tags? or are the binary blobs statically compiled? I'm genuinely curious here how this is all supposed to work. How does one ensure that downstream libx is updated for all of the WebAssembly applications that use them.