 so much for coming to RustConf and to this talk today. I'd like to start by thanking the organizers for inviting me. This is actually my second Rust conference period. I was at RustFest at the beginning of the summer. And I'm really enjoying the community. So this is a talk about the web. Oh, this is me. I have a name. I do. So what makes the web work? What makes it something that is so useful to so many people? Well, there's a number of aspects. One of them is that if you have the internet, anyone can get on it. So there's sort of an equality of access. We have cool stuff like universal resource locators that mean anything has a defined address. And finally, there's something really cool, which is hypertext. Now, hypertext kind of, to me, reminds me of the long efforts that people have made to cite other texts in their works. And traditionally, the way that you would do this is with a quotation. Most works of famous literature, especially when there were not many works of famous literature, were so well known that you could just use the same words and have that be a sort of accepted method of referring to another work and calling in all of its echoes into your own. Later, as there got to be much more literature in the world and we needed a more rational method of organizing it, we developed the citation. But hypertext was something a little bit different. What did hypertext give us that's different from earlier technologies? Instant gratification. So rather than having to look up a citation, perhaps a very lengthy period, you could go from document to document as fast as your internet speed would allow. So who is it that we have to thank for this miracle? It is our favorite gentleman, Tim Berners-Lee. I would like to thank him for so much, most of all the internet and the web that we all know and love, but also for just being a very unproblematic man for about 30 years. He's like an Anglican vicar. He's involved in charity. He's been married to the same woman for like 22 years. Seriously, we stand an unproblematic king. So this slightly minimized screenshot, perhaps you may recognize it. This is famously the first page of the web. And those beautiful little blue links are the only form of interactivity on this document. They are the only thing that you can do with this document, which is great and all, but... So HTML came out in 1993. And almost immediately, the quest began to make the web interactive. Basically, this instant gratification of having all the content linked from one document to another made people start wishing they could do more things with these documents. Made people want to expand the capabilities of what they were looking at. And of course, the people who wrote HTML are not necessarily the ones who began this job of trying to make web pages interactive. Tim Berners-Lee was a physicist working for CERN. The document model was something that probably was enough for him for a while, but not for a lot of internet users. So this also quite small screenshot is of a Java applet. So Java applets. Oh man, they came out so early. They were released with the first version of Java, because Java, even though we think of it as systems and backend programming language, always was trying to bridge this gap between the server and the client. So one of the cool things about Java applets was that they were delivered as Java bytecode, so they were quite small in terms of download size, while of course that does depend on whether you actually had Java already installed to your machine. You might have a very hefty download in between you and whatever piece of content you were looking at. So that's one of the slightly less user-friendly aspects of Java applets, but there were some aspects that were really, really nice. Java code obviously could run on any machine that ran Java, and what was the brag about like one billion devices running Java in 2000 something? Well even back then, there were a lot of devices running Java, it was a solid option for that cross-platform interoperability that we're always chasing as developers. You know, you wanna write it once and have it work everywhere. It also was very fast, just like until JavaScript started getting optimized for performance in a variety of ways at the beginning of this decade, it was just a faster option to run interactive programs in the browser. But it was not the only option available for long. This is like what I found when I Googled JavaScript in 1996. It's just a little script tag there. So JavaScript of course has an origin story that is famous or perhaps notorious to us all. So Java was instantly becoming very popular almost from the moment of its release because it was filling a need that many developers had both to have relatively accessible server-side programming and to again bridge that gap between server and client. This concept was gathering so much steam that Netscape, which was trying to release its mosaic killer, Mozilla, a browser at the time. And somebody's gonna get my, I'm gonna get my faxer on somewhere in here and somebody is gonna have direct personal experience in this audience, I know it. But there was so much urgency that Brandon Ike famously wrote this prototype in 10 days. So we wound up getting JavaScript released by the end of 1995. So basically shortly after the release of Java. It was not called JavaScript at first. I think that was like a slightly later version that they, you know, of course, they called it JavaScript to kind of hang onto those coattails of Java. To this day, confusing people who are very smart, like my mother, you know, she's really smart, but she just can't remember that one. One of the other interesting things about JavaScript is that unlike Java, which was sort of a general use programming language with sort of an API for putting up like applications, JavaScript was designed from the ground up with the, with HTML in mind. JavaScript was designed to manipulate HTML. And that I think is an important aspect to its later success. Another important aspect to its later success was how much people started trying to copy it. Like this was an era of like all proprietary code. Nobody was sharing their code. Well, maybe not nobody, but none of these people were sharing their code. So for Microsoft to actually get their own JavaScript version up, they basically just looked at what was running in Netscape browsers and copied it and reimplemented it with their own engineers. Which is like very 1996, but also kind of a crappy way to work. But then we have, oh God, most blessed. There's one other very popular option for interactivity on the web, and it is Flash. This is an old Flash website. So Flash came out almost right after JavaScript. They are like on each other's heels because clearly this is the movement. This is what people want out of this brand new technology called the web. So one of the cool things that I found out when I was researching this talk is that Flash was actually developed by a, it was called Future Splash, which I guess became Flash. And it was developed by a company called Future Wave that was clearly chasing every trend in the computing space because they had started out making like pen vector drawing computers. Because pen computers were the hot shit of 1993. But they were not the hot shit of like 1994 or 1995. So basically this company took this like animation studio that they had developed and they took the viewer for it, which in a very fortunate development for them was very lightweight and could easily be bundled up and delivered as an extension to web browsers. So this and the fact that Flash had an amazingly accessible toolkit because again it hadn't been originally developed for like technical users, coders. As opposed to the earlier technologies that we're talking about, which while they were relatively user friendly scripting languages, still had that barrier of assuming that somebody knew how to code before they started using them. So Flash really became a colossal success until of course Steve Jobs killed it with the iPhone because the iPhone won. And Flash, not supported on the iPhone could not succeed. This is despite some very legitimate attempts that Flash made to converge back into the JavaScript standard with something like action script. Which was an implementation of I think an early ECMAScript spec. But they never brought them back together and Flash unfortunately died or did it? This is a screenshot I took like yesterday from a paper doll game that was released about three weeks ago. Flash still has an incredibly active and passionate user base and community. It just doesn't include any of the people who probably are first on your mind when you think of internet users. But there are still like children and artists and people who have just developed a lot of skills in this area who are unwilling to let go of this proprietary format. And to me the fact that like Flash has this community, Java applets don't. Even though they both represent sort of proprietary formats really speaks to me how much success Java Flash's accessible tools gave it. And I think there's a lesson there for all of us about keeping our tools as accessible as we can within reason. That I think is the way that most projects find success. So all of this together was the birth of the web platform because these competing visions of what interactivity on the web was going to look like ignited of what we call the browser wars. And this was basically a like triangular conflict between browser vendors, browser users and application developers. The browser vendors wanted to offer features that would be so attractive to the users that they would choose their browser and not somebody else's. But application developers wanted their programs to run on every browser with the same behavior. This conflict eventually led to the creation of ECMAScript which is not in itself a language so much as it is a specification for a language. And basically ECMAScript was developed by looking at all the disparate JavaScript implementations that existed at the time and trying to find the commonalities in them so that they could be defined so that anyone could use them. So that in the future, if somebody were coming up with a new browser, they wouldn't have to just like kind of feel out how JavaScript is supposed to work. They could actually know how it's supposed to work, define standards that if they meet, they know that they're offering a good experience both to developers and to users. So that said though, this birth was much less like this and much more like this. Saturn eating his own children. It was a brutal conflict, red in tooth and nail and as we all know, there were casualties like Netscape but there were also huge wins for the community. This open source governance model was so successful with JavaScript that for that reason and for other reasons, it began to be the accepted way of developing software that you wanted a wide variety of people to use. This was an era of increasing standardization both with like IETF standards for like web and internet technologies and for standardization of stuff like the W3C was actually predates the browser wars slightly because it existed to standardize HTML even before anyone was thinking of trying to standardize JavaScript. So JavaScript has won, right? Nobody out here is writing Java applets seriously to my knowledge and Flash, while we've established that people are still using it quite actively, it is obviously deprecated by all the major browser vendors and has no support on the mobile devices that we consider to be so important in this day and age. But God, JavaScript. Man, I've been writing JavaScript for like five and a half years now. People pay me to do it and everything and it's fun a lot of the time. It's fun because of how close JavaScript is to me. Anytime I want to, I can just open up a terminal and there's my repl. Wow, that's pretty neat, that's pretty easy but there are other aspects of the JavaScript experience that are not so good. Performance, of course, is one of them. JavaScript is a scripting language, it has to run inside like a small subset of your computer's resources. And while browser vendors are always trying to optimize for the way that people write JavaScript, this does create a sort of situation where there's a bit of tail chasing. JavaScript vendors optimize common patterns and then kind of institutionalize what might or might not be good programming behavior. So many people don't want to write JavaScript but on the other hand, the web seems to have won. More and more applications that in a previous era would have been native applications, perhaps on your desktop computer, are now web applications. So what's a person to do if they want to write performance code that runs like native, perhaps with all of the features that JavaScript notably lacks, like any kind of internal coherence? Well, people started feeling out this problem almost immediately. JavaScript, of course, has not been popular among large swaths of the community. So one of the original solutions that people came up with was azim.js. Azim.js basically took advantage of a number of performance hacks of JavaScript. Stuff like adding bitwise operators to all of the integers you were using in JavaScript code, which was a hack that would make them be treated like more like native data structures than like JavaScript data structures. So what azim.js basically was though was kind of a hack for people who didn't want to write JavaScript to not write JavaScript. They would write C or C++ or maybe even Rust, actually, because those timelines do sort of overlap and just run a compilation step on it that would turn it into JavaScript that boasted native performance owing to how it was optimized. But that was not the only proposal for getting native level of performance in a seamless way in web browsers. There was also the Google native client, which was abbreviated as NACL, like Salt. So there were a lot of pretty bad pepper jokes, like Salt and Pepper, for their project names. Bless all Google employees. So this actually is like quite an old project. 2011, I don't know, I feel like that was forever ago. Like I was young then. And this was a Chrome only solution, not shockingly, because it was a, it wasn't a proprietary Google product exactly, but to quote somebody from Mozilla in like 2012, it was an open, it lacked an open specification beyond its Chrome implementation. So there was basically no way that people were going to really adopt Google native client unless Chrome became the only browser that people used. And that is not what happened. We actually exist in a relatively stable and pleasant situation of a variety of browsers competing quite fiercely against each other, but fortunately for users in a much safer and more satisfying way than in the late 90s. And part of that I think is because we have technologies like this next one, WebAssembly. So WebAssembly actually comes directly from the same open governance structures that were established to govern JavaScript at the end of the browser wars. So it is again defined as a specification, as a standard. And basically it defines two formats. One of which is like just binary. I can't read it or make sense of it. You probably can't either no matter how good your brain is. And then the other one is a more comprehensible and maybe kind of human readable and editable assembly like format. Which you can hand edit if you would so choose, but that's probably not what you want to do. You probably want to write code in something like C, C++, Ruby. No, not Ruby. Why did I just say that? I meant Rost. And it was initially, the initial features were based on the asm.js feature set. So again this kind of model of looking at what exists out there, implementing all of its features and then trying to supersede it, which we see again and again in computing. That's how we work. We want to make something better and then we want to make it much better. We want to extend what it does beyond what was already possible. So WebAssembly is so brand spanking new. It was announced in 2015. We had a first like Unity demo in 2016 and the initial release was already in 2017. So that was like last year. And now here we are in the middle of this year. It is actually just blowing up in terms of like interest. I was at Rust Fest at the beginning of the summer and somebody did a talk on you. I think it's still not quite production ready, but the mere notion that you can have now a web framework where you write both server side and client side code in the same language and then have it compiled into JavaScript. Wow, that is so neat. I have been a web developer for so long. One of the things that we are always chasing is isomorphism, this notion that we could have code that will run the same both on the browser and on the server. And why would you want this? Well, every time I write something like a form validation, that's logic that I have to duplicate both in my JavaScript and in my Python, Ruby, Rust, Java, go. Well, that frankly sucks. First of all, the person writing the Python, Ruby, Rust go might very well not be the same person who writes that JavaScript. And they will certainly probably not be the same people maintaining it. It is just as we, if you saw Asus and Chelsea's talk earlier about trying to maintain parity between Rust and C implementations of a complex bit of logic, no matter how many smart engineers you have, it probably just can't be done. So having code that is truly the same, that runs the same with the same assumptions is something that I have been interested in for a long time. And I sort of, I taste it coming with WebAssembly. It's so close. And there's some tools I want to call out, especially in the Rust community. One of them is Wasm-Bindgen, which is what we use to sort of pass functions and data structures over that Rust WebAssembly border. And then we have Wasm-Pack, which is an incredibly cool tool that lets you package up Rust as NPM modules. So you can have your Rust code running in a browser extremely easily with a minimum of setup from you. So now this brings us to me, actually. That's not me. That's Ashley. But I'm here because of Ashley. Because Ashley tweeted at the beginning of the summer about a program called RustReach, which was basically intended to give people who were not currently involved in Rust some mentorship, a project to work on, and try to get them more involved in the Rust community. One, as we've reviewed the success of a language is defined by how many people are interested in using it and how many people find it easy to use. So one of the great things that's built into Rust is trying to both treasure the human element and take out the importance of any one individual contributor so that projects are more sustainable for a long time. Like in Python, just this last year we had a big maintainer step down because of the exhaustion that is involved in working on these projects so long and so hard with so little reward. So the broader base of people that we get into this Rust and WebAssembly community, the more likely that this standard is going to be successful because it hasn't won yet. So this also so tiny screenshot is just a couple of my friends from RustReach having our weekly call where we talk about our projects and what we were working on. One of those people is in the audience, Crystal. Hey girl. And I just wanna say that this experience was incredibly important to me because like I said, I've been a web developer for like almost six years now. I never thought that systems level programming was something that I could do. Not because I didn't think I had the brains for it or something, but just because I was out of college. Where was I gonna get that kind of training? Was I gonna go back to school just to learn assembly? No. But Rust was kind of here when I needed it. And Rust was welcoming to me when I needed it to be welcoming. And there is so much that I've learned just about how computers really work from this last summer's experience of working with Rust. It's like a whole new computer science education for somebody who really missed that experience in college. So I also wanna talk again a little bit about those tools that we have in Rust and WebAssembly. And I want to shout out to Nick Fitzgerald, Fitzgen, who is really a leader in the Rust wasm working group. And has also been very personally welcoming to me and to my contributions on these projects. Basically all I've been doing so far is a little bit of documentation here and there. But despite that, nobody expected me to come in with some great ground-breaking PR. And I wouldn't be accepted unless I refactored the whole language on my first day. Which definitely was always my fear with OSS. But it wasn't the case, at least in this community. People encouraged me to ramp up slowly and gave me the space I needed to get comfortable with what I was looking at. So that also means that I started working on something we call the Game of Life tutorial in Rust wasm. Now the Game of Life, Conway's Game of Life, if you're familiar with it, is a fun sort of computational game with simple rules. As you can see, we have a grid with cells. The rule is that any cell with two or three neighbors, any live cell with two or three neighbors survives. If it has a different number of live neighbors, it dies. And a dead cell with exactly three neighbors will become alive. So this is something that you can run at every step. And depending on the size of the grid, it can become quite computationally intensive, which makes it a very fun test case for wasm. Now it is such an interesting test case that, can anyone read this, is it too small? Yeah, so I had a different computer up until like two years ago. This is a little 2011 MacBook Air that's doing its utmost with its four gigs of RAM. I cannot actually compile the upper levels of the Game of Life on my computer, which is a really fun, cool problem that has prevented me from doing a live demo that I wanted to do at this talk. But I think you guys will forgive me, right? Thank you, thank you, I really appreciate it. So that kind of brings me to another project I worked on, which was just to automatically generate readme's for the exported TypeScript files that are generated when you run some rust code through wasm pack. And I'm still working on that. I learned a lot about NOM and parsing in Rust, and it's a real joy, but multiple functions in one file aren't working right now. It's okay, it's okay, we'll keep working on it. And for that I actually want to really thank my friend Michael Giotzi, who worked with me on that project, and he was my mentor throughout Rust Reach. Because again, he really did the work of letting me know that I could do this, and helping me with it in a very empowering way. So this might be familiar to you. It was linked from the very bottom of that screenshot I showed you earlier. This is the original How Can I Help page of the web. Because Tim Berners-Lee baked that in to that first web page. This call for contributions, this call for help, this call for making things better than they are right now. And that's the exact same thing we need right now with Rust and WebAssembly. We're getting more and more users, we're getting more and more interest, but we need still more people so we can solve things. Like this problem I have where I can't compile on a machine with four gigabytes. Like that's solvable. Maybe I can't solve it, but I think maybe one of you can. And that is the thing that keeps me so endlessly excited about technology, the internet, and the web. There is always someone out there who wants to solve your problem. Maybe they can solve it better than you ever could have thought of doing it. But you don't know until you reach them. You don't know until you convince them that helping out is in their interests as well as yours. And that instinct to improve the tools that we have in a way that is helpful to everyone around us is what has really built the internet that we know and love. And that I think has brought us all together here today. So I'm really grateful to the people who have worked on all the technologies that support the technologies that I write now. Because it has taken not just a village, but an entire world of programmers years and years to get to this point that we are. We all stand on the shoulders of giants. And I'm like literally looking at some of my giants right in this audience here. Thank you so much for listening. If you have anyone who want to argue about what I said or just like give your thoughts, hit me up online later. Thank you guys.