Unlocking the WebAssembly with Brendan Ike

(Approx. Translation: asm.js and WebAssembly technologies have not yet come to the practical plane, regular signals from the tops of Olympus of web technologies development (Mozilla, Microsoft, Google) regularly go about them, but many people know little about their condition. So , it's about time to find out about them now.

Presented by Brendan Ike's interview , made on March 31, 2017. It’s for 1.5 hours , but the 2nd half is about the Brave browser project, does not apply to JS compilers), the creator of Javascript and journalists from SE Daily .

[0: 02: 53.9] Caleb Meredith (CM): I'm here with Brendan Ike, creator of the JavaScript programming language and chief executive of Brave Software. Brendan, welcome to Software Engineering Daily!

[0: 03: 01.0] Brendan Eich ( BE ): Hi, thank you for inviting me.
')
[0: 03: 02.0] CM: Let's start with a WebAssembly. The lowest-level human-readable instruction format that we provide to the machine is an assembly language, the format of which depends on the computer. JavaScript is a much higher level programming language, but it is sometimes described as an assembly language for the Web. Recently, the W3C Community Group, to which you, Brendan, have joined, is working on the WebAssembly specification. Why is assembly language useful for the Web, and why is simply not enough JavaScript as the WebAssembly language?

How did Javascript appear and become?

[0: 03: 37.5] BE : Let me begin by starting with how JavaScript appeared to start playing a modern role. I did javascript in a hurry, in May 1995 for 10 days, in Netscape, and it was partially focused on similarity to Java, due to the company's internal policy. As a result, JavaScript, because it is loaded from HTML and can be written by anyone, from small scripts to large programs, has taken the place of defeated Java on the client side of the Internet over the past 22 years.

JavaScript was an urgent job. Constructions of skeletons of other languages ​​were quickly reworked by me into a Frankenstein robot. He was born fairly quickly, not only because of the Netscape policy, but also because of the binding of Microsoft Windows to Internet Explorer and its connection with Netscape; in the end, this led a lawsuit in the US to Microsoft for abusing the monopoly ... We knew that we needed to hurry. We had some technologies in Netscape 2 — Java-oriented JavaScript, plus some early HTML innovations in Netscape. We understood that if we made them among the first, they would become part of web standards.

In fact, JavaScript was the little that survived from that time. This runtime environment, which does not require installation, has become available almost everywhere, it exists on mobile devices, is embedded in applications on web page technology and, of course, works in browsers that are still economically important for both mobile devices and desktop. computers, here and there.

Imagine: as a software developer in the 90s, you could possibly program for a Windows PC. You should have used Microsoft Visual C ++. If a database was needed, Rogue Wave [0: 05: 23.4] or something similar was used. Then you browse the Internet, and you are surprised to see that no one there is doing this. Everyone makes websites that do not require installation.

Game developers still used C ++ because they needed to get to hardware. In fairness, I exaggerated when I said that no one does. There are still other “fat” applications that have become smaller, because the browser has absorbed most of them and turned the server-based business models into software.

However, the games and your other hardcore applications that are tied to the hardware, if they were forced to use JavaScript, then they had problems, because JavaScript, in addition to its rapid development, has improved the standards for the last 20 years. Got better. He has become more. Opportunities increased and smoothed out some uncomfortable places, and everything went well, except for the garbage collector. It has a performance uncertainty. Predictable performance is one way to tell where you can calculate something at 60 frames per second for a game; and suddenly - you are running out of real time because of the garbage collection that must occur in order to reclaim the occupied memory. Or you made a new engine, and your program changed the idea of ​​the types it supported in the Javascript interpreter.

Now all the code should be recompiled. This can take a lot of real time, and you will not keep within your 162nd frame of animation, you will be pushed out of this conditional limit in real time. Then the game becomes slower, lagging, or the animation is not updated properly. This is a serious competitive disadvantage for games, so developers prefer to stay in C or C ++, so they like to work alongside hardware.

Compiled subset of Javascript asm.js

And this is what we found as a result of the fact that JavaScript has become so ubiquitous and fast, not counting these unpredictable performance failures — we found that if you use a subset of JavaScript — this has been Mozilla since 2012 — if you only focus on parts JavaScript, which looked like the C programming language, like the editing functions for WebGL, and used memory in a flat, large, continuous array called Typed Arrays - then, if you use a subset of JavaScript in this memory model, you can work almost as fast as in C or C ++. You can execute a program in the same way as with any safe approach to such low-level languages. In this case were predecessors, since the 90s; no one has heard of them, especially the native mobile client working for Google, which was at the time, in 2012.

We developed this subset of JavaScript in Mozilla, named it asm.js in honor of the assembler, made a type system for it - Dave Herman made it. Mozilla's Luke Wagner, who is still there, made a terrific compiler for a subset of JavaScript with type checking, such that during parsing it was determined whether this code was asm.js from a subset and it was possible to generate a really good machine very quickly. code, with secure memory access. This was the most important requirement.

When we worked with Mozilla, we used including the compiler developed by Alon Zakai. He wrote his Emscripten as a C or C ++ compiler based on LLVM, which generates JavaScript. To tell you the truth, asm.js was formalized with Dave Herman’s typing, alone in fact - I remember, he said that in 2011 at the JSConf EU. Alon has already developed an intuitive understanding of a subset in the type system for assembler JavaScript by creating an Emscripten compiler and creating its JavaScript to quickly transition to JavaScript with typed arrays in a flat memory region for regular heap variables along with global (heap is a term from compiler theory ).

The JavaScript stack was used for stack variables in C. The translation was very neat for optimizing compilers, and only he helped us understand what asm.js. is. Again, there were predecessors. In Adobe Labs, there was someone who created the system — it seems that it was called Alchemy — which used an earlier version of the LLVM compiler firmware to do the same thing as ActionScript 3 in Flash Player. We were aware of this work, and it was in this school that we studied safe methods for executing our own code.

Then we realized that asm.js could be just a subset of JavaScript with the Typed Array extension. It became standardized because WebGL finally got into all LSS, including iOS. We understood: “This is likely to be a new, secure, portable native code execution environment. It will kill the portable Native Client (PNaCl) on Google. ”Google’s (the pinochle people) plankton didn’t want to admit it, but we really did it. Luke Wagner wrote his fast compiler. Alon Zakai continued to work on his front-end Emscripten, which generated JavaScript code. Dave Herman made sure that the type system was “breathing”.

Going to the game world

By the end of 2012, we contacted Epic Games, the developer of the Unreal Engine, visited a small group. In less than a week, for four days, on the fifth, when they rested, Unreal Engine 3 was ported to the web by cross-compiling its C ++ codebase, the multi-million base of code lines into JavaScript and asm.js. We had to do something similar to their audio APIs for the web audio interface, and they had adapters for OpenAL and other audio libraries, which was easy.

They have already used OpenGL to optimize the mobile GPU graphical interface. WebGL is based on OpenGL, so it was a quick adaptation. They edited the Emscripten bug or two, they had to fix the JIT compilation on the backend, which works on the entire asm.js module, therefore, in a sense, what was done ahead of time. That weekend they had Unreal Engine 3 with full frame rates in the prototype version of Firefox. Tim Sweeney, the founder of Epic, was stunned. He said: “I thought it would take years. And suddenly - everything is ready! ".

Since that time, we in Mozilla have continued to work on our engine, making sure that it works for other games. We worked with Unity developers. I think they announced this next year. We let Microsoft know - they were interested, so I suggested we talk to Microsoft with the engineers. After that, I met with Anders Hejlsberg, the creator of .NET and C #, and Steve Lukko when he led the JavaScript team, the ChakraCore team at Microsoft. They were very interested in asm and joined the project at that meeting, and soon enough announced it.

Over time, about the last three years, asm.js became the environment that could inevitably be made super-fast. The runtime environment that you already have — the browser, instead of trying to add another runtime environment — is not just a portable native client. They wanted to do it on Dart, but this was largely unsuccessful even for Chrome. It is very difficult to add a second environment after javascript. I can understand why. Even Flash, which was the second medium as a plugin, slowed down its execution. Steve Jobs banned it in iOS, and therefore, I think it was withdrawn in Android around 2011.

There was nothing other than a browser available if you had to have fast optimization for languages. The only problem was that everyone said they only understood javascript. Now there was still asm.js - a subset that could be used as a target language for compilers. Over the past six years, people have already built hundreds of compilers from various languages, such as Python, Java or Ruby, in JavaScript. It was a common topic at conferences. People knew that Emscripten is one of many among a large set of compilers.

Some of these compilers did not have to work hard to optimize, because they took a language that was not very fast and translated it into JavaScript. They often translated languages ​​that had a similar semantic level and style to JavaScript, so compiling was easy. This became known as transpiling (cross-compiling). This is done even for our future versions of JavaScript and for previous ones. Emscripten was the one who brought these things to machine code and was used by game developers. Especially when Unity 5 got its "tool chain" (tool chain), when you could take any game of Unity, poke a button, and what they called the "WebGL port" was born, which actually meant asm.js, WebGL , web audio that can be embedded in HTML. Just think that you can have an Xbox game, you make it a second life on the Internet, put it in a store where you can try it before you buy it by simply downloading it into your browser. This is a great success.

How did the concept of WebAssembly come about?

It was clear that JavaScript could be a virtual machine, or a virtual machine for JavaScript could be a virtual machine for mobile languages. JavaScript is still loaded as source code, even asm.js code. When I developed JavaScript, I did not select the shortest keyword for function, these are eight letters. They are just the cost of parsing javascript. Even if you compress it during transportation and transfer the transport layer compression, which saves network bandwidth, saves data costs, and then you still have to unpack it in memory on the target device, and then analyze it.

It turns out that this is why there is a ported Unity-game or even games that can be played right now. For example, the game “Ski Safari” has found a second life on Facebook in the form of a compiled game, asm.js; You can go there and play. It's very funny. It was originally a mobile game. In my opinion, it uses Unity in the 2D version. She has a third dimension, she is a fun high speed skiing game. It works at full frame rate, but at the time of loading it slows down a bit.

It works best in Firefox due to the great work of Luke Wagner. The VA team from Google didn’t really want to do the same complete compilation of programs as Luke. Microsoft people did. They actually took Luke’s code and changed the style, but retained the copyright for Mozilla, and it had to be licensed; they could use the license, so you really will find the code in ChakraCore on GitHub. This engine is now in Edge and in IE, you will find the version of the OdinMonkey compiler from Luke for asm.js. That is why some browsers are better than others in Ski Safari, but download time is a headache.

If the games change levels - there is the same problem [download speed]. Even before I left Mozilla in 2014, we thought, “How can I fix this? Maybe we’ll come up with a binary syntax that makes sense for this subm asm.js? ". It's brilliant - WebAssembly appeared before our eyes. As soon as Microsoft connected to us, at some point it seemed that everything could be finished in early 2015 I’m not sure when these rumors were exactly. There was a “fight” between the VA team and the Portable Native Client team, “the blood flowed like water.” Then, as a result, the VA team won. It was, as I said, clearly all. You will not deal with the second safe executable code. We thought - rather, let's take the JavaScript engine and Adim it is the second input language - WebAssembly.

Apple, too - Apple never announces its earlier intentions, they always want to control their history at WWDC - but Apple got on board. I can say it now, in retrospect. Then I did not want to disclose this. People from Hacker News hurried: now, they say, you have all four browser vendors with the general idea of ​​WebAssembly. Some of them even said: “Yes, asm.js is just a subset of JavaScript. We will quickly achieve results. We do not even need to recognize it as such so that it is fast. You will give us C-like low-level JavaScript that uses a large typed array of memory. We will write fast code. Don't worry about it. "

Asm.js has become like such a whipping boy on the topic “Why do you not have the correct binary syntax?” And this is just one reason, a convincing argument in favor of WebAssembly. As soon as all browser vendors joined the team, WebAssembly began to advance as a W3C community project, as you mentioned, and, of course, on GitHub, where the code and design specifications are.

What is WebAssembly?

[0: 19: 52.7] CM: Explain on fingers what is a WebAssembly? What does he look like? You open the WebAssembly file, what is there?

[0: 19: 57.8] BE : I hope I can tell you why this is useful and why they started doing it. Useful - because it loads faster and gives you a low-level memory model and instructions for performance. You can make a 60-frame shooter (shooter) in the first person.

What does it mean? If you think of JavaScript, for a moment, as C, its expression grammar, C has all the bitwise logical and shift operators, it has several confused priorities because of the history of C, and it has arithmetic operators. JavaScript does not have integer types explicitly, but by bitwise operators you can reduce a number to an integer 32-bit value, remove a sign from signed integers in time series, in the evaluation of an expression. This is the key to asm.js. So, asm.js can have integers that pass faster through a block with a floating comma, not turning into double-precision IEEE 754 numbers, because of which everyone likes to blame both JavaScript and Java. They were a problem with JavaScript types, since it only has this type of number, so people sometimes want to use a different type — and it just isn't there yet. We are working on correcting the situation.

In any language, numbers have double binary precision IEEE 754. If you add 0.1, plus 0.2, and print out the results with complete accuracy, you will find that it is not 0.3, but 0.300000000000000008. This is because you actually do the math in the binary-decimal value, and you need extra precision to figure out how to round, but rounding is done with an error due to finite precision, and you end up with 8 at the end after many Zeros. This is IEEE 754.

Bit-shifted JavaScript operators allow you to handle 32-bit signed and unsigned integers if you use these statements as if they were typed. For the Emscripten compiler, this is easy to do, so this is part of the magic created by Alon Zakai, which led to the formalized asm.js, to do very fast integer math in a subset of JavaScript.

WebAssembly simply gives better syntax than writing infix operators in JavaScript. I think they work with a kind of small machine stack language for a part of the grammar of expressions, and they can have the syntax of bits. This is very efficient for parsing and forwarding.

For larger program structures, there are control structures in if-then-else type programming, while-loops, and other kinds of loops. It is obvious that JavaScript has such. WebAssembly also has them in a structured form. When Java was developed, it was compiled into bytecode, and then the code was sent over the network. The problem was that it was possible to force some kind of unreliable module to send you bad Java bytecodes. It was necessary to run the so-called verifier.

After a very long time, when there was no information about the type, they finally reported that the test could have abnormal (destructive) behavior. I remember my friend Michael Franz, a professor at UC Irvine, showed that they have an algorithm of order 4 of complexity, if you send this difficult test, something like a verifier bytecode, it will take an unexpectedly long time. And verifiers can make denial of service (DoS) attacks.

With WebAssembly, we learned that the WebAssembly binary syntax, despite the fact that it is a combination of prefix and postfix for part of an expression, the SAC machine code is a kind of self-test in the sense that if you analyze it, it will not do anything crazy [on resource costs]. You do not check the code for fraud. Since the verifier tried to check that it is not a malicious byte-code, which could confuse the type in the if-then-else-construction, you send the value through memory, through a variable of one type, and then an attack is possible using a bad type pond or another type, and then after if-then-else values ​​are used, but with the wrong assumption that they have only one type.

This check is important for security. With WebAssembly, you don’t have such an unpleasant control flow analysis problem that Java bytecode has had a very long time, where you can have type confusion if you don’t carefully analyze go-to spaghetti operations that are possible in Java bytecode.

As far as I know, there is no free go-to in WebAssembly. They changed this a little bit, but I think it’s still structured code in the old sense of the 70s structured programming. Not having a go-to is considered harmful, since it gets more compressed code. It loads faster, understands faster, consumes less energy. And then the games you play, such as Ski Safari, can be much faster when compiled into WebAssembly instead of asm.js.

What programs can now be ported to Javascript?

[0: 24: 37.8] CM: That goes well with the next question. You talked a lot about computer games. Honestly, most WebAssembly presentations also show some video game, run in C ++ and compiled using WebAssembly. What are some cases for WebAssembly, other than the inclusion of graphics-rich video games, or is this the only precedent, and this use case is incredibly attractive as WebVR grows or for some other reason?

[0: 25: 05.1] BE : I think that the example described is a good point, but this is not the only case of using complex constructions (long shot). Firstly, the games are very difficult. I went to the game developer conference. I remember hearing from one of the leaders of Valve - he stressed that the games took the place of practical system studies in operating systems. They entered the GPU, when it was still possible to control the GPU with non-malicious code while we were in the sandbox [and we have] different execution threads. They use multi-core. They moved to the vector processing units, the so-called SIMD modules, single commands with several units of data, which are now used in almost all hardware-software modules of the company.

Games really did use everything; They use threads. They were doing DSP. They do physics - it's not rendering, but still, it takes a lot of computation. They use AI functions — they now talk about AI at every corner.

WebAssembly is good for all these cases. It is good for machine learning, algorithms on your device, which can be very practical. They do not need to be in the cloud and use supercomputers. They can sometimes very efficiently perform simpler algorithms on your local data. It was also interesting for the Brave project - people need AI (AI) not only for games, but for all things now, for help and utilities, for voicing texts and vice versa.

WebAssembly is suitable for all these intensive calculations. The games are great because they are fun for the demo and for their viewers. As I said, they really use it all together. The only thing is that we are not able to do pixelation, this is dynamic load of JavaScript. People think, “Oh, WebAssembly! This means that you can get rid of JavaScript! ". Well, not yet. WebAssembly runs as a JS with a fixed amount of memory for C and C ++, and the plans include garbage collection, which should be done in integration with the garbage collector of the only working environment - the JavaScript engine.

Otherwise, you will face the problem of the guest host's cycle collector, where at any time, when you have two garbage collection systems that can form links in heaps together, they will be able to generate circular references. If the garbage collectors do not have special protocols to communicate with each other, or the main executive (supercaller) does not, these cycles become unacceptable. This is an argument for having .NET, which is a multilingual, polyglot, virtual machine with one memory manager. This is what JavaScript is growing into now, improving multilingual support for building.

The WebAssembly in the current minimally viable product (MVP, minimum viable product) truly reflects what is a great achievement for C and C ++, and possibly some other languages ​​that may correspond to the [garbage collection] model. Over time, you need to add garbage collection in this consolidated form so that everyone uses GC (Garbage Collector) and Java Search Engine, without running the guest GC and / or assembly code. You can, of course, do this anytime, but if you ever create links, you will have unrecoverable loops.

I want dynamic languages ​​to quickly, dynamically execute a method that may or may not be in the object. As in the case of the JavaScript engine in Python, sometimes there is no type system, there is no stable representation in the code, which means the type of the object, and you call its method. You always call the same method in the same call configuration. This is how JIT compilers are tested. However, WebAssembly does not yet have the appropriate instructions. Even JavaVM gurus call methods dynamically if they know what the instruction is doing in Java bytecode.

I think it can be put in plans (roadmap), and it will be, but in the end. First you need a few things to really support truly dynamic untyped languages, as well as statically typed languages: C, C ++, Rust from Mozilla and other companies that I think will work well with WebAssembly as a target compiler language now or in the near the future. This means that you can not quickly get rid of JavaScript. In fact, JS will be so obligatory for a long time. There is no definite schedule when you can say, “Oh, yes. By the fourth quarter of 2018, we will be free from JavaScript and have a WebAssembly mechanism, and all JavaScript on the Web can be compiled by the browser into a WebAssembly. "This is a dubious plan. There is no such plan yet. We will develop over the years and think that this may happen, but sometime later, beyond the horizon.

Will all cats go to heaven?

[0: 29: 30.7] CM: Is it true that the code will be compiled into WebAssembly, which over time will gain access to all browser APIs that JavaScript has access to? And one day you will be able to write an entire application in a language other than JavaScript, which is compiled into WebAssembly?

[0: 29: 44.8] BE: I think that, in principle, the answer is yes. APIs that JavaScript can access should be accessible via WebAssembly. You can do this in any way, since WebAssembly is designed to work in a module included in JavaScript, ECMAScript 2015 or the so-called ES6. We still have the fact that the modules work in browsers as separate working group specifications. This takes time, but the WebAssembly idea is modular. This means that you will have something ... as I said, you may have a JavaScript application that will start using the WebAssembly module for machine learning or for the physics engine, or at times for intensive numerical calculations. Algorithm code for WebAssembly can be immediately written in C or C ++.

You will have a mix-and-match model for JavaScript in WebAssembly, so you can always sort the proxy API calls that JavaScript can do with WebAssembly code. The WebAssembly development team has good brains, which are assembled from four browser vendors and understand how to make API calls easily, safely and efficiently through WebAssembly.

I think the general answer is yes, you get all these APIs, and, of course, you might want the games to be cross-compiled and fully translated into the target language. Today it may be asm.js, because WebAssemblies have just been implemented in some top browsers.

A year later [games will be compiled] such as Ski Safari on Facebook, Heroes of Paragon. These are the games that I played on Facebook compiled into asm.js, they can be compiled into WebAssembly. When they are, to a large extent, complete programs - you can make modules, mix and combine, making a single program.

Does Senka have a hat?

[0: 31: 31.9] CM: In a world where a developer can write an entire program in any language that compiles to WebAssembly, the JavaScript language should show that he really is a good programming language. In the end, the developer can write his application in Rust or Haskell or in an unknown future language, without regard to JavaScript. As the creator of JavaScript, I would like to ask: why did someone consciously decide to write their own web application in JavaScript? Is there any merit of JavaScript besides the fact that it is part of an evolutionary system, and it has a share that it has today, because it is the only dynamic language in the browser?

[0: 32: 09.4] BE: I think that opinions differ in languages. You go to Hacker News and still see how people spend time arguing [about languages] [0: 32: 15.4 globs].

[0: 32: 16.9] CM: I really want to hear your opinion.

[0: 32: 19.9] BE : I will express it. In the opinion of Paul Graham - people just fall in love with one language, which they learned first, or they think that it is better, and they assert it unconsciously. I am not going to do this for javascript. I use many languages. JavaScript has advantages in addition to being omnipresent due to a fairly early appearance due to the dirty work in May 1995 that I did, but JavaScript developed and development was important.

You hear, on Monday morning, sitting in a work chair, protests in the year of the 22nd anniversary: ​​"Oh, it could be a Python." No, this could not be, because Python was frozen, went out like a flying spark in 1995. Python was then version 1.3. You would not want it.

In addition, Python had an insecure front end. It is still the same. You would not want it to be on the Internet, because it would be a subset of Python. Then, if it was frozen, and the implementation of JavaScript would be too long, and all the standardization processes of [Python] would go through, but then we must have Firefox to restart the browser market; You would have Python evolution along a different line. That would be a web python. It would be very old, outdated. People would curse him for missing one Python 2, and then he would try to evolve, but would have to evolve differently, because the Web is a different medium.

Evolution matters. You can make dinosaurs complain: “Oh, if the oxygen level had not dropped, and the temperature would not have fallen, and those free creatures would not have won - I would have won.” This sounds helpless (original. - sour grapes).

I say that JavaScript really benefited from an evolutionary niche into which it entered, into space, into huge space, and not into a niche, which definitely meant that the monopoly causes discontent among people, where JavaScript is the only language, then, if God's mercy went to Python, we would get this shimmering sparkle bochuyu Python version which people would swear, not in JavaScript.

Another thing about javascript, I will tell you, is that I could, despite the haste and blunders, do some things right. It has the least authority model - the principle of minimum privileges.. If you get rid of several “backdoors” (vulnerabilities) that are quite wide, this can be a model of the capabilities of the object. This is exactly what Mark Miller in Google research with Google Caja declared a safe atmosphere, which is largely reduced to standards, so you can - with a strict regime and a few other points - you can control trust in a mixed environment. You can use object capabilities, security models with your basic safe pointers, proxies, and membranes to regulate authority [object management]. This is good for javascript. Not all languages ​​have this, and they also developed along with the Internet.

Security Considerations for WebAssembly

Now I have a problem with WebAssembly, because it is now in the W3C. In the W3C, there is a cargo-cult thinking that says: "You must have a cross-origin request security model based security model." I think at the same time that I forgot about everything that this means - CORS. Everything related to cross-domain. By default, you cannot load WebAssembly, this is bad. There is also [they] have such a reflex to the eval function in JavaScript, that anything — for example, eval or a function constructor — that can take a line of code and turn it into executable objects — badly.

“WebAssembly should only come from URLs. It should never be spawned from strings. ”- I think this is just nonsense. We constantly compose programs from strings. We do this in various ways on the Internet, even if you try to neutralize an eval, it returns. He raises his head. This is very much in demand, and security is not “Everything — or nothing!”. This is a compromise. You can limit programs using eval. You must be careful when analyzing a code that is accepted as a string. This is always the case because you use the code as a string for URLs.

I think in the modern world there are risks. Security has never even been resolved, and some problems have bothered big companies like Google. You get something like, as I said, cargo-cult restrictions like "all or nothing", thinking about safety, which in fact, I think, is not suitable either for safety or for convenience. I do not like the old approach to usability security. I think that the best solutions I have seen include both approaches.

Regarding the security of languages, Rust is a language that has a static security model. You cannot have a null reference pointer at run time. You cannot have memory errors outside the array in C-C ++. You cannot extend rights in a multi-threaded code, which is a theorem that easily follows from property rights.

Rust is very interesting to compile into WebAssembly, and I would choose it compared to JavaScript whenever I make some kind of heavy machine, but safe code. Yes, JavaScript is not a hammer for all nails. This has never been the case, so some people will use Java or Flash ActionScript, or even compilers that generate ActionScript code. Other types of runtime programs are dead. They became symbols of malicious software - JavaVM, JRE-plug-ins or Flash.

Because they belonged to one company that "lost its scent" (took its eye off the ball) and did not update the installation of security patches quickly enough, or, if done, it was still too late, as in the case of Flash. It became easy to start a farm of errors, and the bad guys did not have to worry about different versions of the browser.

The variety of browser implementations actually was an obstacle for these bad guys. I think this will be true for WebAssembly. Different mechanisms will be used for the attack, so it is better to have some variety in your system and level of implementation. This is a deeper point that I would point out. According to the research of Constantine Dovrolis from Georgia Tech, I believe that in any network system with hierarchical stacks of protocols or language stacks, or both, these evolving structures are usually obtained in the form of an hourglass, where the waist of the wasp in the form of an hourglass similar to javascript or http tcp / ip. It becomes an evolving core that is in the interest of every human being to be backward compatible and to develop slowly and carefully, given security considerations.Then you will get a lot of variety above and below. As in the work of Dovrolis on the network stack, you get a lot of communication layers from the old 10-megabit Ethernet on a coaxial cable to Metropolitan Ethernet on fiber optic or other radio communications via our phones.

All layers of communication channels are different from each other and are innovative for their time and space, but they all pass through the old TCP / IP protocol. This is also evolving. We get [20: 38: 48.5] HTTP / 2 and QUIC from Google. There is always a slow evolution, but it is very difficult to replace the old protocols. We still use DNS, the domain name system. These forms of evolutionary nuclei are stable, they are similar in their own way to valuable DNA. The same goes for javascript. Since the browser wins both in the runtime and in the mobile environment, it seems that this will continue for some time. Again, I can not specify the end date in javascript.

Is peace a war (browsers)?

CM: Last question, and he will help you talk about Brave. Now, with WebAssembly, is it likely to see a new era of browser warfare, because everyone will compete for the best implementation of WebAssembly?

[0: 39: 27.7] BE: This is a good question. I dont know. Browser wars are hard to predict, but they do arise when the browser market is really something wrong, like the monopolistic seizure of the market that happened in the United States. In fact, the case of ignoring the market by Microsoft, which, it seems to me, sparked a scandal against Microsoft in terms of trusting it after it questioned the simple idea that standards are necessary. It has not yet been punished in the EU for Windows Media Player and the further monopolization of its browser, so it has not formed its own standards for bureaucracy and diplomacy, which Microsoft now has. Now its standards are much better.

In those days, they said, “Back to Windows. Let's make the good old lock from Windows. We use .NET because Ander has done a good job with C # and the .NET runtime. “This set the stage for a new browser world that was launched by Firefox. When I was one of the people who built it, I recruited all the technical staff and was one of the main project managers when we left AOL. We knew that the browser market was flexible (it was possible to get into it) because Microsoft got out of it. They left IE6 their time, IE5, but the 6th was no better; a terrible browser with an architecture that had huge security problems due to ActiveX, and a lot of pop-up windows as a form of ad delivery, so we did things like control pop-up windows.

Browsers are vulnerable for many reasons. I don’t think that WebAssembly will be vulnerable, so I hope that all browser vendors will execute Java WebAssembly code. In fact, I’m concerned that after MVP - the minimum viable implementation of a product that is good for C and C ++ or Rust or similar languages ​​- that browser manufacturers will go different ways because they cannot be friendly under the pressure of competition; Some disciplinary work and a good social network will be required to support the WebAssembly in the direction of further following plans after MVP related to garbage collection support, dynamic languages ​​that provide fast support for method invocation, other required functions.

Maybe they reach implementation. Hope so. Maybe they will move slower. After MVP, they may have a small pause in WebAssembly, when they become comfortable, and developers will figure out how to better use the tools, how to make all these modules for machine learning, physics or various numerical calculations, mix and configure tools, because people now use chains tool chains with javascript, which is a big breakthrough.

16 years ago, people said: “Hurray, JavaScript! I want to write only natively. No ugly tools! ” Then gradually, through Lint, JSLint and ESLint, and then Babel ES6, people began to use cross-compilers, and in fact, it would be useful to reduce the differences between browsers. Therefore, when people learn how to mix in WebAssembly during development and compile code from another source language, they learn to mix other languages ​​with JavaScript. Whether the whole application or part of it, this skill will take time.

In fact, I do not want to express gloomy thoughts about the fact that browser providers cannot cooperate. Maybe they will do a great job with the transition to a WebAssembly implementation. In truth, developers need time to digest new concepts, so we need to devote time to learning. We should not overregulate it or restrain them.

It makes me think that browser wars, if they arise again, will most likely deal with higher-level problems, such as advertising and tracking visitors, and places where browsers do not work now, because the main browser providers do have conflicts of interest with their users. .

[0: 42: 54.0](The end of the part about WebAssembly. Further, in the original - the same amount of interview about the Brave project, about the suppression of advertising on the client, about the legal and moral aspects (do we have a moral right to press advertisements for unfortunate businessmen in our browser) Slave by B. Ike. You can familiarize yourself with it in audio or text format in the original language. But this is, in fact, another topic.)