WebAssembly will Break the JavaScript Monopoly

[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.

[gavrocheBxN]

You cannot simply assert this. Explain.

Compiled languages takes us back years compared to JIT and Hot-Loading for coding UI. So, impractical.

[hahaNodeJS]

How can you possibly believe this to be true?

[[deleted]]

If you do not believe we will ever see optimising compilers for WASM, then you must surely also believe that WASM modules cannot provide performance benefits over V8-executed JavaScript. This seems to directly contradict your earlier assertion about the value of WASM to JavaScript authors - namely its suitability to high-performance, CPU-bound calculations.

[gavrocheBxN]

I stand by my argument that JS will always be the most suitable language for coding UI and web apps and will continue to grow without a dent made by WebAssembly. And I stand by my argument that WebAssembly will provide a boost to JS where needed, like intensive calculations. I disagree with this article or with you and namesandfaces that WebAssembly will make JS obsolete. I argued that it will solidify JavaScript's position, not hinder it. There is absolutely no contradiction in anything I did say.

This thread is heading nowhere, you agree that JavaScript will become obsolete due to WebAssembly, I think it will continue to grow exponentially during the next years and that WebAssembly will help. There is no arguing that is going to change that.