People seem way too optimistic about web assembly.
The elephant in the room is download size. A wasm photoshop, even if it works and performs well, is still a multi-gigabyte "web page". The browser is in no way set up to handle that.
Even simple things will be huge compared to javascript webpage. Let's say you write your todo app in Python with Qt bindings. Sure, wasm lets you run it on the web. You'll just have to ship Qt, the python interpreter, low-level graphics rendering code, shims for system calls in the standard library ... overall you'll end up way, way heavier than the javascript + DOM version. Probably 100MB or something.
wasm as it's implemented is going to have a very narrow band of usefulness. Basically, isolated computational modules (e.g. a physics simulation), and games. The games won't be, like, "Call of Duty on the web", they'll be little flash-type games with not too many assets. Creators will have to put a lot of effort into asset loading and compression to get around browser limitations.
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.
Exactly. 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.
You're comparing JavaScript apps, where the runtime is built-in to the browser, against WebAssembly apps written in other languages with large runtimes. That's nothing more than stacking the comparison to get the conclusion you want.
Not everyone writes their apps in JavaScript. That's a given, we have no choice but to accept this. Some apps or libraries are already written in another language, and it would be nice to run them in the web browser, so people do that. Some people make web games using Unity. Lots of reasons that this happens.
So you end up with emscripten + asm.js, delivering a minified JavaScript blob multiple megabytes in size, which must be parsed, compiled, and executed. WebAssembly reduces the size of the blob you have to deliver and makes the parsing + compiling steps much faster.
You may not like that, but you don't have to write apps that way. You can still write JavaScript if that's what you like. WebAssembly delivers improvements for people who weren't writing JavaScript in the first place, or for people who wish they weren't writing JavaScript.
> The elephant in the room is download size. A wasm photoshop, even if it works and performs well, is still a multi-gigabyte "web page". The browser is in no way set up to handle that.
So you split it into chunks and download the bits you need as you go.
Microsoft has already figured out how to do this -- you can run Office (the real, full Windows version) basically streaming from the Internet already.
> So you split it into chunks and download the bits you need as you go.
at last, the renaissance of the microcomputer programmers (like the COBOL renaissance of the mainframe programmers)! that kind of technique was common back in the 80s to get things done
That's funny - I stopped using Microsoft Office because of that very thing. I have Office '07 still for some minor graphical compatibility reasons, but generally speaking I use the bundled, free, offline, WordPad/NotePad, LibreOffice, and/or AbiWord.
WebAssembly APIs give you access to the compiled code of a module. A Web page can store that code locally, e.g. using IndexedDB, so it doesn't have to be downloaded and recompiled again. Thus, the first time you visit a page, you're effectively installing the app. See https://developer.mozilla.org/en-US/docs/WebAssembly/Caching... for details.
We already are getting desktop apps with HTML based UI [1].
A wasm photoshop would cache the download, use a HTML front end, and be written in a compiled language.
Sure you'll be able to use the tech to do stupid things like running a python interpreter inside a WebAssembler virtual machine. But then your argument is just that if you use the tech to do stupid things you'll get stupid results. Total straw man.
Given an enormous WASM binary one could write a small bootstrap binary that fetches the binary and stores it in local cache. Future updates to the mega-binary can be done with some kind of delta-diff mechanism.
Now, let's say you rely on Qt in some manner. Well, likely the WASM package resides at some known URI and is subject to standard browser caching.
A more likely and practical outcome is using the HTML5 DOM UI instead of Qt, and JavaScript instead of Python, etc. Native web technologies the browser already has support for.
Using web platform technologies can actually reduce the download size over native apps. In the game I am working on, written in C and compiled using emscripten, as a rough measure, the equivalent program compiled natively totals an executable size of about 2 MB, not including texture resource data. An optimized asm.js build is about 950 KB and WebAssembly only 580 KB, this includes the .html shell, .js loader, and .wasm binary itself.
This is not a completely fair comparison because I compile out some native code not relevant to the web, and vice versa, but here are a few specifics of where I believe the gains may come from:
curl: the native C app uses libcurl for fetching resources from HTTP and HTTPS servers, but on the web, we have XMLHttpRequest and HTML5 Fetch. Emscripten provides the built-ins emscripten_wget() and emscripten_async_wget() for these purposes. No need for shipping HTTP and SSL stacks because the browser already has it included.
glfw and glew: libraries for wrangling OpenGL, emscripten has its own implementation which largely simply bridges to WebGL or other HTML5 APIs, a very thin layer. SDL, too.
databases: many apps bundle their own copy of SQLite, often as the single C file amalgamation. I used to, too, even through emscripten and it worked fine (there is even a pre-packaged emscriptenified sqlite.js), admittedly I haven't looked into it much yet but the web platform supports IndexedDB built-in, no extra dependency needed.
JSON: how many JSON encoders/decoders are there out there, separate copies in all of the apps? On the web, you can rely on JSON.stringify and JSON.parse (from JavaScript, but all functionality is bridged through WebAssembly anyways).
We may see a resurgence in "small C libraries" targeting WebAssembly. There is a growing trend of header-only libraries, especially the popular stb: https://github.com/nothings/stb#stb_libs and there is a growing list here: https://github.com/nothings/single_file_libs I consult to find tiny libraries appropriate for linking into a web-based C application. lodepng (for decoding PNG images) and miniz (for reading and extracting zip files) are about the only substantial dependencies I have beyond what is in the emscripten standard library. Everything else is provided by the browser, the web has grown to a surprisingly powerful and complete platform.
The elephant in the room is download size. A wasm photoshop, even if it works and performs well, is still a multi-gigabyte "web page". The browser is in no way set up to handle that.
Even simple things will be huge compared to javascript webpage. Let's say you write your todo app in Python with Qt bindings. Sure, wasm lets you run it on the web. You'll just have to ship Qt, the python interpreter, low-level graphics rendering code, shims for system calls in the standard library ... overall you'll end up way, way heavier than the javascript + DOM version. Probably 100MB or something.
wasm as it's implemented is going to have a very narrow band of usefulness. Basically, isolated computational modules (e.g. a physics simulation), and games. The games won't be, like, "Call of Duty on the web", they'll be little flash-type games with not too many assets. Creators will have to put a lot of effort into asset loading and compression to get around browser limitations.