> "Web apps" could potentially go away

I prefer to think of it instead as native apps going away. Or rather, the web becoming indistinguishable from native.

If native apps start being run on WASM, and web apps start being run on WASM, and the web continues to gain access to more and more "native" APIs... it may not be long before there's basically no difference between a native app and a web app, from the end-user _or_ developer's perspective.

I feel like this won't really take off until we have something other than a web browser, or something that just feels different from a web browser, which is optimized for WASM applications, and which includes package management. Caching a WASM application locally is not much different than downloading a standalone native binary.

Yes! Get rid of the chrome, navigation buttons, etc. and give us a pseudo-VM that runs the browser as we know it as an “app”. I hope WASM and the like might eventually lead us there.

It makes sense if the web is going to be divided up between "documents" and "applications" (which it is, whether anyone likes it or not) not to run the applications in an environment designed to display documents.

Bonus points if the default is to download, cache and update the source code and "installation" is just local compilation to an appdata folder or something, similar to what browsers do with HTML, CSS and JS, rather than just download a blob of bytecode. That would make the FOSS people happy.

I have the suspicion that one possible future of HTML is to be a legacy delivery wrapper for WASM code and a <canvas> element.

I hope not as HTML has accessibility built in while canvas doesn’t. No need to take a step backwards on this. I’m okay with rendering to canvas but long as accessibility is taken into account. (Hint: most of the time it is not.)

I've said the same, but you just know somebody comes along and says "If we render our entire site into a <canvas> it'll make ad blocking more difficult," and then poof there goes the last 20 years of work on accessibility.

We can port webkit to wasm, so our developers won't have to deal with browser inconsistencies anymore :)

Yeah, and V8, so we could just write JavaScript again and wouldn't have to deal with WASM. With a bit support from WASM and a few tweaks to V8 it could run near native JavaScript speed. Let's call it JavaScript paravirtualization.

Interpreters can go a long way, but JIT code generation is required for really fast dynamic language implementation. That's quite a bit off for WebAssembly: https://github.com/WebAssembly/design/blob/master/FutureFeat...

If you strip out the legacy cruft it should be much faster. Reduce it to just the components used!

If I understood properly: yes, I do share the bitterness.

<troll> Look at us introduce this great new lang! It will potentially get rid of 99.99% of the current web developers and prevent any future script kiddies from getting in the game!

Behold the speed of our sealed box environment little jimmy!

Stay tuned for next weeks episode of Tech%20Elitism where we cover DRM for the web and public discourse policing!

Oy, that has to be the most depressing thing I've read all day.

Agreed. There will also be the "This will prevent scrapers" excuse. Whatever the silly rationalization for all-Flash websites was will be invoked, as well.

Most ad blocking is about intercepting specific urls, which can work at a layer below javascript.

They can also do server side ads and make the url indistinguishable from another image asset. They haven't, so it isn't 'dire' enough yet.

Good luck for that site getting indexed by Google ;)

Just like with AJAX sites, Google will simply support it.

But writing third-party search engines will become even more impossible.

OCR is really not that hard to do.

For english. Do it reliably for many 27 languages, with many different fonts, and the results are useless.

Even Google’s OCR utility can’t reliably detect German Umlaute in fancy fonts.

HTML is also much a more convenient encoding for content than writing on the canvas. It's fully declarative¹ and everything.

Yet, plenty of people already prefer to send you a black page and manually write everything on the DOM's document. I certainly do not understand them, but they are way too common.

1 - You just write your content, and it's there. There isn't more declarative than that.

HTML isn't great for application code. That's the issue, and anyone targeting WASM and canvas would be looking to recreate desktop apps on the web, not traditional websites.

Yes, it's bad for applications. But that does not explain why people send their text based pages as javascript.

> But that does not explain why people send their text based pages as javascript.

Probably because they're using front-end javascript frameworks which do that, and because they were taught that this is the best and most efficient way to render anything on the web. No one wants to make a special case for text because it seems inelegant.

But it's not the best and most efficient way to render everything. If you have a mostly static site, you don't need the front-end framework.

Canvas is too slow and handles text rendering poorly. If browsers really want to take another step in that particular direction, they're going to have to expose a lower level API for graphics and text rendering.

Yes, something like OpenGL.

Maybe. OpenGL has a lot of history and baggage. I'm pretty sure the current browser engines don't use OpenGL for 2d graphics. I think they still use Skia (Chrome) and Cairo (WebKit). It could be as "easy" as allowing calls to be made directly to those graphics libraries in WebAssembly.

Skia makes use of OpenGL, DirectX or Vulkan.

In any case, it should be hierarchical. It should be simple and efficient to move an object and all its children around.

I think you're missing the point. An object and child hierarchy is too high level for what I'm suggesting. Just expose the graphics library and let the programmers handle the rest. If you want something hierarchical that's simple and efficient to move an object and all its children around, great. You write that for your applications. Make it into a framework if others want to use it. But if somebody wants to use a different approach for their application, they should be able to do so.

Well, I'm all for a low level approach. But going a little higher allows the GPU to handle a lot of things. Or do you propose to incorporate something like CUDA/OpenCL into WASM?

SVG perhaps?

Say... WebGL?

Same here.

I am beting once WebAssembly gets mature enough, we will get the revenge of plugins.

Nothing intrinsically wrong with plugins that are instantly available on every platform.

Hope you keep being positive when Flash, ActiveX, Java, Silverlight get reimplemented in WebAssembly.

That would actually be fantastic. We'd get to preserve all the old stuff built with them, while running it in the browser's sandbox rather than giving it full access to the machine.

I don't think so, at least not from non-professional content producers. There will still be a desire to have an easily written, shared, and rendered document upon which you can give your thoughts.

HTML has always been best at that, and will still be good at that in the future. The only contender I know of would be markdown, which fulfills many of those needs while being even easier to write. Its greatest pitfall in a contest against HTML is that it is by design non-standard, as it is meant to be a pre-render stage document, and presumably your render stage will smooth out any non-standard markdown elements, giving you a standard document in a format like HTML.

Alas poor applets, they were before their time.

The web is mostly documents, with a few apps sprinkled here and there. HTML will likely be around, and in good use, for a long time.

Even the apps will use HTML's model via their DOM tree.

Yes, and there will be a default WASM code that interprets and renders the rest of the HTML! (in case anybody still wants to use HTML as W3C defined it).

It can't be that and that alone unless browsers somehow decide not to support the rest of HTML... which seems very unlikely.

I am also very interested in learning more about using WebAssembly as a primary deployment target for desktop applications. Recently when I was working on a cross-platform C++ application using Qt and boost, a major pain point was in understanding the different packaging conventions of the operating systems.

If WebAssembly takes off, and is available on Windows, macOS, and Linux, would it be possible for me to build just a single binary from a C++ compiler which could work natively on all three operating systems? Would the WebAssembly project build the necessary infrastructure (linkers, dynamic loader, etc) for this to work?

In theory, yes, but WebAssembly current has put little effort on standardizing packaging and ABIs. That work is in progress here: https://github.com/WebAssembly/tool-conventions but is still very early. You'd then need each of these platform exposing a standard set of imports to WebAssembly binaries because from the compiler's perspective WebAssembly looks like an OS with a virtual ISA, so these embedder imports are kind of like an OS' syscalls. That's a lot of work, isn't very advanced yet, but in theory is all possible and WebAssembly was explicitly designed to make it possible.

I'm actually working on an effort in this space. Specifically we're at the point where it's time to stand up a libc in a non web embedding.

If anyone is interested in the effort they should let me know.

I'd honestly just start with musl libc. The one Emscripten supports mostly just imports the same syscalls as Linux, with some ugliness to be able to do some DCE. If you clean that up your embedder will only need to implement those syscalls.

I am working with musl, however not the one with emscripten. That one is heavily modified farming out significant parts to the javascript runtime. It is a goal to provide a minimal surface area for embeddors and part of that is not requiring a JS runtime.

Please contact me privately. My email is in my profile. Thanks!

WebAssembly itself is just (more or less) an instruction set, not a complete runtime platform. It doesn't define APIs for rendering, audio, input, filesystem access, networking, etc...

Electron provides all that, but at the very high cost of shipping a complete browser runtime with your app.

Yup, we need an stdlib (and not libc)

Oh don't you worry, that will come and we'll be free of that ugly JavaScript thing.

You are lucky, Java 9 was just released.

Now you can ahead-of-time compile any JVM project into a single executable, it will run on all platforms, and it will have nice UI toolkits (JavaFX is quite awesome).

Even better, with Truffle + Graal in Java 10 also native interoperability with basically every other language is coming, so you can basically combine this with every language.

Write once, run everywhere always has various tradeoffs. The closer you get to fundamental differences in operating systems, the more platform-specific code you need.

UI, for example, is hard to make platform independent if your application needs to look and feel native; or needs to plug into platform-specific features.

What would be useful is a way to easily call WebAssembly libraries from native applications. This way common business logic can be written cross-platform; but the parts of an application that need to remain native are left native.

No, because at the least all three have different executable formats (PE, Mach-O and ELF respectively). I suppose it might end up being possible to ship some sort of HTML + WASM bundle that they all know how to interpret if it became common enough.

If you google around, you'll find that POCs exist - qt apps on the browser in canvas tags. Accessibility nightmare but otherwise a dream come true in the so called enterprise. Can't wait for this tech to mature a bit more.

We had that in the 90s. We called it Java.

I'm quite excited about WASM (as I was, admittedly, about Java Applets in the 90s), but this is a question that haunts me. I wish someone with better understanding of WASM and Java than me could write up why byte code delivery to a sandboxed VM in the browser failed in the 90s and why we should believe it will succeed now, or what exactly WASM brings to the table that Java didn't.

I think it mainly failed because Sun basically abandoned it. Security was not the issue I think (Flash was the same, maybe worse, still widely used) but the UX was quite terrible and never really improved: You had the jvm with its long startup times which was more than noticeable in the 90s and early 2000s. Applets always felt very alien inside a Website and using the applet simply to call into optimized code from JS was, while possible not really what it was used for.

Security maybe more of an issue today but WASM probably is not worse than JS in that regard (basically it's just another turing complete language). As others have said APIs are more problematic, which I suspect will ever get worse while browsers further and further try to transform from document viewers to application runtimes (think of such "brilliant" ideas like WebUSB). WASM is not the key issue here, it's running untrusted code on the client which, even if it's sometimes not outright harmful takes control away from the user in one way or antother. In the end the main difference is that it's now a feature of the Browser rather than a plugin which has a hard time to fit in nicely.

Virtual machines tend to take a while to initialize, for Java in part to verify the code.

If it were just the bytecode then it would not have failed. JVM bytecode and WASM have plenty of similarities. What cost Java is the stdlib surface area and security model. Also that it is a separate runtime was annoying, like Adobe with Flash, there was one primary vendor.

So many JVM bugs and a huge stdlib. WASM has no real lib, and when it does, it's security model is already restrictive... there's no disk, network, threads (yet), etc.

Along with the other responses, the JVM imposes its own object model on any language implemented on top of it. WebAssembly does not, so it is vastly simpler and more flexible.

For example, you had to rewrite your apps to run as Java applets. You do not have to rewrite things to run on WebAssembly- all the existing C, C++, etc. code is compatible, up to the platform API.

This is of course assuming that the WASM GC proposal doesn't require a specific object model to get host GC interop.

So far it doesn't look like it will: https://github.com/WebAssembly/gc/blob/master/proposals/gc/O...

But either way, I'd still take "use this object model for host GC interop" over "use this object model or leave the platform."

A big reason Java failed was that it was painfully slow. Starting the VM and importing everything took tens of seconds on old machines, and still takes a couple of seconds on new ones.

Then people started worrying about security and all of the Java applets broke because nobody wants to go through that code signing process.

I have to admit I don't know much about the security model of WebAssembly, but I wonder if it will become as annoying as Java in the future.

>I have to admit I don't know much about the security model of WebAssembly, but I wonder if it will become as annoying as Java in the future.

WebAssembly in browsers executes similarly to javascript in the same sandbox with the same platform APIs with the same kind of delivery methods, so I don't think we have that to worry about.

That's very much the question indeed. All that's really needed for a native experience on both Android and iOS is a native ARM binary, optionally bundled with webkit, but then that's what native runtime environments for Android and iOS have already built-in.

Java only had one closed source implementation and had many security issues during its life. It wasn't designed for proper sandboxing and for having multiple implementations in the first place. And its communication with the rest of the browser was done through a slow and ugly channel (IIRC everything had to be sent around as strings).

> Java only had one closed source implementation...

This is not true. There were alternative implementations from very early on, most notably the Microsoft one.

> ...and had many security issues during its life.

True, but WASM hadn't had much of a life so far, so we will see.

> And its communication with the rest of the browser was done through a slow and ugly channel (IIRC everything had to be sent around as strings).

From what I understand, so far, every communication between the browser and WASM has to go through JavaScript and from what I see I think it's ugly as well[1].

Don't get me wrong, I'm not at all against WASM, but I see the very same arguments for and against WASM I remember from the 90s about Java. This is especially true when it comes to security. Java was designed with a sandbox and a bytecode verifier from very early on.

[1] https://kripken.github.io/emscripten-site/docs/porting/conne...

> most notably the Microsoft one.

My bad. However it was closed source too, and abandoned rather quickly.

> True but WASM hadn't had much of a life so far, so we will see.

It uses the same security model as JS, which is much more mature than VMs not designed for so much exposure to random third party code.

> from what I see I think it's ugly as well

Ugly but not slow. WASM memory can be read and written directly from/to a typed array, instead of converting strings. Since it's fast enough, one can make less ugly APIs wrapping that behaviour.

> Java was designed with a sandbox and a bytecode verifier from very early on.

They probably protected the code itself from escaping the sandbox, but not the environment (all the API in its complex glory). WASM on the other side is exclusively allowed to talk with JS (for now, at least), therefore the only API level bugs are in JS, not in WASM.

> The goal for WASM is to enable browsers to run untrusted code in a trusted environment. Our approach is to be conservative at first, and to add functionality when it can be added securely. The intent is to prevent code from inspecting or changing files on the client file system. Also, the intent is to prevent code from using network connections to circumvent file protections or people's expectations of privacy.

> WASM provides the basic technology for loading and authenticating signed code. This enables browsers to run trusted code in a trusted environment.

Sounds familiar? This is straight from 1998 [1](ha!) with JDK replaced by WASM and applet/classes by code;-) I hear you and I hope this is enough for WASM to succeed. Still I don't see the killer argument why I should believe it will.

[1] https://web.archive.org/web/19980214233937/http://java.sun.c...

"functionality" in this case means APIs. WASM won't have any APIs that JS doesn't already have. So "conservative" means "just a few APIs", not "just communication with code in an already battle-proven VM". And AFAIK there are no plans for "loading and authenticating signed code" in WASM. It's always untrusted unless you run it with a runtime that provides the privileged APIs (such as node.js). Java always had both unprivileged and privileged APIs in the same place.

And how much of that is true today?

All of it except the closed source part. The design decisions are still there, the attack surface is still pretty big (although with much more testing and fuzzing done to date), and there's still only one implementation that can run any applet out there (not counting MS java which was abandoned when XP was released).

It's still ugly

It was so ugly

After some time you realize: The hype train is traveling in a circle.

Spiral?

Java never had, or tried to have, binary portability.

"Write once, run everywhere" was literally the motto of Java. Java bytecode does run everywhere there is a JRE and the JRE has been ported to a lot of hardware.

Java bytecode is 100% portable.

Java 8 still has syntactic sugar for generics?

What does syntax sugar have to do with binary portability? Generics information is available in the bytecode, and you can access it through reflection (it's available on methods and fields).

> It may become the future platform that native, dekstop apps run on

So Flash, again?

Someone will most certanly implement a SWF to WebAssembly converter.

They should be fined

My first thought reading the specification was '6 months before there's silicon that runs the bytecode directly.'

Obligatory "The Birth & Death of JavaScript" reference: https://www.destroyallsoftware.com/talks/the-birth-and-death...

METAL is coming.

No really. WASM is based on a stack machine and not a register machine. On the other hand there was PicoJava [1] and there is Jazelle [2]. So, maybe...

[1] https://en.wikipedia.org/wiki/PicoJava

[2] https://en.wikipedia.org/wiki/Jazelle

Stack machines used to be common in mainframe hardware, back in the day.

http://www.retrocomputingtasmania.com/home/projects/burrough...

http://datamuseum.dk/wiki/Rational/R1000s400

Sounds like good news for Chromebooks.