Transpiling), which has some obvious drawbacks. High-level languages ​​have different functions, grammar, and habitual expressions. You can’t map every line in one language to an equivalent construct in another. Even if you can do this, you will leave a lot of pits. What if the community stops developing your favorite translator? What if the translator introduces a lot of errors on its own? How do you want to insert a JavaScript framework like Angular, React or Vue? If your language is different from your colleagues, how do you work with your team?

Many things in the programming industry are essentially the same, that is, the level of a tool depends primarily on the prosperity of the community behind it.

Who will replace JavaScript?

Translators are very common today, but they have almost one use – that is, to handle backwards compatibility.

Developers might write cutting-edge JavaScript and then use a translator like Babel to convert their code into equivalent (but less elegant) old-fashioned JavaScript code to run in all locations. Or better yet, they use TypeScript (a modern JavaScript that adds features such as strong typing, generics, and non-null types) and then converts them to JavaScript. But no matter which method, you can’t escape the palm of JavaScript.

Asm.js: Stepping Stones

The first light of the new possibilities comes from asm.js, an eccentric experiment done by Mozilla developers in 2013. At the time they were looking for ways to run high-performance code in the browser. But asm.js doesn’t try to run outside the browser like a plugin; instead, its goal is to make a channel directly through the JavaScript virtual machine.

In essence, asm.js is a concise and optimized JavaScript syntax. It runs faster than normal JavaScript because it avoids the slower dynamic parts of the language. And the web browser that supports it can also apply other optimizations to significantly improve performance. In other words, asm.js follows the golden rule – don’t break the Web – and provides a way to improve in the future. The Firefox team uses asm.js and a translation tool called Emscripten to put real-time 3D games built in C++ into a web browser.The conditions needed are just JavaScript and the ambition to achieve the goal.

Who will replace JavaScript?

Unreal Engine running on asm.js

The biggest significance of asm.js is that it forces developers to rethink the role that JavaScript plays. The Asm.js code is JavaScript, but the code is not intended for programmers to read and write by hand. Instead, the asm.js code is built by an automated process (translator) and provided directly to the browser. JavaScript is the medium, but not the information itself.

WebAssembly: A new technology

Although the asm.js experiment has made some dazzling demonstrations, most mainstream developers are indifferent. For them, this is just another interesting technical concept. But with the birth of WebAssembly, things have changed.

WebAssembly is both a successor to asm.js and a completely different technology. This is a compact binary code format. Like asm.js, the WebAssembly code is also entered into the JavaScript execution environment. It has the same sandbox and the same runtime environment. Like asm.js, WebAssembly’s translation mechanism can further improve efficiency. But now this potential is much larger than before, and the browser can completely skip the JavaScript parsing phase. For a common piece of logic (such as a very time-consuming calculation), WebAssembly performs much faster than regular JavaScript, almost as fast as natively compiled code.

Who will replace JavaScript?

Simplified view of the WebAssembly processing pipeline

Want to know what WASM looks like, imagine you have a C function like this:

int factorial (int n){

if (n == 0)

return1;

else

return n * factorial(n-1);

}

It compiles into WASM code and it looks like this:

get_local 0

i64.eqz

if(resulti64)

i64.const1

else

get_local0

get_local0

i64.const1

i64.sub

call0

i64.mul

end

When starting to transfer to the network, the WASM code is further compressed into binary encoding.

WebAssembly is designed to be the target of the compiler. You never have to hand-write its code automatically. (But if you want to explore it in depth, it is ok to write it yourself.)

WebAssembly was born in 2015. Today, the four browsers on desktop and mobile devices (Chrome, Edge, Safari, and Firefox) fully support it. Internet Explorer is not supported, although WebAssembly code can be converted to asm.js for backward compatibility. (The price of compatibility is performance loss. Please let IE go into history!

WebAssembly and the future of web development

WebAssembly is out of the box, giving developers a way to write optimized code logic (usually in C++). This is a powerful capability, but the scope of application is relatively narrow. This method is useful when you need to improve the performance of complex calculations (for example, fastq.bio uses WebAssembly to speed up their DNA sequencing calculations. If you are porting a high-performance game or writing a simulator that runs in a browser, this The ability is also important. But if this is the full strength of WebAssembly, there is nothing to be excited about – it’s just that there is no hope of replacing JavaScript. But WebAssembly also provides a narrow path for framework developers to make They can plug their platform into a JavaScript environment.

This thing becomes interesting. WebAssembly can’t circumvent JavaScript because it’s locked in JavaScriptIn the runtime environment. In fact, WebAssembly needs to work with a minimum of normal JavaScript code, because the former can’t directly access the page. This means that WASM cannot manipulate the DOM or receive events without going through the JavaScript layer.

It sounds like this limit is fatal. But smart developers have found a way to stuff their own runtimes through WebAssembly. For example, Microsoft’s Blazor framework will download a small .NET runtime as a compiled WASM file. This runtime handles JavaScript interop and provides basic services (such as garbage collection) and higher levels of functionality (layouts, routing, and user interface widgets, etc.). In other words, Blazor uses a virtual machine that resides in another virtual machine, a paradox at the level of the Pirates of the Dream space, and a clever way to run a non-JavaScript application framework in a browser.

Blazor is not the only one supported by WebAssembly. Also take a look at Pyodide, which is designed to put Python into the browser with an advanced math toolkit for data analysis.

This is the future. WebAssembly was originally created to meet the needs of C++ and Rust, but was quickly used to develop more ambitious experiments. In the near future, it will support non-JavaScript frameworks to compete with JavaScript-based rivals such as Angular, React and Vue.

And WebAssembly is still growing rapidly. Its current implementation is just a minimally viable product – only enough to use in some key scenarios, not a versatile Web development method. With the promotion of WebAssembly, it will continue to evolve. If a platform like Blazor is popular, WebAssembly may add support for direct DOM access. Browser developers are also planning to add garbage collection and multi-threading support so that they don’t need to implement these details themselves.

It seems that this development path is long and full of variables, but please recall the history of JavaScript. First, we found that what JavaScript can do is written as JS code. Then we realized that if one thing is repeated many times, the browser will make it do better, and so on. If WebAssembly becomes popular, it will enter a virtuous circle that will continue to evolve and easily surpass the inherent advantages of JavaScript.

People often say that WebAssembly is not intended to replace JavaScript. But this sentence is the same for all revolutionary platforms. JavaScript was not meant to be replaced at first.Java embedded in the browser. Web applications are not intended to replace desktop applications. But once they can do this, they will definitely follow that path.

Author introduction

MatthewMacDonald is a teacher, programmer, and author of many major departments.

English original text

https://medium.com/young-coder/what-replaces-javascript-a6493b4e2d6e

The cover image is from pexels