With the advent of the New Era of the Web, WebAssembly, which is to be designed in cooperation by Google, Microsoft, Apple, and Mozilla:
WebAssembly High-Level Goals
- Define a portable, size- and load-time-efficient binary format to serve as a compilation target which can be compiled to execute at native speed by taking advantage of common hardware capabilities available on a wide range of platforms, including mobile and IoT
read more...
I would like to ask those who already possess this knowledge:
Can potentially any programming language be compiled to WebAssembly once its made? Let it be C#, Java, Python, JavaScript, Ruby. If this is the case - could a web developer choose any language to accomplish things he would achieve with JavaScript now?
WebAssembly is a low-level, assembly-like language with a compact binary format that runs with near-native performance in web browsers. At the same time, WebAssembly provides a portable compilation target for C/C++, C#, Rust, Go, Kotlin, Swift, and other programming languages.
WebAssembly is designed to be a complement to JavaScript, not a replacement. That means that it is not meant to be used independently, but rather to be used in conjunction with JavaScript. For example, you can compile WASM code to run alongside JS code.
WebAssembly is a new type of code that can be run in modern web browsers — it is a low-level assembly-like language with a compact binary format that runs with near-native performance and provides languages such as C/C++, C# and Rust with a compilation target so that they can run on the web.
Python is the second most popular programming language. Thanks to a few different efforts, it is now possible to compile the Python interpreter to WebAssembly. It is now possible to run Python inside of a WebAssembly runtime.
The goal is indeed to support any language, but supporting any language is difficult to pull off without huge delays.
WebAssembly is currently focusing on languages that are traditionally compiled ahead-of-time, work well with on linear memory heap, and which don't require dynamic recompilation, runtime code loading, or garbage collections. Some of these constraints were there to get to a Minimum Viable Product as early as possible (this happened in February 2017), and take into account what existing in-browser compilers can do.
Note that the MVP doesn't support threads. Threads will be added shortly after.
Python, JavaScript and Ruby can easily be supported by compiling an interpreter, written in C/C++, to WebAssembly. Later versions of WebAssembly will support JIT-compilation, but engines like V8 will have to target WebAssembly as if it were a new ISA (e.g. on par with x86-64 / ARM / ...).
C# and Java require similar GC and stack manipulation primitives. That's also on the roadmap, but after MVP, threads, and dynamic linking.
Note that the languages may work just fine, but supporting all their libraries is also difficult! We (browser engineers) can work towards supporting languages well, but we need communities to build up around great library support.
On your last sentence: yes WebAssembly should be able to do many things JavaScript can do because it'll have access to the same Web APIs. Its goal isn't to replace JavaScript though: it's to complement JavaScript, avoid adding features to JavaScript for the sake of un-naturally supporting other languages, and offer predictable near-native performance to low-level languages such as C++ / Rust.
Keep JavaScript evolution for folks who target JavaScript or compile similar languages to JavaScript (e.g. TypeScript), and evolve WebAssembly to be JavaScript's cool sidekick who likes other languages.
Eventually WebAssembly will support even more low-level features. Some of these wouldn't make sense for JavaScript to adopt, yet existing code (e.g. large C++ codebases) assumes these features exist for correctness and / or performance.
Should people stop writing JavaScript and switch to WebAssembly? No. I expect the tight integration with JavaScript means that WebAssembly modules will be used from JavaScript (say, a fast image processor), and existing C++ codebases will target the web, but I don't see JavaScript dying any time soon.
I think in this case gradually, written in javascript code will be transferred to a more preferred programming language.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With