Just as it is in the desktop: you have loads of languages, libraries and runtimes. I don't really see the problem with the same happening on the web. If there is openness to diversity, chances are higher that quicker evolution will happen over time.
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.
> 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
> 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.
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?
