There's probably billions of lines of Javascript code out there, code many people paid a lot of money to be written. Javascript isn't going anywhere.

What might happen instead is that there will be a sudden burst of front end languages running on WASM, which will allow some front end people to completely avoid Javascript.

It's hard to predict what the adoption of those languages will look like, there's a million factors in play and few of them are technical.

Most of said languages are already adopted. You can expect languages running server-side to target WebAssembly first.

The other great thing is that WASM libraries written in all sorts of languages will be available to all of them.

There are still problems with WASM in the areas of multithreading, shared data structures, and memory barriers (think advanced/concurrent GC implementations). Because of this, languages do not automatically, cleanly and efficiently map to WASM yet.

Most of the pre-existing server side come with their own baggage. PHP powers most of the internet, just saying :)

I don't have a problem using good WASM libraries that were written in PHP. To target WASM, a PHP compiler would have to respect the WASM semantics which is what I will consume.

For a dynamic language to run on WASM, you would have to bundle its runtime with your application, which is probably a deal-breaker for many use cases.

I like javascript and think a lot of other people do as well so it probably won't go away just because of web assembly. I don't see too many people writing c# in browsers. I worked with c# backend and javascript front-end for 4 years and got sick of having to create classes for no other reason than because c# needed a type and other things like that.

The independence WebAssembly brings it that you'll still be able to use JavaScript whether or not you are using a compiler targeting WASM and giving everybody else the liberty of that choice. What's also great, is that even if you stick to your guns, you'll be able to use libraries written in other languages targeting WebAssembly.

And finally, to appease your OO concerns, in fact... I became progressively annoyed by the state of the web as it seemed to make heavy adoption of OO patterns (thinking angular). The ML family of programming languages has offered a much better software development experience in typed programming languages since the 1970s. There are already several compilers for those languages targeting JavaScript which are only waiting to target WASM. (WebSharper for F# & C#, ocsigen for OCaml, Scala.js for Scala, I'm sure plenty others).

JavaScript was conceived as Lisp with all the good parts removed. Note that ClojureScript is a delivery of Lisp that target JavaScript. I'm not a Clojure developer myself but I would have to agree that Clojure developers seems to be the most productive programmers out there.

There are some fundamental issues with running dynamically typed languages on top of wasm. Those issues can be resolved somewhat, but there's quite a bit of work to be done before they can be supported.

For basic support these languages need support for GC - some degree of stackwalking if they don't want to use shadow stacks. That support should be coming soon.

But you can't get around the fact that you need to ship a runtime to support these languages, so you're not just shipping your code, but the runtime required to run it.

But a runtime alone doesn't give you fast execution - you need to jit. And JITs require a lot of deep access into the architecture. You need to be able to generate and inject executable code into the program. You need to be able to patch code at runtime. For security purposes you'd ideally like a separate process that manages the codegen to provide fast w^x support for jitcode.

For the forseeable future, any real dynamic language support on the web will require direct runtime support, namely the regular JS engine.

Disclaimer: I'm a JS JIT developer at Mozilla, have worked on the IonMonkey optimizing compiler and did a good chunk of the design and implementation of our baseline JIT.

I'm excited at the prospect of wasm being a portable, tight runtime that'll eventually be a good cross-platform target for writing dynamic language, but there is quite a bit of infrastructure required within wasm before it can support that.

Oh and I forgot to mention: Elm (also an ML), TypeScript and what already looks to be Rust/Go/C/C++ already targeting WASM.

There must be a cost involved in everybody using different languages even though you can use the libraries of any language.

For example, the API between your language and the other language is probably not going to match your languages style. You see it all the time with APIs that seem to be written for java but are in another language.

If the library has to write different APIs for all the different langauges, then that is an additional cost.

Then there is the fact that less people will know a "standard" language, because they will all be using different languages, so they can't contribute back to the libraries that they use so easily. For example, if I am using a scala library and want to change something or commit a bug fix or whatever, I will have to learn scala.

I will grant there is some truth about your first point however I have some doubt as to the extent to which it'll be a problem for two reasons. The first is that WebAssembly will narrow down the variability of programming language X with respect to Y. The second is that I've consumed several JavaScript libraries from F# (using WebSharper) and always found my out. In particular, I've seen all sorts of libraries adapted to Angular directives (which I think relays some of the problems) so we know people can learn to handle it.

Your second point is fair, however I think programmers tend to stick to their "favourite programming language" like a religion and fail to appreciate that learning a new programming language can be done in 2 weeks while learning the ecosystem of libraries of a platform is a multi-year endeavour. In particular, you'll be able to carry your knowledge of all the WASM libraries you've learned to love when you decide to make a switch from say JS to XXX.

I think you're very lucky if you can learn a new programming language in two weeks.

I've been writing Python for longer than I've been writing C#, but I'm nowhere near as productive in Python.

Your two statements don't directly seems to support each other, I'm not sure if I should interpret them separately.

As for the second, there's zillions of things that can explain that and I'm definitely not clear that your being less productive in Python than in C# has anything to do with how much time you've spent on either. Which is the whole point, programming languages aren't equal. Neither are libraries.

If you set aside the time to learn the libraries and narrow it down only to syntax, that certainly the time to learn it will vary from person to person but isn't a multi-month task for anyone. I think you are scoping it in the larger context of non-shared libraries.

The best example I could give would be learning VB.NET when you already know C# (or vice versa).

I'm a C# web dev mostly - I have the opposite concern to you. I ended up using the module pattern a lot to get the same kind of structure in my JavaScript as I have in my C# code. If I'm hitting a WebAPI backend, I want the "frontend" boilerplate to match pretty closely.

There are already several libs that compile to WebAssembly and let you manipulate the DOM, e.g.

https://github.com/mbasso/asm-dom

You can already call out to small JS code snippets that work on the DOM from WAM, and since DOM manipulation is slow anyway, the small overhead you get for calling into JS won't make a difference. So I'd say, go ahead and manipulate the DOM from WASM, even if WASM supports direct DOM access later it won't make much of a difference (apart from slightly less and cleaner code in the DOM-access library).

Java didn't go away when the JVM got invokedynamic. JS will be the default language of the web for some time - although it's great that other languages can now be citizens.

But Java is an actual well designed language. A bit verbose yes. Lacking generics early on, yes.

JavaScript however is in a way similar to PHP and I'd say more dangerous as, unlike PHP it doesn't have a ugly syntax to warn you.

I've been working in the JS ecosystem lately and suddenly crazy knowledge from my life as PHP programmer turns out to be useful:

- adding statements above a function or a class? No problem: will be run on loading the file just line in PHP.

- == not checking if things are equal? Just use === like in PHP

Thst said I'm really impressed with the ecosystem. It is just JavaScript the language that needs to be replaced.

Multiple downvotes, no correction.

I guess that is either the "shoot the messenger strategy" or what I said was so horribly wrong I should have seen it myself.

Whoever wonders which one is true can verify for themselves that except for the syntax modern PHP and JavaScript are surprisingly similar: )

So my estimate is that this is going to happen approximately never.

The challenges to offering a direct DOM api are numerous. The DOM API uses the full complement of javascript types; whereas WebAssembly only has integers. So you need to either standardize a binary representation of javascript objects, arrays, functions, pointers, etc., or you need to modify all the hundreds of API calls to use different semantics, e.g. a C-style string for a node name, a wasm function-table index for a callback.

References of all kinds would be a huge sticking point, especially with garbage collection involved. If you store them c-style as integers, then how do you dereference them safely, or what if you add 50 to a reference etc. If they're stored as opaque references then that's an entire new system added on to wasm.

All of this could be done in theory, but I don't see it happening with WebAssembly. WebAssembly is a deliberately conservative and simple project. It was partly a reaction to the more aggressive NaCl project which had threads and its own low-level API pepper etc. WebAssembly is moving at the glacial pace typical of browser consensus, and the stakeholders involved don't actually want it to take over the web ecosystem (Apple doesn't want web apps to be as good as App Store apps; Google doesn't want opaque web apps that can't be easily injected with ads and analytics; Mozilla doesn't want the browser to be a simple, commodity VM).

Direct DOM access is a pretty high priority for the Wasm folks; that said, the consistent message of WebAssembly since forever has been augment, not replace.

You can find the proposal here: https://github.com/WebAssembly/host-bindings/blob/master/pro...

Yes, we first need to define an ABI. But that can be quite simple. Passing floats, for example could be done by passing the bytes that define the IEEE float. For strings, you could pass UTF-8. Etc.

Besides what WebAssembly offers as general purpose VM, in an ideal world TypeScript would take JavaScript's place.

Why would it do that? Javascript is more appropriate in the early stages of a project. You don't want to go to the trouble of declaring types everywhere only to realize everything has to change. Once you stabilize you can add in typescript, which is the great thing about it.

It is precisely when you want to change everything that types are useful, because the compiler will helpfully point you to all cases that you forgot to change.

No matter what stage of the project, you're implicitly writing code to a specific type whether you know it or not. Typescript just makes types explicit, and makes clear all the places you've made type assumptions. So if you need to change types later in the project, you can do so with confidence knowing that you've handled all the cases you made type assumptions.

Some of us only see a value in dynamic typing for shell scripts, burned too many times in large code bases.

Wouldn’t a UI in WebAssembly make it impossible to block ads? The recent QT announcement renders to Canvas doesn’t it?

I thought the idea was to mostly use WebAssembly for parts that are performance critical, not replace all of it?

This has always been possible if you just write sufficiently obfuscated JavaScript. However a UI that is entirely rendered in a canvas element would basically be unusable by anyone with a disability, so that technique is useless for big orgs.

The cynic in me can't help but expect most web companies to care more about pushing unblockable ads down everyone's throats than about the disabled.

That’s why decent countries have regulation to make them care about things other than short-term profit.

It is not correct, but most big orgs don't care about those details unless they are legally enforced by the government.

I am yet to have worked in any web project where stuff like ARIA was even on the requirements list.

Unless they spent a _ton_ of effort re-implementing the DOM/native browser UI in canvas, it'd probably be basically unusable by anyone without a disability too.

What stopping anyone from adding accessibility features to single element canvas apps?

A UI framework developed exclusively for canvas-apps could probably add many such features.

It would also be impossible to inject ads into an existing wasm ui that didn't have them.

> Wouldn’t a UI in WebAssembly make it impossible to block ads?

In the future machine learning will be applied to detect and disable ads visually.

I also cant wait for binary blob websites.

I'm all for this, but I'll hold my breath until I see a responsive GUI emerge.