undefined | Better HN

0 pointsilaksh3y ago0 comments

I am very aware of all of that.

The idea that web assembly is not meant to be the platform to run primitives on stems from the political and technical approach initially used to get web assembly inserted into browsers. The basic concept is that it was much easier for people to accept if it was "only the compute part" and also practically speaking only made sense to leverage the extensive UI and other functionality of the browser. Which made it very easy to say it's just for compute.

It's amazing that people are still stuck on that. That just goes to the power of PR and poor adaptability of the average brain. Even Brendan Eich was in a web assembly issue wondering when they were going to add some kind of minimal UI functionality.

Look at for example the web assembly shell and WASI to see how input / out has reluctantly been added to make it so these systems can have some utility on the server.

The only real reason that there hasn't been something like a serious extension to WASI for UI things is because people accept the status quo. We will forever ship a large monolithic overlay operating system controlled by a single megacorp and everyone will use that.

Except for one "competitor" which actually is also mostly controlled by the same megacorp.

0 comments

soylentgraham3y 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

ilakshOP3y ago

No, what I am suggesting is to add the basic UI and audio stuff and leave it at that for a large class of applications.

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.

j / k navigate · click thread line to collapse