WebAssembly Beyond the Browser • Dan Callahan • GOTO 2019

[Music] [Applause] thank you so my name is Dan Callahan you can find me on twitter as callahan I've tweeted a link to all the links that are relevant for this talk so if you want to learn more or see something you wanna learn more go to Twitter I work for Mozilla you might notice for Firefox we're also the nonprofit that began the rust project and we are one of the co-inventors of webassembly what I want to do today with this talk is start by demystifying webassembly because I think we're at a point in the industry where many web developers have heard of love assembly and can probably connect it to the ideas of performance or efficiency but I don't think we have a broad understanding of what web assembly really is what problem was it trying to solve how does it do it what does it look like under the hood and so what I want to do first and foremost is have you leave this room feeling like you're empowered to know when you should reach for web assembly and why the second thing I want to do is take that knowledge and apply it outside of the browser because what web was simply set out to do was to lift a fundamental limitation from the web and we happen to do so in a way that applies broadly to everything from how we develop and distribute software potentially to edge computing and IOT devices and and I want to convince you of the transformative potential of of assembly because I think it will influence everything about our craft in the coming years and my remote does not work very well I should have used the room's remote I will stand over here to understand what I mean by fundamental limitations in web assembly or on the web that web assembly is trying to address you just look at what our web technologies first and foremost in 1993 the first version of HTML was introduced and this was wonderful but within three years we had added two other languages we had add CSS and JavaScript because we found that there was something missing HTML alone could not express everything we wanted the web to express I didn't have all the capabilities we wanted to have to have and so by 1996 we had HTML CSS and JavaScript we had structure style and logic and these three technologies formed the basis of the open and standards-based world wide web for the following 22 years so in the first three years we went from from one to three and then for the following two decades we haven't added anything else to the base of the web and sure HTML and JavaScript and CSS have gotten better and they've evolved and they've they've added new capabilities but as far as fundamental open standards-based parts of the web we stopped there and did we stop because we we finally found everything we needed or did we stopped for some other reason or we were we not done yet when I think about programming languages I tend to think about them on a spectrum from high level to low level we're at the lowest level there's machine code the the actual instructions that the physical CPU inside of your computer understands and just slightly higher level than that or languages like C C++ rust languages that compile to machine code but that still give you the programmer a great degree of manual control you can control how things exist in memory when memory is allocated when it's freed and I think for me and this is all subjective high and low level don't have have static definitions but for me I think that control over memory is what makes the difference between a high level and a low level language because on the opposite end of the spectrum where languages like JavaScript and Python and Ruby and Lua and typescript which free you from having to worry about those low-level details but you also lose the ability to reach down to those levels should you need to until recently javascript only had a single numeric type floating-point number so if you needed to work with larger numbers you could not do that in JavaScript on the other hand you didn't have to worry about things like where does my memory for a list come from and then of course there are languages in the middle Java c-sharp go and Swift they give you a great degree of control but they still have mandatory garbage collection or reference counting baked in little into the language so you don't quite have the same degree of manual control that you would get from a language like C or rust and the great thing about programming is that we can reach into this toolbox of dozens of languages that are in use today and we can choose the best language for the task at hand and so if you're doing low-level work you can reach for Cu or rust if you're doing high-level work you can reach for Python or Ruby or JavaScript until you go to the web and when you go to the web you only have one choice and that choice is JavaScript and JavaScript is an excellent language but it's a high level language and that means that it has strong opinions about what sort of data types are allowed to use and how you're going to use them and so while on the on the backend on native platforms it's very common to mix and match these languages for instance the data science community is standardizing on Python and pythons a great high level language but all of their computation all their their analysis software happens to be written in or the majority of it written in C C++ Fortran these lower level languages that that can benefit from that degree of control and that are then wrapped in these nice Python modules so that they're high-level application logic can stay stay in Python well we can't do that on the web because our only choice is a single high level language nothing wrong with JavaScript but there is something wrong with only having one opinionated choice let's talk about SAS SAS is a CSS preprocessor it lets you write very terse very expressive style sheets SAS was originally implemented in Ruby which is another high-level language and one of the challenges with high level languages is because they have those opinions because they have these these broader expectations of what sort of runtime environment will exist in it's hard to combine high level languages it's hard to use a ruby library inside Python and so after a few years when SAS became popular enough there was an effort to rewrite it in C++ libsass and by writing in a low-level language it's possible to build bindings from libsass so you can use the same core logic in a dozen of other languages so in Crystal Go Java Java Script Lua net note Perl PHP Python Ruby Scala all of these have libraries that are based on the same C++ code no SAS for example gets over four million downloads a week on NPM very popular implementation one of the most popular rappers of libsass and it's trivially easy to use if you're an OU developer you go into your package.json you depend on notes ass and what you get is something that looks and feels like a JavaScript module but in the inside it's really a C++ library with a very thin layer of JavaScript on the outside one of the challenges with this mode of software development this mode of software distribution is that you have to compile that CSR that CP C++ differently for every machine code architecture that you want to target and so for 32 and 64-bit Intel you have to compile it differently for different versions of arm you have to compile that library differently and not only that you have to compile it differently depending on which operating system you're going to deploy to you and because node itself does not have a stable ABI you also have to compile that same matrix for every version of know do you want to support and so you get the benefit of only having a single C++ library so you have a single point of development but when it comes to distribution you suddenly have this combinatoric explosion of platforms node versions and CPU architectures that you have to support and indeed when you go to the node SAS release page on github and you scroll down you can see this table of supported environments operating system CPU architecture node version and when you scroll further you can see the binary assets that they publish with every node release a hundred and seventeen binary packages each individual file each individual compilation of note SAS is about two megabytes two and a half megabytes and yet we're publishing hundreds of megabytes of compiled data every release because the node SAS authors don't want you to have to compile it yourself they want to just work out of the box and so they have to to deal with that big 3d matrix of compatibility a notable thing that's missing is no ARM processors or support so if you're doing this on a Raspberry Pi you have to compile it yourself that's fine the big difficulty in the the problem I have with this this method of software distribution this is something we've done in every native platform community it's not you need to know it's that you need to know at SAS we can do all this compilation but none of this helps us go to the web and we can't go to the web because we don't know what machine architecture the was going to run on and the what needs to be forever and the web needs to be universal and so if you don't know what operating system we don't know what processor the web's going to be on how could we take these native libraries and bring them to the web and the web shows up in weird places a few years ago a product owner at LG decided that he wanted the the company to create a refrigerator that had windows on it so that you could get more utility a refrigerator and someone else read that spec sheet and maybe there was a capitalization error or maybe something happened and they put windows on a fridge literally Microsoft Windows not like glass windows that would be useful but like the gadget headline LG's 29 inch Windows 10 tablet comes stuck to a smart fridge but the wonderful thing about this is that this fridge has a browser and that means this fridge has access to the web and this fridge has access to the whole entire web there's not a fridge web there's not a fridge OS you're not having to build things for the fridge store you you just build things for the web and now they work on the fridge and you don't even have to know that exists you hopefully did not know that exists it's the same way that the mobile web doesn't exist at least not anymore the mobile app anymore it's just the web on mobile because we've created this set of standards with HTML with JavaScript and CSS where if you bring a browser engine to to a new platform then the whole web comes with it and the web is the killer app I don't know why but I don't think it's possible for any consumer electronic device to exist without the ability to render web content my car has a web browser the Apple watch can render websites who knows where it's gonna go but the problem is when you go to the web you only have this one high-level language and that imposes a kind of complexity floor where you're not allowed to reach deeper into the machine than JavaScript exposes and that means that all these other languages the target machine code languages light go and rust and si have a hard time going to the web so that's what web assembly is we can't have a real bike our machine coke so you don't know where the web is going to go but we can have a slightly abstracted machine code and then trust the runtime the browser or node or whatever else happens to be supporting web technologies to translate the web assembly into machine code and execute it the idea here is that you can take a single single file a single program compile it to webassembly you get away as a module and then you could distribute that one binary to a number of platforms so to Firefox on a laptop to Safari on and I have iPhone to know JSON our raspberry pi and then those runtimes themselves do whatever they need to do to make that code execute on whatever processor they have to be having to be running on great that means that you as a developer compile it once distribute it once and that whole matrix just goes away in favor of for instance hopefully in the future libsass Tizen and sure you can still put a thin JavaScript layer around it so that it maintains the same interface that that you would expect to have from the the previous version but you no longer have to compile it 117 times what's more the way that we've designed web assembly modules is we've designed them to be compatible with es6 modules with echo script modules so that in the future even that javascript wrapper can go away and you should be able to use this inside nodejs just like you would any other yes module so you could say import render from libs a style Azzam now that's something that you can make that syntax work today with enough command line flags and node the hope is that will be a common way to work with things in the future but right now you'll still have to write a little bit of JavaScript to get a happy path experience the goal here being if webassembly modules have a similar semantic model to echo script modules then you can depend on them and you can intermix them in your dependency tree and so you write JavaScript because it's a high-level Ling and it's a great language and your application code fits well in it but your dependencies might be you might be depending on code that's written in whether something you might be offending on code that's written in JavaScript and you don't have to care you don't have to be aware because they all work like modules and that's great because it means that as the things you depend on find uses for rob assembly and perhaps find efficiencies in web assembly they'll be able to to kind of swap out their JavaScript implementations your code gets better your application gets better and you don't have to change a thing because you can maintain that same API interface and this is real October 2017 was when edge shipped web assembly by default on by default and that was the moment where every major web browser was shipping web assembly on by default and so this has been real and this is existed for two years over two years which means we have the fourth thing and we've had it for two years we have content presentation high-level language low-level language and those two languages compliment each other because that's what what allows you not to run web assembly on the web you're not going to think about running web assembly on the web that's what gives you freedom to insert other tools of your choice so the web stack is HTML CSS JavaScript and anything else that compiles to webassembly and many many languages I daresay most languages have some experiment or some additionally mature way to compile from that language to up assembly and that's the goal the web shouldn't be monolingual and it's not anymore because we have web assembly and that gives us that platform that lets us bring the other languages along webassembly is a binary format you can pilot it's a bytecode bytecode means we have 256 operations to work with kind of map them out I'm gonna take you through them one by one they're they're color coded there there are a few types of operations you'll see when you look at web assembly bytecode not that you'll ever need to do that in practice but I want this talk to to at least give you a sense of what's going on under the hood that's that's what I find fun we've got a number of operations for control flow so things like loops calling other functions we don't have go to control flow and rub assembly to be structured so you can't have execution go jump to a random point in in your code we have functions for variables for parameters some functions for memories so webassembly can load and store data in memory it can request more memory it can't access arbitrary memory it only has access to memory that it has access to that it's being given access to so it's not gonna run rampant on your system and then everything else is numbers webassembly has four number types integers floating point numbers 32 64-bit and all the rest of the bytecode operations are constants of those numbers comparisons of those numbers conversions between them or operations on them you can read the spec it's it's generally actually kind of nice to scroll through and you can look at the slides later where you see okay here are all my my numeric operators for integers I can and/or X or I can add subtract multiply four floats I can ceiling floor truncate really basic stuff it can do math but math is useful it can't do a lot of other things right now just webassembly on its own can do math math is useful because if you take a language like c and you write a function that takes an integer foo or it takes an integer X and returns X divided by four when you compile that you get out this webassembly module that exports the function named foo it says foo is a function that takes a parameter VAR 0 of type 32 bit int and returns a 32-bit end and the body of the function is three operations it gets the variable you passed in it gets the constant value of four because well simply the stack machine so it kind of puts both of those on the stack and it calls div s sine division which pops those off divides them and puts the result back on the stack there's your return value again you won't have to worry about this this is just for interest in edification intellectual gratification you'll worry about writing code and C or in rust or whatever other language but what will happen is that that code will get compiled down to web assembly and then when the browser or node or whatever other runtime seems that web assembly it'll convert it into machine code one of the nice things about web assembly is it has static types it has those four number types and C also has static types we took in an int and we returned an nth JavaScript by being a dynamic language is a lot harder to optimize because you don't know up front you don't know just by reading the code what data types functions are going to deal with and so browsers have to sit there they have to watch your code execute they have to profile and they have to take guesses and say okay I think this is working with integers I haven't seen a floating-point number yet so I'll go ahead and and I'll generate some machine code all just in time compile this to be a fast function dealing with integers but then what if you pass a float so every time the JavaScript engine has to has to check itself and throw out those optimizations and reoptimize and it's this very dynamic and very complex process whereas if webassembly we know the types of front and if you're using a language that can compile to static types then you can can get a lot of efficiency just in that for example if I know I'm only going to pass positive numbers to this I can change that from taking int X to taking unsigned and X and then when I recompile instead of being a divided by four this turns into shift right by two because if you take an integer and you shift the bits over every time you do that you cut it in half and the other thing that happened is that we eliminate some of the machine code operations because that's a much easier operation for a CPU to perform and that's where a lot of the efficiency gains and webassembly come from they come from being able to take advantage of that lower-level information of having the data types of being able to pre-compile things well simply on its own is like a CPU on its own you can hook them some wires up to it you can do math but if you want to do anything more interesting you need some way to do i oh you need some way to to connect it to something else and so what assembly does have a concept of imports and exports and so you can build shims that from the outside environment exposed functions to web assembly so you can hook up console dot log to web assembly or the html5 canvas api s or any other function that exists in your computing environment you can expose to web assembly and you are responsible for exposing it well assuming we can't go out and on its own get these capabilities and it can't do anything it can't break out of the browser sandbox because it's running the same sandbox that Java scripts running into you and so you don't need to worry about this reading random memory or doing anything beyond what you worry about with JavaScript and and by and large we trust browsers because they're doing the machine code generation from JavaScript to native code we trust them to do that safely in the same way that we trust them to convert web assembly and execute that safely but if you have the ability even if it's not particularly economic and it's not yet that we're working on it if you have the ability to expose browser api's to a web assembly module and the module can take those in and can use them then that's enough to write a compiler to take kind of arbitrary code from C or C++ and this is where where a lot of these projects start is we started with a compiler called M scripting that can take C and C++ and it can compile to web assembly and it can shim things like if you use STL to access opengl to do 3d graphics it can port that to WebGL and so suddenly you can take things like the unity and we thought games were great a great test case because there were one of the few holdouts of plugins on the web these these kind of non-standard third-party native code modules that we were loading into browsers and that expanded our surface attack surface and we're all sorts of problems but they gave you that performance they gave you the ability to bring other code in well assembly tries to find a way to do that safely with very close to native performance and leveraging the web api is it's not apart from the levites part of the web and so you can also see epic porting their Unreal Engine web assembly so both of these these game development engines Unreal and unity can export to the web and they can do that via web assembly and this all runs live in the browser street but again if you have a compiler you can compile arbitrary things so the AutoCAD team compiled AutoCAD web system will you took a 35 year old codebase a codebase older than the web itself and that's now just a link away and you can run AutoCAD in your browser or you can take something like imagine the dosbox emulator so DOSBox lets you run a little dawson early women programs see chrome windows 3 in the browser and if you have Windows 3 you can also run netscape 3 and this is a version netscape from 1996 so CSS had been proposed but had not yet been introduced into netscape this version does support javascript though and what's interesting is is how similar this looks to a modern browser it's at least recognizable as a browser and this is what 23 years old but it's all running in firefox because we could compile DOSBox to web assembly then we can run all this other code unmodified and that's kind of neat it's not particularly practical but it's possible and the Internet Archive is actually using this two port emulators to the web to preserve our software heritage so you can go you can play old games and use old applications right in your browser without having to download anything without me worrying about your willis emulator still work when you upgrade to a new process or architecture or whatever else it's no it's all part of the web now but by being part of the web but what this is doing is DOSBox is drawing pixels into to the web assembly memory and then javascript on the browser site is reading that out and drawing pixels to an html5 canvas and if you have a canvas you can mix that up with other web api's and so you can map that onto a WebGL texture and so that you can simulate coding in a basement in the 90's and this is a demo by James Pike Ohio who published it in April 2017 I just credit where credit's due brilliant brilliant idea oh this is magic its spectacle it's wonders I'm like look we put games in your browser we put windows in your back in your window it it's fun but it's not particularly practical and so our job over the next few years is to kill magic and turn into something useful because the the demos that we've seen over the last two years with the introduction web simply are not the things not the problems that I'm dealing with in a day to day job as a web developer so when do I reach for what assembly when should I be reaching for over simply when do I do I harness these capabilities in my my actual job well two things one we've seen that you can use both assembly to reuse existing code on the web and that's pretty cool second and and I think much more important you can now use better languages on the web and I say that not to slight JavaScript JavaScript is an exceptional language but no one tool can be the best tool for every job and so by by having webassembly we can now bring other tools that may allow me to express myself more concisely or more efficiently they may be able to to solve a certain problem more performant ly then I could have when I was previously limited just to a single language choice a more practical example for using code for both of these reasons is squish a p-- spelled squish app and this is by the chrome dev tools team and what they wanted used they wanted to put an image optimizer in the browser so you could upload a big image and then client-side experiment with you know what does this look like as a quality to JPEG or what if I rien coded as web P re encoded it as PNG and they were able to take these existing image libraries up to PNG Lib Moz JPEG Lib web P compile those code bases C and C++ code bases compile them to web assembly and then you can run those image encoders directly in your browser and you don't have to re-implement them in JavaScript you can reuse libraries that are the standard and desktop in native environments you can now use them on the web and you don't have to remit the wheel and I think that's really important I'm really powerful but they also had a really interesting use case where they wanted to allow you to rotate images if you're dealing with a large enough image the ability to work at a lower level could be really helpful because you're you're swapping pixel data when you're doing the rotation and if you could do that if you could control how all that data is represented in memory and control how that gets swapped you could avoid creating garbage collection loops you could you could probably do it more efficiently or at least that was the the theory and so what the the chrome dev tools team did was they implemented that rotation function in JavaScript and they found that a couple browsers could do it in under half a second for a large image one browser took over eight seconds this is a logarithmic scale and that variation really strikes at the heart of JavaScript being a complex language it's really really hard you have to be really really clever to get good performance out of JavaScript when you're doing something that's compute-intensive because it doesn't give you a lot of information upfront and so he did that and then he also turned around they implemented the same function in web in three languages that compile the web assembly see assembly script and rust and what they found was not that the webisode we was always faster wasn't always faster but the variation was much less between browsers because well this simile gives you so much more information upfront it puts everyone at a more even playing field you don't have to be as clever to to get good performance out of web assembly and you're not having to rely on tricks and hacks that might make one browser faster but might confuse another browsers Jay SVM and so their takeaway from this was was not that web simply is faster always but that web assembly is much more predictable in terms of the performance it gives you and that means that if you have a set of modules or you have a software project that has one code path that's spending a lot of time on your CPU and it's slowing everything else down it's possible to take just that one hot code path and replace it with rust to replace it with Swift or go or well these other languages that compile web assembly and then hopefully both free rein in your performance and also ensure that performance is more consistent across browsers you're seeing this sort of sort of approach and a number of of web-based tools I believe Sigma does quite a lot with web assembly there's a really interesting talk two months ago at Rus comp called from electron to atom to rust and back to electron by arena sestok and she works on a project called MongoDB compass and what that is is a it's an electron slash browser app that lets you analyze MongoDB databases and kind of see what sort of data is stored in a collection and because it's electron because it's browser-based it was already in JavaScript but when analyzing very large collections they were running into into bottlenecks where it was taking up to three minutes to analyze ten thousand documents so she rewrote the analysis functions in rust compiled that web assembly and got a 40 X speed-up so what was prohibitively expensive waiting two minutes for summary could now happen in three seconds and that somewhat mirrors our experience in Firefox where a few years ago we we make the Firefox dev tools using web technology like HTML CSS and JavaScript we're using react when you open the dev tools and Firefox it's all just web tech and so we had a source map parser that was written in JavaScript hand-tuned highly optimized javascript and we wanted to try porting that to rust and porting that to webassembly and seeing what happened and what happened was we started with just a naive implementation do it as simple and straightforward as possible make sure it works and we got a 6x speed-up and then we tried to make it faster and tried to optimize it and we got an 11 X speed-up just out of gate and Nick Nick Fitzgerald the author of this post read another post called speed without wizardry which notes that we actually we went from more complex to less complex code when we went from JavaScript or us because parsing and data analysis are two of those sweet spots where you're really doing things that are memory or CPU intensive that web simply shines at and by writing simpler code we also got better performance I thought that was pretty cool or as arena put it rust lets you write performant and clean code right off the bat so plug for rust rust is a is a great language in its own right highly recommended if you're interested web assembly start their interest and just learning another language start their great community attached to an amazing language really really cool but of course every other language is welcome to play on the web tube because weld assembly if you have a compiler you can go to the web so that's what web assembly is do does that make sense do you feel like you kind of have a better understanding of like this is what we're trying to do this is how we did it what the heck does that have to do with things outside of the browser well if you go back ten years Ryan Dahl looked at HTML CSS and JavaScript and said you know JavaScript cool on the web it's cool in the browser I wonder if it's any useful on its own and as we all know nodejs was complete failure and we we've learned from its mistake ever since node used v8 so you have the most most common programming language or the most common runtime for the most common programming language in the world which now supports more programming languages because v8 supports what assembly and that's pretty wild because it means you're someone like CloudFlare and you're an edge compute network where you you have a bunch of servers around the world and people update their code and you run it for them close to other users well normally when you isolate those things you would isolate them by running them in their own virtual machine and that has an enormous amount of overhead whereas on the web we're really used to running untrusted code side by side and keeping things separated and so v8 has an isolate model where you can you can pack more code kind of all in one process so you start up a single JavaScript VM and you would everybody's code into it and everything's still separated and safe and so that's what CloudFlare does the CloudFlare worker platform supports JavaScript and it supports web assembly which means it also supports every language that compiles to web simply and that's pretty wild but then that raises the obvious question of well 10 years after node well this simply is great in the browser web assembly is great with javascript is web assembly any good on its own and we mozilla think so so we built was sometime at sometimes a standalone web simply runtime it's small it's configurable it's embeddable and we weren't the only ones fastly also built a runtime called lucid which allows them to operate their own edge compute network where you can compile to web assembly and and one of the benefits of doing this is that by going to of assembly and by losing javascript downside you don't have javascript up side you don't have to start a whole J SVM and so in fast Lee's case they're able to start up a web stably process instantiated websley module in about 50 microseconds compared to 5 milliseconds for v8 and it has a few kilobytes of memory overhead versus tens of megabytes of memory overhead and so your what a hundred times faster 10,000 times smaller downside you don't have JavaScript upside you can go so many places that JavaScript just wouldn't fit IOT devices edge computing kind of interesting and apparently the two of us aren't alone last week Mozilla announced the founding of the bytecode Alliance alongside fastly until on Red Hat all of whom were working on web assembly executable runtimes outside of the browser and we're trying to define the future of web assembly beyond the browser web assembly itself is is standardized at the w3c but this is more of an industry group that's formalizing existing cooperation where you're trying to figure out all right well we're facing one of the same problems that Ryan doll face when we created nude which is that once you remove the browser how do you data into and out of JavaScript and so we had to define the node standard library and so we're running the same thing a flow of assembly well if we don't have JavaScript we don't have the node standard library how do we get I Oh in web assembly and so just like web simply gave us a slightly abstract CPU we have something called huazi the web assembly system interface which is a proposal for a slightly abstract platform library in the same way that like POSIX or the way API describes things like file system access and network paths and how i/o works wisey concerns itself those same sorts of things how do you get data in and out of whether simply how do you give it access to the network then I say Y Z is it's just a library weather symbol a modules can import functions and they can export functions and so they can import functions from Y Z and the way I like to explain this is I like to think about potatoes this is also the first time I've tried to explain it this way so you'll have to let me know if it works but but you can look at this and you can tell those are all potatoes they're different potatoes and maybe they're different because like programs even though programs are all made up of compiled binary sometimes they're compiled for different architectures and so you can imagine that each potatoes is a different CPU architecture I don't know the the point where this analogy runs into trouble is what's a web assembly module what's what's what's an abstract potato what's an abstract program and I think it's this kind of naked mr. Potato Head and and the idea of the naked mr. Potato Head is that it has well-defined points for imports and for exports and so you can you can look at this toy and you can see if this were a web assembly module it's not a real potato it's not going to go and when you're not looking grow eyes somewhere and do something unexpected it's it's inert and so if somebody handed you this mod this webisode module and said I want you to translate and run this we could say okay well that's only gonna be able to do math because it doesn't have anything hooked up to it and they hand you this one you could say okay maybe it can read and write files because it has eyes and hands if they hand you this one you might be a little more concerned because I does a whole bunch of other capabilities the one in the middle you're not worried about it you know green write files we're not worried about walking off of the files cuz it doesn't have any feet and so this is this is one of the ideas behind the the static modules the ability that webassembly has to declare here are the things that I'm importing here are the things I need you to attach to me and here are the things that I'm going to give you back and you can know that without having to execute any code and what happens is the runtime will take take that web assembly module as kind of a template it's kind of a guide and it'll say okay I need to build a real program that can read and write files and so it translate that into a real potato and it doesn't look exactly the same has to use whatever machine code whatever potato starch is available in its local environment but what you get out is is a program that has the same capabilities to be more concrete this is hello world and y'see again you're not gonna write this you're gonna write things that compile to this but the important part is up here at the top where you declare a module and you say you import from huazi unstable FD right and if T right is a function that has the function signature input for integers output one integer the names of these functions there are arguments what those arguments mean for instance when you call this view give it the first integer as one that means you're willing to write two standard out but that's what web assembly system interface Y Z defines it's the the syntax and the vocabulary around dealing with i/o it's just a standard library but the ability to import functions from the outside world is something that's common to all webassembly modules any module can can ask for any sort of functionality the idea being that if you're doing something like this this is hello world and rust and you go to compile it you can use a tool called cargo huazi you say alright cargo as you build it'll go and compile your web assembly module and then you can run that output binary file with lazon time so say Y sometime gives it the path to the dot wiesen file and you get hello world and if we go and disassemble that binary and we search it for the string FD right you can see that on line 26 we imported FD right from lies neon stable so you can look at that module and you can know exactly what capabilities it's pulling in from the outside world and when you run it because the the runtime environment is responsible for fulfilling those imports while some time will say okay if u FD right to file descriptor 1 I'm going to print that to the terminal so I'm operating in a terminal environment but if you take you to the browser you don't have a terminal I mean you have a console but it's not quite the same and so it's up to whatever page you're loading in the browser to choose how to implement that function and so for example on this page you can take that same exact binary that you just ran in well some time on your on your native platform and you can upload it into a browser and that browser supplies a definition of F T right that prints into a text area it's a that one layer of abstraction just like whether somebody gives you a layer of abstraction over machine code was he gives you a layer of abstraction over these system calls and it's up to the environment to kind of supply functionality that makes sense you don't have to use these tools the hope is it wisely is just what comes in the box well as some time loose it the the bike hood Alliance runtimes support y'see we're working on up streaming lousy support into node the idea is that if you say like I need file IO and you use Y Z's vocabulary for it it should just work on these other runtimes if you want to attach something else you have to supply the implementation for the runtime but ok let's say let's say you have a module and the first thing is that you know what capabilities it has let's say it needs file IO access it needs to be able to read and write things how do you make that safe because a big part of assembly a big part of not having execute memory not having go to you is that we want these modules to be safe to run untrusted code in and that is where it gets lightweight sandboxing where we take those modules and any access to the outside world is mediated by the runtime a good example this is file i/o so say I had that hello world and one of its dependencies got updated and I recompiled it if I built this as a native binary so I just cargo build cargos the the rest build tool carga build what I get out is a native binary for Mac OS and when I run that I get hello world looks like everything worked I updated my dependency I recompiled off to the races if I do the same thing in huazi cargo as II build compile it get as and file out this time when I try to run it it errors and the error it throws is that error failed to find a pre open file descriptor through which user Dan SSH ID RSA could be open so for some reason my hello world was trying to read my SH key huh hello crap I ran the native binary because we run native binaries they execute with the same permissions as the user and we don't have that degree of mediation who knows what that native binary just did with that file it shouldn't have needed to access that but because I was running it just as my user it was able to whereas the wazoo module as far as he is we don't have an instruction that allows for arbitrary file access any file that the module opens has to be kind of pre authorized by the runtime and so I can start Wisin if I can say ok it's ok for you to access - Dirar and pass it the path - to the files that needs to access and then prints hello world and god knows what it did with my key and this this is a simplified example but but this sort of attack put about 15 million dollars at risk in a cryptocurrency wallet there was an electron app that had a node dependency that just handled showing notifications on your system and the maintainer of that module decided to retire from maintaining it passed it off to a community contributor someone else said like I'll take over I'll keep that up to date that person released a few completely benign updates to the module kept it working and then they released an update that in addition to doing what it was supposed to do also try to exfiltrate the private keys from this cryptocurrency wallet and so somewhere deeply nested in this in this tree of dependencies when you npm installed it it would go and try to read all these private files it has no business reading and so if we adopted webassembly modules for these extensions or for these sorts of use cases were british tribune code where we're using third-party modules if we had that type of lightweight sandboxing $15,000,000 would not be at risk right now and that seems kind of useful so Leah Mazar is safe portable runtimes right we can you can run untrusted code we can run on Trista code in a way that can be safe and is easy to make safe and is safe by default and that's coming off of experience that the webassembly community group has as browser vendors we've had a lot of experience running untrusted code and we we want to have a runtime that that implements the principle of least Authority that doesn't give doesn't automatically grant all the keys to your computers any program that you run we also gain a universal binary format so this gives us something that that other programming languages and other programs can compile to you and targetnode they can target the web they can run outside of that they can run on their own and that's really interesting because if we if we make these runtimes small enough and portable enough you can imagine you know we seen we've seen web symbol in the browser we've seen web with somebody outside the browser you can also imagine whether somebody inside other languages so as an experiment a few months ago we ported one time that the Mozilla whoops in the ground time we ported it to a Python module and so yeah we have to do a whole matrix of compilations but we do that once and now when you import math sometime as a Python module you can then import wasm modules into Python as if they were Python modules so what we do is we took pull down see mark which is a rust library for a markdown compile that to web assembly and now when you say import markdown this is actually going importing a markdown that hasn't file into Python completely seamlessly and we've called markdown dot render you get HTML X that's what markdown does and now that's interesting because that same exact byte for byte identical markdown that lazon file can also be used a node or in the browser and we can take this one module this one code base compile it once and share it everywhere and so not only just love to simply bring all the other programming languages to the web for the browser it also solves some security and some efficiency problems with untrusted code outside the browser and it also gives us potentially a universal library format and you use universal executable format and I think that's pretty exciting and I think that's something that whether or not web assembly itself succeeds in whether or not was he becomes the standard library we build on or these runtimes become the ones we use I think the the idea is here in the implementation here I think we'll shape the way that we build develop distribute and use software pervasively in the future and it's real like you can do all of this right now I pre record the demos because I don't want to tempt fate but all of this works on my laptop right now and I can show it to you after the talk and I think that's pretty cool so if you want to learn more I said my name is Dan Callahan on Twitter is Cal ahead I tweeted a link to github just that just has a bunch of links to other things you can go and find some articles I really recommend if for nothing else it's just fascinating the Nick Fitzgerald article on speed without wizardry it's under the the thing where we oxidize source maps oxidizing being like the rust lingo for converting code to rust in Firefox cuz it talks about how we got that 11 X improvement by rewriting and rust and some of the the crazy things that you can do to get similar performance in JavaScript if you're willing to tune for a specific engine lots of resources really cool I've got five minutes I can answer a few questions thank you so much I hope this is if not useful at least interesting thank you

Channel: GOTO Conferences

Views: 21,169

Rating: 4.8146343 out of 5

Keywords: GOTO, GOTOcon, GOTO Conference, GOTO (Software Conference), Videos for Developers, Computer Science, Programming, GOTOcph, GOTO Copenhagen, Dan Callahan, Mozilla, WebAssembly, JavaScript, JS, Front-end, UX, User Experience

Id: TGo3vJVTlyQ

Length: 45min 15sec (2715 seconds)

Published: Fri Jan 10 2020

Reddit Comments

[u/mto96]

This is a talk from GOTO Copenhagen from Dan Callahan, WebAssembly contributor at Mozilla. The full talk abstract can be found below:

WebAssembly began as an experiment in bringing other languages to the browser, marking a radical shift in the fundamental programming model of the Web. It's not done.

Today, WebAssembly is poised to reshape everything from Node.js modules to containers, and even edge computing. But how is technology from the client side relevant to those domains?

Packed with live demos and real-world examples, this session draws from WebAssembly's past to predict its future. Come find out where we'll be in 2020, and beyond!