What about search engines?Well, I don’t have a good answer for this yet.
But I could imagine several technological solutions.
One solution is that we retain the separation of content and presentation.
The content is written in a standardised format such as, for example, HTML.
The presentation is managed by a WebAssembly application that fetches and displays that content.
This allows a web designer to have any arbitrary presentation using any technology he or she wants — no CSS is required, while search engines and users requiring different kinds of accessibility can still access the content.
Keep in mind that many WebAssembly applications aren’t meant to be textually accessible, such as games and many applications.
A blind person won’t get much benefit out of an image editor.
Another solution is that we invent an API which can as a WebAssembly module to provide a DOM of what it intends to render on the screen, for consumption either by a screen reader or search engine.
Basically there would be two kinds of presentation: one on a graphical canvas, and another that produces structured textual output.
A third solution is to enhance the canvas with metadata that a screen reader or search engine could use.
The WebAssembly is executed and content is rendered on a canvas with extra metadata that describes what was rendered.
This metadata would include, for example, whether an area on the screen is a menu and what options there are, or whether an area wants textual input, and what the natural ordering (aka the tab order) of the areas on the screen are.
Basically, content that was once described in HTML is now described as areas of a canvas with metadata.
Again, this is just an idea, and it might suck in practice.
What Could Have BeenIn 1995, Sun Microsystems released Java, with Java applets and a whole lot of fanfare.
For the first time, a web page could do something more interesting than <marquee> and animated gifs.
Developers could make applications run entirely in a user’s web browser… kind of.
They were not integrated into the browser, but rather implemented as heavy plug-ins and required an entire JVM to be installed.
In 1995, this was not a small installation.
The applets also took a while to load and used a lot of memory.
With our huge amounts of memory these days, this is no longer a problem, but in the first decade of Java’s life it made the experience tiresome.
Applets were also unreliable.
There was no guarantee they would run, especially if the user was using Microsoft’s implementation.
They were also insecure, which was the final nail in the coffin.
To the JVM’s credit, other languages eventually evolved to run on the JVM.
But now, that boat has sailed.
FutureSplash / Macromedia / Adobe Flash was also a contender, but a proprietary one, in a proprietary format with a proprietary tool set and a proprietary language.
I read that they did open up the file format in 2009.
Support was eventually removed from browsers as it was a security risk.
The conclusion here is that if you want your technology to exist on everybody’s machines, your security needs to be tight.
I sincerely hope that WebAssembly as a standard reacts well to security issues.
What’s Needed?WebAssembly is still in it’s infancy.
It currently runs code fine and the specification is at version 1.
0 with a freeze on the binary format.
SIMD instruction support is currently being worked on.
Multi-threading, via Web Workers, is also being worked on.
Tooling is available, and will continuously improve for the years to come.
Browsers already let you peek inside a WebAssembly file.
Firefox, at least, lets you view the WebAssembly bytecode, set breakpoints and view the call stack.
I hear that browsers also have profiling support.
Language support includes a decent set of languages — C, C++ and Rust are first-class citizens.
C#, Go and Lua apparently have stable support.
Python, Scala, Ruby, Java and Typescript have experimental support.
It might be an arrogant statement, but I truly believe that any language that wants to be relevant in the 21st century needs to be able to compile or run on WebAssembly.
In terms of API support to access external devices, the only API I’m aware of that’s made available to naked WebAssembly is WASI, which allows for the core functionality such as file and stream access to allow WebAssembly to run outside a browser.
Otherwise any API that accesses the outside world needs to be implemented in Javascript inside a browser.
This allows for almost everything an application needs, except for file access on the local machine, printer access and other novel hardware access such as non-standard bluetooth or USB devices.
“Naked WebAssembly” is not a necessary requirement for it’s success; it’s merely a minor optimisation to not require a browser to include support for HTML, CSS or Javascript.
I’m not certain of what would be required to make WebAssembly first-class citizens in a desktop environment.
You would need good copy and paste support, drag and drop support, localisation and internationalisation, window management events and the ability to create notifications.
Perhaps these are already possible from a web browser; often I’m surprised by what is already possible.
The spark that will cause the explosion is the creation of environments that allow existing applications to be ported.
If a “Linux subsystem for WebAssembly” is made, then a huge amount of existing open source software can be ported to WebAssembly.
It would need to emulate a filesystem — which could be done by having all the read-only parts of the filesystem be cached HTTP requests, and all the writable parts be either in-memory, remotely stored or using whatever file access a browser can provide.
Graphical support can be done by porting an implementation of X11 or Wayland to use WebGL (which I understand already exists as AIGLX?).
Some SDL games have already been ported to WebAssembly — most notably the official demo.
Once a JVM runs inside WebAssembly, a huge amount of Java software can run in a browser.
Ditto for other virtual machines and the languages that use them.
As with the huge world of Windows software, I have no answer.
WINE and ReactOS both require an underlying x86 or x86–64 machine, so the only option would be to get the source code and port it, or use an [x86 emulator](https://copy.
sh/v86/).
So then…WebAssembly is coming.
It is coming slowly, but all the pieces are now available on the browser you’re using right now.
Now we wait while infrastructure for targetting WebAssembly from various programming languages is built.
Once built, we will be freed from the tyranny of HTML, CSS and Javascript.
https://webassembly.
org/.