[18973294]

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.

[davidgrenier]

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.

[kannanvijayan]

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.

[davidgrenier]

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

[18973294]

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.

[davidgrenier]

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.

[voltagex_]

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.

[davidgrenier]

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

[voltagex_]

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.