Ep 57: Till Schneidereit & Ralph Squillace on WebAssembly and Bytecode Alliance

James Thomason: 0:04

It's the Next Wave Podcast Episode 57. This week I'm here with my co-hosts, Dean Nelson and Brad Kirby, and today we're joined by two distinguished guests, both board members from the Bytecode Alliance. Till Schneidereit is Chair of the Bytecode Alliance and Principal Software engineer at Fastly. He joined Fastly in October 2020, departing Mozilla after nearly eight years as a Principal Software Engineer of WebAssembly, and self-described as a failed philosophy major. Priot to Mozilla, he had various software developer positions, including as a Flash developer till Welcome to the show.

Till Schneidereit: 0:33

Thank you. And thanks for having me.

James Thomason: 0:34

Wonderful to have you. Our other guest this week is Ralph Squillace. He's Vice-Chair of the Bytecode Alliance and Principal Program Manager at Microsoft Azure. He joined Microsoft in 1995. After completing his undergrad and master's degree in History at UC Berkeley, Ralph, Welcome!

Ralph Squillace: 0:49

Hey, thanks. Great to be here.

James Thomason: 0:50

So good to have you both. Today we're discussing the most important internet technology of 2021. That's according to The Next Web, not the metaverse, not NFTs but WebAssembly. It's a deeply technical yet fascinating subject. So we'll start at a high level before leading into sort of a deeper dive around this technology and its impact on the future. Bytecode Alliance of which you're both on the board of is the industry partnership dedicated to building on standards such as WebAssembly, allowing application developers and service providers to constantly run untrusted code on any infrastructure for any operating system or any device. That's quite a mouthful. So we'll just say that with WebAssembly, this is the second time in history where technology has migrated out of your browser and come out to invade servers and everything else. So maybe Till Could you give us a brief overview of what what is WebAssembly?

Till Schneidereit: 1:42

Hey, Sure, happy to. So WebAssembly is the- next to JavaScript - the second way that browsers can execute logic as part of websites or web applications. And for the first, well, for the first few years, logic simply wasn't a thing. You could only display documents. But then briefly, after the advent of the web, JavaScript came along. And that was the language that absolutely everything had to go through in the browser. For about 20, actually, pretty exactly 20 years. And then the browser vendors banded together and introduced WebAssembly as a completely difficult way to execute logic that integrates really well with JavaScript, but allows other languages like much lower-level languages like C, C++, and Rust, but also Go and Swift, and whatever else to compile to a machine-independent format, that could then run in browsers, wherever those were running, be it on the desktop, running Intel or AMD chips, or in smaller devices, like phones, finding arm chips.

James Thomason: 3:02

And this this goes, this idea goes back quite a way, right? I mean, I'm old enough to remember the the advent of Java. And Java's claim to fame at the time was right once run anywhere, this idea that you would have a single, a single programming language that was portable to basically any kind of operating system, or environment that you might be on. And of course, that technology was immediately... we tended to use that right away inside of browsers. And if you're, if you remember those days, you would sit there waiting for components to download JAR files to download in your browser for you know, 3, 5, 10 minutes, maybe forever, before the application would run. And it was a pretty unpleasant experience. And then JavaScript really took off, right? Because it was a lean mean very fast, and simpler programming language as well. So it was more accessible to a lot more people. So we have JavaScript, it's very fast. It's also pretty secure. Everyone wants to break out of your browser and into your operating system and steal all of your data. So it's a hardened surface, the runtimes that are in your browser.. we, most of us(you don't) but most of us take for complete granted. What's the major advantage of WebAssembly over JavaScript world that we live in today?

Till Schneidereit: 4:12

I think the best way to summarize that is it allows all of us developing for the web, but increasingly also other environments to use the right tool for the job in many more situations. JavaScript is a fantastic language. In many regards. I used to be Mozilla's representative to the TC 39 serialization committee working on JavaScript. I have a soft spot for JavaScript as a language. But this situation of having a monopoly on any logic being executed in the browser also meant that everything had to go through JavaScript. So It had to be the one tool to use. And so... there's the saying of if all you have is a hammer, everything you see is nails. In this case, it's not about only seeing nails, but not being able to use the tools like the hammer. And with WebAssembly, we are making it much easier to use other languages for parts of what you're doing. And I think that's what we're increasingly also seeing that it's not too much entire web experiences being completely done in one language in Java, then targeting WebAssembly, but parts of web applications where much of it then, maybe, is written in JavaScript and parts that are, for example, particularly memory or CPU-sensitive, being written in languages that are a better tool for that particular job.

James Thomason: 6:00

That's a really great explanation and characterization. So I can use different languages that might be faster, for example, for certain tasks, like processing a lot of data or 3d rendering or other things that are really CPU intensive. And I guess one of the advantages is that WebAssembly, the bytecode, itself that gets compiled is a lot closer to the machine code that runs on the processor, is that correct?

Till Schneidereit: 6:23

It is it still in terms of virtual machine architecture is it still kind of an odd one it is not nearly as similar to how individual, separate actual CPU architectures are to each other. So say, the arm amd x 86, or x 64 instruction sets, those are all ... the entire programming model is roughly the same, and then the instruction sets differ. WebAssembly is a very different beast, it has some some constraints and sudden some architecture decisions that are pretty different, but are there for very good reasons, a lot of them to do with security, such as there are parts of your memory that in normal applications, you can easily access and just just inspect like the stack in WebAssembly, those that hidden from you and controlled by by the runtime, which is really good for security, but makes for an interesting compilation target. But that's a good thing. This is all something compiler designers have to care about. And not developers targeting this environment. That's that's something you just don't have to care

Ralph Squillace: 7:43

Unless you want to read the manual. If you want if you're the manual reading type, you can still do it. I wanted to throw one other thing if I could, you know till discuss the the evolution and you're talking about it in the web. And tell me the point that you can use other languages for certain tasks when they're better suited for those kinds of things. But it's also very useful for code you already have written or already exists for certain tasks. So you may not think of it only as something like, oh, I can do this now. But I haven't been able to do it before it turns out, you can now reuse and repurpose some of your code that has been around maybe 5, 10, 15 years or more that is outstanding at what it does. And now you can bring that into the WebAssembly environment. In this case, you know, the browser,

James Thomason: 8:34

that seems like a huge advantage from where we are today is that all these millions and millions of lines of code written in languages like C, C++ or Rust. Even higher interpreted languages like Python, I assume I I saw recently a project where they got the Python interpreter running also on top of WebAssembly in the browser, which is pretty clever. And I assume that will that will continue development. Maybe we should back up just a moment. And Ralph. Both you until are are on the board of Bytecode Alliance, what is the Bytecode Alliance and how is it helping to foster technologies like WebAssembly? Well,

Ralph Squillace: 9:10

So I'll start and then Till will correct me because Till's been doing this collaborating with the the founders of the organization that was originally the Bytecode Alliance.

Till Schneidereit: 9:22

Oh, Ralph you'lll do just fine. Don't pretend you don't fully understand.

Ralph Squillace: 9:28

Alright now I'm actually going to lie so Till is forced to correct me. No. So earlier earlier on, so a couple years ago 2019 2018 Probably you are creating it. You know, Mozilla, Fastly, Intel and Red Hat were collaborating on this space. They they all had aligned interests and all participated upstream organizations that wanted to collaborate to develop, create an organization where they could with others, develop some designs and take WebAssembly and create new things like the WebAssembly System Interface (WASI) concept, component model for WebAssemblies. All of these are based on the core WebAssembly specification, which is in the W3C. And they needed a place to do this work collectively and transparently so that everybody else with their their own skills could jump in. And there were lots of people who participated with the proposals for things that needed to modify that need to be modified in the WebAssembly spec. Those things go to the working groups and the W3C, for example. And so

Till Schneidereit: 10:39

That was indeed always the intent, it was everything the Bytecode Alliance did was directed toward public specifications and reference implementations for those kinds of things that demonstrate that they were actually good ideas, to get contributions from people who realize that this area could be done better, and so forth. Till I believe the intention was always to become a foundation, Was that correct? Because I came in just a little bit later. always clear to us that the space would have enough importance and what would have enough, just just going on that we would need a space with that that allows open collaboration for companies where that's sometimes difficult. And just having a formal space for this with bylaws that give a clear explanation for this is how you reason about IP and the conversations we are having, for example, it was clear that something we need and open governance it besides like IP questions, just having something where you can actually become a stakeholder in everything we are doing, that was extremely important to us.

Ralph Squillace: 12:04

And so when I got involved, you know, I work for Microsoft, this big, huge corporation. Some of you may have heard about it. Some of you may have been angered by it. These things, these things happened,

James Thomason: 12:15

Most of us have been angered. But there you go.

Ralph Squillace: 12:20

I've been working at Microsoft for a long time, and had been one of the first people working on Linux, things inside the company and open source and then containers and so forth. So I've been doing this a long time. And as the company was changing its direction are realizing that the vast majority of development would be open and transparent. And the some of the best software in the world would be open source software. As it did so I was able to realize that the some things were happening in the WebAssembly community that were what I believed was technically superior in some areas to what containers had done with Kubernetes. And open source. Containers are outstanding. But there were certain areas in which they were a little bit tricky. I can go into them. But before we get there, I just had seen the work that was happening with the collaborators, the bytecode. Alliance, and realize that they were doing what I felt was the right thing. And then Microsoft should jump in and support that and begin collaborating. So we started doing that, and eventually were invited until was very sweet. So it was everybody else on the board at that time, and allowed us to help contribute to the creation of the foundation. So that's how we joined. And we got to join the rest of the what you might call bootstrapping members. And we've spent the last year in addition to doing incredible work on the engineering front spent the last year adding members, making sure that the the elections are upcoming that the structure of the governance is correct, and so forth. And we're getting very, very close to sort of completing the or at least closer to completing the bootstrapping period. And very soon, and I'm looking forward to this the bytecode. Alliance foundation will be up and running and extremely democratic. As it really should be, I think the the objectives of the foundation are radically more democratic than almost any other major foundation that I know of, and I absolutely believe in it.

Dean Nelson: 14:29

Okay, so I need to I need to back up for a second because here we are today. Think about this, Ralph. Okay, I've been in the industry 32 years. So I started the Sun Microsystems in 89. Right. And we were we were and we were bitter enemies. It was great. It was great. But just just think back then, there was none of this open source there was nothing about it was all about IP and proprietary and, and, you know, fully, you know, systems that were actually controlled, and then, you know, things started to change. But tell us a little bit about This from the past because I mean until you were also involved in, like the very early browsers at the same time. So that history, right, is it? Or am I wrong?

Brad Kirby: 15:12

Maybe Maybe I can take a crack at the just the history of web browsers. And who invented it was really effectively was Tim Berners Lee right 1989 at CERN, but it took him a couple of years to get the support around it. And it was called the world wide web, www, which we all know today. And effectively with that he created in 1990, the first web client and server, it also created the specifications for HTTP and HTML. And 291.

Ralph Squillace: 15:45

Brad, somewhere around this period, Microsoft began seeing that activity as possibly competition, just throwing that in there to sort of give it a shot. For sure, there you go, keep going.

Brad Kirby: 15:59

And this is this is just the web. Right? You go you can go back to ARPANET in 1969. And, and, and what they did, you know, creating two nodes between UCLA and Menlo Park, and being the first kind of internet example and then Vint Cerf and TCP IP in 1974. Who James, I know. Vint used to be one of your mentors at one point in your life.

James Thomason: 16:26

Advisor to our start-up. And yeah, you know, it was mentor as a implies a relationship that's a little closer than that. I mean, I got to hang out a little bit with Vint Cerf, which was super cool to me, because this stuff, I mean, for for a nerd like myself, that was like, one of the coolest things ever is to have Vint Cerf advising our company. And he, who is at Google now, by the way, and he just one of my friends are at Google. And they just, it's surreal to them that Vint Cerf sort of just wanders the halls over there. In the regular building, yeah. And the Greygler building, exactly. That's where they keep all the gray haired folks that actually know how the internet works. I I look forward to being brought out of retirement as someone who understands IP routing. Interestingly, I'm sorry to keep going Brad with history,

Brad Kirby: 17:07

I think I think, you know, you always reference Al Gore's internet, like in 1991, you know, the High Performance Computing Act.

James Thomason: 17:14

although I never saw him plugging in cables, though. Not not amazed either.

Brad Kirby: 17:18

He did fund $600 million for the infrastructure. I know you call it Al Gore's internet.

Ralph Squillace: 17:25

I want to point out one of the interesting things about this history too, is that that, Brad, as you're like, you know, spilling out this story. And we know we're going to get the, you know, web browsers as we currently conceive of them. One of the most fascinating things is without that network connection, that speaks the appropriate language between the browser and something we call a server. In other words, a talker and a listener process. Without that connection, there is no web browser in any sense. So I'll rip, I'll bring that up again. Keep going.

Brad Kirby: 18:02

That's why I step back

Ralph Squillace: 18:03

I like, like where you're going.

Brad Kirby: 18:05

Prior to that. So maybe I'll let James take over from there, effectively?

James Thomason: 18:11

Well, I mean, if you obviously there were the great, there were the great browser wars, Netscape, Internet Explorer, a little company called Microsoft, right? Decided it wanted to be a part of the internet or something, you know, what kind of?

Ralph Squillace: 18:24

Well, we were a company that sold standalone software, right. And if you could abstract away the user interface, and put that same user interface, more or less on any number of other devices, all of a sudden, you didn't need to buy Windows, for example. So from the point of view of a company that now makes tons of money over windows, this one thing, and then also does sell compilers and stuff like all of which, you know, are optimized for use on Windows, you can imagine what a threat this is.

Brad Kirby: 18:54

In 1995, Netscape Navigator, right, which was, you know, Marc Andreessen hired Brendan Eich, who to, to effectively do something that he didn't end up doing, and he ended up creating JavaScript in 10 days. And that was a that was a product of direct competition with Microsoft. Right. And Sun Microsystems was obviously heavily involved with that.

Ralph Squillace: 19:20

We had something after a little while, we had something called VBScript, which I won't talk about. Continue.

Brad Kirby: 19:29

Yeah. And the history could have been very different.

Ralph Squillace: 19:32

This is, this is wonderful, from my point of view, because I can feel the opposite side of this history.

Dean Nelson: 19:37

Yeah, it's awesome.

Ralph Squillace: 19:39

Keep going. Yeah, it's fantastic. Yeah. And then

Till Schneidereit: 19:42

The technical platform, so the the engine under Firefox, I think it was still in Firefox, but certainly before when it was the Netscape Communicator and so on. It at some point had full Python bindings to all API's in addition to JavaScript one And there was a question should Python also be a first class citizen of the web. And then that didn't happen for exactly the same reason Dart didn't happen in the browser, because cross language opt turns out to be really, really hard, which was, I guess, part of the topic we're here for today.

James Thomason: 20:18

Exactly. But there's something else here that I'll try to try to tease out of this, that. And I'll do it by way of showing Till because so Till you work, everyone knows I probably on this show what Microsoft is, and what from whence it came, you work at a company called Fastly. And certainly those of us in the infrastructure space or who are running websites, running content, we know who fastly is, as a, as a leading contemporary in the content delivery network(CDN) space. But things are changing, like in the in the CDN space towards this other thing called edge computing. And we run a small startup company that's also in the CDN space, also the edge computing space called EDJX. That's where Brad and I from and we recently joined the Bytecode Alliance. And what's interesting about that, is that, you know, at a, at a micro level, you might look at Fastly and EDJX and say, well, these companies are competitors. Why are they... Why are they cooperating with each other to further a technology, right, that seems antithetical to what businesses do, which is to compete with each other and win market share? But the reality is that what doing what WebAssembly does, and getting it right is extremely difficult. And, you know, there's many moving parts as hopefully the audience is getting a sense from this conversation, right? There's different interests at work, and technologically, just that, that task of making multiple languages run in the same sort of environment, the same runtime on the same virtual machine is quite complex. So I think that's one of the really interesting things about open source. And getting into the heart of discussion that Dean and Ralph were having a little bit earlier, like in the in the late 80s, early 90s, there was not an open source world, like Microsoft kept all of its source code, a secret, IBM kept all of its source code a secret. And when Linux sort of came on the scene, this stealth war between IBM and Microsoft started to emerge. I mean, the probably the audience is aware of the great operating system wars between IBM and Microsoft going back decades, you know, IBM failed operating system attempt was to did not take over the desktop market by storm. Of course, you have apple in the next year. But IBM began to help Linux like in no small way. In fact, without IBM, I would say we wouldn't, we wouldn't have Linux today. I mean, it may never have been the success that is because they took their particular expertise, their knowledge of how to build large scale systems and mainframes and such and brought bits and pieces of that into the Linux operating system and made it a robust server operating system that that we could use in production. And so here's, here's you fast forward that Linux dominates the server market today. No offense, Ralph. But in terms of

Ralph Squillace: 23:18

I'm not personally, injured.

James Thomason: 23:20

Okay, good. Good. You know, in terms of overall market share, it dominates right. In the browser

Till Schneidereit: 23:23

It is? Yeah. space. Chrome, I think is dominant. Am I correct? Now,

James Thomason: 23:27

Yeah. Chrome is also open source. So you know, Chrome is now is still dominant? we see this pattern where things that are high value technologies that have to work in multiple problem domains seem to do better when they're open source, because they capture more of the use cases. They allow innovation to take place, right? It's not, it's not perhaps the things that are happening at the the lowest level in something like WebAssembly is obviously innovation. But there are higher order innovations that are happening on top of WebAssembly that are the real sort of differentiated use cases that companies like Fastly, are bringing to market companies like EDJX and companies like Microsoft are all bringing to market independently to serve different customers. The last thing I'll say is that, and we mentioned this right up front is the second time in history that a technology has migrated out of the browser and turned around and run on the server side. And Ralph brought up the client-server model. And so I think this is perhaps want to hand it back to you guys, because that technology was JavaScript and node.JS. So a lot of the backends for web applications and mobile apps today are running node.JS on JavaScript. And it looks like in the near future, a lot of them are going to start running WebAssembly. And that's that's an area where I know the three of us, the three of our companies are hotly pursuing, and it's specifically around this idea of client-server. And in particular, there's a newer paradigm that many of us are experimenting with called serverless? I think Fastly is one of the comedies leading the way in serverless. So Till maybe you could tell the audience, what's the difference between client server? And serverless?

Brad Kirby: 25:12

I think we should we should also say that all the main web browsers do run WebAssembly. today. Oh, yeah. Right. In terms of computation, right. So that's, but we're talking about in the last couple of years and, and the transition. And that's ultimately, what the Bytecode Alliance has been formed to deal.

James Thomason: 25:30

Yeah. But that's, that's in the browser. But now it's moving out of the browser on the server.

Brad Kirby: 25:34

I just want to give the timeline of that. Exactly.

James Thomason: 25:37

So what's what's the difference between client server and serverless?

Till Schneidereit: 25:41

I guess maybe the most important part is allowing developers to focus on the thing, they actually care about the business logic for what they are doing, and not

questions around: 25:54

How exactly is this run? What operating system is it running? What is under the hood? How do I make sure that my dependencies down to the kernel are kept up to date? How do I scale my application with incoming traffic?" And serverless, the promise of serverless is to make you not care about the server. Obviously, there's things things are running on, on servers, I mean, in this case, it's other people's computers, but that they don't have screens attached to them, their servers, obviously, they are servers of some fashion. But as a developer, you don't have to care about it. And ideally, you also don't have to care about kind of any aspects of the server, like the operating system, and the CPU architecture it is running on all of these things should also not be there they are you do have to care about those parts still in most serverless solutions. And I guess that's one of the most interesting aspects for me personally, that we, with what what we are working on WebAssembly-based serverless, we can get much closer to actually making things serverless. Actually realizing this promise of saying, no scaling. You don't have to care about architecture you don't have to care about it's all just taken away or in way external dependencies, we can virtualize those sufficiently for you that you actually really don't have to care about it.

Ralph Squillace: 27:27

And that's an amazing step.

Dean Nelson: 27:29

Yes. Huge.

Ralph Squillace: 27:31

So this, this goes back to one of the things that we learned with containers, containers are a fantastic thing. They are amazing. What Docker did was fantastic, made it easy to sort of wall off a tarball of code and environment and replicate it and push it around the internet and share it. And so for the just these these amazing things. But unfortunately, is not, even though it's a huge agility and shareability advantage over native code that we had before. You know, and certainly over VHDs, right, virtual machines, huge advantage, but still yet gotta compile it for a particular operating system, you gotta build it for a particular architecture that that operating system, still, you got to optimize it, instead of just build only the thing you're running, you got a whole environment you're bringing, you know, there are layers you got to think about, and there's stuff like this, and really, the developer just wanted to build the binary,

Till Schneidereit: 28:39

and you still have to care about the scaling. But no, it's not not even that is actually fully taken away,

Ralph Squillace: 28:45

got entire programs do that. So that the reason I love containers is also the reason I noticed that there are areas where something you really want is operating system agnostic, architecture agnostic, and is not an environment, but actually a binary format. And WebAssembly happens to hit those.

James Thomason: 29:09

There are a lot of business listeners on this podcast. So I'm gonna I'm going to uplevel this just a little bit. Because we take things for granted by

Ralph Squillace: 29:16

Buy! Buy! Buy!by, that's the person who go ahead,

James Thomason: 29:20

We take things for granted, like the you know what a container is, for example. So I'll just, I'll just back up to 10,000 feet for a second and say that, of course, there are different ways of virtualizing computers. And when we say virtualizing, we mean running multiple copies of an operating system on the same hardware used to be, you know, go back into the early PC era, you installed Windows on your laptop if you were most people. Some of us were rebels and installed Linux, and that's the operating system that ran your hardware inventory. In the 2000s. We got the ability thanks to companies like VMware and open source projects like this tend to run multiple copies of the operating system on the same hardware at the same time. So I could run both Windows and Linux and multiple copies of Windows on the same PC, as several virtual computers and to the to the, you know, for all intensive purposes, my one computer was several computers from all the resources I could use. And then, in the mid 2000s 2008/2009, we gained the ability in Linux, to do what we call containerization, which is like run, a very thin copy of the operating system sans what we call the kernel, the things actually runs on on the processor, we gain the ability to just partition the network resources, partition the CPU resources and storage resources and run a really thin copy. That's what containers basically are, is there a thin layer of provisioning, that you can lay down on the hardware. And so in a weird way, WebAssembly is another evolution of the virtualization model, right? Where we're not virtualizing a piece of the operating system or an entire operating system, we're virtualizing the the machine layer with respect to a single piece of a program, that developer might write a single function, as we say, and the rest of the runtime is supplied by WebAssembly or the libraries that you compile into your function? Is that, would you both agree with that laypersons kind of explanation?

Ralph Squillace: 31:32

No, that was a good, a good rewind.

Brad Kirby: 31:34

and a good quote around, you know, Docker and containers, right? The co founder of Docker said that, if wasm and WASI, which existed in 2008, that Docker...

Ralph Squillace: 31:48

we'll get to that

Brad Kirby: 31:49

...Would never exist, right?

Ralph Squillace: 31:51

Yeah. And this technology came came out of the web browser world came out of JavaScript came out of the web browser world, the others virtualization, these are these were hosting specialists,

James Thomason: 32:02

yeah, server side

Ralph Squillace: 32:03

Server server servers, this wave is coming from the web. And it brings a legacy of not only functionality, knowledge about how to optimize processors and virtualize you know, compute, because of course, JavaScript is an interpreted language, and so forth. So it also brings that knowledge, but also brings in the requirement to be secure, because browsers get attacked like you can't believe. And so it's really fascinating to me that this wave is coming from the web browser. Evolution and not from the server companies. It's fantastic.

James Thomason: 32:39

I so agree with that. It's amazing. And then go ahead, and you're about to say something.

Dean Nelson: 32:43

Yeah, I look at these these trends that have happened. And it all comes down to abstracting things away. You're abstracting the complexity away. And so if you think about, I had hardware that was dedicated to a specific operating system, that operating systems that were only dedicated to one thing, then you broke that apart and said, I can do virtualization, then we went to containerization, because we could do orchestration better. But then all of a sudden, there was a mixture of say, well, containerization has a limitation to have only 20,000 modes and right with a master that you run into scale problems. And then we started doing virtualization as well, to enable that to get bigger. And so is there a limitation that is going to come from WebAssembly? Because once we get these things, it's all one problem, new problems emerge? Can you see any of that? That would be that barrier? similar pattern?

Till Schneidereit: 33:34

I don't know that I see. bappy. Yeah, exactly. It's, it's not like there are no limitations. I mean, it's, this is not the fabled free lunch,

Ralph Squillace: 33:47

But it is engineering.

Till Schneidereit: 33:48

It's intense amounts of engineering, it's, right now, overhead, that is not not meaningless. But a lot of that can be optimized away. But then we're back to the engineering. It's also this hardware abstraction, we talked about comes at a cost, it comes at the cost of not gradually being able to make use of all the bells and whistles your hardware would have available to you. So if you compile natively to a the latest version of your office specific instruction set that you know, the hardware you will be running on supports, you'll be able to eke out more performance and you will be able to use highly optimizing vendor specific compilers for that, that that is a cost that we have to bear from using WebAssembly. But at the same time, it scales like I think, literally nothing else. I'm so at the lower end right now. The the limitation is that the more minimal size for the manual page. So just the kind of space that an application gets to play with in its sandbox is 64 kilobytes. I mean, we heard that 10 times that is enough for everybody. But

Dean Nelson: 35:17

Mr. Gates, thank you very much.

Ralph Squillace: 35:19

There's some famous Bill quote about

Dean Nelson: 35:20

That's right, who would need more than 640 kilobytes. Come on?

Till Schneidereit: 35:23

He apparently never said that. But it's, it's a that is a limitation that people are running into where they actually want to have it scaled down. That is possible. It's not that there's no inherent limitation, it's possible to extend the spec to say, hey, we could use a memory type or flag on the memory to actually scale down further. And then that is taken care of. And I there's a fundamental reason why you can't go to really the Chinese embedded hardware. And going up, I also besides the just, yes, it's a lot of engineering work to get more and more off the latest hardware performance pieces in there. Besides that, I don't really see limitations on on the other end, we have.

Dean Nelson: 36:11

And I'm asking this question for a reason. Because there's there's an acceptable cost in all of this, that when you lose a bit of that being able to to fine tune everything. You gain scale, you gain security, you gain. And that's really the big difference here is that the point of all the substraction is to remove all the complexities from the majority and let that majority, right, do what they do best developers write code, don't worry about all the complexity. Realistically, this is the lesson of JavaScript to

Till Schneidereit: 36:43

exactly that. That is why JavaScript is successful on the server, not just in the web, it has had for the longest time it had this monopoly on on the web. And people were saying, well, JavaScript is only popular because it's the only game in town on this important platform. The success of JavaScript on the server side with node for the longest time no other environments like Dino just I think demonstrates that no, people actually want to use this yes, maybe because it's then the thing they can use on all in all these environments. But

Ralph Squillace: 37:16

it's also the thing they can approach

Till Schneidereit: 37:17

it doesn't even stop there. electron is a big thing that makes use of all this in environments where we wouldn't, people wouldn't have to, they could use other technologies they choose not to

Ralph Squillace: 37:28

in many in in almost all these cases, the abstraction that you embrace gains, you skill set sharing, it gains you network collaboration, network size, collaboration, the human collaboration. In other words, the more people who are learning and using a particular language or a particular technology, and then can apply more brainpower to common problems. And that that is the one of the core aspects of open source and open collaboration generally. So when we're talking about WebAssembly, the potential is massive. But one of the things that is clear is that the optimization, the niches, the little places where you need to pay attention to hardware, you may have to make another choice. And that's what good engineering is about. It's not about whether you use one label of one thing for everything. That's not the objective. The objective is to see whether we can build a tool that is incredibly more useful than just all of the tools we currently have. And that's that's the the potential of WebAssembly.

Brad Kirby: 38:31

Really would you call that? Like, boil that down to portability, really, both language portability and platform portability?

Ralph Squillace: 38:39

Yes, although I think, you know, the, the funny thing is that, so I'm talking from, you know, the company is now it's a server company, a developer company, it's a massive, you know, mega corporation is, I would say, the mega corporation. So the strange thing is, is that nobody would look at me as a webhead. You know, historically, like my upbringing was not that not in that area. Portability is critical. So when till talks about OSI agnostic city and hardware agnostic city, he's right spot on. That means you can take the same module and run it on this chip that chip. When we get RISC-5 chips, we get other chips coming in the future. Right. All all you all those modules will continue to run in as soon as the runtime runs there, the modules run, that that kind of network effect is is not just geometric, but exponential. Because it's not just one more platform. It's all the users that weren't on the platform now can replicate their work. And so it's massive upside to general use cases. But the cool thing about it is with the work that the BCA is, is leading with system interface and component model and so forth. There's also ways to more safely, not safely, but more safely designed special access to certain kinds of hardware like GPUs, or TPM, or whatever it might be as well. So tremendous future there.

James Thomason: 40:14

So in terms of what this means for the average person, it means in part that the presence of WebAssembly in the browser will lead to more rich user experiences, which today, you might have to install a full blown application on your iOS to receive right. So if you're, when we're talking about a mobile iOS device, or desktop, computer or laptop, to get that kind of experience in that kind of performance today, I would almost certainly have to install a native application that's compiled for that operating system. But in the near future, I might be able to download that application on the fly, have it run securely on my computer without having to install anything? So on the browser side, would you say that's a fair characterization of, of kind of the future that that WebAssembly is going to give us?

Till Schneidereit: 41:04

I think it's an entirely fair characterization. Except, in part, it's up the future. It is. That future exists in in some some parts. And it started in really tiny ways, such as Google Hangouts has been using WebAssembly for echo cancellation, just a tiny bit for years now for since I indirectly, when but before maybe even more years. And back then represent me maybe it wasn't available. If it wasn't available, I don't even know if they fell back to a JavaScript compiled version or just didn't have echo cancellation, I don't know. But it made the experience better that you had WebAssembly. And you didn't have to go outside of the web and to an ADF application to get that improved experience. figma is a design tool that for actually, they used ASTM J as the kind of precursor that Mozilla introduced. But as a subset of JavaScript, no standardization needed to begin with, to WebAssembly. And then they switched to WebAssembly eventually. And that is a web first experience. They never had native applications, and they didn't need them. Photoshop is available on the web. Now, Google Earth runs in the web. And so there are actually tons of really high quality. So Photoshop, to me is feels like this. The thing? I don't know, probably not not not all listeners have used Photoshop. But if you have ever used Photoshop, it's sort of to me, it seems like the prototypical Whoa, application that obviously needs to be a native app. Except it doesn't

Dean Nelson: 42:52

doesn't. Yeah, I've used the sense of Photoshop too.

Ralph Squillace: 42:56

If we're talking to your your, your business audit audience, for example, I can even throw in a stranger story, which is that Microsoft has Excel Online, right? So you can do your little calculations and so forth on the browser. They wanted to put lambda functions in cells, so as part of the macros and the macro language, right? And, but that's hard. In JavaScript, lambda functions really hard to get in a web browser, and not be massive. And so some of the researchers partnered with some academics, and they took C, C code C++ code, I believe it was from 1985 for the client, and compiled into WebAssembly, and Excel, one of the largest web applications out there. You can use lambda functions in your cells as a script as part of the scripting. And that's done with WebAssembly with C++ code from 1985, that is so cool. That's amazing. That's how amazing it is.

James Thomason: 44:06

That's amazing. You know, there's a lot of talk out there about Web3 And you know, I think Well, here we go. Right, here we go. Because dive in with your Web3 is often so conjoined to the discussion of blockchain or crypto, and I guess, you know, in fairness, if you own 10,000 Bitcoin, I guess everything looks like it should be solved by crypto to you, right? I mean, that's just the nature of the beast, right? If you have a huge investment in crypto, it looks that way. But you know, here we are going on a decade later, I guess. And crypto hasn't found its its killer app, so to speak yet, but technologies like this seem far more transformative than you know, conveniently writing things to a ledger, you know, the ability to run fragments of applicant ones that have existed since 1986. You see 86 or 84. Anyway, you know and repurpose them and use code that is that is tested that is true that is known to be good. and reuse it inside of Web3. So loaded

question Till: 45:19

Do you care to comment about the relationship with Web3 and in WebAssembly?

Brad Kirby: 45:27

Can i Let's go on I just precursor this with with a trivia question. Do you know who coined the term Web 3.0? I do not. Tim Berners-Lee in 2006. Oh, in New York Times. Now separate that from Web3, right? It's a semantics thing. Like Web3 is more of a Gavin Wood term. He coined in 2014, the co-founder of Etherium that wrote the technical paper, founded Parity Tech, he created Solidity language, and you know, heruns Polkdot and they created Parity Substrate, which is written in Rust and compiles to WebAssembly. So that's, I just want to put that in there. Just to distinguish the Web 3.0 conversation because we talk about Web 2.0 being kind of where we are today. And the Web3 being, it is associated blockchain really because that's what this the web three is one word is, is associated with Blockchain, because that's what the projects are building on and referencing. Both Brendan Eich and Tim Berners Lee have Web3 companies right now.

James Thomason: 46:38

Like, wait, hang on Brad, I had very carefully painted till into a corner to try to get him to answer. Like,

Ralph Squillace: 46:44

We got to get back to the corner.

Till Schneidereit: 46:45

Now I need to get out of this.

Ralph Squillace: 46:50

I want to get a hot dog.

James Thomason: 46:53

Popcorn.

Ralph Squillace: 46:56

This is gonna be good.

Till Schneidereit: 46:57

I am not convinced that the problems Web3 claims to solve are either solvable at all or have technical solutions. And I am deeply concerned about many of the problems that it causes. And to me, so some of the problems that came to solve are, I think, societal questions that we as technologists don't have any business. And when I hear all these claims about the performance, you'll be able to achieve with this, I only see that if at the end of the day, you take all the decentralization away, because turns out the speed of light exists, and far we know is a hard limit. And that just puts an upper bound to I mean, it's something shipped vendors have to grapple with, and try to reduce the length of the distance between different parts of their chip, because the speed of light is too slow for them to get the performance they want. It now talk about something we're at inequity as part of the architecture you want to run across the entire world. I think a lot of claims that are being made about edge are just very, very difficult to bring together with with some of these fundamental hard constraints. And I'll not dive too deeply into the other concerns I have, but I'll I'll leave at that. At that I I'll say at the same time, I can absolutely appreciate that. They are amazing. Technical challenges being addressed here. And a lot of what is happening in that space is just a whole bunch of technical achievements. And I'm sure there will be actual uses of some of these solutions. I don't see a lot of what the hype is currently about as being in that space. I'm okay, but I apologize for being a downer on this. But

Brad Kirby: 49:27

No, no, I think you're right

James Thomason: 49:28

Very skillfully navigated Till.

Ralph Squillace: 49:30

I was gonna say that was some complex surfing. Yeah,

Brad Kirby: 49:33

Let's use an example of the hype, right? Like look at a look at a website like and like open c.io that are selling NF T's right? If you break that down. It's not the amount of transactions that actually happen on the blockchain. It's only when you go to pay them a fee, but it makes the user look like they are actually creating a NFT they own it, they have ownership of it, and then it's on a blockchain That's what the website shows when in fact, that's not the case. For the most part, so you're effectively creating a JPEG like a JPEG with some metadata that's stored centrally in the cloud. And it's only when you go to trigger a ERC 1155 smart contract that charges of transaction fee and gas, to get rid of that your creation, that there's actually a true ownership concept. And that these kind of things are really, you know, clouding the the entire tech underlying technology.

Ralph Squillace: 50:37

They are and I could even follow on what you're saying, because like, for example, what you just described as a website, yes, right. Yeah. In other words, for those people who are listening, right, the the experience the user has up until the point they actually try and transact is the experience that websites build. And websites give you in, in in those websites, it could be JavaScript, and it could be WebAssembly. Right? So you can have an amazing experience with WebAssembly, with JavaScript and all that kind of stuff. That's a lot of fun. But they're quite aside from the, when you step off the the website experience and you drop into the transaction experience, there are some aspects of what goes on that WebAssembly is a kind of technology that can be used there very effectively. Now I am of the opinion that Till hit it on the you know, right on the head there, I do not necessarily believe, in fact, I don't believe that deliberately turning up more silicon wafers, in order to charge a lot of money, just so that it scales sometime in the future, maybe we'll still be on this planet by the time you can make it really efficient. I'm not sure that, in fact, I don't believe that's really the way engineering should go. However, having said that, and thus joining till in the downer club. Having said that, a lot of the little bits and pieces of technology in there are very useful in WebAssembly and apply. So for example, contracts. smart contract needs to be something that's fairly immutable. And I say fairly, because immutability is, you know, when we get quantum boy, we get confusing. That's right, we get uncertain. Yeah, I think technically. But the point here is that lots of aspects like "what is a smart contract?", you can compile smart contracts to WebAssembly, sign them, then you get a little immutable smart contract that you can pass from website to website is very, very small, super efficient runs almost everywhere, you can now use widely available tech, you know, chips, any operating system you want. And so that technology in that one little area, you can see how that actually is a really good application of the technology that that we're all involved with right now. And that's similar to things that are going on WebAssembly in other places. So if you're in Kubernetes, and containers, there are projects like Kube Warden, like envoy, and in the service mesh space where a network filter is WebAssembly, and it runs to do network filtering. Or in the case of Kube Warden your rego expression. For those who are business people just think policy that disabled This allows or permit some some behavior. Those policies are compiled into immutable WebAssemblies. And that's how they execute in killboard. So there are little areas of technology that do exactly the same kinds of things as some of these areas in Web3 transactions where you need something immutable, binary, lightweight and a public specifications so everybody can look at it, see what it is the whole thing. So there are areas where that engineering actually makes sense. If we stop and talk about web three till is right, I think Till's right also I'll bring it back up till

Brad Kirby: 54:01

I think when you talk about public permissionless blockchains like Bitcoin and Aetherium like a Solana like you talk about the compute, right? They're using proof of work, compute, which, which is a massive amount of computing. Yeah, we

Till Schneidereit: 54:17

I haven't even touched on those aspects. And I don't know that I decided against doubling down on the it's also kind of helping us kill the planet quicker apart, because

Ralph Squillace: 54:29

Wait well that was my point. Yeah, no, no, I got to that one first.

Brad Kirby: 54:32

That's also why I'm against

Till Schneidereit: 54:34

Because that that is the thing right now, I think proponents of all this claim that Proof-of- Stake will do away all this. From all I've seen so far it seems like that brings to it a whole host of other problems and seems like it takes away a lot of the other claims of components of the technology make about it being so democratic, let alone Whether that I mean, you're not going to question How To what degree that is even true in proof of work systems.

Brad Kirby: 55:05

That's and that's taking away.

Till Schneidereit: 55:07

Maybe those problems are actually solvable? I don't know. It seems I don't know of any, any heart arguments for why no, there's something fundamental here that cannot be figured out. For all I know that a solvable and I don't, and I, I do think Proof-of-Work is just bad. And everything being built on top of that is just a huge problem. And it's, it's taken years taking years and years of advances.

Ralph Squillace: 55:44

It is an opportunity cost on this planet, for example, to the degree that it is unsuccessful in its original aims, because it may have some successes till set in certain areas and so forth. There may be spin off technology, technological uses that that appear. But in its original aims, that is a massive social opportunity cost. What did we not do? With all that talent? And all that money? Oh, yeah, at this point in our history that we might have otherwise done? That is a definitely an alternative future. Because, you know, there it is.

Brad Kirby: 56:22

I mean, when you say Proof of Stake, you could also think about it being a delegated or nominated proof of stake where you do have less computing and less validators effectively that are operating the network. Right? And then you do have participants that are then, you know, backing them based on their behavior. And that is the governance model. That's happening, like if you go to Polkadot.

Till Schneidereit: 56:47

So that's, that's why I'm saying, I don't know whether it's a fall I know these problems are solvable. Maybe there are maybe there are not, I don't want to make any any kind of hard statements sprung statements about the whether any of this as a setup, overall can work based on something that, as far as everything else is concerned is to some degree, an implementation detail that maybe can be changed. I mean, it's this is stretching the limits of implementation detail, maybe.

Ralph Squillace: 57:20

But we don't ban people from spending their investment dollars on it.

Brad Kirby: 57:23

So when we talk about...

Ralph Squillace: 57:25

Prove us wrong,

Brad Kirby: 57:26

When we talk about WebAssembly being portable, and being you know, specialized components, and then you start thinking about IoT and machine-to-machine economy, and how that could work. Right? In terms of what level do you settle? Right? Are you going to be using bank accounts to be settling when a drone delivers to a spotter? Or is there the possibility of actually running that runtime? Like at the at that level? Because of its its size, and its security? I'm just thinking like,

Ralph Squillace: 58:01

There's a lot of potential advances to be made I in transactions. Yeah, yeah. There is no question about that. So like, like, for example, if you want to take an entire step back and say that the worldwide financial system is inefficient? And has operating taxes, not not actual government tax, but like just the tax on operational costs, that goes into their pockets or whatever might, might do. That's absolutely true. Right? So that motivation, right to drive efficiency into transactions is an obvious space for improvement. Right? It that that isn't even a disputable, nobody sits around and says, I got an idea. SWIFT network is the best that we can ever do. Like nobody, nobody says that. So the the, the thing that you're suggesting is fascinating are also other ideas. So for example, like, have you ever purchased a book on Amazon? Or anything on Amazon? I'm old. So it's a bookstore, you know, like,

Brad Kirby: 59:07

No, I've actually quit Amazon. But that's that's a lie. It's a lie.

Ralph Squillace: 59:13

Amazon is an example because Brad's on Amazon strike. So, you know, if you purchase a book on Amazon, and you Your card is expired, or for whatever reason you use a debit card near your check, checking count is zero or something like this. Amazon actually sends the book before they reject you. And the reason is, because they will send the book and then the next day, they'll send an email to you and they'll say, Hey, man, you didn't pay us. I mean, the books on the way no problem, but we want some money. And you're supposed to go back in and remediate the problem. You go, you know, yeah, okay, I forgot my, my, my expiration date was needs to be updated or whatever it is. Now, the funny thing about that Uber does the same thing, I believe, yeah, a lot of companies do this. Now, the interesting thing about that is the transaction is not actually atomic in the engineering sense. So what's going on here is that there is this very attenuated transaction, period, within which there is some ultimate point at which the company or you make a decision. So for example, if I didn't update it, I'd be making a decision about whether Amazon I wanted to purchase things at Amazon in the future. And Amazon would be making a decision whether losing my my, you know, me as a customer is worth one book that they're going to lose right? Now, if you think about that, it's not even an engineering problem, you can actually think about transactions in a different way. With, for example, your idea of a drone comes and shows up at my door. Like, the web three idea of this is that the transaction could occur safely, you know, using WebAssembly or whatever, in the drone, for example, right, immediately. But does it really need to even Amazon doesn't think so. Right. And so there are things here where parts of the technology areas where Web3 might be investigating stuff, and investing in possible solutions might be more, you know, like very profitably applied to other business changes, that make those kinds of scenarios really possible. And not strictly in the kind of the Web3, mechanism. I think there's tons of room for this kind of stuff. But even more to the point, if we take that drone, and it's flying over the agricultural field, we can hot swap, you know, temperature sensors on that drone, at any time with web assemblies, we can even just hot swap them, like you can even hotswap the drones operating system, it could be flying and just all of a sudden, it's flying on a different version now. These things are amazing. And so like not just Web3, but any edge scenario, even leaf devices still talking about, you know, less than 64 KB, how much less Till doesn't even know yet. But, you know, as they say there is a limit, but it's in the sky somewhere. There's a lot more possible, especially in small devices in small spaces. And WebAssembly is just, you know, the the potential there for new businesses and new business opportunities is massive. And I'm a I'm a big scale hyperscale cloud person, right?

James Thomason: 1:02:28

That's why I say you know, in the in the Tim Berners-Lee, sense of Web 3.0, WebAssembly is truly a transformative technology. And we won't even really think much about blockchain or ledger to the extent that they get used.

Ralph Squillace: 1:02:41

No, you'll think about your experiences, what is the business doing? What is the customer seeing? That is, you know, or the user, the organization? Like? Do they get to do their banking anywhere without thinking about it, that's going to be the solution.

James Thomason: 1:02:53

I think one of the greatest ironies of Web3 is that the killer use case for Web3, the killer use case for blockchain was invented right at its at its inception of, you know, Proof of Work comes out of the Hash Cash algorithm in the late 90s 97. And that was... that was designed to prevent what? It was designed as a digital tax, someone would have to pay in order to thwart a denial of service attack, which is to thwart someone sending you unsolicited email, for example. And so that, you know, that algorithm was was simply, "hey, you're a strange email sender, or strange server I've never heard from you before, I don't trust you. So therefore, I'm gonna make you solve a big inefficient math problem as a kind of tax to slow you down so you can't just you know, send me 1000s and 1000s of emails". And here we are, over 20 years later, the algorithm has taken off as being used inside of Bitcoin. And I think pretty much every other proof of work system, but it's still not being used to stop spam. Why not?

Ralph Squillace: 1:04:00

Everybody went to Slack.

James Thomason: 1:04:01

I know, if there was a way I could charge people a fraction of a Bitcoin to send me an email. I mean, I think that's the world we should live in. Like, it's the opposite of the Yeah, obviously, the postage system.

Ralph Squillace: 1:04:10

Oh, I gotta say, I work at a mega corporation. And there was a period last year where I deleted 150,000 emails in one cell, one button push. Tell me what about spam?

James Thomason: 1:04:21

I know. And it's, that's, I mean, it's ironic because the problem is solved, in essence, right. But the, the email standard hasn't hasn't taken on Hashcash. Still, you know, 20 years later, even though all of these other blockchain-centric technologies have. But that's the one case where like, you would absolutely say this is we should use this everywhere and just just in spam, like this year, we're just in spam this year.

Ralph Squillace: 1:04:43

Oh, I wish we could do that.

Brad Kirby: 1:04:44

Here's the interesting thing, the creator of the term blockchain, who actually patented, the first patent around blockchain, back in the 80s, maybe even late 70s, like an MIT cryptographer. He recently came out said there was

Till Schneidereit: 1:04:59

Any day now. never any reason to use proof of work in blockchain. That was never a concept. This is a concept that was created specifically from Hashcash, and then, you know, Bit Gold with Nick Szabo. And ultimately Bitcoin was the first real life application of it at a very opportune time post 2008 financial crisis and took off and so proof of work is not is not something that's inherent to blockchain. It's it's inherent to, to Bitcoin, really, ultimately via Hashcash and the evolution of it. So that's that's something to really consider is that blockchain and even distributed ledger technologies is a wider concept. We really don't need all this compute power, because in order to get the consensus, which goes into economic game theory, you don't need that, that it's a fairly genius algorithm, but it's not a requirement, effectively to that to actually run this type of technology. And I think that's what everyone has realized. And that's why Etherium is moving to Proof-of-Stake.

James Thomason: 1:06:08

Any day.

Dean Nelson: 1:06:10

So I've got a, I love this discussion, open absorbing that, like, I'm forming the tendons in my head already, based on the input. So now I'm gonna go look at a little bit more and see and see exactly what this debate why this debate continues. But I think it's important for us to think about the future, you know, we looked a little back, we saw what's going on here in the middle of it, right? WebAssembly, and the work you're doing is incredible. And I really think is something the entire world is going to be leveraging. So awesome work there. And one comment before we go into predictions for the future. Ralph 30 years ago, there is no way that we would be collaborating in this way. Everything. Yeah, I it is so amazing when you think of what you guys have put together, that these companies are together and actually trying to figure out how to actually make all this work. That collaboration is awesome, open source and everything that's been happening in the last decade. Incredible. Now, this kind of stuff is happening.

Ralph Squillace: 1:07:09

By developers too. I mean, it's easy to point companies, but every human that is contributed, didn't matter who they were.

Brad Kirby: 1:07:17

Why do you think that's the case?

Ralph Squillace: 1:07:19

Because it's a... I mean I'll, I'll say my piece. Humans love sharing ideas. And they always have. They've always been writers, painters, photographers, musicians, or, you know, storytellers, humans love sharing. And it turns out, we write software, and software is a mental idea of something that could happen. And so if you give people the opportunity to collaborate on core ideas, that is ideas that are shared among a lot of people, you create a lot of enthusiasm, and a lot of social strength. And when you bind people together, that's just an incredibly powerful thing. And when they bind themselves together, it's even more powerful. So it's very easy to look at big companies having success with this project, or that foundation, when in fact, the real beautiful thing that's happened in computing over the last 20-30 years has been the growth of individual developers talking to each other and being able to share a love of a good problem.

Dean Nelson: 1:08:29

And you guys are history and philosophy majors who said that those degrees were going to be useful. Come on now.

Brad Kirby: 1:08:36

Would you would you say also them possibly at a point in time? You know, with the rise of like, called the platform economy, Facebook, and social media. There was a little bit of that sharing, obviously blew up, right. But what we didn't realize what we overshare do we overshare? Or do we get underpaid? Is our data...

Ralph Squillace: 1:08:59

that compensation is another issue. Yeah. So I, so I

Brad Kirby: 1:09:03

think when I think of web 3.0 versus web three, I think about data ownership and privacy and bringing that back. And so I am just thinking if that's another facet of it that you would consider.

Till Schneidereit: 1:09:21

I worked for was it for more than seven years. And I actually I joined with a lot as an employee after being a volunteer contributor to the JavaScript engine for for a while. So I actually have and I used to be a front-end developer. And as James said, initially doing flash development of all things. It's the one of these sort of more unlikely paths that is enabled by open source I would not be here I would not have had the opportunity to work on helping create something like the Bytecode Alliance if if that hadn't already existed, but I joined Mozilla specifically because I believed in a lot of what it was, was about. And so privacy being for for the user caring about users rights in all this and having, being able to be in control of your own data. I do care about all these things. And Brad I don't want to say yes, I see how what we currently have this this platform economy. A lot about this is fucked up.

Brad Kirby: 1:10:48

And it was not intentional, right. Nobody intended this to happen

Till Schneidereit: 1:10:53

Yep.

Ralph Squillace: 1:10:53

Not true.

Brad Kirby: 1:10:54

Well, so I shouldn't say I shouldn't say nobody. But I don't think it was envisioned in 1989, you know.

Ralph Squillace: 1:11:04

Engineers think that this was going to be the way that would turned out, no, that's absolutely true.

Brad Kirby: 1:11:09

Hackers, well, hackers are engineers, Generally.

Ralph Squillace: 1:11:13

Yeah, they are. And and but but the platforms we have now are businesses, they're not engineer X and engineer Y, they are businesses and businesses do design strategies to achieve market outcomes. Yes, sometimes they're in most of the most of the times they fail the vast majority of business in the like 90%. And that's what business are, right? So it is important to realize both are true.

Dean Nelson: 1:11:41

Ralph, what's what's funny is another trend. If you think about it, we had all these proprietary systems with, you know, Sun hardware, and Solaris and Microsoft and right and it just now you think about it, there are these very big platforms that it's it's better to be in, like, when you're in the Apple platform with all the different things. Yeah, it's easier to be a game staying with them. And so whether it's Google, whether it's Microsoft, like everybody wants to be in that one, because everything is integrated together. So it's a similar pattern with it?

Ralph Squillace: 1:12:13

Sure, I have a couple of concerns in this area and Till I'd be interested in provoking you here. One of the things is that we've had this huge explosion into the business world of open source. And Brad, I can remember with you or Dean mentioned, you know, value capture, you know, compensation, where, who's getting the reward for the work that they actually did, and so forth. There is a real concern that I have, as we go forward more than five years, 10 years down the line or whatever, that the open source world will be dominated by corporate funding - one stripe or another - and that there will be a change in the joy that engineers of all over this planet get sharing their ideas with somebody else who thinks they're great. That is, there's something that has to be there's something that's that is evolving, right now you can feel it. And it's going to be interesting to see how that works. That is one of my biggest concerns, because I think that the human race has really benefited from open sharing, and open licenses, fully open licenses, not just random, you know, "I'm going to say it's open" kind of thing. So that's a that's an area that is definitely you can sort of look forward at the problematic space.

James Thomason: 1:13:48

See, humanities majors, make the best technologists full stop, because they're the most insightful, the most self-reflecting. And they think about the big problems.

Ralph Squillace: 1:13:58

Right, James, you could you have no... just... you could not be more right.

James Thomason: 1:14:02

I see it over and over again, over and over again, the humanities majors who make the crossover into tech are the ones driving for the big ideas. And so

Ralph Squillace: 1:14:11

I haven't asked till about this about my concern here. I want to hear what Tulsa till Do you see the same way? Do you see it slightly differently? Or do you have different concerns?

Till Schneidereit: 1:14:19

I do share these concerns. But I also at the same time, don't see it slightly differently. Yes, we see. Obviously, money comes into this I mean, we were weapons me is the kind of technology that just has a huge amount of leverage. And of course, money comes into it not just from the big companies investing in it also from startups trying to make quick bucks off and not really contributing and only only taking from shared kind of taking from the commons not not actually engaging in in good faith. And collectively, this is all happening. This gets back to why we created the Bytecode Alliance because we saw we need a space that gives the right kind of structure to the collaboration. And Ralph knows one of the things I'm currently working on with a couple of the people is bootstrapping the technical governance aspects of the Bytecode Alliance creating a charter for a Technical Steering Committee and defining governance there. And there are aspects here that I care deeply about, including how do you make people stakeholders? How do you set things up in the right way to enable people to say, we are we are stakeholders in this project, we have a right to be stakeholders here, because here is why, here is what we are bringing to the table, here is how we are carrying our own weight. And I care about this for two reasons. One is just so that you can't just come and just take. But there's another one that's a bit more more subtle. And that has to do with golf, what you were just talking about is probably a bit controversial. I think some aspects of this should be for lack of a better term more transactional. Right now, how do you get a large company to invest in open source projects, you get that by having to principal or D level engineers also talk to their CTO and say, Hey, this is a cool thing we should invest in, trust me. And and then you get that if you're a junior developer somewhere, you either do it in your spare time, or you do it after someone did this. And I think, imagine we had these kinds of setups within organizations. We have these large, open source communities that are effectively just organizations that have structures with governance schools with, it's not called that, but management structures among the product management aspects in there. And imagine having the kinds of power dynamics that we have in these organizations inside a company, nobody would find that acceptable. And I do not think and then I think we should do better. Because I think right now, people are burning themselves out by doing things in their free time and not getting to a sustainable place. And I think that is something we need to fix that runs the risk of taking the joy out of it. And I see that it is a hard problem. I hope, and I am optimistic that these things don't, aren't fundamentally in conflict, because I can say I enjoy my work that I do at my workplace, not in a Bytecode Alliance context, but also just in a work at Fastly context. I enjoy my work. So clearly, it is not in some kind of fundamental conflict. And I think we as the people designing the organizations in which we collaborate, need to do better on getting/achieving that then we have so far.

James Thomason: 1:18:36

If we said I'm going to double down on what I just said about humanities majors, making the best technologists to see what I mean. And both in both cases presented well. So I wonder if you'd take us out by we're right at the end of our time about 1 hour 23 minutes. And I wondered if you'd take us out just by giving us a forecast of the future. Looking five years out what kind of market penetration will WebAssembly have? How much you know how much of the Web3 will depend on WebAssembly five years from now. What do you think?

Till Schneidereit: 1:19:08

I don't know about the Web3 part.

Ralph Squillace: 1:19:11

The Berners-Lee Web 3.0, not the crypto Web3.

Till Schneidereit: 1:19:13

I think WebAssembly will run in most places most people interact within P2P permeate devices. And then chances are that device talks to something else. It goes through a couple hops running represent me maybe not quite in five years. But I think that picture will clearly be visible in five years. And and and the reason I think this is we haven't even talked in this entire almost an hour and a half about supply chain security and all the interesting problems coming with us, or the Nano process model that we announced the bytecode aligns with and how we want to improve things on in in this regard.

James Thomason: 1:20:05

That just means you have to come back. So we can have that discussion as well.

Brad Kirby: 1:20:09

Also, the articles on Bytecode Alliance.org very, very, very well written and if anybody's interested to go read those for sure, so you and Lin.

Till Schneidereit: 1:20:19

At least once, I mean, certainly the ones Lin, my colleague, Lin Clark, wrote, and it was also the co-founder of the Bytecode Alliance, those are yes, I can whole-heartedly recommend those to get a deeper understanding of all this

Ralph Squillace: 1:20:35

to learn more about what Fastly is doing with WebAssembly,

Till Schneidereit: 1:20:49

We have a developer hub that gives an overview of the Compute@Edge product, which kind of teaches you how to target our platform using different languages, but also contains an overview of some of this. And then our CTO Tyler McMullen. Well, some, and also members of the early Fastly team even before I and other people even joined, have written some excellent blog posts on the fastly developer facing blog about what the big deal about Compute@Edge as opposed to a CDN is.

James Thomason: 1:21:30

Excellent. And Ralph, where can folks go to read more about what Microsoft is doing with WebAssembly?

Ralph Squillace: 1:21:36

Well, if you want to look at several of our open source projects, you can go to Deis Labs.io, deislabs.io. There's a bunch of projects there. And you can read their blog, we've written several articles there about various usage of WebAssembly, also the WebAssembly system interface, which we didn't talk about much. And the component model, which is related to the Nano process that Till was mentioning about. So if you read about the Nano process, think about that. It's evolution. So that's one place, we also actually use wasmtime, a Bytecode Alliance runtime, in AKS, Azure Kubernetes Service, WASI node pool previews, so you can actually play with WebAssembly as a Kubernetes workload instead of containers if you're into that sort of thing. So those are two really, really good places.

Brad Kirby: 1:22:30

Even the Microsoft Flight Simulator runs on WebAssembly,

Ralph Squillace: 1:22:33

Even Microsoft Flight Simulator does its mods with WebAssembly.

Till Schneidereit: 1:22:37

Ralph, and I think all the contacts I have within Microsoft, were not aware of this.

Dean Nelson: 1:22:45

That's the best application.

Brad Kirby: 1:22:46

What about Blazer, what about Blazer,

Ralph Squillace: 1:22:48

blazer is an interesting thing. So if you don't know what Blazer is, Blazer is a kind of a server client programming model. It's a web server with a kind of a programmable front end. So that you know, in, you know, you can create a website or webpage that projects WebAssembly into a browser, and you can program with it, you know, using JavaScript, and so forth. So the kind of, if you're a developer, it's really easy to say you're using JavaScript in a web page with WebAssembly, very straightforward, but it's a built in programming model. So it's very, very easy to do. You don't have to wire things up yourself and so forth. And recently, that team, the Blazer team and .NET, and developer division, did a demo of the server-side running in WebAssembly, which would mean that you would have both sides running in WebAssembly. And if that's the case, for example, you could just pick up both sides and run them on pretty much anything which has not been true, up until now, which is great, fun things to see. So you mentioned earlier, the Python, the C Python compiled in we had last week Ruby was compiled in and the .NET team did a demo of what they've been Dorking around with, which is just there's lots of things happening right now. It's just truly tremendous.

James Thomason: 1:24:12

Gentlemen, it was a pleasure to have you on the podcast. Thank you so much for coming. This was a great conversation incredibly informative for me. And I'm sure the audience as well. And, folks, if you do enjoy podcasts, such as this one where we bring you the entrepreneurs and innovators and leaders of business and humanities majors who quite frankly are ushering in the next wave of technologies. Please do give us a like it does help us grow our audience. We are sponsored by Infrastructure Masons who is uniting builders of the digital age. Learn how you can participate by going on the web to imasons.org. That's

https: 1:24:46

//imasons.org, and by EDJX, who's building a new platform for all the things and yes, using WebAssembly is a deeply integrated part thereof, please do visit us on the web at

edjx.io. That's https: 1:24:54

//edjx.io.