Beyond the browser: toward a more declarative future with WebAssembly

Okay, so thank you for that introduction, so that I don't have to, go to the next slide.

Which is great.

As she's already done this bit, I'm just gonna jump right into the presentation.

And, I know this is a very controversial statement to make.

And I think, Katie covered it beautifully from the website of things.

But in general, to be really honest, how we build software today is broken.

And I'm sure everyone, wherever you're seated on the spectrum, whether you're an architect, a systems engineer, a manager, a developer, whoever you are, You agree with this.

Just count the number of production incidents you've had in the past one year, you'd probably agree with this statement.

Honestly speaking, who all in this room have been around, or were around for the heartbleed vulnerability?

Ah, that's good.

I'm not the only old person in this room.

That's really nice.

Thank you.

And who all remember the log4shell vulnerability?

Oh, yeah.

Okay.

Slightly younger crowd then.

But, I'm sure, wherever you are, in terms of age and experience, you know that when we have any sort of changes to libraries, you have to patch code, recompile them, test it, then deploy it.

And, honestly speaking, I remember when both of these vulnerabilities had actually, been, not mitigated.

When they had being announced as vulnerabilities, especially the log4shell because I remember that I got the announcement a day before Christmas, and I will not forget that because that was the worst Christmas ever.

It was in 2021.

And after that, no surprises, I left my company, but, but I remember that I had to sit up for three, four subsequent days, figure out our estate, figure out how to, make a plan for mitigating the entire, set of, vulnerability, mitigate the vulnerability on the estate that was discovered, and, I ended up looking like that, and I'm really serious.

I could that, literally was me.

And, sometimes it just doesn't have to be vulnerabilities.

It could just be changing, bit of your code.

And that might, trigger this entire process.

And it is, or it gets difficult to maintain this whole cycle over and over again.

And honestly speaking, I, I'm honestly edging towards this because I am unable to keep up with trends and technologies and tools and the amount of versions that come out every single week.

It's very astounding that, given the ecosystem that I'm in, which is open source, I say this, but we release at a very fast cadence, and honestly speaking, some of the times those changes are breaking, and they affect downstream, and at the end of it, I'm really glad that I'm not one of the consumers, because I would have had a hard time doing the whole process of patching and testing and deploying and everything else.

It doesn't necessarily have to be just, vulnerabilities, it doesn't necessarily just have to be flaws in your code, it could just be version changes that trigger that entire cycle.

But, what if this was not the only way, to, build software?

What if, there were other ways to improve the way you build software?

That is the premise of my session today.

And, hopefully by the end of this presentation, I hope to have you see my point, even if you don't completely agree with it.

So yeah, I'm not gonna, go into how JavaScript is bad, because like Katie said, it's not.

And I do need to stand here and explain to a room full of front end devs, how it's the holy trinity of front end languages and how it's the default compilation target.

Yada.

I'm sure nobody wants to hear that.

We've, been on the search of alternatives.

We all like alternatives, don't we?

I do not really like eating the same food every day, so I'm pretty sure that's the case with everyone else.

So we like alternatives in everything that we use, and we've been searching, for I wouldn't say alternatives, but yeah, other things to do that could emulate the way we work with JavaScript.

And, that's what this timeline represents.

It's only up till 2019, because after that, the unsayable, not unsayable, unmentionable thing happened, where we were all locked down for three years, not three years, three years, yeah, three years.

And, Yeah, so basically 2019, up to 2019 is where this graph is at, but of course after that also there has been significant amount of progress in both the web tech and core tech ecosystems.

But yeah, we were on the search of alternatives and as Katie mentioned in her presentation, we had ASM.JS, we had Emscripten before that, then we had the Portable Native Client Libraries.

Who remembers that by the way?

It was by Google.

Okay, great.

That's good.

Those were the predecessors of what WebAssembly came to be as a specification.

We as an industry came together collaboratively to actually announce this, because the others that are there on the graph, like Portable Native Client was by Google, got axed.

ASM.JS Was by, Firefox 20, Firefox 20, Mozilla, and, they all had their, own ways of implementing the benefits that Katie mentioned, but also they were eventually converging, they weren't conforming to a standard right from the start.

WebAssembly was announced as a specification, in 2015, and two years later, we had our MVP.

And after that, there's been a lot of progress.

Again, I only have the graph up till 2019.

I, have, and after that, there has been like a lot of competition in the market, not just in the terms of, companies that are leveraging WebAssembly, but also companies that are utilizing WebAssembly, to build newer products, like there, there's this whole, wave of serverless WebAssembly that's coming up, there's, like PaaS based on WebAssembly, so there are a lot of cool things being done in this, field.

Again, I know this has already been, said in Katie's presentation, so I'm not going to, reiterate it here.

This is basically the definition of WebAssembly if you did not know, and, that's the website where you can go and check the definition out and the specification.

And, Honestly speaking, this also was covered, so I don't need to check, I don't need to tick this box in terms of what a program looks like.

And, the fundamental unit here that I would like to mention in the WebAssembly world is a module.

And, that is what encapsulates all your program definition.

It is in the binary format, as aforementioned, and, because it's in the binary format, a module can be thought of as, a trench coat of numbers.

Because that's really what it is.

But, obviously, every programming language has its own, set of ways in how it structures things, right?

A module structure is like this, and this was drawn by me, I'm not Picard [??], so I don't even know how to draw properly, but this is essentially what a WebAssembly module broken down looks like.

But, at this point, you may ask, we're trying to build better software, right?

How does this exactly fit into building better software?

What you've just shown, feels you're trying to reinvent the wheel, by building a whole new, instruction format for all the programming languages to compile to.

And, remove the platform agnosticity, Introduce platform agnosticity.

Some might even say that, you're trying to build a new platform as a service.

But more importantly, do I actually have to give up writing whatever I know as a programming language and actually learn WebAssembly the way, it was shown earlier on?

So let's tackle that one by one.

First up, we saw how modules were numbersin trench coats, right?

Because they're numbers in trench coats, they, and they are, and by definition, web assembly is, a compilation, is designed to be a binary instruction format.

And the output of a compilation target, you do not need to know how to write it, right?

But it would be good if you are, interested, you could go and dive right in.

But you don't have to learn a new language in order to learn WebAssembly.

The whole idea behind introducing WebAssembly as a specification is so that you can write in whatever language you're comfortable in, have it compiled to WebAssembly, bring it to whichever, device you want to run it on, irrespective of the platform, OS, CPU architecture, etc.

That's the aim.

It's a lofty aim, again.

Not saying that, I say it today and it'll get done tomorrow, that's not how it works, but, that's the aim that we come with.

And, why that is important is something we've all come to recognize right now.

I don't know if any of y'all attended the keynotes yesterday, but y'all saw all the different architectures that we are moving towards.

And, if you are actually trying to run software customized to those different architectures that look nothing like the servers that we run on, it's obviously essential that you have we have something that can run natively, or at least in near native speeds on those, without actually having to, compile it to a whole different language.

Being just numbers in a trench coat, you don't really have to worry about, it, gaining malicious access to something else that it should not gain malicious access to because numbers are just numbers until you give meaning to them.

They are, they need to be endowed with capabilities and that is precisely why, WebAssembly is thought of as, something that is not really ready.

That's when, that's what I have come to realize when you, when I talk to a lot of people.

You're talking about sandbox, you're talking about all these binary things.

Is WebAssembly really ready for, higher level programming?

And, the actual programming that we do in our real life?

So we are in, there, there's like asterisks out there, but we are.

And, that is where the ecosystem of all these, specifications, runtimes, and frameworks come in.

These can all be viewed on, the official website for the technology, which is https.webassembly.org.

And, of course there are, Institutions like Bytecode Alliance and Cloud Native Computing Foundation and W3C that shepherd the maintenance and progress on these specifications, tools, and frameworks.

One of these collaborative initiatives that is being developed and stabilized is the component model.

And that's what we're going to talk about today.

It's being developed and stabilized under the WASI preview process.

And, let's dive right in.

Who here has never, ever, in their life, had leftovers after any meal?

Ever?

I'm assuming that everybody has had, at some point in their life, gotten some leftovers after their meal.

And I'm really glad that this is the case, because if not, y'all would have to stand here and answer my questions on how to cook better.

But, picture this, it's, Saturday morning and you're staring at the refrigerator trying to figure out what you can cook and that there are leftovers from, say, Friday evening or Friday morning.

At this point you have a couple of options in front of you.

First up, you actually are insane and, whip up something brand new from scratch.

I'm sure none of you good folks are in that category.

If you're allowed, please teach me patience.

Because I would never do that.

The second is, in my opinion, something very Indian that is done and that's very common in my house.

You take whatever is there and you mishmash it into something completely new.

It, the original and the, new thing doesn't match in any way whatsoever The third is what I would do personally.

I take it from the refrigerator and just heat it and eat it.

I don't go through the effort of actually making an alternative.

And the fourth, if you're completely unhinged, you will just take it out of the refrigerator and eat it.

You won't even bother with reheating the leftovers right?.

I'm going to go ahead and ask each one of what would you do because this is not who wants to be a millionaire.

But I'm guessing that most of you would either say two, three, or four, and I'm rolling with that, so that, I have an inch of self esteem left after the presentation.

That's what component model tries to do with software.

And that is why I brought up that analogy.

It enables you to, not go around in circles and implement stuff right from scratch when you already have code written in another language, for the same purpose.

It allows you to do that without incurring the full cost and operating system dependency of splitting your program into multiple processes.

How does it do that?

That is by composing your program, which will be in WebAssembly, of course, as a hierarchy of components and having each component of that program do its own thing perfectly.

Now, yeah, now you, I spoke like I, I taught component model, component, at least a few times in the past couple of, minutes.

What exactly is a component?

I'm gonna bring back our trench coat analogy, and I love tenchcoats, if you've not, understood that by now.

Bringing back our trench coat analogy, like modules were numbers in trenchcoats, a component is a bunch of modules in trench coats.

And these modules are able to talk to each other.

Now, the components that are so designed, can support high level variable types like strings, records, variants, resources, and so much more.

How do these modules actually talk to one another?

Because just a while back, I told, we are sandboxed and we don't have capabilities and all that jazz.

That is where the concept of a world comes in.

The world describes the imports and exports in a text format called WIT.

And, it may represent the execution environment of a component.

The world so defined can be abstract in the sense that they define a contract between the components.

Or an agreement, or they can be concrete, wherein they actually describe the imports as well as the, exports of the the component.

They are called worlds because, no guesses there, they actually represent the world of a component in terms of its interaction with other components.

It can be thought of as an equivalent of a component type.

And this is what I mean.

The one on the left side can be visualized or conceptualized as a component type on the right side, right?

But once a component is created, oh, you've managed to create a component.

So congrats to you without even having me told you how to do that.

But once a component is created, how do you store it and where do you store it and where do you execute it?

So for the storage and the distribution, we have component registries which are just like container registries.

So I don't know how many of you are from the server side of things, but, we have container registries out there and, content registries are very similar to that, and they are basically federated namespaces of WebAssembly components.

Now, these registries natively understand the component model specification and implement package transparency.

Now, what is package transparency?

It's, a cryptographic verifiable log of anything and everything that has happened to a component that has been stored within the registry.

So this is all great.

You create a component, you store it in a registry, but where do you use them?

You need to use them somewhere, right?

You can't just create things for the sake of it.

This is technology, and I know as much as I love the arts, we can't just create something and put it up for auction.

We have to actually be able to use them somewhere.

One of the places where they can be independently executed, like each component can be independently executed, is in a WebAssembly runtime.

Now, WebAssembly runtimes, there are a lot of them.

And your browser is one of them, by the way.

Your node server side environment is one of them.

There are a bunch of them, like WasmTime, which I think Katie demonstrated in the last bit of a presentation, and, there are a bunch of what was imagined depending on your use case.

It's like a supermarket when it comes to, WebAssembly compatible runtimes.

But what if someone in your team has actually, written something and you want to use it, in your code?

And I spoke about building better software and starting off with lofty aims, right?

How do you, promote the reusability of code, so to say, with the component model?

That is where the componentizer bit comes in.

A componentizer is essentially what takes your source code and converts it into the component.

That, of course, you can store it in your registry.

And last but not the least, there's the composer.

Now, composers are essentially, what do I, how do I explain it to you?

Let's take, let's go back to our food analogy, should I?

So when we talk about composers, remember how in the second stage I talked about, Indian families basically taking one dish and making it into something completely brand new?

That's what composers do.

They basically take your code, your component, and you can basically convert it, you can basically create a new WASM component from that existing component.

Your code, first, you can convert it into a component, and then you can create a brand new component using composers.

And what is the use of all of this?

Honestly speaking, I've gone a long time talking about component models and blah, blah, blah.

Besides the true platform and language agnosticity, I think one of the major, things that I foresee as one of the benefits of this is, it improves the reusability of the code because I come from working at major enterprises wherein we write like a lot of code, used to write a lot of code, and a lot of it was redundant, in my opinion.

That is, where I stumbled on, that is where my interest in WebAssembly actually ended up, peaking.

Because I really, I'm no, code ninja, and I come from a system side of things.

Performance doesn't really, make a difference to me because I'm like, it should not affect my CPU, it should not affect my memory because I will have to, I'll have other app owners to complain to.

But, reusability of, code is something that is very, close to my heart because systems, from a systems perspective, I think that the easier the code, is to maintain, the easier it is for people to access them, the easier the workflows are.

Now, I know all of this is, really high fondue and, it might not really make, a lot of sense right now, but I promise, I'm going to actually demo some of it.

So first up, what I'm going to do is I will quickly componentize a very basic app.

Like I said, I'm not a developer, a full fledged developer like most of y'all in the room.

I've, I'm self taught at best.

Yeah, so I'm going to demo a very simple, hello, whatever app.

And then I will, make, that com I will compile it.

I will trsnspile it into, transpile the WASM Component into, a JS file again, so that, we can run it in the NodeJS runtime again.

And, I actually, sorry, I actually wanted to also push it to the WebAssembly registry, but I don't think the time constraints allow for that.

I'm just gonna start off with the demo here.

Let me just, hopefully I'm clicking the right stuff.

This is the, very simple JavaScript file, please don't expect a lot.

And, what, what I wanted to draw particular attention to is the, WIT file that describes the world that we talked about before, right?

This is that WIT file wherein it describes the world that our component will be, occupying in the best way and this is the componentize.mjs file wherein we call on the API that is componentize.js which is the componentizer.

It's a Bytecode Alliance project and it's very much still under progress.

There is, there are others for Python and a few other languages, if I'm not wrong, that is in the works.

And, here we take the JS file that we have written, which is a basic Hello World app, and, the WIT file which describes the world, and, we are going to have the output, as, hello_component.wasm.

So this will be a wasm file.

It'll unfortunately not be readable to us because we haven't turned into machines yet.

So, here, what I'm gonna do is, first up, I So if you see here, the, there's this wasm file, obviously that it's not, it is unsupported in terms of the content.

And, once you have this, for the sake of speed, I'm just gonna copy off, the command, because I realize that a lot of people have come here for the next session.

So what, this is, what this does is, this is, jco, which is, a project, again, under the Bytecode Alliance, and this essentially transpiles the, component.wasm into, a JavaScript file that can basically run all the, that it'll, basically output a hello folder with, different, JavaScript files and TS files.

And that will be, that we'll be able to run on the server.

So if you see, these files are generated and, here, So here, I'm just gonna, I'm just gonna change up stuff a bit because I'm bored.

Because I was supposed to do this in the morning, then I slept off.

That's the jet, that's, that, that is the jet lag and, unfortunately doesn't really sit well with me.

So yeah.

I'm not even sure anything is clicking at this point.

This is what happens when I try to reinvent the wheel.

Huh.

So we have this.

And, [applause] thank you.

That was a lot of effort with a lot of errors.

But essentially what we've just done is we've componentized a JavaScript file.

And this component can now be pushed into a WebAssembly registry, like warg.

Warg is another project under the Bytecode Alliance.

You can just pull and push content from warg.

If you've ever worked with containers, it's very similar to container images.

Although I'm, although the implementations obviously vary.

And, yeah, I think that's the end of my presentation here.

These are the resources.

Okay, I'm just gonna, so that you don't have to read the text.

Yeah, these are the resources that I'm gonna leave you with.

The Bytecode Alliance is one of them.

There's CNCF, which is cncf.io.

You can see the component model specification here, and you can see the WebAssembly specification on that website as well.

But yeah, that's about it.

Thank you so much for having the patience to sit through this, I really, appreciate it after the heavy lunch that y'all might have had, and, yeah.

Thank you so much.