Is WebAssembly returning Java and Flash applets?
- Transfer
In the last article on WebAssembly, I made the following statement:
I think the comparison with Flash and Java applets is quite natural when you come across this description of WebAssembly:
The first reason for the differences WebAssembly is that he eventually managed to succeed, but the previous technologies do not. I mean victory in a specific sense. If you compare the number of Flash-applications and the number of applications WebAssembly, then Wasm certainly lose. Adherents of WebAssembly will have to work a lot to distribute this platform.
When I talk about the victory of WebAssembly, I mean that it has become part of the web platform. Flash, Java applets, and PNaCL worked through plugins. In a sense, they were outside the web ecosystem. They have never been included in the standard, and this is very important.
In a sense, this explanation is sufficient. But just pointing out a fact does not mean explaining its causes . The rest of this article will try to figure outWhy it happened: why WebAssembly managed what other technologies could not do. Here many reasons are connected with each other, but I am trying to reasonably divide them into separate points.
Remember this?
Or that?
How about this?
An applet created with these technologies is not really a web application . You have a web page with a piece cut out of it, and your applet worked in this frame. You lose all the benefits of other web technologies: no HTML, no CSS, no ability to integrate into the web. These platforms do not interact with the rest of the platform in the browser. Well, technically they can , but in practice these technologies were used differently.
How does the web support an ecosystem that is not integrated with it? This will never happen. And users ultimately strongly rejected it. In addition to games, users hatedFlash, and Java applets were heavy and slow. These technologies are not fixed in the web platform.
WebAssembly, on the other hand, is much closer to JavaScript. In fact, Wasm does not take away part of the screen from you. He does not create his own little closed world. Now with the help of JavaScript, and in the future independently , he is able to interact with the environment. He just ... fits into it.
Java was owned by Sun Microsystems, Flash was owned by Adobe. Why is it important?
Corporate influence on the Internet is a complex topic. In general, the web works on a pseudo-consensus model. Java and Flash, on the other hand, were controlled by their respective companies. They have a strong motivation to make a profit, not to improve the Internet. And this partially led to the above situation: these companies did not care to integrate properly with the rest of the platform. Why do they need it? It is much better for a business to block its platform and completely abandon the rest of the Internet. Motivation is completely skewed.
WebAssembly is a joint initiative of Mozilla, Google, Apple, Microsoft and others. It does not promote any particular platform, but instead represents the general interests of a wide range of stakeholders, both corporate and individual.
Corporate identity also means that these technologies have never followed the process that we use to standardize the web. The process of adopting web standards is well established, but these technologies were too big and worked a little differently. In contrast, WebAssembly followed the standard procedure adopted for web technologies.
It was first created
WebAssembly was an improved version
Another reason why Wasm succeeded: it is tiny. Wasm uses the approach of other web technologies: start small and grow on this basis. Maintain backward compatibility. Past technologies also did not follow this particular social convention. A specific runtime environment was loaded for Flash and Java applets, so compatibility was not required. PNaCl is built on top of a completely unstable LLVM IR code. They were going to make it a stable subset, but if LLVM was changed, there would be a discrepancy, which is not very good.
These technologies are also too cumbersome to once hope for stabilization. Can you imagine that the four browser vendors fully define the JVM specifications and then agree with this semantics forever? For the whole ActionScript, which is in itself a similar, but different version of ECMAScript? For all LLVM-IR?
Major technology introduces unacceptable risk. This is an “all or nothing” deal, and here is a secure “nothing” bet. WebAssembly, on the other hand, does almost nothing. This is mainly math and javascript challenge. That is, it is much easier to agree.
In this article I did not mention Dart, but he also fits here. The sentence “Let's just put the JVM in every browser” has the main problem that the browser already has a runtime for JavaScript. Even one runtime environment is difficult to maintain, not to mention two. And how do you integrate them?
WebAssembly, on the other hand, is designed as a small extension to existing JavaScript virtual machines. Although you can implement your own WebAssembly virtual machine - this is often done when using offline WebAssembly, but for browsers the maintenance costs are much, much lower.
WebAssembly is fundamentally language independent. Flash and Java applets were created primarily to launch ActionScript and Java. They are deeply tied to their relative semantics. Even PNaCl suffers to some degree from this: LLVM is really adapted for C-like languages, although not quite to the same extent.
Do we really want to choose one language for the entire Internet? We already have javascript. Ever introduce a third language? Fourth? An independent approach is much better in the long run.
Java applets and Flash were a real nightmare for security. Even if attempts were made to secure them, in reality problems constantly arose.
On the other hand, WebAssembly again received bonuses from a JavaScript VM: all efforts to isolate its sandboxes also apply to Wasm. Some of the functions of a regular assembler are missing here, which can lead to vulnerabilities, such as stack destruction. Wasm safely works with memory, which is very important!
In addition, WebAssembly was originally designed for validation : it is fully typed, and programs can be tested without running code. Specifications include instructions on how to do this validation. This is quite useful!
I want to say the following about this article: it is written from the point of view of the developer . But developers are important because they control the web. The technology must meet their goals - it is as important as convenience for end users. In a future article I will try to analyze the problems from the point of view of users. Will have to write a lot!
Summing up:
Some compare WebAssembly with Java applets. In a sense, they are right, but on the other hand they are greatly mistaken. Somehow I will write an article about the differences, but for now let's talk about the similarities. In a sense, WebAssembly is another way to do what the JVM was intended for: it is a regular virtual machine for cross-platform software.Many people have expressed interest in this topic, so let's take a closer look at it! In this article, we compare WebAssembly with three technologies: Flash, Java applets, and a little with PNaCL. In addition, the article focuses on the use of the web , although we have previously considered options for using WebAssembly offline. But we will talk about this comparison later. Finally, this article is like eating tapas [Spanish snack of many different ingredients - approx. Lane], there are a lot of small sections. It seems to me that it is a bit short, but at the same time I try to keep a blog, and if you continue to expand it, it will take forever, so sorry.
I think the comparison with Flash and Java applets is quite natural when you come across this description of WebAssembly:
WebAssembly (Wasm for short) is a binary instruction format for a stack virtual machine. Wasm is designed as a portable compilation of high-level languages such as C, C ++ and Rust, which allows you to deploy client and server applications on the Internet.This is a bit like past technology. It is quite logical to compare how they are related, and suggest small differences between them. But WebAssembly is significantly different for several reasons.
Wasm won
The first reason for the differences WebAssembly is that he eventually managed to succeed, but the previous technologies do not. I mean victory in a specific sense. If you compare the number of Flash-applications and the number of applications WebAssembly, then Wasm certainly lose. Adherents of WebAssembly will have to work a lot to distribute this platform.
When I talk about the victory of WebAssembly, I mean that it has become part of the web platform. Flash, Java applets, and PNaCL worked through plugins. In a sense, they were outside the web ecosystem. They have never been included in the standard, and this is very important.
In a sense, this explanation is sufficient. But just pointing out a fact does not mean explaining its causes . The rest of this article will try to figure outWhy it happened: why WebAssembly managed what other technologies could not do. Here many reasons are connected with each other, but I am trying to reasonably divide them into separate points.
Other technologies do not fit into the platform.
Remember this?
Or that?
How about this?
An applet created with these technologies is not really a web application . You have a web page with a piece cut out of it, and your applet worked in this frame. You lose all the benefits of other web technologies: no HTML, no CSS, no ability to integrate into the web. These platforms do not interact with the rest of the platform in the browser. Well, technically they can , but in practice these technologies were used differently.
How does the web support an ecosystem that is not integrated with it? This will never happen. And users ultimately strongly rejected it. In addition to games, users hatedFlash, and Java applets were heavy and slow. These technologies are not fixed in the web platform.
WebAssembly, on the other hand, is much closer to JavaScript. In fact, Wasm does not take away part of the screen from you. He does not create his own little closed world. Now with the help of JavaScript, and in the future independently , he is able to interact with the environment. He just ... fits into it.
Other technologies belonged to companies.
Java was owned by Sun Microsystems, Flash was owned by Adobe. Why is it important?
Corporate influence on the Internet is a complex topic. In general, the web works on a pseudo-consensus model. Java and Flash, on the other hand, were controlled by their respective companies. They have a strong motivation to make a profit, not to improve the Internet. And this partially led to the above situation: these companies did not care to integrate properly with the rest of the platform. Why do they need it? It is much better for a business to block its platform and completely abandon the rest of the Internet. Motivation is completely skewed.
WebAssembly is a joint initiative of Mozilla, Google, Apple, Microsoft and others. It does not promote any particular platform, but instead represents the general interests of a wide range of stakeholders, both corporate and individual.
WebAssembly followed the web process
Corporate identity also means that these technologies have never followed the process that we use to standardize the web. The process of adopting web standards is well established, but these technologies were too big and worked a little differently. In contrast, WebAssembly followed the standard procedure adopted for web technologies.
It was first created
asm.jsas evidence that we can do impressive things with the web. His performance turned out to be of sufficient quality and demonstrated the capabilities of the technology, although there is nothing fantastic there. The trump card asm.jswas that this is just JavaScript code: it is fully compatible with the existing ecosystem. “Do not break the Internet” is a very, very important rule for browser developers.WebAssembly was an improved version
asm.js. After finding a certain consensus around, asm.jseverything came together to make WebAssembly a reality. Since this is not just JavaScript, it had to go through the whole process for implementation in browsers, and it went through it. Now this is a W3C specification that conforms to, and does not contradict, web standards.Consequence: other technologies were too large and unstable.
Another reason why Wasm succeeded: it is tiny. Wasm uses the approach of other web technologies: start small and grow on this basis. Maintain backward compatibility. Past technologies also did not follow this particular social convention. A specific runtime environment was loaded for Flash and Java applets, so compatibility was not required. PNaCl is built on top of a completely unstable LLVM IR code. They were going to make it a stable subset, but if LLVM was changed, there would be a discrepancy, which is not very good.
These technologies are also too cumbersome to once hope for stabilization. Can you imagine that the four browser vendors fully define the JVM specifications and then agree with this semantics forever? For the whole ActionScript, which is in itself a similar, but different version of ECMAScript? For all LLVM-IR?
Major technology introduces unacceptable risk. This is an “all or nothing” deal, and here is a secure “nothing” bet. WebAssembly, on the other hand, does almost nothing. This is mainly math and javascript challenge. That is, it is much easier to agree.
Corollary: other technologies require a whole separate virtual machine.
In this article I did not mention Dart, but he also fits here. The sentence “Let's just put the JVM in every browser” has the main problem that the browser already has a runtime for JavaScript. Even one runtime environment is difficult to maintain, not to mention two. And how do you integrate them?
WebAssembly, on the other hand, is designed as a small extension to existing JavaScript virtual machines. Although you can implement your own WebAssembly virtual machine - this is often done when using offline WebAssembly, but for browsers the maintenance costs are much, much lower.
Other technologies are too specific
WebAssembly is fundamentally language independent. Flash and Java applets were created primarily to launch ActionScript and Java. They are deeply tied to their relative semantics. Even PNaCl suffers to some degree from this: LLVM is really adapted for C-like languages, although not quite to the same extent.
Do we really want to choose one language for the entire Internet? We already have javascript. Ever introduce a third language? Fourth? An independent approach is much better in the long run.
Wasm has a strict approach to security
Java applets and Flash were a real nightmare for security. Even if attempts were made to secure them, in reality problems constantly arose.
On the other hand, WebAssembly again received bonuses from a JavaScript VM: all efforts to isolate its sandboxes also apply to Wasm. Some of the functions of a regular assembler are missing here, which can lead to vulnerabilities, such as stack destruction. Wasm safely works with memory, which is very important!
In addition, WebAssembly was originally designed for validation : it is fully typed, and programs can be tested without running code. Specifications include instructions on how to do this validation. This is quite useful!
Conclusion
I want to say the following about this article: it is written from the point of view of the developer . But developers are important because they control the web. The technology must meet their goals - it is as important as convenience for end users. In a future article I will try to analyze the problems from the point of view of users. Will have to write a lot!
Summing up:
- Other technologies were not integrated into the web platform, and commercial interests interfered with this.
- Other technologies required too much: many had to sacrifice implementation.
- Wasm has really good sandboxing and validation, which others just didn't have.