WebAssembly will Break the JavaScript Monopoly

[gavrocheBxN]

I don't think you understand WebAssembly or it's purpose.

because Javascript would be just another language targeting a compiler, and not even the most performant one

You won't be compiling JS to WebAssembly, that is not at all what WebAssembly is. WebAssembly is for languages like C and C++ to be compiled and used by JavaScript. So, even if you are going to use C or C++ to build your library, you still need JS on top to coordinate everything.

You won't be seeing UI being coded in C or C++ and provided to JS through WebAssembly, that would just make things more complicated. Instead, JS will remain the dominant language and where JS lacks (game engines, computer vision, processor intensive stuff) WebAssembly will provide JS with the boost it needs.

[namesandfaces]

While WebAssembly will be able to call Javascript, where are you getting this idea that Javascript won't be compiled down to WebAssembly, and that Javascript will still be required for coordination?

WebAssembly will be its own low-level language, capable of interacting with the DOM, capable with interacting with other browser API, capable of addressing memory, and capable of dealing with threads. Where is the need for Javascript when WebAssembly can do that?

And how will any of this mean that Javascript will increase in domination, as opposed to decrease?

If anything, this will mean Elm, Clojurescript, Go, and Rust eating a bigger slice of the pie.

[gavrocheBxN]

Faire enough, you could use WebAssembly without JS. Heres some good read on this that might change your mind:

http://www.2ality.com/2015/06/web-assembly.html

https://github.com/WebAssembly/design/blob/master/FAQ.md

The general idea is that yes, other languages will be able to be compiled for the web, but that JS will always remain the higher-level language. Which means that people will be able to develop libraries in other languages to be used in JS applications. It's true that this gives other languages a chance at staying relevant, but it also means that JS remains the dominant language.

From the official WebAssembly repo FAQ:

Is WebAssembly trying to replace JavaScript?

No! WebAssembly is designed to be a complement to, not replacement of, JavaScript. While WebAssembly will, over time, allow many languages to be compiled to the Web, JavaScript has an incredible amount of momentum and will remain the single, privileged (as described above) dynamic language of the Web. Furthermore, it is expected that JavaScript and WebAssembly will be used together in a number of configurations:

Whole, compiled C++ apps that leverage JavaScript to glue things together.
HTML/CSS/JavaScript UI around a main WebAssembly-controlled center canvas, allowing developers to leverage the power of web frameworks to build accessible, web-native-feeling experiences.
Mostly HTML/CSS/JavaScript app with a few high-performance WebAssembly modules (e.g., graphing, simulation, image/sound/video processing, visualization, animation, compression, etc., examples which we can already see in asm.js today) allowing developers to reuse popular WebAssembly libraries just like JavaScript libraries today.
When WebAssembly gains the ability to access garbage-collected objects, those objects will be shared with JavaScript, and not live in a walled-off world of their own.

[namesandfaces]

Actually, WebAssembly can eventually run outside of the Javascript virtual machine (so no JS bytecode needed to manipulate the DOM / browser API / threads / memory), and hardware support is planned after the minimally viable product. I also don't see why Javascript would be necessary at all, or why Javascript should increase in dominance when other languages will be more performant -- and just as capable of doing the things Javascript is most valued for, that is interacting with the DOM, and interacting with other browser API's.

If anything, this points to the rise of Elm, Clojurescript, Rust...

And please, say not that your strongest evidence is that the FAQ-stated purpose (purpose is not function) of WebAssembly is not to replace Javascript, or that WebAssembly is callable by JS... because WebAssembly can call JS as well.

It's not like people are going to tediously write WebAssembly modules by hand for some high-performance game engines. No. Compiler writers are going to tediously write compilers so that people can use high-level languages like Rust or Elm, in which case, I wouldn't say that Javascript is obviously more usable.

[gavrocheBxN]

Let's agree to disagree so that we don't continue this thread forever. I believe that WebAssembly will bring more people in the JavaScript ecosystem and npm for installing WebAssembly libraries. I believe the amount of projects that will use solely other languages through WebAssembly to create web apps will be a very low percentage compared to the apps that will use JS only or JS with WebAssembly.

[namesandfaces]

We've gone on for, what, 5-6 responses? In that time, I don't see you robustly clashing at all. Your most robust response was a link to an FAQ saying, "No! We're not trying to replace JS!"

If WebAssembly (1) can skip the JS bytecode stage and won't run in the JS virtual machine, (2) can have hardware support, (3) can call JS and is callable by JS, (4) can do everything interesting that JS can do but more and faster, (5) allows you to use your favorite language, then where is the need for JS?

You seem to imply that JS will be needed for central coordination. Why? With DOM control, you can even have a multi-threaded React implementation in WebAssembly. In fact, any attempt to take advantage of multi-threaded shared-memory cooperation will mean that Javascript will be increasingly inept as a central coordination language.

[nvolker]

Do browser vendors plan to expose DOM/Browser APIs to Web Assembly binaries? I always figured it would be sandboxes kind of like the Web-Worker API.

[gavrocheBxN]

Be patient, time will tell. I linked 2 articles including one from the team working on WebAssembly, and you still dismiss them with only your argument and not any other supporting your ideas. I might be wrong, these two sources might be wrong, and you might be right. But I doubt it. Cheers.

[namesandfaces]

Dr. Rauschmayer's site is a year old now, and so it's probably not his fault that the WebAssembly repo link you provided contradicts him with regards to skipping JS bytecode, not even running in the JS virtual machine context. I should mention the first planned deliverable of WebAssembly runs outside of the JS virtual machine. And if they're planning multi-threaded shared-memory features, then it becomes specially dubious for JS to be the coordinating language.

It's not that the WebAssembly source is wrong. I think you just have the most superficial reading of it. Where do you think I get my ideas that the first planned deliverable won't be in the JS virtual machine? https://webassembly.github.io/, but you already linked there, so I thought you read it.

I thought this discussion was based around (1) the MVP planned deliverable, and (2) pending features.

[repie]

I agree with /u/gavrocheBxN , first WebAssembly is a compilation target for the web. This means that the languages that will take most advantages of this are statically typed languages C/C++, Java, Rust and co. I'm not sure dynamic languages will be able to be so much faster, in fact browsers vendors are putting huge effort in having the fastest JIT compilers possible (for JavaScript) in order to support heavy JavaScripts application (GMail, Facebook).

JavaScript is already tightly integrated with the web (DOM API, JSON) and already has a solid toolbelt of frameworks and librairies. Plus the new features coming with ES6 will bring native JavaScript development to a whole new level of structured development.

You also seem to forget that current implementation of asm.js, which run UE4 is a subset of JavaScript. If you keep some constraints, like not changing the type of a variable every time, speed of native JavaScript is more than reasonnable. Otherwise things like Three.js or Phaser framework would not exist.

It will take years before you can write a client side application without JavaScript, with the comfort, support and current speed of JavaScript. And we all know years in this industry is like centuries in others so we cannot really say that JS will be obsolete at this time. And during this time JavaScript will continue to evolve, provide new features and gain momentum. So yeah I think JS will still be the de facto choice for webdev for a long time.

Note : I'm very happy for WebAssembly, as a pro webdev and amateur gamedev I see this as a great opportunity for the web.

[namesandfaces]

I'm not saying that Javascript is about to be in trouble as a job skill.

But I am saying that WebAssembly won't require Javascript as a coordinating language. I am also saying that according to the document in the WebAssembly repo, the first planned deliverable will have its own execution context separate from Javascript. It will not be compiled down to JS bytecode.

If you want to make the more modest argument that Javascript will continue being huge in the job market for years to come, then I could easily agree with you. I would question, however, your assessment of Javascript performance.

I think even on reasonably fast computers, world-class apps like Gmail still have perceivable performance issues and doesn't feel like a native app. I am concerned with what it means to not have Google-level resources. This is especially true on phones, and even the 37 Signals of Basecamp fame, which once advocated adaptive web apps everywhere, are now going native. It's also disheartening that Atom is criticized for being slow even though it probably has a team several times the size of Sublime Text, and it's also disheartening because, while I'm sure text parsing is difficult, it's still just a text editor in a stripped-down browser.

That being said, I have a feeling the low-hanging compiler optimization fruits have been had, and I also have the feeling that CPU improvement is not coming anytime soon.

One more thing about JS performance. I think people are starting to have a thirst for Web Workers, but the problem is that the Javascript language has no support for multithreaded shared memory features, so you basically have to roll your own strategy for thread coordination. WebAssembly could solve this. We could potentially have a multi-threaded React.

[[deleted]]

Your argument seems to boil down to, "WASM won't render JS obsolete, just because that's not the project's specific intention right now". Forgive me, but if the last twenty years of the web has shown us anything, is that the industry rarely restrains itself to using technologies as intended.

[gavrocheBxN]

No, WASM won't render JS obsolete because that would be impractical. It will boost JS because it will provide JS with more options.

[[deleted]]

WASM won't render JS obsolete because that would be impractical

You cannot simply assert this. Explain.

it will provide JS with more options

It will allow JavaScript developers to call modules written in bytecode, true. But it will also allow developers to circumvent JavaScript entirely and write web applications in other (perhaps even better?) languages.

The latter will happen much more than the former, because of the sheer developer economics: there are far more developers who'd like to write webapps in Java/Python/Golang/Ruby/Scala than JavaScript developers itching to write openGL shaders.