5 ms·

Only thing we need now is presentation/distribution. Download this stuff one time for the machine as a standalone progressive hybrid native/web app, and run as

Only thing we need now is presentation/distribution. Download this stuff one time for the machine as a standalone progressive hybrid native/web app, and run as an exe from there on. With auto updates. No browser involved. HTML5 games don't take off because of the presentation/distribution. The browser is the problem. Now that we have WebAssembly, performance is much less of a problem.

Klathmon 8y ago
I absolutely disagree. The browser is the solution to the presentation/distribution problem. I don't need to worry about installing the game, or worry about what OS I'm on or where it was installed to or anything else. I go to the URL, and the game downloads if needed, then plays. Updates, local caching and storage, and more is all taken care of. If I want to play with a friend on some multi-player game, I send them the link, and they go to it and start playing themselves. no "launchers" needed, no app stores which take a cut, no platforms which can decide that the game isn't suitable for their system, no app stores which can decide that the app is too close to something they offer and removing it, no expensive publishing costs, and you have multiple browsers to choose from if you don't like any one in particular.
- rafaelvasco 8y ago
  I disagree. But I understand your view. The thing is I don't want the game running IN the browser. I want it running standalone, but being web enabled and having the facilites it provides.
  - tyingq 8y ago
    The WASM folks have plans to deepen the browser ties with direct DOM access, tying threads to webworkers, GC that's tied to the browser js, etc. I can see why you want what you do, but it will get harder over time.
    - rafaelvasco 8y ago
      Unfortunate.
    - neurotrace 8y ago
      That's not quite true. They intend to create a way of interfacing with ANY GC which would then allow them to make APIs that call in to the DOM. None of this would tie it directly to browsers. The whole intent is to keep it platform-agnostic, last I heard. > An important constraint is that, while WebAssembly should allow tight integration with the Web, it should not bake in details or Web standards dependencies that prevent execution in a non-Web embedding. This suggests a design (called opaque reference types below) that hides the details of JavaScript and WebIDL behind Web-embedding-specific builtin modules. On the other hand, WebAssembly can define a set of native GC primitives that allowed portable GC code to be written regardless of the host environment. https://github.com/WebAssembly/proposals/issues/16 https://github.com/WebAssembly/proposals/issues/16
      - tyingq 8y ago
        That's encouraging. As far as I can tell, threading is currently webworker centric.
  - computmaxer 8y ago
    What? If it isn't in the browser, what's the difference between that and something you download on Steam?
    - rafaelvasco 8y ago
      For the user almost none. The difference is for the devs. If I want to make a cross platform game now, I have to worry about which Graphics api I will use, OpenGL, Direct3D, Vulkan etc. What sound api I will use. What Display, Input, abstraction I will use. Etc. If I could have a unified api and runtime abstracting all that already for me, making full cross platform games would be easier, assuming I don't want to use Unity. But that is of a much bigger scope that just WebAssembly. We already have that power, but we are chained to the browser. The discussion is to free that runtime from the scope of the browser. Decouple it. The final dream is having a unified, Desktop, Consoles (Ps4 and Switch) and Browser runtime with a unified API (where sensible). One can dream.
      - openbasic 8y ago
        One does not simply develop cross-browser. Different browsers have different issues with different graphics cards. As soon as you're not drawing a textured triangle anymore, things get hairy. Same for the audio API. And don't get me started on the sad state of WebRTC and websockets.
        beetwenty 8y ago
        Yes, it's just not viable to develop for browsers unless you have the maintenance budget for a moving target. I decided on that after living through the Flash era and trying HTML5 for a little while. The browser is backwards compatible only for certain kinds of applications.
        rafaelvasco 8y ago
        Well, yeah. I agree. You escape from several problems in native environments and find another several in the web.
- krapp 8y ago
  > I don't need to worry about installing the game, or worry about what OS I'm on or where it was installed to or anything else. Most people don't worry about that in any case. If I'm on Windows, I download the Windows version of whatever, and the installer does whatever. In a browser, you're just "installing" software to the cache. It's the same thing in a different wrapper. >I go to the URL, and the game downloads if needed, then plays. Updates, local caching and storage, and more is all taken care of. If I want to play with a friend on some multi-player game, I send them the link, and they go to it and start playing themselves. This is a good argument for HTTP as a distribution system, but you don't need a web browser for any of that. >no "launchers" needed, no app stores which take a cut, no platforms which can decide that the game isn't suitable for their system, no app stores which can decide that the app is too close to something they offer and removing it, no expensive publishing costs, and you have multiple browsers to choose from if you don't like any one in particular. Except the browser is the "launcher" and the site you download from being an "app store" for all intents and purposes, entirely capable of curating or charging money.
  - rafaelvasco 8y ago
    Couldn't have said it better myself.
  - Klathmon 8y ago
    >Most people don't worry about that in any case. If I'm on Windows, I download the Windows version of whatever, and the installer does whatever. In a browser, you're just "installing" software to the cache. It's the same thing in a different wrapper. I agree, except for the magnitude difference in time required in most cases. A web-app that takes more than 10 seconds to load is consitered broken to many. A desktop app that can go from "discovery" to "using" in less than a minute is consitered fantastic. Plus then there are update headaches. I genuinely believe one of the major reasons why the web is taking over is because every other platform makes the process of "installing" code such a difficult slow process. Not to mention the security issues with giving code access to desktop systems which traditionally are difficult for the average user to secure. And the fact that I don't ever think i've had a piece of installed software ever completely "uninstall" itself correctly. They always leave stuff behind. In a browser, a single "clear browsing data for this domain" gets rid of all of it, entirely. >This is a good argument for HTTP as a distribution system, but you don't need a web browser for any of that. But you do. Some platforms (like iOS) don't allow distribution over any methods other than their app store, or a browser. Still more heavily discourage distribution over HTTP (most linux distros). And most users will download the "installer" for a game via a browser in the extreme vast majority of cases, so why not cut out the middleman and just allow the game to be playable in a browser? There are also other benefits of a web-platform game, like the ability to "deeplink" inside the app. I can not only share a link to the game, but can easily share a link to a specific screen in the game, or can share a link to allow you to connect to my game. And that whole process is crawl-able for search engines, and easy to implement. Sure, it's possible to do with desktop software, but it's much harder in most cases, especially when you throw cross-platform into the mix. >...the site you download from being an "app store" for all intents and purposes, entirely capable of curating or charging money. While of course a specific site can act as a gatekeeper, that's not what I was talking about. Time and time again we see stories about how Apple removed some app from the app store, or some company pulls their subscriptions from being allowed to sign-up on iOS devices, or how some game makes their own app-store to get around the limitations on android, or even how most "app stores" don't allow adult content. That is the kind of stuff that the web-as-a-platform gets you away from. You aren't going to have Google removing your app because it's too adult, or Apple charging you a 30% fee for all subscriptions made on their platform. I'm all for streamlining this process to allow users like yourself that want a "local install" to get it, but I don't think we should throw the baby out with the bathwater here. Browsers give us a shitload of benefits, and the discovery and "install" process (or the lack of) is second to none. I think we can work with those benefits, and give users and developers the options needed for other formats if they want. For example, The microsoft store has started allowing PWAs to be listed, browsers could work with the OS and define some APIs that allow you to choose where to "install" a PWA or web game, possibly even allowing you to simply move it or uninstall it after the automatic "install" happens. We are finally getting away from the days where it would take tens of minutes to download and install software on a computer, where it would require you to give a considerable amount of trust to that software once you run it, and making it really hard to share content within apps with others. I don't see why you would want to go back. But now that I said all of that, I realized that I don't really know why someone would want to not have it. So I guess my question is why do you want a traditionally "installable" code? Is there something I'm missing here, or some assumption that one of us is making that is getting rolled in with this conversation?
- tracker1 8y ago
  The problem, as in this case is assets of > 400mb downloading every time you run the game. It would be better to have a browser extension (at least) to manage "games" or "large applications" ... maybe similar to the Chrome Apps attempt(s). So that you can choose to have it as an application where at least some manifest of assets could be held offline, maybe using webtorrents to share.
  - rictic 8y ago
    Why would it download the 400mb every time you run the game? There are caching and storage APIs in the browser. It's possible that there are some more controls needed for both the user and the site author over this storage space, but that's definitely not a fundamental impediment.
    - tracker1 8y ago
      I'm unsure if browsers will cache 400mb from a single site in a single file. Also, where are you going to cache it... all of said APIs would have to request to expand local storage interface... which may not be bad.
      - Klathmon 8y ago
        indexedDB can easily store gigabytes of data without issue. I've personally used it to do so before, and it will happily "cache" it for weeks at a time. There are several web apps which work entirely offline and cache all of their data using that API. devdocs.io is one of them. Like the parent commenter said, i'd welcome more control over the storage of that data, but it absolutely can and will cache large blobs like that.
        Gab_CV 8y ago
        Actually, indexedDB is used to cache/store the whole .pk4, but using small chunks of data (50MB or so). This works well in practice. The best would be that all browsers support the Chrome Filesystem API, but that's not for now
krapp 8y ago
>Now that we have WebAssembly, performance is much less of a problem. It will be, as long as we can stay away from the paradigm of Electron as the de facto runtime for Webassembly. Despite its name, Webassembly doesn't need to run in a browser, we can have executable WASM run in thinner native clients.
- rafaelvasco 8y ago
  Agree completely. The true power of WebAssembly will be realized when it gets completely free from the Browser.
- tracker1 8y ago
  Although I can agree in some respects... however, a browser gets you a LOT more than just a WASM platform... canvas + webgl can go a long way, but then why not get the reset of the rendering platform which gives you stylistic support of a hypertext/dom model that is well understood with cross platform engines for pretty much every platform out there. Creating compiled applications that look halfway decent is REALLY hard with compiled UI toolkits, for the most part. And really easy for browser based toolkits. While I don't appreciate the additional bloat of Electron itself, it is a nice option. I would like to see something similar be available as a cross-platform baseline, auto-updated like chrome. Node + Carlo could be an option, which would at least use the platform installed Chrome. In the end, something like Adobe's Air platform could be incredible, but run by a company that supported more modern JS, and rendering. My hope is that with MS changing Edge to use Blink's engine that something like this could evolve and be adopted by other platforms.
manigandham 8y ago
If there's no browser then there's no need for WebAssembly. You can already download binaries and run them, that's what a game install is.
- krapp 8y ago
  What webassembly provides is a bytecode format that multiple languages can target, that isn't owned by a corporation, and that's intended (as per their own docs[0]) to run both natively and on the web (with browser vendors already opting in.) This offers benefits over native code tied to an operating system, existing bytecodes and VMs tied to a specific language or company, and allows the possibility for applications to seamlessly operate on the web and offline. The only thing a browser offers is an HTML and Javascript context... which are necessary to run it in a webpage, but not really the entire purpose of webassembly as a concept. [0]https://webassembly.org/docs/non-web/ https://webassembly.org/docs/non-web/
- mattnewton 8y ago
  Sorta, I think go means “browser chrome” like the part isn’t the url bar and menus. Webassembly, assuming you use the browser engines, gets you some nice things sand boxing and true cross platform execution.
tree_of_item 8y ago
Eh? I don't really understand; a progressive web app is standalone, but of course the browser has to be involved, it's a web app.

Klathmon 8y ago

I absolutely disagree. The browser is the solution to the presentation/distribution problem. I don't need to worry about installing the game, or worry about what OS I'm on or where it was installed to or anything else. I go to the URL, and the game downloads if needed, then plays. Updates, local caching and storage, and more is all taken care of. If I want to play with a friend on some multi-player game, I send them the link, and they go to it and start playing themselves. no "launchers" needed, no app stores which take a cut, no platforms which can decide that the game isn't suitable for their system, no app stores which can decide that the app is too close to something they offer and removing it, no expensive publishing costs, and you have multiple browsers to choose from if you don't like any one in particular.

rafaelvasco 8y ago
I disagree. But I understand your view. The thing is I don't want the game running IN the browser. I want it running standalone, but being web enabled and having the facilites it provides.
- tyingq 8y ago
  The WASM folks have plans to deepen the browser ties with direct DOM access, tying threads to webworkers, GC that's tied to the browser js, etc. I can see why you want what you do, but it will get harder over time.
  - rafaelvasco 8y ago
    Unfortunate.
  - neurotrace 8y ago
    That's not quite true. They intend to create a way of interfacing with ANY GC which would then allow them to make APIs that call in to the DOM. None of this would tie it directly to browsers. The whole intent is to keep it platform-agnostic, last I heard. > An important constraint is that, while WebAssembly should allow tight integration with the Web, it should not bake in details or Web standards dependencies that prevent execution in a non-Web embedding. This suggests a design (called opaque reference types below) that hides the details of JavaScript and WebIDL behind Web-embedding-specific builtin modules. On the other hand, WebAssembly can define a set of native GC primitives that allowed portable GC code to be written regardless of the host environment. https://github.com/WebAssembly/proposals/issues/16 https://github.com/WebAssembly/proposals/issues/16
    - tyingq 8y ago
      That's encouraging. As far as I can tell, threading is currently webworker centric.
- computmaxer 8y ago
  What? If it isn't in the browser, what's the difference between that and something you download on Steam?
  - rafaelvasco 8y ago
    For the user almost none. The difference is for the devs. If I want to make a cross platform game now, I have to worry about which Graphics api I will use, OpenGL, Direct3D, Vulkan etc. What sound api I will use. What Display, Input, abstraction I will use. Etc. If I could have a unified api and runtime abstracting all that already for me, making full cross platform games would be easier, assuming I don't want to use Unity. But that is of a much bigger scope that just WebAssembly. We already have that power, but we are chained to the browser. The discussion is to free that runtime from the scope of the browser. Decouple it. The final dream is having a unified, Desktop, Consoles (Ps4 and Switch) and Browser runtime with a unified API (where sensible). One can dream.
    - openbasic 8y ago
      One does not simply develop cross-browser. Different browsers have different issues with different graphics cards. As soon as you're not drawing a textured triangle anymore, things get hairy. Same for the audio API. And don't get me started on the sad state of WebRTC and websockets.
      - beetwenty 8y ago
        Yes, it's just not viable to develop for browsers unless you have the maintenance budget for a moving target. I decided on that after living through the Flash era and trying HTML5 for a little while. The browser is backwards compatible only for certain kinds of applications.
      - rafaelvasco 8y ago
        Well, yeah. I agree. You escape from several problems in native environments and find another several in the web.
krapp 8y ago
> I don't need to worry about installing the game, or worry about what OS I'm on or where it was installed to or anything else. Most people don't worry about that in any case. If I'm on Windows, I download the Windows version of whatever, and the installer does whatever. In a browser, you're just "installing" software to the cache. It's the same thing in a different wrapper. >I go to the URL, and the game downloads if needed, then plays. Updates, local caching and storage, and more is all taken care of. If I want to play with a friend on some multi-player game, I send them the link, and they go to it and start playing themselves. This is a good argument for HTTP as a distribution system, but you don't need a web browser for any of that. >no "launchers" needed, no app stores which take a cut, no platforms which can decide that the game isn't suitable for their system, no app stores which can decide that the app is too close to something they offer and removing it, no expensive publishing costs, and you have multiple browsers to choose from if you don't like any one in particular. Except the browser is the "launcher" and the site you download from being an "app store" for all intents and purposes, entirely capable of curating or charging money.
- rafaelvasco 8y ago
  Couldn't have said it better myself.
- Klathmon 8y ago
  >Most people don't worry about that in any case. If I'm on Windows, I download the Windows version of whatever, and the installer does whatever. In a browser, you're just "installing" software to the cache. It's the same thing in a different wrapper. I agree, except for the magnitude difference in time required in most cases. A web-app that takes more than 10 seconds to load is consitered broken to many. A desktop app that can go from "discovery" to "using" in less than a minute is consitered fantastic. Plus then there are update headaches. I genuinely believe one of the major reasons why the web is taking over is because every other platform makes the process of "installing" code such a difficult slow process. Not to mention the security issues with giving code access to desktop systems which traditionally are difficult for the average user to secure. And the fact that I don't ever think i've had a piece of installed software ever completely "uninstall" itself correctly. They always leave stuff behind. In a browser, a single "clear browsing data for this domain" gets rid of all of it, entirely. >This is a good argument for HTTP as a distribution system, but you don't need a web browser for any of that. But you do. Some platforms (like iOS) don't allow distribution over any methods other than their app store, or a browser. Still more heavily discourage distribution over HTTP (most linux distros). And most users will download the "installer" for a game via a browser in the extreme vast majority of cases, so why not cut out the middleman and just allow the game to be playable in a browser? There are also other benefits of a web-platform game, like the ability to "deeplink" inside the app. I can not only share a link to the game, but can easily share a link to a specific screen in the game, or can share a link to allow you to connect to my game. And that whole process is crawl-able for search engines, and easy to implement. Sure, it's possible to do with desktop software, but it's much harder in most cases, especially when you throw cross-platform into the mix. >...the site you download from being an "app store" for all intents and purposes, entirely capable of curating or charging money. While of course a specific site can act as a gatekeeper, that's not what I was talking about. Time and time again we see stories about how Apple removed some app from the app store, or some company pulls their subscriptions from being allowed to sign-up on iOS devices, or how some game makes their own app-store to get around the limitations on android, or even how most "app stores" don't allow adult content. That is the kind of stuff that the web-as-a-platform gets you away from. You aren't going to have Google removing your app because it's too adult, or Apple charging you a 30% fee for all subscriptions made on their platform. I'm all for streamlining this process to allow users like yourself that want a "local install" to get it, but I don't think we should throw the baby out with the bathwater here. Browsers give us a shitload of benefits, and the discovery and "install" process (or the lack of) is second to none. I think we can work with those benefits, and give users and developers the options needed for other formats if they want. For example, The microsoft store has started allowing PWAs to be listed, browsers could work with the OS and define some APIs that allow you to choose where to "install" a PWA or web game, possibly even allowing you to simply move it or uninstall it after the automatic "install" happens. We are finally getting away from the days where it would take tens of minutes to download and install software on a computer, where it would require you to give a considerable amount of trust to that software once you run it, and making it really hard to share content within apps with others. I don't see why you would want to go back. But now that I said all of that, I realized that I don't really know why someone would want to not have it. So I guess my question is why do you want a traditionally "installable" code? Is there something I'm missing here, or some assumption that one of us is making that is getting rolled in with this conversation?
tracker1 8y ago
The problem, as in this case is assets of > 400mb downloading every time you run the game. It would be better to have a browser extension (at least) to manage "games" or "large applications" ... maybe similar to the Chrome Apps attempt(s). So that you can choose to have it as an application where at least some manifest of assets could be held offline, maybe using webtorrents to share.
- rictic 8y ago
  Why would it download the 400mb every time you run the game? There are caching and storage APIs in the browser. It's possible that there are some more controls needed for both the user and the site author over this storage space, but that's definitely not a fundamental impediment.
  - tracker1 8y ago
    I'm unsure if browsers will cache 400mb from a single site in a single file. Also, where are you going to cache it... all of said APIs would have to request to expand local storage interface... which may not be bad.
    - Klathmon 8y ago
      indexedDB can easily store gigabytes of data without issue. I've personally used it to do so before, and it will happily "cache" it for weeks at a time. There are several web apps which work entirely offline and cache all of their data using that API. devdocs.io is one of them. Like the parent commenter said, i'd welcome more control over the storage of that data, but it absolutely can and will cache large blobs like that.
      - Gab_CV 8y ago
        Actually, indexedDB is used to cache/store the whole .pk4, but using small chunks of data (50MB or so). This works well in practice. The best would be that all browsers support the Chrome Filesystem API, but that's not for now

krapp 8y ago

>Now that we have WebAssembly, performance is much less of a problem. It will be, as long as we can stay away from the paradigm of Electron as the de facto runtime for Webassembly. Despite its name, Webassembly doesn't need to run in a browser, we can have executable WASM run in thinner native clients.

rafaelvasco 8y ago
Agree completely. The true power of WebAssembly will be realized when it gets completely free from the Browser.
tracker1 8y ago
Although I can agree in some respects... however, a browser gets you a LOT more than just a WASM platform... canvas + webgl can go a long way, but then why not get the reset of the rendering platform which gives you stylistic support of a hypertext/dom model that is well understood with cross platform engines for pretty much every platform out there. Creating compiled applications that look halfway decent is REALLY hard with compiled UI toolkits, for the most part. And really easy for browser based toolkits. While I don't appreciate the additional bloat of Electron itself, it is a nice option. I would like to see something similar be available as a cross-platform baseline, auto-updated like chrome. Node + Carlo could be an option, which would at least use the platform installed Chrome. In the end, something like Adobe's Air platform could be incredible, but run by a company that supported more modern JS, and rendering. My hope is that with MS changing Edge to use Blink's engine that something like this could evolve and be adopted by other platforms.

manigandham 8y ago

If there's no browser then there's no need for WebAssembly. You can already download binaries and run them, that's what a game install is.

krapp 8y ago
What webassembly provides is a bytecode format that multiple languages can target, that isn't owned by a corporation, and that's intended (as per their own docs[0]) to run both natively and on the web (with browser vendors already opting in.) This offers benefits over native code tied to an operating system, existing bytecodes and VMs tied to a specific language or company, and allows the possibility for applications to seamlessly operate on the web and offline. The only thing a browser offers is an HTML and Javascript context... which are necessary to run it in a webpage, but not really the entire purpose of webassembly as a concept. [0]https://webassembly.org/docs/non-web/ https://webassembly.org/docs/non-web/
mattnewton 8y ago
Sorta, I think go means “browser chrome” like the part isn’t the url bar and menus. Webassembly, assuming you use the browser engines, gets you some nice things sand boxing and true cross platform execution.

tree_of_item 8y ago

Eh? I don't really understand; a progressive web app is standalone, but of course the browser has to be involved, it's a web app.