Ben Taylor joins the show today to share his recent developments about integrating Ruby snippets within a browser in less than a day.  The panel asks about his process and what he did to make this a quick and successful strategy.  Learn about this new process and what you can do today to make this happen!

Hey everybody and welcome back to another episode of the RubyRogues Podcast. This week on our panel we have Dave Kimura.

 

Everyone

 

I'm Charles Maxwood from Top End Devs. Wanted to give a quick shout out about Rails Remote Conf. Just go to railsremoteconf.com. I'll make sure that link's through to the right place. We also have a special guest this week and that's Ben Taylor. Ben, do you want to say hello and introduce yourself?

 

G'day, how you going? I'm Ben, software engineer from Australia. Mostly work in education software. But today I'll be talking about WebAssembly.

 

Yeah, that ought to be fun. Maybe we'll have you on JavaScript Jabber too. We haven't talked about WebAssembly for a while. But to kind of kick this off, you wrote an article on Dev2 that walks through how to run Ruby snippets in your browser.

 

Yeah.

 

And that was interesting. So I'm curious, yeah, what did you do?

 

Yeah, that's a good question. What did I do? So I'm pretty interested in education and particularly programming education. And so I've been looking at different ways to get code running in the browser for like 10 years. And a long time ago, we had M scripting, which was a technique for compiling programs

 

Mm-hmm.

 

And more recently, we've got a technique called WebAssembly. And the tooling for WebAssembly is just getting better and better every year. And like a start of this year, a person called Katei made a bunch of changes to Ruby, to see Ruby, that were part of a bigger mission to get Ruby running in WebAssembly. and I was thinking about how could I get Ruby running in WebAssembly and I went and had a look and it turned out that all those changes had been merged. And this was around January of this year. And I had a look and Ruby ran in WebAssembly and the toolkit that I was using, which is called, it's from a group, The tool is called WebAssembly.sh. It's a tool I'm basing my stuff off. But the program I use is called the WebAssembly Package Manager. And it allows you

 

Mm-hmm.

 

to install WebAssembly binaries as packages really easily. And Katay had put Ruby on the WebAssembly Package Manager. And that meant that my program, which is called runo, could just run it. And so I just installed it and ran it. it ran client-side in the browser. It was like a few hours of work in total for me, but all the backing was there from a bunch of other people.

 

Nice. So I kinda wanna just walk through this a little bit. I mean, I read your article, but it was pretty short.

 

Yeah, really short.

 

But yeah, so effectively, well, let's start with how this all works, right?

 

Yep.

 

So Ruby, I guess, compiles to WebAssembly?

 

Yeah.

 

Is it the VM that actually compiles to WebAssembly?

 

So it's a bit hard to understand. There's this standard that is pretty new. It's a web standard, and it's called Web Assembly System Interface, WAZI. And

 

Okay.

 

you can kind of think of that

 

you

 

as like Linux. So when you're compiling Ruby, it compiles to a bunch of different targets. So like you get binary for Ruby for Mac OS, for Linux, you get one for Windows.

 

Mm.

 

And then Wazzy is a different target that is kind of like one of those. But instead of being an operating system, it's just kind of like a fake API. And that API defines some really simple stuff like how to access files. And when you run that WebAssembly binary, you have to provide those function calls. So you, as a consumer of the binary, the binary can't do anything until you let it access files or until you let it access sockets and things like this. And so that's the way that Ruby is able to compile to WebAssembly. It has this kind of like operating system emulation layer.

 

Okay, so what would be some of the actual use cases of having a Ruby based in the browser? So WebAssembly or anything like that. You know, what is that going to give us that we do not currently have with server rendered HTML and client-side JavaScript and that kind of stuff?

 

Frontend on rails, right?

 

Ha ha ha.

 

Yeah, it's a good question. And front-end on Rails, maybe that's the future. There's a lot of weight in it as well. The Ruby binary is like 11 meg GZIPT. And so if we were to serve our front-end on Rails, it'd be a bit of a nightmare, much worse than serving React. You'd have to serve that Ruby binary and then also serve all of your Ruby code. The

 

Nothing's

 

use case

 

worth it than serving React, right Dave?

 

Ha ha.

 

for a user of the Ruby binary, a web browser use case is not particularly compelling. For me, what I find useful is I can use it for education purposes.

 

Right.

 

So I can run Ruby in the browser. student's code is working, I can get them to run their code, and that requires no installation. So that's a really cool use case. But that's not really the use case that people were imagining when they were inventing this stuff like Wazzy. One of the really interesting parts of Wazzy is that it's fully portable. So if you think about like a Linux binary of Ruby, that can only be run on Linux, or a Mac OS binary can only be run on OS. A WASI binary can be run on any system that implements the WASI API. And this is kind of a really neat idea because it means that if there's a new CPU architecture out there, they just need to implement the WASI API and then they're able to run binaries. So when the M1 came out, there were all these problems because people couldn't get compiled favorite programming languages or libraries. And if they're in WebAssembly, then they can just run by default. And they don't have to be compiled to your particular target. And this can be very useful for server-side situations rather than just client-side web browser stuff.

 

I gotcha.

 

Yeah.

 

You know, I did say there's nothing worse than loading React, but this feels a little bit like Java.

 

Hehehe

 

Yeah, it does feel a little bit like Java. This was the dream of the Java VM.

 

Mm-hmm.

 

But the Java approach never really took off. And what we're seeing with WebAssembly is because it's web standard as a target, it kind of is a lot more compelling than the Java virtual machine.

 

Yeah, I can see this having some, you know, not necessarily the Ruby aspect, just WebAssembly in general, having some real world applications outside of running your Ruby interpreter or that kind of stuff. But anything that requires like actual hardware processing power that you are wanting to take off of the server just because of the latency on the server generating or calculating and then sending back to the user. But if the user had a more powerful machine, then you would have a lot more capability. So any kind of like

 

Mm.

 

AutoCAD work, if Autodesk or somebody made a online AutoCAD version that could really take power or make use of 3D rendering and that kind of stuff, then I can see WebAssembly having some really powerful use cases and stuff. web development and Ruby aspect side of things. I mean, maybe there will be some better machine learning libraries that get integrated with the web assembly down the road.

 

Yeah, so in terms of client side, I worked with someone who used to call client side free compute, which I really like as an idea. It's being able to run Ruby in the browser, I think, is kind of interesting. It means that if you've got some library that you're super dependent on that only exists in Ruby, you can chuck it up there, and you can have it running client side. And that might be useful to you. the WebAssembly binaries with this WSZ standard is interesting beyond that. You've got stuff like Cloudflare workers can now work with Ruby. Previously they couldn't. Fastly has a similar worker standard. These are different ways to run programs, not just at a server level, but like at the edge of a CDN network. And a lot of these use WebAssembly as a way to run code. WebAssembly. Now you can use Ruby for that. And I think that's really interesting.

 

So, but you still have to take the hit on the package size, correct?

 

So what I mean is this is server-side Ruby running on the edge. So

 

Uh-huh.

 

edge networks are like CDN networks. And

 

Right.

 

so you've got a server running, say, I live in Melbourne. Most web servers are in the US. That's like a 200, 300 millisecond latency, but

 

Right.

 

a CDN network, the edge might be a few blocks from me. And so suddenly you're bringing that latency right down milliseconds.

 

Right. But with this approach, you're basically trading off the latency for the package size and the bandwidth usage.

 

No, what I mean is literally the Ruby would be running server side, but it's using Web Assembly to run it.

 

Oh, okay.

 

Yeah, so because Web Assembly is portable, it's way easier to run. And a lot of these CDN edge networks run Web Assembly rather than running real

 

Oh, okay.

 

binaries. Yeah, does that make sense?

 

Yeah, that makes sense. That was not a connection my brain was making. So that makes sense.

 

Yeah, so Ruby running in WebAssembly means we now have this new use case. Like we can run Ruby on edge networks. There's also like people talk about it. It's not particularly interesting to me, but a lot of cryptocurrencies use WebAssembly as a standard for running code. This means if you're willing to package, you know, the 11 meg Ruby binary in your cryptocurrency, I don't really understand how that works. blockchain thingy. Thanks for watching!

 

I mean, that's so cool!

 

I'm sorry.

 

Blockchain! Haha.

 

Yeah, so I don't really understand that use case, but it is there. Another thing I think about is like, sometimes you'll be installing a package and that package will install another package and that package will install another package. And then you're watching

 

Mm-hmm.

 

your package manager compiling Python for some reason. And you're like, why is this happening to me? If all of those steps were using WebAssembly, your binary wouldn't have to be built. It's just already there. already built to WebAssembly and that could run on your machine like on your laptop.

 

that makes sense. So we're talking portability. I kind of imagined WebAssembly being something that, hey, you know, I'm just going to stick this on the web page and it's going to magic some Ruby up on the browser, right?

 

Mm-hmm.

 

So is that not something you can do then?

 

Yeah, so absolutely you can do that. I got a bit distracted by portability. I think the portability story is really interesting. But yeah, absolutely. You can

 

Right.

 

run Ruby in the web browser. The new Try Ruby page, which is try.ruby-lang.org, has the real CRuby, CRuby 3.2 running on it, which is pretty cool. So you can try Ruby

 

That

 

and

 

is

 

it's

 

cool.

 

real Ruby. It's not some custom Ruby that's been built for the browser. It's the real Ruby binary. And that also means that as Ruby gets updated, those WebAssembly compilation versions of Ruby will also get updated. And so we'll see web browser as a target for Ruby being updated as frequently as any other operating system.

 

Peace.

 

Yeah, so you don't quite do it with the HTML. You do it with a JavaScript API, but it's basically like that. You can instantiate the WebAssembly runtime with a URL. You let it boot up and then it provides a bunch of exports and you provide a bunch of imports. And so the exports that the binary provides, you can call into and the imports that the binary requires to provide information to the binary. So you can think about it kind of like a WebAssembly binary can't do anything unless you provide it with the imports or unless you use those exports. The binary is kind of by default sandboxed.

 

Yeah, and my understanding of WebAssembly is that it's not directly interchangeable with JavaScript. So, you know, you kind of have to... They do interplay. You can call one from the other and vice versa, but it's, yeah, it's not like a direct, hey, these are all running on the same VM because it turns out that the WebAssembly VM and the JavaScript VM are separate and JavaScript actually can't compile the WebAssembly.

 

Yeah,

 

So...

 

it's like it's a bit of a like that boundary can be a bit rough,

 

Yeah.

 

because you're running you're running system binaries. Stuff like strings is tricky. Like you would think that passing a string to some library would be easy mode. But strings have to exist in memory, and they have to be encoded in some format. The

 

Mm-hmm.

 

JavaScript default is to encode in UTF 16, which And so you've got kind of like, you've got your JavaScript stuff and you've got your WebAssembly stuff and then the boundary can be a bit tricky.

 

Yeah. We've talked a little bit about this on JavaScript Java. I'll see if I can link some of the relevant episodes into the show notes. But yeah, so I'm a little curious too what this means for things like Opal, right? Cause Opal kind of, it was kind of a halfway measure that compiled the JavaScript.

 

Yeah, so there's lots of other strategies for running Ruby on the web. And some of these strategies are much more appropriate for the web. Like I said before, this huge page weight of a WebAssembly binary, Ruby is big, like 11 meg,

 

Mm-hmm.

 

is going to be slow. If what you need is compatibility with real Ruby, That's exactly what I want. I want real Ruby running in the browser. I don't want people to learn some kind of slightly different Ruby. Then you're going to take that hit. But if you don't really care about how your Ruby runtime works, and if it could be a bit different to real standard Ruby, then something like Opal is still going to work for you.

 

that makes sense. And it has all the support for things like web sockets and stuff like that. So if I did want to load it into the page, right,

 

Yeah.

 

it could.

 

You

 

Yeah.

 

mean Opal or you mean Ruby

 

Ruby.

 

running in Wazzy?

 

Yeah.

 

Yeah, well, so if you run Ruby and Wazzy in Wasm, like in WebAssembly, you kind of get nothing by default. So the WebAssembly system interface doesn't provide much more than files and sockets. And so if you wanted to have Ruby connect to the internet via your WebAssembly runtime, have to implement files and sockets, which would be a bit of a nightmare.

 

Okay.

 

Yeah. So it's a bit of a niche use case, but once it's implemented once, you can run any programming language. So my website, Rano, it's a tool for teaching programming languages, currently supports SQL. And the way it works is that I implement that WASI interface once, and then I can run any of these programming language binaries. So adding Ruby to it was really easy because

 

Mm-hmm.

 

Ruby supports the WebAssembly system interface now.

 

I want to argue about SQL being a programming language, but I would

 

Hahaha!

 

lose, so...

 

Hahaha!

 

No, that makes sense. That's really interesting. So, and you said this runs on kind of edge systems that are out there on CDNs. Do all the CDNs support this? Are there certain ones that you found that work?

 

Yeah, so probably for WebAssembly, I think Fastly is the one that's the most into WebAssembly, and they do things the most WebAssembly way. Cloudflare,

 

Right.

 

I think they prefer it to be a JavaScript runtime rather than a WebAssembly binary, but maybe that's changing. So I know with Cloudflare, a lot of the time, they run other programming languages by having those programming JavaScript, which is a bit tricky. And then you end up with these edge cases where the JavaScript doesn't quite implement things exactly the same as the way Ruby does. And you kind of have to write Ruby as if it's JavaScript.

 

Right. I'm just trying to think through what the implications for this are. One thing that I'm wondering about too though is with the page size and things like that,

 

Hmm.

 

do we foresee Ruby ever implementing some kind of optimization that way or maybe the build tools for Wasi Wasm implementing some kind of optimization that way?

 

Yeah, and that might be a strategy for reducing the size of these binaries. People also talk about having a garbage collector built into WebAssembly. And so then Ruby wouldn't need to package its own garbage collector with it. That might bring the weight of the binary down.

 

Mm-hmm.

 

It's hard to tell how much of the binary size is necessary and how much of it is optional packages. of tree shaking out a bunch of stuff from Ruby,

 

I was gonna

 

you know?

 

ask that next,

 

Yeah.

 

yeah.

 

So it's, yeah, it's hard to know like how small we could get Ruby. There's like, Ruby's an old piece of software now. There's a lot in there and maybe it doesn't need to be as big as it is.

 

What does the performance on this look like? If I'm running Wazii, on the browser end, I don't know what I would expect, but if I was going to run this versus a compiled C version on my Linux or Mac distribution, how do they compare?

 

There's definitely a performance overhead. The intention of WebAssembly is to be very low level, but it's an emulator effectively. And there's not a one-to-one correspondence between the WebAssembly. calls and the calls that you would have on your CPU. And so about 20 to 30% performance hit anytime you're running something in WebAssembly.

 

you So you wouldn't run your Rails app on it, you would use it for other things.

 

Yeah, absolutely. There's interesting stuff with WebAssembly. I was talking about portability and security is another really interesting part of this story. With a WebAssembly binary, you provide it with what functions it can do. And so if you have a situation where security is very important, to data that you want to keep secure, and you have external dependencies that you need to run. If you run them in WebAssembly, you can guarantee that those external dependencies don't get access to anything you haven't given them access to.

 

Oh, interesting.

 

And

 

Okay.

 

you could guarantee that kind of like at the, at the binary level, like where you're running the binary, rather than having to guarantee it at kind of like a system level by using something like Docker. So that's not so much a use case for compiling something with Ruby to WebAssembly, but rather running WebAssembly from Ruby. So you might, let's say, you know, ImageMagic was a huge issue years and years ago. Everyone had to run ImageMagic on their server and ImageMagic is a binary piece of software. It would crash all the time. it had a bunch of other issues. Running that with WebAssembly instead of running the direct binary would mean you'd have a lot more control over what it was doing.

 

So when you have this set up on Runno and you've installed it to Runno. You're running it on your CDN, correct?

 

So yeah, so the CDN use case is kind of more like, I think something that's interesting. It's not something I'm using.

 

Oh,

 

So

 

okay.

 

yeah, so runo, the way it works is I've got a WebAssembly, like a Wazze layer, and then I've got a terminal emulator, and that terminal emulator connects to the Wazze layer. And then

 

Okay.

 

behind the Wazze layer, I've got the WebAssembly binary for a programming language. And so, runo loads up, you've got a program in there in Ruby, you click run, runo then downloads the Ruby binary and starts Ruby running on your browser and

 

Okay.

 

then it runs the code using that emulator.

 

Makes sense.

 

I think the thing that's really interesting about Runno that I kind of designed it for is this idea of running snippets of programming language on any website.

 

Mm-hmm.

 

So Runno runs client side, and that means that you don't have to run a server that runs other

 

Right.

 

people's code. And so if you're writing an education platform, or if you're just writing blog posts, you can embed Ruby snippets in those blog posts. using Ronno. And I've got two strategies for embedding, one with iframes and the other using a node package.

 

Gotcha. How do you account for things like Ruby gems then?

 

Yeah, that's the big question. So currently, runo can't do Ruby gems. Technically, it's possible. Ruby gems just exist on the file system and Ruby loads them up when it's running. So I could download those Ruby gems and then put them on the file system. But then if the Ruby gems have any dependencies that aren't just Ruby, then I'm going to have to

 

I

 

figure

 

gotcha.

 

out a way to run those It's a like that's where kind of like the iceberg is with running stuff in the browser

 

Mm-hmm.

 

is like that whole network of every other thing that you know your program depends on. But I think there's some like interesting use cases for this also around stuff like documentation. I would love to see runnable snippets inside documentation. Yeah.

 

Yeah, that would be amazing. But yeah, I can imagine some of the utility gems that we have out there. Yeah, no problem. But then you pull in like NockleGuri that has to compile against the C library.

 

Yeah. And what's interesting there is I'm actually, I'm running C in the browser, because someone, I forget their name, figured out a way to compile LLVM to WebAssembly. And so my C runner takes LLVM, it compiles, it takes the compiled LLVM, which is compiled to WebAssembly,

 

Mm-hmm.

 

binary, that WebAssembly binary then running in the browser compiles that C code to WebAssembly, and then I run that C code. So it's like this multi-layered WebAssembly series of actions. But what that means is that something like NoKogiri, which needs to be compiled, could technically compile in the browser using LLVM, which is wild.

 

Interesting. Trying to think through the implications there.

 

I think the power here is that as we keep adding to WebAssembly, you're going to see your full stack eventually just be able to run in the browser. And it's not going to be some trick where it's a x86 emulator or something

 

Mm-hmm.

 

running a virtual machine. It'll really be running in the browser.

 

Right. Oh yeah, that could be interesting too, right? Where you have the target for like a Nokogiri target that doesn't require

 

Mm.

 

the C library and instead

 

Yeah.

 

runs on the web assembly. Sorry, I cut you off Dave.

 

Yeah, so the story with WebAssembly is that the binary can only do what you give it access to. So like the binary can only access functions that you give to the binary. So if you think about like a normal Ruby program that you run on your web server, you've got a Rails server, you install a gem. If that gem decides it wants to access the internet, it probably can. You can't really do much about it. goes and does it. With WebAssembly, you tell each binary that you run what it's allowed to access by providing it functions that it calls. So, if you installed a... In an imaginary world where you can compile gems to WebAssembly, if you called a WebAssembly gem and you didn't provide it with internet access, it wouldn't be able to access the internet. But if you had compiled your whole and then you went and supplied that WebAssembly binary with access to your database, it's gonna be able to access your database. And so there is still that idea that you can always shoot your own foot and tools are trying to make that harder and harder over time, but you still tend to be able to. Yeah, so if you're compiling, let's say you're compiling keys to your AWS or whatever into a WebAssembly binary and then serving that binary to your users, it's the same as if you were putting it in your JavaScript and serving that JavaScript to your users. Like that key is there.

 

Mm-hmm.

 

It's just a bit harder to read.

 

Yeah, but the flip side is that there are systems out there that seem to have robust security that do some of this stuff like Firebase and things like

 

Mm-hmm.

 

that. So those kinds of security exist, but it may not exist in the same way that we do from like our Rails server to our database server since there's nothing that's kinda, you know, sitting in between, you know, the front end in the way that the Rails server does.

 

Yeah, so like, you've got the same security problems that you've always had. And this is like an extra tool that you can reach for. Especially if you have, say, binaries or programming language tools that you don't trust. You could use WebAssembly to run those. This would be extremely useful if say, you wanted to implement your own serverless run So like, let's say you've decided you're going to invent new Heroku, but you're doing it serverless. And you want to write it all in Ruby, you could reach for WebAssembly as a tool for running customers code.

 

Right, that makes sense. But on the other end, yeah, you're going to handle your security the way that we handle security in the browser, not the way you're going to handle it on a provision server or provision Docker container or something.

 

Yeah, yeah, you would probably end up with both those layers. The kind of neat thing is Docker is Docker as a like, system is providing a whole emulated computer.

 

Mm-hmm.

 

It's a whole computer in there, you know,

 

Right.

 

like, which is just it's quite strange as an idea, like we run our, you know, tiny little web server, but to entire computer.

 

Right, I'm gonna run my server on my server.

 

Yeah, absolutely. And what WebAssembly is targeting instead is just the binary runtime,

 

Right.

 

not the whole computer. And so if you think of it as a kind of like attack surface, the attack surface for WebAssembly is very small, whereas

 

Right.

 

for a Docker container, it's quite large because it's a whole computer.

 

I'm just waiting for popular websites like YouTube or something to make a Bitcoin mining WebAssembly package

 

Hehehehe.

 

that'll just start mining Bitcoins on your computer.

 

Yeah, that's the danger with WebAssembly. People have been talking about this for ages. As soon as people were able to compile stuff like Bitcoin miners to web browsers, people were using it to dodgily make money out of their users. Something that's actually interesting, you mentioned YouTube. There's a neat use case of WebAssembly where you encode images or video on the client side So encoding images or encoding video is like a really expensive task. And it's expensive if you have to do it on your server. But why not get the client to do it before they send their file to you? And then

 

Mm-hmm.

 

you get a saving in two ways. You don't have to do the computation. And then it's also smaller over the wire. And so I forget which software it is. One of the forum software's they now compress your images with WebAssembly before they send it to the server. And so the user puts their image into upload, and instead of uploading the raw image file, we re-encode the image file, compress it, and then upload it, saving you a bit of bandwidth.

 

Yeah, I don't know if it would really say bandwidth if you are doing adaptive bit rate streaming, meaning that you have to do several different transcoding for a 4K video to 1080p, 720p, and stuff. So you're still going to be sitting a lot. But definitely on the server side, reducing that computation size, especially on something in the scale of YouTube would be really amazing. You know,

 

Yeah.

 

for YouTube at least, because then they're going to be able to do a lot more without the additional infrastructure. Because

 

Yes.

 

having done the video transcoding on the server side before, it's really taxing. Especially if you're a smaller shopper, you want to do video uploads to your transcoding, it can really mess with your systems a bit. Especially when things start to auto scale because you uploaded a new video, and then you're like, but I don't need it to auto scale because of traffic right now.

 

Hmm

 

But if I were to take care of all that on the client side without having to know the ins and outs of what video transcoding is, then

 

Hmm.

 

that could be a real use case. That's really interesting. Of course, I guess that's a good point. I mean, I think that's

 

Yeah,

 

a good point. I think that's a good point.

 

what's the Linux package for doing transcoding of video?

 

FFMPEG

 

Yeah,

 

Mm-hmm.

 

FFmpeg. FFmpeg

 

Yeah.

 

has been compiled to WebAssembly. And so,

 

Oh really?

 

yeah, so you can run FFmpeg in the browser. So if you were doing this, if you were creating your own video website, and you were using, and you wanted to not have to transcode the video use FFmpeg from the front end and compress that video before it comes to your server.

 

Oh now that is awesome.

 

Yeah, that sounds

 

Well,

 

really

 

I know

 

nice.

 

what I'm doing tonight.

 

Yeah, and these sorts of like people are doing all of this kind of stuff, getting as many different libraries as possible, compiling to WebAssembly. And the more and more of this stuff we can run in a portable way, the more we can run it on the front end. But it also means we can run it on the back end in a more reliable way using WebAssembly

 

Right.

 

rather than having to compile that binary yourself.

 

Yeah, and just thinking like PDF conversions and stuff before you have to do most of that on the server side. If you're not using a package like Prawn where it kind of re-implements everything,

 

Hmm.

 

if you're using Wicked PDF which uses WK HTML to PDF under the hood,

 

Hmm.

 

you had to have that binary installed on the server. But if you could get a WebAssembly package for that, you just pass the HTML to that WebAssembly component,

 

Mm-hmm.

 

or just downloads it because it's

 

Hmm.

 

already generated on the client side, that would save the hassle of having to change your Docker infrastructure, bring in these extra packages just for that functionality.

 

Yeah, is WK to HTML, is that reading WebKit? Yeah, I think I think that there used to be this technique of doing PDFs where you would run web kit to generate the PDF, which is funny because then you'd be running a web browser in your web browser to generate a PDF.

 

Yeah, it wouldn't shock me. I think most PDFs when you break them down are XML files. or have some XML component do them.

 

It's a funny world and probably you're going to end up in this world where we're running web browsers in our web browsers so that someone can do some arcane magic. It's kind of cool.

 

Yeah, well running web browsers in your apps is a thing that's been done for a long, long time where effectively you embed some kind of web view and then you run a local web server to serve up the information for that. I know that several mobile apps do that

 

Hmm.

 

on iOS and others work in similar ways. And then you've got like the Ionix and stuff that actually the whole app is in a web view.

 

Uh huh, yeah.

 

Anyway.

 

Yeah.

 

Yeah. Mm-hmm. Yep.

 

Hmm. And to bring this back to WebAssembly, if you are doing those sorts of techniques, hybrid techniques, and you want to use some system binary, if that system binary is compiled to WebAssembly, you can just do that from a WebView.

 

Ooh, that's interesting. So there's been a lot of talk, and I don't know if you know the answer to this question, but a couple things connected in my head. So there are a lot of things that you are restricted from effectively uploading to your iOS apps, right? You can't just put anything you want in your iOS app. So if I need a compiled binary for a particular thing that I want to do on the iOS app, that already exists or write it

 

Mm-hmm.

 

myself. And what I'm wondering is, is if I can get those libraries in some kind of WebAssembly API, then it just depends on the browser engine on iOS, which is Safari. Do you know if Safari

 

Hmm.

 

actually supports that kind of a thing? Like

 

Yeah, so

 

what's the mobile

 

Safari,

 

support for Wasm?

 

Safari will run WebAssembly. My website, Runo, runs on iOS on Safari. So if you wanted to run Ruby inside your iOS app, you could do that via a WebView and the WebAssembly compiled version of Ruby.

 

I'm gonna make Tim Cook cry.

 

Hahaha!

 

Anyway, yeah, that's really cool because it opens up some of these other possibilities where maybe not Ruby, but maybe a C library or something that compiles to Wasm

 

Hmm.

 

or FFmpeg or something else, right? Where it's like, okay, I'm going to pull in the FFmpeg package and I'm going to do the FFmpeg stuff on the phone, right?

 

Yeah, and it's also got a really interesting story with web applications that you might download and save on your phone. So if you've got a web application and it uses

 

Hehehe

 

WebAssembly to run some system calls, if you're saving that application to your phone and it saves all those resources locally so they can be run offline, you can do a kind of a native-like app experience that was all running in the web browser.

 

Yeah, we're getting into progressive web app

 

Yep.

 

area

 

Yeah.

 

here. But yeah, also interesting.

 

Yeah, absolutely.

 

Cool, so what's kind of the next stage for this technology as far as our capability of running Ruby on your browser?

 

So for me, for runo, I think what I'd love to get to is being able to run Ruby gems in the browser. I think a lot of people would love, from a learning and education point of view, would love to be able to run Ruby snippets wherever they want.

 

Right.

 

If you could have on your blog any little piece of Ruby that you've written, if you could run that just in the browser on your blog, that'd be great for running demos. I think a lot of people would find that really useful. That's kind of, that's the next step that I want to get to with Rhino.

 

Yeah, for that documentation end too, right? It's, hey, here's

 

Yeah.

 

Ruby with my library or my gem or whatever installed. You know, here you can play with it, right? Without me having to go and actually kind of rewrite it in Wasm or whatever.

 

Yeah, and that documentation example, I think is really interesting because if you have documentation that is kind of hard to understand, often you have to get it all running on your system to try it out. And that's something that's really great about Ruby. It's very easy to open up IRB or open up a debugger and get things running. But if it was just there and you could edit the arguments to a function and see what the output was, that'd be so much easier. it'd be so much easier to find exactly the method or function call that you needed.

 

Yep. I'm also imagining a CI-CD that runs on my tests in the browser.

 

Yeah, totally plausible. GitHub is trying out all this stuff with running VS code in the browser. And I think we'll probably see more and more of your app able to run in the browser. So eventually you might just open up your GitHub repo, click edit, edit your file. It runs your tests and you commit it right there development environment.

 

Yeah, I'm assuming that they've compiled Git to WebAssembly, so.

 

I have no idea. Probably. It would be relatively easy to.

 

So from there, yeah, you know, if you have a Git repo and you want to interact with the code in the repo. Yeah,

 

Yay.

 

I'm just seeing a whole bunch of things open up here, right?

 

Yeah,

 

Just depending

 

it's-

 

on what you can do with local storage.

 

Yeah, I think it's that portable portability story. Uh, it seems kind of like, oh, cool. You can run stuff in other places. Um, but then once you start like thinking that through and thinking about all the use cases, like it actually like creates this wild combination of ideas, not just

 

Mm-hmm.

 

like this one new thing, it's the new things combined together to enable stuff that you never thought of before.

 

Yep. Makes sense. Dave, was there anything else you wanted to bring up? I know, right? Mind blown.

 

Hehehehe

 

I- Yeah, I've seen some things that look a whole lot like, I think there's a version of Photoshop or something like it that runs in the browsers. You can do all kinds of, you know, I know Canva does it, but Canva does it, I think through JavaScript, but.

 

So Figma, have you used Figma before? It's really popular

 

Yeah.

 

for designers. Figma's all written in WebAssembly.

 

There you

 

So

 

go.

 

Figma's written in C++ and then compiled to WebAssembly. And that's a full, more like a Illustrator than a Photoshop, but it's

 

Mm-hmm.

 

there in the browser.

 

Yeah, I guess I'm imagining then, you know, those kinds of tools also being able to be opened up, right? Where you could

 

Mmm.

 

actually, there's one for podcasting too, I'm trying to remember what it's called, but there's an audio editor that you edit in your browser. And I always wondered, oh, is it talking to some backend and saying, you know, snip here, snip here, this, that and the other. But yeah, I wonder if it's written in WebAssembly and, you know, just manages the audio file in memory in local storage on your, or, you know, or not even in memory on the file system storage

 

Mm.

 

on your browser and then as you go it you know uploads the version that you're working with.

 

Yeah, very well could be, yeah.

 

Cool, just all kinds of neat stuff that you could go do with this stuff.

 

Yeah, absolutely. And I think the story is, you know, we've been talking a lot about the browser. I think the story is just as compelling on the backend with Ruby.

 

Right.

 

You can use WebAssembly from Ruby. You can call out to these WebAssembly binaries from Ruby and you could have the same binary running client side and server side and have that, you know, no knowledge that it's gonna execute the exact same at both places.

 

Nice. All right, well, let's just leave it there.

 

Mm-hmm.

 

Hopefully we melted some brains here. Let's do some picks.

 

Absolutely.

 

Dave, do you wanna start us off with picks? Nice. I know I have two linear actuators in my standing desk. So is that a standing TV? very cool. Now I want one. I don't need one. Maybe I can convince my wife I need one. Anyway.

 

I love the idea of hiding a TV somewhere in your furniture, you know, and then having it just like pop out from nowhere.

 

Yeah, I've seen them built into bed like the footboard of your bed. And so, you know, the little door opens up and it comes up out of the. And those are pretty cool, right? It's like, OK, we're going to put the TV away now.

 

Yeah

 

I've also seen them where they drop down out of the ceiling on a linear

 

Oh, that's

 

actuator.

 

cool. Yeah, because TVs can be kind of ugly. I mean, nowadays they're pretty good, but like you got a big TV in your room, it takes up a lot of space. If you could hide that, that's cool.

 

Yeah, I mean, you know, we have one in our bedroom and it's just mounted on the wall. But

 

Yeah.

 

yeah, you know, if you want to put other things on your wall or you don't have the kind of wall space you need or want for that computer or computer for that TV. Yeah, I can kind of see that. I'm going to throw out some more picks. My first pick, I always pick a game. And the game that I'm going to pick is and this is something so because we went on a road trip with my wife and kids. But this game is Fantastic Beasts. What was it? Perilous Pursuit. And it's a cooperative game, which isn't always my most favoritest kind of game, because a lot of times those... The cooperative games, sometimes you all kind of work together and sometimes you play a four-player cooperative game where three of you are watching one person play the game. And anyway, this one I could see kind of going that way, but for the most part, it was fun and there was plenty of interaction and we were just kind of having a low-key game night. But Fantastic Beasts, you can imagine it's from the Harry Potter movie series, right?

 

Mm.

 

You're all working together to capture all of the beasts that came out of Newt Scamander's case. You each play one of the characters from the movie. You have different abilities basically. Everybody has the same abilities, but each of you have different capabilities within that ability. You may be better at distracting the beast than at capturing it.

 

Hmm.

 

And so what you do is you roll dice and then you stack the dice to activate the abilities and then use those abilities to capture the beasts. And it's relatively simple. Board Game Geek weights it at 1.83. A 1 is a really simple game and a 2 is kind of a casual gamer game. So, you know, yeah, everybody could kind of sit and play it. And yeah, I could kind of see kids at that age being able to pick the game up. So anyway, it's kind of a fun one if you're into Harry Potter and you want kind of a different game mechanics. Like some of the elements reminded me vaguely of some other game elements in other games, which is pretty common if you play a lot of board games.

 

Mm-hmm.

 

But there were a few ways that it went together that was kind of unique. And so it was kind of fun to sit down and figure it out. really have about the game is that I don't see how you could basically not win it every time.

 

Hahaha.

 

So, and that was just my experience, and maybe there's a way to make it harder, but anyway. So yeah, but it was fun, and it was fun to just sit around and, yeah,

 

Yeah, I really

 

anyway.

 

like those sorts of cooperative board games. It sounds like it's not your favorite when you're working together, but some of them, it's like actually really exciting when you lose because then you really wanna play it again. You know?

 

Yeah,

 

Yeah.

 

yeah, yeah, we have pretty much every version of Pandemic ever made, right? And

 

Yeah, I love pandemic.

 

there are a few of those that really kind of make you go, all right, you know, how do

 

Hahaha

 

we do this? So yeah, you know, and that's a fun one. And we've also played all the Pandemic Legacies, which is kind

 

Mmm.

 

of fun, because it introduces a new element every time you, you know, you play it until

 

Yeah, I

 

you

 

really

 

finish

 

like that

 

and then.

 

legacy version where it kind of gets

 

Mm-hmm.

 

harder or easier, depending on how you play. If

 

Yeah.

 

you don't play well, it gets a bit easier. If you play really well, it gets harder.

 

Right. Yep. So. So, yeah, so that that's kind of where those are at. I am going to do a quick shout out about Rails RemoteConf. If you want to speak, the CFP is still open. If you want to come, you can buy a ticket. If you want to do a workshop, I am going to share some of the money with you. So, yeah, just let go fill in the CFP. Let me know what you want to do. an hour long Q&A. And so it should be really fun. It's going to be at the end of September. So anyway, looking forward to that. And yeah, then I'm looking at getting the meetups together this next month. So if you want to speak at the meetup, if you want to sponsor the meetup, the meetups will be free. The conferences, you have to buy a ticket, but the meetups are free. They're going to be low key. We're going to have some mechanism for you to sit down at a virtual table and chat with people. So it should be fun. And then as far as the road trip went, there are a few things I want to shout out about. Now one of them was, and this is more of a pick to just remind people, you know, to go connect with your roots, right? So the family reunion we had was in Nauvoo, Illinois. And if you're not familiar with the history of Nauvoo, Illinois, it's where members of the Church of Jesus Christ of Latter-day Saints gathered after they were basically chased out of Missouri. of the Mississippi River, built a city, built a temple. A lot of my ancestors came through there. They stayed there for several years until they got chased out of Illinois. Then they crossed the Western United States to Utah, what is now Utah Salt Lake City. A lot of my ancestors after that And so yeah, that's where I'm from. I live here in Utah. But anyway, it was terrific, because we got to kind of walk around and kind of see how the city was laid out and stuff like that. There are still historic buildings there. So you can go and check it out. And they have like a blacksmith shop and like a brick kiln and a gunsmith shop. John Browning, he actually invented a whole bunch of technologies that are still used in firearms today. And he had his shop there in Nauvoo. And so you can kind of go walk through it and see the different things that he used and did in the gun shop. They had a tinsmith shop, they had a print shop. Joseph Smith, who founded the church, was martyred out there. And so you can go see the jail where he was killed and where he lived. And anyway, so it was really, really you just kind of want to go see how they made things with hand tools when you know, I like my power tools. I really appreciate them now. But if you want to kind of go see how they did it back in the day, it's a terrific place to go visit. The other picks that I have, so when we got out there the check engine light came on on my car and one of the things that I have invested in that I just leave in the car is I have a little OBD2 car and it connects to my phone so it just sets up its own Wi-Fi network. You get on the network and then you can use an app to connect to the thing and it reads the codes off your car which is really convenient and I think it cost me like 20 bucks and so that that's really really handy as opposed to the big bulky things with the big fat cord that you have to fight in order to anyway. So yeah slides into the trailer hitch on our car, you just, you know, you pull the the ball. I can't remember what it's called, but you pull the the big beam with the ball out and then you slide this into it and it works great. So anyway, and it's a lot more pleasant than trying to throw things in a basket on top of your car. And so that's what we did because we have an eight passenger vehicle and seven people in the family. So it doesn't leave a whole lot of room for luggage in the isn't very big. So that was awesome. And so and I think we got that on Amazon for 100, 150 bucks. So I don't know what the prices on these are now because we've had them for a while. But anyway, those made the trip more pleasant. And then the other thing that we had was the old cigarette lighter power thing, you know, the round thing that you plug the power in in your into it that provides three of those outlets and four USB charging ports. And so we were able to charge all of our devices driving out and driving back, which was a lifesaver with a six-year-old whose iPad only lasted half the drive before we had to charge it. So anyway, it made for a really, really, really pleasant trip. So I'm going to pick all that stuff and we'll let Ben do some picks. Ben,

 

Yeah,

 

what

 

absolutely.

 

do you want to shout out about?

 

So I'm obsessed with this book at the moment called Anathem. It's by Neil Stevenson. I'm on my second consecutive read. It's about this concept. Neil Stevenson's famous for doing really deep sci-fi. And Anathem is from this concept. He was pitched this idea of a million year clock. So how do you make a clock that goes, runs for a million years. And anathem is what he imagined the clock would be. And so the system has these layers and each layer in the system opens at a different interval of time. And so there's a day gate, a year gate, a decade gate, a hundred year gate, and a thousand year gate. And in each of these layers is kind of like a different length of time since those people have been outside. And the people within those layers study and learn about maths and physics, but they're not tainted by this outside world. And it's just this fascinating idea and he explores it in this massive way in this kind of totally fake but kind of similar to Earth world with all these weird words and kind of strange concepts. It ties together a lot of philosophy of science ideas and physics and, you know, multiverse kind of stuff. Super interesting book. And that's like my number one pick for today.

 

Very cool. Now one last question, if people want to connect with you or see what you're working on these days, where do they find you?

 

So best place is Twitter. I'm TaybenLaw, T-A-Y-B-N-L-O-R on Twitter. And if you wanna check out my project for running code in the browser, it's called runno, R-U-N-N-O.dev, runno.dev.

 

Awesome. All right, we're gonna go ahead and wrap it up here. Thanks for coming, this was really fun.

 

Thanks apes.

 

All right, till next time, folks, Max out.