We are working towards that. There are two ABIs (sets of syscalls, such as read a file or opening a socket) that we believe would help to bring universality between platforms: * CloudABI * PWSIX

We wrote more about it here: https://medium.com/wasmer/webassembly-cloudabi-b573047fd0a9

What about packaging & distribution? Unless I missed something, it's up to us to package & ship our app complete with assets.

I firmly believe that this project is incomplete without a standard like .war (Web ARchive, from the Java ecosystem).

Of course, you could just use what's out there eg. .app (macos) or .appimage (gnu/linux) but there has to be a well-defined and clearly endorsed way of distributing wasmer'd apps.

This "ship all libraries in the package" approach is also quite scary, you never know if an app will use your patched local libraries or use an ancient library with lots of exploits.

Double so for anything exposed to the internet.

WASM binaries needn't be exposed to the internet.

That said, the OS-sanctioned runtime could very well support a shared-object-like approach instead of one-binary-per-app but that would 1. complicate the runtime quite a lot 2. hinder startup times of wasm apps due to dependency solving.

Small nit, the product is Cloudflare Workers. https://workers.dev/

Isolates are a V8 feature that is used to implement Workers: https://v8docs.nodesource.com/node-0.8/d5/dda/classv8_1_1_is...

Mass adoption in what way?

So, we are officially campaigning for Javascript as the default language for everything now? :-(

WASM is not javascript

Funny, I hear often that "WASM is just javascript" whenever I compare it to Flash and Java, as a defense for why it is different this time and totally won't have any of the problems of those other runtimes.

Because wasm runs on the same javascript and not as a separate plugin. It will be a major feature of the browser and be automatically updated with it. (also it allows for feature discovery)

It has no relation to ecmascript, but you could say that it is integrated in (but independent from) javascript.

People say that it is not javascript because you can use ALL of the wasm toolchain without any trace of javascript.

WASM and javascript are run using the same underlying environment. WASM is not javascript on a language level.

actually, the exact opposite

This is Java 2.0 isn't it? "Write once, run everywhere".

I wonder how one would solve linking to native libraries and the like through this.

I still prefer just having the application source code available so one can compile it for a specific system.

No. Java is a language. WASM is a byte code compile target. A better comparison would be the JVM, such as a language like Scala that is definitely not Java still compiles to the JVM and can run anywhere there is a JVM.

> I wonder how one would solve linking to native libraries

Either use WASM outside the browser (I don't even know if that's a thing) or create some sort of import mechanism using JavaScript.

> No. Java is a language [...] A better comparison would be the JVM

I think the point was that it's a reinvention of "write once run everywhere", which had its own problems at the time (such as native libraries). Java introduced the idea, and arguing the fact that the JVM is the reason why it works is a touch pedantic in this discussion.

> Either use WASM outside the browser (I don't even know if that's a thing)

That's what TFA is doing.

Actually, Oberon first came with it, with JIT compilation of intermediate code into the target code.

The concept goes back all the way to Xerox PARC workstations and Pascal UCSD.

> use WASM outside the browser (I don't even know if that's a thing)

Not mainstream, but absolutely a thing. There's people even looking at running it in Ring 0.

https://github.com/nebulet/nebulet

I thought Java was both a language and a virtual machine target. You can compile programs written in other languages for it's VM like Clojure.

It should be far more open and lightweight than java.

Linking to native libraries isn't desirable - you don't want to leak your native vulnerabilities into your web browser.

If you have the source however (as you mentioned), using Clang to compile to WASM should be a viable approach.

But if this is to be a "universal" binary it has to interface with the OS, the DE and other native programs not just the browser.

If not you will end up with Swing type libraries that look very off compared to native applications.

Same for games really. You usually need to be aware of what platform (hardware and software) your run on and adjust for that to be able to use it optimally.

This is supposed to kill javascript(hopefully)

WASM is a parallel technology with no intention of impacting JavaScript, according to its spec. Therefore WASM will never replace JavaScript. JavaScript can be replaced, but it won't be WASM that does so.

https://webassembly.org/docs/faq/#is-webassembly-trying-to-r...

https://webassembly.org/docs/js/

Au contraire: if people can ship WASM to the browser to do what they’re currently doing with JS, but it’s faster, in nearly whatever language they like and just as nice/if not nicer, then they’ll stop writing JS.

I’ve long maintained that the reason that JS is so prelevant and popular is the result of it exclusively being the only language allowed in the browser.

Mozilla has already proven that a Rust WASM can take in the DOM, do all the necessary transformations and hand back the final result faster than JS can transform it. Host binding protocols are the first step in negating the necessity of JS. Once a direct DOM <-> WASM API comes along (and it will), JS will be as good as deprecated.

You're forgetting two relative benefits to JS - it can be written in a text editor and it doesn't require knowledge of a second language, toolchain and compiler. A lot of javascript is still hand written.

Also, deprecating JS would mean deprecating functionality most of the web itself. No one is going to rewrite all existing javascript in Rust or C or whatever and compile it to WASM.

Like it or not, as long as the web exists, javascript has to exist, browsers have to support it.

> it can be written in a text editor

Are there programming languages that we don’t use as targets that can’t be written in a text editor? I’m not sure what you mean here. I can write Rust, C, C++, Python, Swift, .Net, etc etc in a text editor with no more difficulty than JS?

> it doesn't require knowledge of a second language, toolchain and compiler. A lot of javascript is still hand written.

Have you not seen the borderline arcane processes and quantity of tooling involved in “compiling” and bundling JS applications? It’s nightmarish and far more convoluted than literally any other language I’ve dealt with.

> Also, deprecating JS would mean deprecating functionality most of the web itself.

Oh no, what a pity, large chunks of bloated websites will go away. I’m sure we’ll all miss them greatly, they made such a great difference to our lives. /s

> No one is going to rewrite all existing javascript in Rust or C or whatever and compile it to WASM.

You don’t have to write it in whatever low-level language, I’m sure any number of higher level languages will get support. Also, we dropped flash pretty hard and fast, and I distinctly, distinctly remember a huge number of websites being entirely flash.

It’s maybe not going to go away entirely, but it will hopefully cease to become as popular as it is now.

> Oh no, what a pity, large chunks of bloated websites will go away. I’m sure we’ll all miss them greatly, they made such a great difference to our lives. /s

I don't even know how to answer this... You are proposing to partition the web into a past and future version where almost no site of commercial interest has any incentive to leave the old internet.

Do you seriously believe that a browser without javascript (not a "noscript" addon, just no javascript) could be successful in any way? or say, more than elinks?

> Also, we dropped flash pretty hard and fast, and I distinctly, distinctly remember a huge number of websites being entirely flash.

And some sites still requires it. It is one of the reason I still keep chrome on my computers

Steve Jobs killed Flash. I fully believe that Flash would still be around and kicking (horribly) if he didn't step in and do something about it.

Jobs isn't here to save us anymore.

Really? He single-handedly killed Flash? What a powerful man.

He took the risk of creating a botched experience on his platform first. He did not fail and other followed. He was maybe not the single reason why flash declined, but for sure is the one that initiated it.

There is no issue rewriting JS. People do it anyway every year. I.e new frameworks, new tools etc. JS won't be deprecated. It will just cease to be used (i.e like COBOL)

> if people can ship WASM to the browser to do what they’re currently doing with JS

If if if.... That is not what WASM is or whats to be.

> I’ve long maintained that the reason that JS is so prelevant and popular is the result of it exclusively being the only language allowed in the browser.

People who hate JavaScript have long maintained that, without evidence. I can remember writing JavaScript long before it became popular and was still everywhere.

> WASM API comes along (and it will), JS will be as good as deprecated.

A DOM interop spec is underway, which will allow access into the WASM target from JavaScript. It will not allow access from WASM to the DOM, because that is insecure.

According to Mozilla : "There are future plans to allow WebAssembly to call Web APIs directly.".

https://developer.mozilla.org/en-US/docs/WebAssembly/Concept...

Although I couldn't actually find any description of the intended capabilities.

MDN has a page for that as well:

https://developer.mozilla.org/kab/docs/Web/API

The page DOM is not listed there. The closet thing is DOMParser which will allow parsing of an XML/HTML island into a new DOM object.

https://developer.mozilla.org/kab/docs/Web/API/DOMParser

What you're missing is https://github.com/WebAssembly/host-bindings/blob/master/pro...

I believe you are over thinking this bullet point:

> Ergonomics - Allow WebAssembly modules to create, pass around, call, and manipulate JavaScript + DOM objects

That would allow WASM functionality similar to behavior already present in the browser, but that page does not say where that behavior will occur. Given this is an update to WASM it will likely occur against WASM artifacts. An example would be allowing a WASM application instance to create JavaScript event bindings and DOM artifacts on an internal DOM tree.

It is wishful thinking that an update to WASM would modify the web environment outside of WASM.

I think I’m just really confused as to what you’re saying. In the browser, you will be able to manipulate the browser DOM directly from wasm. That’s all I’m saying. I don’t think I understand what you mean in this reply.

So currently there is demand for a DOM interface in WASM and WASM has none. I have seen several WASM applications that ship markup and then fabricate their own DOM-like instance to accompany that markup to allow web-like behaviors to the WASM application instance. That is a significant amount of overhead. If WASM had access to a DOM interface applications could be written in any language that execute DOM methods on accompanying markup without need for JavaScript. You get the benefits of a self-contained event-driven UI environment with minimal overhead and without need for JavaScript, but just because WASM ships with support for DOM method execution does not necessarily mean that execution reflects a state or environment outside the WASM sandbox.

Yeah, that does sound like a lot of overhead.

> just because...

It certainly will though, 100%. I know this from talking to all sorts of people who work on wasm. That’s what the above proposal I linked you to does.

> A DOM interop spec is underway, which will allow access into the WASM target from JavaScript. It will not allow access from WASM to the DOM, because that is insecure.

More insecure than allowing arbitrary JS like we do now? I wouldn’t be surprised if we do get a WASM DOM API, maybe it won’t start as an official spec, but it’ll eventually happen.

a DOM API for wasm is planned, but IIRC before that people need to standardize the whole concept of external references/GC, so it might be still quite far away.

This may not be a goal of the project, but it is still the hope of a lot of people. When parity with JS is reached in terms of ability to access the DOM and JS interop, then there shouldn't be much advantage to JS, and possibly a performance penalty.

Having one language in a 'privileged' position for a platform isn't ideal. At least with the mobile platforms ObjC could be supplanted by Swift, and Java by Kotlin.

> This may not be a goal of the project, but it is still the hope of a lot of people.

I hope for world peace.

> When parity with JS is reached in terms of ability to access the DOM and JS interop

There is work being down on DOM interop, but its not what clueless people think it is. DOM interop allows JavaScript interaction to WASM via the DOM. It doesn't allow WASM to creep out of its sandbox to become some magical JavaScript replacement.

Even if it did, you would still have to learn to access the DOM. Most developers completely fail at this point. Somehow the DOM is scary.

> Having one language in a 'privileged' position for a platform isn't ideal.

Why not?

These threads always repeat themselves. There are the people painfully explaining why they would like to be able to program for the web in the languages they like. And then there are the JS advocates that take it personally and go out of their way to explain why JS is all you need. Even though no other platform forces you into a single language somehow the web is different.

But the web is different, web pages (HTML/CSS/JS + whatever) are script supposed to run in the browser and offer a fairly uniform interface. You can already compile to javascript, and also platform like android force you to use some of the native language.

The difference is that the web has a very different security model, where for example it is unthinkable to ship binaries.

Javascript was not designed as compile target. Stop this insanity! You can sandbox wasm. It's not unthinkable. It's real!

WASM already is a sandbox by default, and so is JavaScript in the browser. I don't understand your point.

Web technologies are defined by standards that define the limitations of said technologies no matter how sad people get about it.

I don't understand what you mean. The standards have to be defined and as demonstrated by wasm there's nothing preventing a runtime that all languages can target that isn't just compiling to JS. How that was ever considered a solution is just mindboggling. What was delivered by wasm is something that we've wanted for 10 years and were repeatedly told was not possible. Even today there are people in this very thread arguing that was is already available is not possible...

The Pandora box is already open, haven't you noticed it?

https://platform.uno/

https://blog.qt.io/blog/2018/05/22/qt-for-webassembly/

https://blazor.net/

http://teavm.org/

https://www.leaningtech.com/cheerp/

Telling everyone what the purpose of WebAssembly is regarding JavaScript doesn't matter, unless browser vendors decide to backtrack on it.

Web technologies are based on standards otherwise there is no conformance. If you want something different advocate for a change to the standard.

> The Pandora box is already open, haven't you noticed it?

WASM has been widely available for a while now in all major browsers and yet the fantasy of replacing JavaScript still has not come to pass. I guess I haven't noticed it.

Companies are still migrating from IE 8 to IE 11 on their RFPs requirements list, and WebAssembly is at 1.0.

Flash will come back rest assured.

I am already using pure browser versions of WebEx and Citrix.

While Autodesk customers can play with their AutoCAD projects on the browser.

When talking about web technologies I am astonished by the repeated irrationality. Most JavaScript developers are deathly afraid of the DOM. They will happily sink their careers over it and perform 100x more work to not contend with it and justify the strangeness of that reasoning in really creative irrational ways. It’s bizarrely fascinating. That phobia is further strange considering it’s about a skill that can be learned in 2 hours of active study and mastered in 4.

Then there are people who are equally fearful of JavaScript. Again, they will justify their phobia in all manners of ways at great energy. They will even form an alternate future reality to justify knowingly bad decisions in the present.

Both of the groups are really demonstrating the same phobia with all the same behaviors but just slightly shifting the subject a bit. What’s ironic though is that the people afraid of JavaScript, and thus having little to none experience working with or understanding the DOM, really want access to DOM.

When you get past the irrational fear around these things the motivations of the technologies and their direction becomes something completely different. This is why web technologies are difined in one way and yet people strangely impose their own alternate realities, abstractions, and unfounded projections upon them. It’s also why the standard technologies are slow, intentionally so, to reflect certain things even those things are highly demanded.

I have encountered these phobias enough, even in person, that I am curious to learn more about them and how they arise.

It is the need to feel assured one did the right choice to belong to a certain group.

As polyglot developer I have a schizophrenic attitude towards technology, you will see me bashing tech X in one thread and praising it in another one.

Because at the end of the day, regardless of my personal opinions, is what the customer wants that counts, and every tool has plus and minus.

Now, some people that sell themselves as Developer on X, User of Y, need to be sure that they did the right choice otherwise the hard truth is that they need to go elsewhere.

Naturally this creates a religious attitude around technology decisions and us vs them.

As for the Web, from my point of view it should have stayed for interactive documents, with native for everything else, using Internet network protocols as it was.

Everyone wanted to turn browsers into general purpose VMs instead, so naturally we are now here, with everyone porting their favourite stack into WebAssembly.

If DOM access to the page were to come to WASM what is the expectation that deveopers suddenly learn to appreciate and execute DOM instructions? On what basis do you form your answer?

Due to the phobias I described above my expectations of success are low, and rightly so. Rather, people are whining for something they don't have in their favorite language and if they get it the results will be a shit show. I espcially doubt advanced topics, such as accessibility, will be successful. If subjects that actually are challenging were taking seriously these developers wouldn't be crying something simple, like executing the DOM from JavaScript.

There is no if, DOM access is already at Stage 3.

https://github.com/WebAssembly/reference-types

Besides there is already WebGL, WebAudio and WebGPU is being worked on.

You completely ignored the details of the thing you linked to and you completely ignored my comment to do it. Dillusionment is a part of extreme reactions to phobias.

The details for the spec update you are talking about have already been addressed in these comments: https://github.com/WebAssembly/host-bindings/blob/master/pro...

You should read my previous comment if you want any further replies.

Thing is, I don't have any phobias, unless you haven't been paying attention, Web development is part of my job.

I am just stating that Flash like Web sites will come back, regardless of what WebAssembly haters think.

As for further replies, oh well.

Restating the goals of the WASM project and actually reading the spec doesn’t make anybody a hater. Also Flash had the equivalent of host bindings and could not modify the containing page.

Goals and spec are theory, what matters in the end is what people are actually doing on the field.

The goals of W3C were never to have a general purpose VM, rather hypertext documents, which nowadays only a minority cares about.

Javascript exists because you can't run anything else in the browser. wasm allows you tonuse your fav language so I can't see why anyone would use JS once wasm gets DOM access

WASM is getting DOM access, but there is nothing indicating that DOM access is to the page containing the WASM instance.