3 ms·

It's surprising how big programs are. Very basic android apps can weigh in at 30-60mb, and I've noticed cordova apps are particularly bad for that. Imagine need

by shubb 9y ago

It's surprising how big programs are. Very basic android apps can weigh in at 30-60mb, and I've noticed cordova apps are particularly bad for that. Imagine needing to pull that much data every time you visited a new site. We're already seeing this weird situation where websites that are perfectly usable in urban areas become impossible to use in the mountains. Urban telcom networks can be upgraded to make a 60mb runtime feel reasonable, but a lot of rural networks don't even work for todays sites.

notheguyouthink 9y ago
> It's surprising how big programs are. Very basic android apps can weigh in at 30-60mb, and I've noticed cordova apps are particularly bad for that. Imagine needing to pull that much data every time you visited a new site. Bit of a straw man Imo. WASM is specifically designed with page load in mind. It's why the garbage collector specification is so important, as languages with GCs want to use WASM but they don't want to ship their own for fear of slowing down page speeds. > We're already seeing this weird situation where websites that are perfectly usable in urban areas become impossible to use in the mountains. Urban telcom networks can be upgraded to make a 60mb runtime feel reasonable, but a lot of rural networks don't even work for todays sites. I agree completely, though for this I blame the companies/devs targeting a specific audience more than anything. Ie, I don't think it's the fault of "the modern web" or what languages/etc we use today for slower page speeds. For the same reason I don't blame languages we have today for desktop applications that aren't as "fast" as they could be. We have more RAM than we did 20 years ago, and conversely programs use more available RAM. The program might be doing a "better" job (hard to measure, but I imagine UX is the main concern), or it might be doing a worse worse job.. but at the end of the day, developers took the opportunity to use languages/frameworks that used more RAM, for one reason or another. So, just like the RAM, higher internet speeds and faster browsers have led to developers using more bandwidth than ever before. We use just as much as we can get away with, and always will. Sure, WASM may change our idea of what is acceptable, but I don't think it will by too much. We're impatient beings, we want the damn page to load fast as hell. How willing do you think the ~2B Facebook users are to wait 30s while it downloads hundreds of MiB of some FB WASM app? I think people would flip out. As an aside, what I think will be really interesting, will be compiling normal non-web apps WASM, as a deployment target for systems. Hypothetically, it could be the new "native" and vastly easier to deploy to for all OSs. Not intended to run on web, but still WASM. Talk about cool, Imo
- kodablah 9y ago
  > As an aside, what I think will be really interesting, will be compiling normal non-web apps WASM, as a deployment target for systems. Hypothetically, it could be the new "native" and vastly easier to deploy to for all OSs. Not intended to run on web, but still WASM. Talk about cool, Imo Yup, WASM ports to non-web archs quite well. The abstraction overhead in most cases is very minimal.
mikewhy 9y ago
On Android specifically, most Cordova apps include a plugin that lets them use a consistent, up-to-date webview for the platform. It bloats the .apk size by quite a bit. From maybe two megs to about 20. That wouldn't be needed in WASM.
- shubb 9y ago
  Browser inconsistencies are the 2nd worst part of web development. Are you sure you wouldn't want to render your site in a consistent 'browser in a browser' if you could?
VHRanger 9y ago
> Imagine needing to pull that much data every time you visited a new site. Did you ever profile websites? Loading a NYT article without adblockers and script blockers loads up around that much data

by shubb 9y ago

notheguyouthink 9y ago

> It's surprising how big programs are. Very basic android apps can weigh in at 30-60mb, and I've noticed cordova apps are particularly bad for that. Imagine needing to pull that much data every time you visited a new site. Bit of a straw man Imo. WASM is specifically designed with page load in mind. It's why the garbage collector specification is so important, as languages with GCs want to use WASM but they don't want to ship their own for fear of slowing down page speeds. > We're already seeing this weird situation where websites that are perfectly usable in urban areas become impossible to use in the mountains. Urban telcom networks can be upgraded to make a 60mb runtime feel reasonable, but a lot of rural networks don't even work for todays sites. I agree completely, though for this I blame the companies/devs targeting a specific audience more than anything. Ie, I don't think it's the fault of "the modern web" or what languages/etc we use today for slower page speeds. For the same reason I don't blame languages we have today for desktop applications that aren't as "fast" as they could be. We have more RAM than we did 20 years ago, and conversely programs use more available RAM. The program might be doing a "better" job (hard to measure, but I imagine UX is the main concern), or it might be doing a worse worse job.. but at the end of the day, developers took the opportunity to use languages/frameworks that used more RAM, for one reason or another. So, just like the RAM, higher internet speeds and faster browsers have led to developers using more bandwidth than ever before. We use just as much as we can get away with, and always will. Sure, WASM may change our idea of what is acceptable, but I don't think it will by too much. We're impatient beings, we want the damn page to load fast as hell. How willing do you think the ~2B Facebook users are to wait 30s while it downloads hundreds of MiB of some FB WASM app? I think people would flip out. As an aside, what I think will be really interesting, will be compiling normal non-web apps WASM, as a deployment target for systems. Hypothetically, it could be the new "native" and vastly easier to deploy to for all OSs. Not intended to run on web, but still WASM. Talk about cool, Imo

kodablah 9y ago
> As an aside, what I think will be really interesting, will be compiling normal non-web apps WASM, as a deployment target for systems. Hypothetically, it could be the new "native" and vastly easier to deploy to for all OSs. Not intended to run on web, but still WASM. Talk about cool, Imo Yup, WASM ports to non-web archs quite well. The abstraction overhead in most cases is very minimal.

mikewhy 9y ago

On Android specifically, most Cordova apps include a plugin that lets them use a consistent, up-to-date webview for the platform. It bloats the .apk size by quite a bit. From maybe two megs to about 20. That wouldn't be needed in WASM.

shubb 9y ago
Browser inconsistencies are the 2nd worst part of web development. Are you sure you wouldn't want to render your site in a consistent 'browser in a browser' if you could?

VHRanger 9y ago

> Imagine needing to pull that much data every time you visited a new site. Did you ever profile websites? Loading a NYT article without adblockers and script blockers loads up around that much data