Instead, they needed a new language-one that was designed specifically to be compiled to. There were still things that engines could do to make this faster.īut they couldn’t do it in JavaScript itself. Once the other browser vendors saw how fast asm.js was, they started adding the same optimizations to their engines, too.īut that wasn’t the end of the story. This subset of JavaScript was named asm.js. But Mozilla engineers found a type system hiding inside the generated JavaScript, and figured out how to make this JavaScript run really fast. The JS it automatically generated was still significantly slower than the comparable native code, though. This made it possible to bring large existing C++ code bases, for things like games and desktop applications, to the web. The very beginning of WebAssembly’s story starts with Emscripten, which made it possible to run C++ code on the web by transpiling it to JavaScript. So let’s look at what’s been filled in already, and then we can see what’s yet to come. We’ve fully filled in the top few of these skills, but there is still this whole skill tree below that we need to fill-in to unlock all of the applications. I think of these future features kind of like the skill tree in a videogame.
There are many features that are coming to WebAssembly which will fundamentally alter what you can do with WebAssembly. This means that the WebAssembly that you create today will continue working on browsers into the future.īut that doesn’t mean that WebAssembly is feature complete. The WebAssembly community group is really committed to backwards compatibility. I can understand where that misconception comes from. They think that the WebAssembly that landed in browsers back in 2017-which we called the minimum viable product (or MVP) of WebAssembly-is the final version of WebAssembly. People have a misconception about WebAssembly.
0 kommentar(er)
