3 ms·

Have you actually shipped a complex codebase to the web? There are a TON of major issues which are just as bad: Old problem: Downloading New problem: Downloa

by pwang 13y ago

Have you actually shipped a complex codebase to the web? There are a TON of major issues which are just as bad: Old problem: Downloading New problem: Downloading. Large JS apps have to asynchronously load potentially very large codebases, every time the app is loaded Old problem: Installation New problem: Installation. What if the user has NoScript? AdBlock? Mobile Opera vs. Mobile Safari vs. Chromium vs. IE. Old problem: Special User Permissions; gate keepers New problem: Proxies. Websockets. Anti-virus software. On-machine firewalls. Corporate firewalls. "Special" toolbars and plugins that redirect the browser. The web is not a "software distribution platform". It is not a "distribution platform", because code is retrieved on-demand and run, and there is no simple way to "cache" that locally and re-run it. (Chrome App Store does not count, because it is antithetical to the model you've described). It is not even software in the traditional sense that you mean, because everything is inherently client-server, so most of the app lives on the server or in the cloud.

flohofwoe 13y ago
http://www.flohofwoe.net/demos.html http://www.flohofwoe.net/demos.html, these demos are about 150k to 250k lines of C++ code, and are about 700k to 1.5MB downloads, the same as zipped native executables. I'm also on the team which does a web-based MMO which is running for 3 years now (not done with emscripten though), so I'm aware of the problems :) It's still miles better then closed platforms.
ehsanu1 13y ago
None of the things you've listed are actually really problems, or have well-known solutions. HTTP caching solves the downloading problem for most classes of application. You can also run apps locally with app-cache and local storage (and in the future IndexedDB), though I'll grant that this isn't absolutely perfect today. I don't understand your "installation" issue. A user with NoScript knows how to turn it off for a web application they want to use, and generally do so. They just want to retain control over JS execution. AdBlock is not related to actual application delivery, but revenue generation, somewhat orthogonal. Having to support cross-platform quirks is also something that isn't unique to the web. If you support multiple versions of iOS for your app, you will hit similar issues. Not to mention if you wanted to actually be cross-platform and work anywhere other than iOS with the same app.
acdha 13y ago
Having worked on both traditional and web projects, I disagree with “just as bad”. In every case, what you're talking about is easier to solve on the web than off-line. Downloading: easily solved with browser caching. This is still faster than trying to, say, walk a very non-technical user through downloading and opening an installer. Installation: not an issue for most users. NoScript/AdBlock are a small percentage of users for most sites and since most of the web breaks that way, many of them have learned to recognize when their local system broke something. Permissions: the problem in both cases are the gatekeepers and every single “new problem” you listed was also an old problem of equal or greater impact. If the gatekeepers are determined and unaccountable, they'll block everything either way. The difference is that the web side has a better security model and is more likely to be open because you're following a known precedent – Google, Amazon, Facebook, etc. have created enough demand that even the most fascist IT departments allow HTTPS. This is not the case for the traditional desktop model where every local software install is considered independently.
Aldo_MX 13y ago
> New problem: Downloading. Large JS apps have to asynchronously load potentially very large codebases, every time the app is loaded Unless you use an old browser, this is not a problem anymore. http://www.w3.org/TR/html5/browsers.html#offline http://www.w3.org/TR/html5/browsers.html#offline

by pwang 13y ago

flohofwoe 13y ago

http://www.flohofwoe.net/demos.html http://www.flohofwoe.net/demos.html, these demos are about 150k to 250k lines of C++ code, and are about 700k to 1.5MB downloads, the same as zipped native executables. I'm also on the team which does a web-based MMO which is running for 3 years now (not done with emscripten though), so I'm aware of the problems :) It's still miles better then closed platforms.

ehsanu1 13y ago

None of the things you've listed are actually really problems, or have well-known solutions. HTTP caching solves the downloading problem for most classes of application. You can also run apps locally with app-cache and local storage (and in the future IndexedDB), though I'll grant that this isn't absolutely perfect today. I don't understand your "installation" issue. A user with NoScript knows how to turn it off for a web application they want to use, and generally do so. They just want to retain control over JS execution. AdBlock is not related to actual application delivery, but revenue generation, somewhat orthogonal. Having to support cross-platform quirks is also something that isn't unique to the web. If you support multiple versions of iOS for your app, you will hit similar issues. Not to mention if you wanted to actually be cross-platform and work anywhere other than iOS with the same app.

acdha 13y ago

Having worked on both traditional and web projects, I disagree with “just as bad”. In every case, what you're talking about is easier to solve on the web than off-line. Downloading: easily solved with browser caching. This is still faster than trying to, say, walk a very non-technical user through downloading and opening an installer. Installation: not an issue for most users. NoScript/AdBlock are a small percentage of users for most sites and since most of the web breaks that way, many of them have learned to recognize when their local system broke something. Permissions: the problem in both cases are the gatekeepers and every single “new problem” you listed was also an old problem of equal or greater impact. If the gatekeepers are determined and unaccountable, they'll block everything either way. The difference is that the web side has a better security model and is more likely to be open because you're following a known precedent – Google, Amazon, Facebook, etc. have created enough demand that even the most fascist IT departments allow HTTPS. This is not the case for the traditional desktop model where every local software install is considered independently.

Aldo_MX 13y ago

> New problem: Downloading. Large JS apps have to asynchronously load potentially very large codebases, every time the app is loaded Unless you use an old browser, this is not a problem anymore. http://www.w3.org/TR/html5/browsers.html#offline http://www.w3.org/TR/html5/browsers.html#offline