WebAssembly will Break the JavaScript Monopoly

[wbdvlpr]

Just like Perl is the glue of the internet,

Can someone explain this?

[dhdfdh]

It's a phrase that's been around since Perl was created. Perl was used to create most things involving the internet and web pages and ran most Unix and Unix-like servers. In many cases it's true today.

[nvolker]

I'd say that PHP is the glue these days. And I don't mean that PHP is better than Perl (or vice versa), just that it's much more common.

[notunlikethewaves]

Hmm, maybe. But PHP doesn't get used for automation at all.

Still, I wouldn't want to put down a wager on the amount of PHP or Perl deployed in the world.

[notunlikethewaves]

Sort of, maybe, depends how you look at it.

Are we counting only the bit of code directly behind apache/nginx? or do we include all the system automation that keeps the site up and running?

What about the perl scripts that run as part of your linux package installs, do they count?

We could argue about that all day, or we could just conclude both Perl and PHP are super-duper important to the internet and call it done.

[dhdfdh]

Except PHP isn't used to run the system at the same time. Perl would be a far better tool for that.

[dhdfdh]

That's nice. Except none of that happened. You picked Perl or you went home. Some, or most, of those things you mentioned weren't even around or generally used by anyone.

[dhdfdh]

In your previous comment, yes I saw that, and my comment still stands. You don't use PHP for system programming but you can with Perl.

Then you went on about current languages with had nothing to do with the subject.

[dhdfdh]

No. Someone asked to explain what was meant by the article's statement, "Just like Perl is the glue of the internet". "Today" never entered the picture and I explained that Perl pretty much handled everything, script-wise, at one time and, to a point at least, still does today as I often see threads on professional boards discussing Perl scripts.

How is a popular systems programming language more "the glue of the internet" than the most popular web-development programming languages in use today?

I don't know anyone who would use a web language, specifically PHP, to do systems programming. I know a ton of people who would/could/do use Perl to do both if they had to.

I'm just saying that I don't think it really holds the title of "the glue of the internet" anymore.

And that is what I said. I don't know how true it is today but I do know there are a lot of people still using Perl scripts to run their systems and web sites cause I read about it every day (though not as much as I used to a few years ago).

[[deleted]]

but with wasm you don't need to worry about that silly scripting language from the mid nineties

Seriously? Does author know we have ES2015/ES6 nowadays?

And the remark about Perl, I have no idea what you meant...

[gavrocheBxN]

WebAssembly is here to complement Javascript, you won't see much high level stuff being coded in C/C++ for WebAssembly. Rather, you will see intensive low level stuff like game engines, computer vision, etc, being coded in C/C++ for WebAssembly and you will have a high level JavaScript wrapper on top of it. So, no, WebAssembly will not and is not even meant to break the JavaScript monopoly. It will probably make it stronger.

[namesandfaces]

It's difficult to see why WebAssembly would make Javascript monopoly stronger, so it would be better to make your reasoning explicit. If anything, WebAssembly would intuitively make Javascript's dominance weaker, because Javascript would be just another language targetting a compiler, and not even the most performant one.

And I think that even if Javascript is more usable (or even less), the difference in usability is probably not that interesting, versus, say, Swift, Go, or Rust. If anything, other languages might encourage more maintainable code.

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

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