4 ms·
Except that the download size for an application of the same complexity in JS and Wasm looks like it will be smaller in Wasm. There are plenty of demo games mad
by sqeaky 9y ago
Except that the download size for an application of the same complexity in JS and Wasm looks like it will be smaller in Wasm. There are plenty of demo games made in Wasm that play great already. Doing the same thing as those demos requires larger JS and is slower in JS.
This just expands on what can be done now. No one is claiming this will fix everything, it will just allow more than we have now and leverage many of the advantages of native development.
As for photo shop, why does a Wasm application need to be structured the same way as a desktop app? Desktop apps shipped all the the software in a single download because that download came from a disc or was expected to be used after being disconnected from the Internet. Why not download the functionality piecemeal? Download a small set of libraries that enable core functionality, then download modules as they are requested. When the user clicks a menu or button go get the code that makes the functionality behind that work. I am not saying break up every button, but if there is a new screen of group of functionality, make that a module then go get that.
In a video game it could be broken into levels or regions the in game map. In gaming paged loading is a solved problem, it seems like it could be applied here. The next level or nearby regions can be downloaded while the player explores this one.
- astrodust 9y agoExactly. If it's a packaging problem, we'll just need to be smarter about how we package things. Shipping Photoshop as a unified blob of WebAssembly is a dumb idea, just as having the executable load in every single DLL it might ever need is ridiculous. These things are fetched on demand.