>I believe the community could make nice libraries compiled to WASM that anyone can use regardless of the programming language. JavaScript would be just another language(albeit a popular one, at least due legacy reasons).
I understand and respect the aim -- the browser should be ambivalent about programming languages.
But this is not intention, because it is quite unfeasable. WebAssembly allows one to target the web with much more low-level languages, but that also means that the languages dictate the memory structure of things. In WebAssembly world there are no 'javascript arrays' or 'object hashmaps'.
Imagine mapping the Javascript DOM API surface (with all its dynamic datastructures and callbacks) to C++, Haskell and Smalltalk. Three languages that may compile to WebAssembly, but would have drastically different internal datastructures. And all of that data marshalling that you would need to do, would need to happen for every dom feature for every language that compiles to WebAssembly.
OR! We just implement an API that does nothing more than interop with JS land. This doesn't change often and it will be easy to support many different languages quickly.
Think of Javascript as the BASH of the web. In a shell script you would pipe the output of one written-in-c program to the input of a written-in-rust program. With HTML+JS you would hookup the heavy part of the application and plug the IO's exactly how you want them. Its closer to configuration, really, much like a shell script.
So there needs to be some glue language, and we need to support Javascript and its DOM operations in a way that is completely backwards compatible, and at least as fast (read: tighly coupled) as it is now. And we want to limit the attack surface. There is no other choice than that Javascript will be that glue language.
But its fitting, because Javascript like BASH is a language whose strongest competitive advantage is compatibility. Like BASH it will be the glue language and shell of a platform.
The web APIs are described using the Web IDL and I believe that could be translated to C++ , Haskell and pretty much any language with more or less effort.
In fact I think there are bindings for some languages such Python and Objective C though they are not open. I see no reason why a WASM interface could not be exposed (the code itself could be developed in C/C++ and compiled to WASM)for the web APIs and exposed to the client.
I understand and respect the aim -- the browser should be ambivalent about programming languages.
But this is not intention, because it is quite unfeasable. WebAssembly allows one to target the web with much more low-level languages, but that also means that the languages dictate the memory structure of things. In WebAssembly world there are no 'javascript arrays' or 'object hashmaps'.
Imagine mapping the Javascript DOM API surface (with all its dynamic datastructures and callbacks) to C++, Haskell and Smalltalk. Three languages that may compile to WebAssembly, but would have drastically different internal datastructures. And all of that data marshalling that you would need to do, would need to happen for every dom feature for every language that compiles to WebAssembly.
OR! We just implement an API that does nothing more than interop with JS land. This doesn't change often and it will be easy to support many different languages quickly.
Think of Javascript as the BASH of the web. In a shell script you would pipe the output of one written-in-c program to the input of a written-in-rust program. With HTML+JS you would hookup the heavy part of the application and plug the IO's exactly how you want them. Its closer to configuration, really, much like a shell script.
So there needs to be some glue language, and we need to support Javascript and its DOM operations in a way that is completely backwards compatible, and at least as fast (read: tighly coupled) as it is now. And we want to limit the attack surface. There is no other choice than that Javascript will be that glue language.
But its fitting, because Javascript like BASH is a language whose strongest competitive advantage is compatibility. Like BASH it will be the glue language and shell of a platform.