When the topic discussed is software that can run on any platform, you have to care about UNIX desktop, otherwise you're cheating - or at least not providing a solution to the problem as was stated.
"Browsers won't and should never have the full capabilities of native APIs. It's certain that many more applications will shift into web apps, but there are limits to what I'll want my browser to do."
Which given the increase in mobile OS across the planet and their use of native apps, is something I wish will turn the tide.
Once you run WebAssembly as a virtual machine providing a core API without a windowing system, it barely counts as a browser anymore.
There's nothing in its essence that makes it different from the virtual machines in Java or C# or Python, other than having several alternate working implementations, available in every device that runs a modern browser (true, the latest wouldn't count as "native", but nothing stops you from running a headless WebAssembly instance directly on the metal without the intermediate application layer).
The solutions you proposed (iOS, Android and UWP) may count as native, but they definitely don't count as "universal" in the same way that WebAssembly would.
There is a big difference from all other VMs, a lowest common denominator UI/UX across all devices, even the JVM does better in regards to integration with the host OS.
This has not changed since the HTML5 is going to change the world kind of thing, and I doubt WebAssembly will change that.
Simple stuff like Web Components are still pretty much a Chrome thing and WIP everywhere else, let alone more specific OS APIs.
Uh? Why would that make it any different from providing an "official" GUI API with the virtual machine, like Java Swing and MS XAML (or whatever Microsoft calls its current View stack nowadays)?
Are you talking about implementations not being there (yet, though that could change with time) or is there a fundamental difference in the platform architecture that I'm unaware of?
I am talking about the full stack from the lower layers all the way up, integration with peripherals, audio engines,GPGPU, 3D that doesn't look like Glide demos, ability to fully utilize any kid of wireless communication,composition engine, GUI components, security, 2D acceleration that is guaranteed to always work, ...
Doesn't UWP also try to provide all of that? The only difference I see is that HTML5 comes with a formally defined standard, so it is possible to build more than one implementation by different parties, while UWP is proprietary.
I don't understand why you think providing all those services in UWP is a good thing, but extending HTML5 + the Javascript VM to cover them would be a terrible idea.
> I don't understand why you think providing all those services in UWP is a good thing, but extending HTML5 + the Javascript VM to cover them would be a terrible idea.
It is not that is a terrible idea, it is that it will never happen, thus always being a 2nd class UI/UX.
I am still waiting for a version of WebGL that can actually fully use my graphics card, WebGL 2.0 surely isn't it yet.
Or for web components to be ready across devices and multiple browsers. How many years has Google been talking about them at Google IO now?
Never happen? Unreal Engine has been ported to WebAssembly. Sure it's not part of the standard, but it runs on the platform. I'm sure Vulkan could get the same treatment.
Once you have a development stack with a good toolchain and widely available on many platforms, many people will be interested , and it will grow. Having a standardization body that will incorporate the best is a good thing to have, but it's not a requirement for the platform to get the tech support by third parties (see what happened with Flash or Silverlight, which required a separate unsupported engine as a plugin). Having a single target will surely accelerate development?
