There needs to be official OS support from vendors (MacOS, Windows and Linux distros) in order to avoid the stinking pile of non-shared shared library mess that is electron.
[1]: https://blog.cloudflare.com/cloud-computing-without-containe...
We wrote more about it here: https://medium.com/wasmer/webassembly-cloudabi-b573047fd0a9
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.
Double so for anything 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.
Isolates are a V8 feature that is used to implement Workers: https://v8docs.nodesource.com/node-0.8/d5/dda/classv8_1_1_is...
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.
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.
> 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.
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.
Not mainstream, but absolutely a thing. There's people even looking at running it in Ring 0.
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.
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.
https://webassembly.org/docs/faq/#is-webassembly-trying-to-r...
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.
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?
The difference is that the web has a very different security model, where for example it is unthinkable to ship binaries.
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.
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.
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.
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
Jobs isn't here to save us anymore.
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.
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.
https://developer.mozilla.org/en-US/docs/WebAssembly/Concept...
Although I couldn't actually find any description of the intended capabilities.
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.
> 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.
> 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.
https://blog.qt.io/blog/2018/05/22/qt-for-webassembly/
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.
> 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.
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.
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.
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.
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.
https://github.com/WebAssembly/reference-types
Besides there is already WebGL, WebAudio and WebGPU is being worked on.
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.
I am just stating that Flash like Web sites will come back, regardless of what WebAssembly haters think.
As for further replies, oh well.
The goals of W3C were never to have a general purpose VM, rather hypertext documents, which nowadays only a minority cares about.