|
|
|
|
|
|
by soylentgraham
1514 days ago
|
|
|
So, your complaint about wasm is that to make it useful we have to bundle it with a browser full of 1000's of APIs. And your solution is... start bundling Other APIs (mouse, keyboard, presumbly touch, a frame buffer) into wasm runtimes? Then I guess later people will also want, midi, serial/pipes, audio, simple GUI, shaders, opengl, accessibility, screen readers, sockets, account sign in, webcam acess, notifications ... All in a nice cross platform bundle |
|
|
Then the rest of the features should not be one monolothic bundle. Because what that does it make it so that you have to implement every API in order to be compatible with the platform. Which is impossible unless you are a large corporation.
The platform should be carefully explicitly designed to allow subsets of functionality to be implemented and distributed.
Again, starting with the very most basic UI stuff as one common chunk. Without all of the other features and devices.
The point of this is to make it feasible to have many implementations of different types of browsers or subsets of functionality. This prevents us from being locked into a single dominant vendor or two.
The information browsing can actually be the first subset of functionality. Very simple small vector images and a relatively small amount of RST or markdown. Many different groups can make information browsers.
Then you have the next level up / type of functionality which is basically web assembly SDL. This would be used separately but in conjunction with the information browsers.
You could standardize on another set of functionality with shaders and networking support. Or, if you do it right, it may be possible to create a common web assembly interface for each feature, and package up the additional features into something like device drivers which could be shared across "extended" browser implementations. This would allow for diversity of extended media browser implementations as well as alternative "drivers" to be available.