WebAssembly (WASM) is a core technology of the Web and supported by all browsers as well as various other runtimes. Yet despite this fact most Web devs don't use it and have little or no familiarity with it. This week we are joined by Istvan Szmozsanszky "Flaki" to discuss some of the significant transformations currently taking place with this tech, which could make it much more mainstream.

Hey there and welcome to another episode of JavaScript Jabber. This week on our panel we have Dan Shapir.

Hey from still warm and sunny Tel Aviv, mid November, isn't it wonderful?

AJ O'Neil.

Yo yo yo coming at you live from the no shave shed.

Nice, I'm in that shed too. By the way, it's 20 degrees Fahrenheit here, which is below zero in Celsius. So I'm not even gonna talk about warm and sunny. I'm Charles Max Wood from Top End Devs. Big shout out, I got the developer book club launched. You can go to topendevs.com slash book club and check that out.

Yay! Congratulations!

Yeah, we're reading clean architecture starting on December 7th, so our first call. And if you can't make it, we're recording them too. So anyway, guest this week and it is I'm gonna check it out and just say Floki and he can tell you what his name is.

Yeah, I mean, yeah, Flaky works for most people, but the long version of that is Istvan Smolchanski, I'm originally Hungarian, but I'm coming at you at the very snowy and absolutely not sunny

Sure.

He was just rubbing it in our faces. I have to ask. So I didn't hear Flaki in Ishtvan, however you said your name. So where does Flaki come from?

Yeah, Floki goes back, very boring, 20 years ago. If any of you is old enough to have played and learned enough to have played any mods, like multi-user dungeons, this is the text version of what we call to do MMORPGs. Like

Oh, like rogue and stuff like that.

you type into a terminal. Like you literally use Telnet to connect to a server, and then you kick rats. And

good

then

old days.

it tells you that you just kick the rat you gain free experience points or

A

that

Chris

sort of

knife.

thing.

You're supposed

Yeah.

to try to get a Chris knife.

Yeah, so I was playing one of that and my character was called Falcon Master, which was like a druid or something and so like that basically evolved. I was really adamant in like high school, like that people call me Falcon Master now and they're like, they're not taking my bullshit. So they're like, oh yeah, like that just evolved into like Falky and Flaky eventually and just like stayed with it.

Hmm.

All right, well, you can be our resident wasm druid.

Okay.

Dan, you invited Flocky onto the show, so I'm a little curious if there's some context you wanna give before we get rolling.

Yeah, for sure. So we had some episodes recently in which Wasm came up. I think we mentioned that what's that drawing software that uses Wasm? The one that got acquired by Adobe,

sigma.

Figma, that's it. And we also kind of contrasted it with edge computing, because we were talking about technologies like they are very useful and very interesting, but I'm not sure of the applicability to the mainstream. Anyway, WASM is a topic that kept coming up for some reason or another, and Flaki is like the WASM guru that I know, so I thought that it would be awesome to have him on the show to talk about what it is, because I'm assuming most of our listeners have never good for now after all these years.

All right, those are some big shoes to fill.

Hahaha

Yeah, I mean, honestly, I've been giving a bunch of talks like in the before times about WebAssembly. And back then, I would usually tell people, and I still think like this is increasingly the case. It's like a lot of people don't really actually have to know about WebAssembly and still take advantage of it, right? There's like so many like tiny things, has a tiny bit of WebAssembly in it to generate hashes. That was a bunch of issues with Webpack using hashes

Thanks for watching!

and these being super slow. And then Node deprecated these hashes because Webpack was using some Node library, both built-in hash generation. That was just very insecure. But we don't need cryptographic hashes. These are really just content hashes. And there was all these like turmoil about deprecating and that's breaking all sorts of software. And so they have this tiny bit of WebAssembly module inside Webpack. And if you actually search the Webpack repo, you couldn't even find it. It doesn't have a WebAssembly extension because it's actually inline. I think it's assembly script. It's like a thousand characters of assembly script repo, I think this is Webpack 6, that is compiled during build time to WebAssembly and just included into Webpack and it uses or can use, I don't know if it's like default, but like it uses WebAssembly to generate like hashes like so much faster and like without having to depend on like cryptographic hashes included in OJS, that sort of stuff. It's like people don't even know the thing like uses WebAssembly that they're actually using.

So going back to my original comment, maybe we should go back a little bit. Because like I said, my guess, and I think it's a fairly safe guess,

Thank you.

is

Thank you.

that while

Thanks for watching!

many of our listeners might have heard of WebAssembly, hardly any of them ever used it. And consequently, I think probably their knowledge about it is a bit vague. So maybe it's worthwhile to kind of backtrack and talk about what is WebAssembly, where it came from. What can it do? How it differs from just writing code in JavaScript? Where does it run etc etc etc?

Oh yeah, that's a really good point.

you

I had a whole talk about the whole history of WebAssembly, but I think the most important thing to know about the history of WebAssembly is that it didn't just like some gurus of engineers like sit down and conceive it, but it comes from a lineage of technologies that have been trying for years

Thanks for watching!

execution speed in the browser. And partly from the lineage of like, we have a bunch of like pre-existing code that we want to run on the web, but we don't want to port it to JavaScript, like hand port that code to JavaScript. Kind of these were like one of the two main motivating factors that led to technologies like SMGS. And like eventually, like everybody kind of came up with their own like way to port like code from C or C++ or languages that are pre-existing code and run it in the browser. So there were these multiple underpinnings to why people wanted the technology for this reason or that reason. And everybody had their own Google Headless neckle, pinnacle technology. Everybody is trying to do their own thing. And WebAssembly came as a very unexpected to me. It's very hard to get browser vendors to have you on something like this. Web assembly was basically a culmination of the PNaCl and SMJS effort of trying to ditch these technologies that were trying to solve these problems and kind of unify them into what WebAssembly is doing. Usually how this happens is the classic XKCD, there is no 15 standards. There's no one unifying standard. they managed to pull this off with WebAssembly, Binocule went away, Asm.js still exists for historical code, but they have this technology now that fulfills this need to be able to compile existing code in other languages, to run in the browser, and also to use languages that are not JavaScript to compile some piece of code in a browser than like JavaScript built-in, like default JavaScript. Then to use some other language to compile some code into the browser that would run faster than canonical JavaScript code would be running. And so they kind of used all of these to create a technology that like fulfills these needs.

So WebAssembly effectively, and that's, I think, the important thing to stress, is a compilation target. It's basically people coming around and saying, we're using JavaScript both as a programming language and as a compilation target because we had various programming language compiling into JavaScript. And that's not an ideal use case for JavaScript. So instead of compiling to JavaScript, compile to something lower level that can run at, quote unquote, machine code speeds in the browser, right?

Yeah, exactly. Some of the early inspirational predecessors, like SMJS, was doing exactly that. We had a lot of languages compiling to JavaScript, going back all the way to the CoffeeScript times. But SMJS was really like, we're not even trying to have people handwrite this code, like this other language. We just want to take something like C++ and compile it to the browser. And yeah, people have been realizing that that had a lot of drawbacks. lot of issues with that, like parsing JavaScript code that was compiled to SMJS, like that could be like several tens of megabytes was really slow, and that could not be improved like because of how like you had to like kind of maintain compatibility with the language. Like a lot of that reasons basically like people just wanted to re-architect something. Like when you go to the WebAssembly homepage, when you go to the WebAssembly homepage, it will say stack-based virtual machine and a lot of very interesting words. But what it really means is that it's a very limited instruction set. It's almost like machine code that is similar to computer architectures, like a virtual processor, basically. Similarly, how you would compile to x86 M2 Apple Macs, like the ARM processors in those Macs, you could compile to WebAssembly as a compilation target, and it has its own instructions that are platform independent after you've done the compilation process.

One thing that I'm kind of curious about, and I don't know if you know, I have some guesses, but I don't know like an official answer, is why did they come up with another, effectively another virtual machine, rather than let's say use the JVM, or use.NET or something like that? Because these are two existing virtual machines, you know, that fairly popular, do you know? Or is that they're like, do they have technical needs that are different? JVM is pretty tightly bound to Java, so maybe that was a consideration. Also, it has a lot of baggage in the form of various services like the JVM garbage collection, et cetera. So maybe they didn't want that. I don't know. But I'm curious.

I'm honestly not sure. I don't really know what is the demotivating factor. I definitely think WebAssembly as it happened, I definitely think that WebAssembly as it happened came out very different than any of the existing bytecode languages. Particularly, one of the things that is limiting WebAssembly's adoption today is the fact that it is still a proof of concept. the MVP, which was basically, I mean, that was the result. That was the reason why people could agree like Microsoft, Apple, Mozilla and Google could agree that, oh yeah, we want this like technology into browser. And like they could agree on like what to ship eventually, features that exactly catered for these needs of running fast, being able to parse it fast, and compile in the browser fast, make streaming compilation. All of these properties that they had in mind, they tailor made this language, this instruction set for that approach. And a lot of the other features that they couldn't write off the bat, like all the features that they couldn't agree on, they went on and they're like, OK, we're going to punt this after actually people have some time to work with this programming language and give us some feedback. Well, not programming, we work with BabAssembly. So they're like, OK, we're going to go ahead, give this MVP to people. After they gave us some feedback, we're going to use that to iterate on some of these other concepts that we couldn't agree on previously. We're going to spend some more time on it and bring those back. that must have contributed is that they had very specific needs in mind and they wanted to pare down like the bare minimum like they wanted to bear down their requirements to the bare minimum to be able to ship this in a browser.

And how do you actually ship WebAssembly code to the browser? I mean, how do, let's say I say, okay, this is really cool. I would like to develop for the web in C++ or in Rust, I think, or I know that there are a variety of programming languages these days that compile to, to WebAssembly. How, how do I even, what do I do?

Very good point. There are some programming languages that provide and some frameworks really that you could use and ship end-to-end code into a browser. So I know there's this framework in Rust that's called U-Y-E-W, that basically lets you write code in Rust. This is a Rust framework. into WebAssembly, not just writing the code, the business logic, but also the interactions with the user interface and interactions with the DOM inside you as well. You could even embed in-line JavaScript and things like that. And it has some glue code that it takes care of for you. But this is right now not really the

Thanks for watching!

primary target, mostly because of the MVP nature of on making

you

a bunch of features available that are necessary to make this really convenient and really useful, or really fast even, to write something in C++ and then move that over to the browser. What is more? What people do more? right now with the current version of WebAssembly is people get some piece of code, whether they got that library from somewhere or they wrote that from scratch, and use that code to compile some very core business logic to WebAssembly and use it in their front-end application. There is tools to help make that happen. One of the early tools that existed into the SMGS era. And that is one of the core tools, or main tools today. For doing that is Emscripten. So you could totally use Emscripten to generate some C++ code, generate web assembly from some C++ code. And that will eventually end up in the browser. Emscripten will take care of applying a bunch of glue code for you. game or a WebGL application or an OpenGL application, Emscripten can actually take care of translating that into an OpenGL application. Emscripten can actually take care of translating an OpenGL application to WebGL and will just give you a canvas in the browser. And so you don't have to worry about the front-end stuff. But that really is currently not really possible of all of these technologies, and some of those actually just landed. There's a standardization process ongoing for a lot of these missing features, like in-process features. For example, garbage collection or like object preferences. Many of these features are required to make this interaction between WebAssembly and the browser both fast or even possible. What a lot of people WebAssembly, the specification, it has nothing to do with the web or JavaScript at all. WebAssembly has been split up to various different pieces of specifications. And this core specification to WebAssembly itself is agnostic to the browser. It has nothing to do with the browser. It literally just describes the virtual machine semantics, where the interactions with the web browser called the JavaScript Embedder or like the Web Embedder, which is basically specifying an environment for the WebAssembly virtual machine and providing some escape hatches, providing some APIs to interact with this WebAssembly virtual machine. And so when this happens, when you're interacting with your WebAssembly code, a lot of things are still not possible, because WebAssembly doesn't know what a JavaScript object is. Like complex objects are opaque to WebAssembly right now. WebAssembly ships with four value types, just integers and floats really, and doesn't really know what happens when you want to give it like a JavaScript object or like want to give it a WebGL function object. So a lot of these interactions are not defined in a current specification because they are currently being worked on. There are mostly ways to overcome these, like writing your own glue code or writing your own bindings between these two languages or letting a tool, like the Anthropten I mentioned, take care of some of these. Some of this work for you. But there are definitely hurdles in the developer experience right now.

Yeah, that's kind of what I hear about WebAssembly, that like the two biggest limitations that have for years prevented wider adoption are the ones that you mentioned, which is first the lack of a garbage collector,

Thanks for watching!

which means that any programming language that relies on garbage collection that you want to compile into WebAssembly, you actually have to implement and ship that with your code, which obviously significantly inflates your code, because you're effectively delivering a part of the operating system, as it were. And I think that Blazor from Microsoft does something like that. But anyway, so that's one hurdle. And the other hurdle, which you mentioned, is indeed the fact that the communication the DOM is kind of impossible. It can hardly interact directly with the DOM. Instead, it needs to go through a JavaScript bridge, like tell JavaScript code that gets shipped along with it, to interact with the DOM for it. But like you said, even that interaction is kind of difficult because you effectively need to have that JavaScript code serialize everything into byte arrays or word and then post that over to the WebAssembly code, which does whatever it does, and then kind of throws it over the fence back to the JavaScript, which is obviously challenging. Let's put it this way. And again, like you said, you've got frameworks that kind of deal with it for you, but then obviously it kind of restricts the way that you go about these things use these services, you know, either whether they fit your needs or not, that's all you have.

This is all true, but there is light at the end of the tunnel. Garbage collection, I believe, has just shipped, just moved into, what was it? I think it's in phase three. Just moved to phase three, the proposal on garbage collection. This can be if somebody has been following ECMAScript, like the ECMAScript process, based off of the ECMAScript process in terms of standardization. So phase three, if I'm not mistaken, it means that garbage collection is basically in the browser implementation phase. There are some browsers that already have implementations or preliminary implementations for garbage collection. So garbage collection is at least coming pretty soon. And as you mentioned, like right now, pretty much everything from TinyGo to Ruby to Python, all of those languages, when you try to compile something into WebAssembly, you have to ship a garbage collector as compiled to WebAssembly into that bundle. And, yeah, that is untenable, not just because it inflates the bundle, but because, like, every module then will have to have its own garbage collector. So every interaction between modules with their own garbage collector, it just becomes exploding mass of like things. So you really don't want that. And so this has been one of the primary focus areas of new specification room. The other issue, as you correctly said, was translating between WebAssembly and the browser, or whatever the embedder happens to be. It doesn't have to be the browser. Now basically translation between, or bridging between WebAssembly and the outside world. not to crack and there have been years of research like bringing in the very best of programming language research into WebAssembly and exploring various ways how to... Again, there was a lot of requirements, like a lot of requirements that people had to choose what to cater for, how to make this not just for developer experience but also an ecosystem experience perspective of ecosystem experience, tenable at least. Which is the current case is what you do when you create a WebAssembly module is you really create a monolith. And you really don't want monoliths, because the whole world has been moving away from monoliths into microservices. And right now, that is not possible. You can't really build, not easily at least, build microservices in the sense of, WebAssembly. So you can't compose a larger WebAssembly program from WebAssembly modules or like tiny compiled WebAssembly modules because you have to hand define and orchestrate the interactions between these modules. Not just with the outside world, but like in between the modules, like any information exchange would have to happen this very lowest level of integers and floats.

So.

And that's really something that doesn't people

If

don't

I'm

want.

if I'm I want us to see that I understand what you're what you're getting at so with JavaScript I basically can just stick script tags in the HTML and any script tag is wholly Independent on any other script tag obviously that you know they share the same global Namespace so they can step on each other's feet But ultimately they kind of function independently and in the fact that I put in one script tag does not preclude me from putting in and there are various mechanisms in which those independent scripts can collaborate. What you're saying is that with WebAssembly that's not the case. I basically more or less need to build a single bundle and deliver it as a single bundle and not break it up into multiple bundles. Is that what you're getting at?

Yeah, it's more like, I think the better analogy is like, what we have in ES modules or even NPM, is you have a program and you want to, I don't know, like import express or import like a JSON parsing library, something like that. Your program can interact with that JSON parsing library because they can exchange objects and they can talk over interfaces. It's fairly easy to do so. How this looks like in WebAssembly land, is you either have to, for example, you're writing a piece of Rust code that you want to compile to WebAssembly. You can import other Rust modules, and that will just work. You can import C modules, because Rust allows you to do that. But you can't just import a module that was written in Python right now. You would have to figure out how to do that in Rust somehow. And at the end of the day, what you uses the compiler in Rust in this case will generate the WebAssembly module for you from all these packages and will give you a WebAssembly monolith. What

The-

you would want here, rather, is to write a piece of code in Rust, compile it to WebAssembly, and write a piece of code in Python, write it in WebAssembly, compile it to WebAssembly, and have those basically runtime link those two together,

Hmm

each other, which is you could do it, but you would manually

Thanks for watching!

have to ferry those bytes over the boundary, like from the Python code and from the Rust code.

That's really interesting because I brought up before two other virtual machine, bytecode virtual

you

machines that exist, the.NET virtual machine and the JVM. And both of them kind of, in a sense, come up with really different solutions for essentially the same problem. And the JVM basically said, everything is Java, so as long as you conform with Java, you can just work. with their own kind of language agnostic way to describe objects and interfaces, which kind of sounds like what WebAssembly is trying to achieve.

Yeah, yeah, was it was it was it what JNI I think like the the native interface I don't know

That's in the Java land.

Yes, yes.

Mm-hmm.

But that's not very knowledgeable at C Sharp, but closer to the web space, a lot of what WebAssembly has been initially thinking about is the WebIDL specification. So WebIDL, for those who haven't heard about it, is this kind of sort of, I mean, I wouldn't call it language, it's agnostic, but more like declarative way to describe an interface between

Thanks for watching!

the browser and JavaScript. So Web Ideal is used by browser vendors to sync, or like specifications, for example, intended for the browser or the DOM. Uses Web Ideal specification to create an interface that will be used by browser vendors when implementing a feature. So for example, when you're using a built-in browser feature API, these web ideal interfaces define the functions and objects that get generated or exposed by these APIs. So browser vendors use this as a sort of compatibility hook.

Thanks for watching!

So everybody implements the same functions, it gives back the same objects, all of that stuff. Because JavaScript is an untyped language. So we kind of need these things to help us some sanity into that.

By the way, just an aside where you can actually easily, for listeners who want to see examples of IDLs or you can easily see those, is if you go into the MDN and look up any documentation for any DOM feature, usually has towards the bottom links to the W3C specifications. And if you click on those links and look at the W3C specifications, let's say for, I don't know, the location object interface, you will see that it's all specified via IDLs. And it's actually fairly readable and it's not too difficult to figure out what they mean. It's fairly straightforward. Certainly anybody who's familiar with TypeScript should be able to read it fairly easily.

Yeah, and I believe to best of my knowledge, that was the initial moderation to use IDL, not only or not even, not really that it's close to the web or whatever, but because they are fairly readable and fairly succinct. The people working on extending WebAssembly and making this modular interface possible between the two worlds in this case, the WebAssembly role than the outside role, and like between modules. When people came up with this, they looked at the WebIDL spec and said, okay, we can just extend this and we kind of use or reuse this for our own use cases. But eventually ended up like, they eventually ended up moving away towards what they call, what do they call them? hype. They changed the name of this like for so many times. Honestly, I would have to look it up. I'm blanking

It's not

Ha

that

ha

on it.

important.

ha!

basically some sort of type specification language

Uh, yeah, um, uh.

Clickety-click. Ha ha ha ha.

I really have. boy.

It's all good. One thing that I wanted to... Oh, go ahead.

No, it's all right.

No, you go first Chuck.

Yeah.

Well, I'm gonna change the direction we're going in, but.

That's

It,

alright.

one thing that I keep hearing about with WASM is that, and you kind of implied this with, you know, whatever the program is that it's embedding the WASM, right? So we talked about browsers, but I keep hearing about people running WASM code like from the command line and stuff like that, right? So if you have a, basically a VM that runs out there, you can compile stuff to run there, right? I mean, it's not, I guess, but you know you have a lot of flexibility because yeah you can write different parts of your code in different WASM languages.

Mm-hmm, mm-hmm. Oh, what?

Are you seeing widespread use of that or is it mostly focused

Thanks for

on

watching!

the web?

Yeah, I mean, not widespread, but people are starting to experiment with that. So what we are seeing...

Yeah, go. Sorry.

No, what we are... What I said about the WebAssembly core specification not being tailored to the web browser in any way, people recognize a lot of properties of WebAssembly that they have been missing from other places. And when you mentioned edge computing, WebAssembly at the start. That was really funny, because if you look at a web browser, WebAssembly had all these properties from the very get-go, all these needs and requirements that they needed to adhere to as they were developing WebAssembly. And those were all, it has to run in hostile environments. The browser is one of the most hostile environments when running third-party code in somebody's machine is always really bad, and you don't want that. very tight sandboxing, very tightly locking down all the things in WebAssembly. But also, it has to ship very small code. Dan mentioned this before, that you can't just blow up your WebAssembly bundle. One of the reasons why we moved away from SMJS because they were just generating huge SMJS JavaScript binders. And you really don't want that. You really want to keep sizes at minimum. You want to make it, one of the optimizations that they made is when WebAssembly downloads, it has to be parsed on basically wire speed, that is as fast as the data is coming in, your browser is already translating it into its internal format. And all of these properties, people looked at that and they were like, huh, that sounds like all the things that we need in a small embedded system, some very limited resources, something that runs fast or fast enough. that is very sandbox, compiles quickly, takes up very little space, and people are like, what if we actually use this in something like edge computing? And edge computing, at the end of the day, is like somebody has a bunch of servers scattered around the world, and they just decided to deploy your code in every single one of them. And if you have 160 servers, or 360 servers, or thousands of them, you can put the code in every single one server and whichever server is closest to the user who is requesting or who's trying to use your application, they will just run it on the server as close as possible to that user. That's kind of the whole deal. That's the whole shtick of edge computing. And when you kind of put it that way, when you phrase it that way, it kind of clicks that, oh, so I need this small module because it has to be small because everybody's module, every code I'm deploying Cloud for workers is doing

Thanks for watching!

this, right? Has to fit on every model of my servers. And I want them to be small. But I also want to have to distribute these over the planet to 1,000 servers. So the transfer payload has to be small, because I'm paying all those costs, right? And so it has to be very sandboxed. It has to be deeply, deeply tied down, because I want to be executing multiples, of these modules in parallel on the same machine. And you can't just put them all, every one of them in a container. I mean, you can, but you're gonna have overheads. And people figured out that WebAssembly can do it. WebAssembly can do tens of thousands of modules. WebAssembly can do that, tens of thousands of modules concurrently. And all of these, people slowly realize that there is all these properties to WebAssembly that make it great for the web because we chose to build these properties and just make a lot of sense for a lot of other computing scenarios.

It's really amusing because it really mirrors what we saw with JavaScript itself. I mean, you had JavaScript originally in the browser, then you had JavaScript on the server side, then you had JavaScript all over the place. We had people on our show talking about edge computing, talking about embedded devices. And effectively what you're saying is we're seeing kind of the same thing with WebAssembly. for example, so anywhere that you can put V8, you can get WebAssembly. And the other funny thing for me is that, again, it kind of mirrors what happened with the JVM that the people these days don't remember because it was way back in the 90s, but originally JVM started on the client side and then it kind of migrated to the backend. So now, you know, we see this, the JVM is this kind of universal backend platform, but

And don't forget the DVD players

Exactly.

and the set top boxes.

Thanks for watching. Bye.

So

Hehehehehe

effectively, we're getting kind of a replay of what goes around, comes around, happening again with WebAssembly. Yeah, interesting.

It's really funny that AJ mentioned setup boxes. You know who uses WebAssembly? Disney Plus. Disney Plus runs WebAssembly in their setup boxes. Not only them, oh, who was that? Amazon Prime runs WebAssembly in their setup boxes. There's a talk from a couple months ago by one of the main engineers behind Amazon implementing WebAssembly service and basically they talk about it's they're running a web browser right they're running an electron ish stack so

Mm-hmm.

they have javascript in there and they have c++ in the back end but c++ is really hard to deal with uh a thing they start yeah they had c++ and started replacing some of that with rust and then they started replacing a bunch of stuff that rust like they ended up like using some web assembly in there as well uh that the same the same reason why JVM or Java runs in set-top boxes. The same cross-platform portability reason comes up for WebAssembly. It is a low footprint, high performance language that you can use with today's compilers to generate code, and you can put it into, especially for things like set-top boxes and embedded devices in general. You want to be able to iterate quickly, Assembling payloads you can just put into these devices in a ways that you couldn't just like put like C++ or update the firmware on them And and while you could do a lot, but a bunch of this stuff in the client side when you're using some react ish framework like on the front end to build your documentary and this place that stuff in the Television screen or something that is you're losing a bunch of performance So if you could go with it in between already written in Rust, put them in between, ship them as web assembly, and keep the low fluff stuff in the frontend. You could totally do that and improve performance without actually breaking the bank or spending a bunch of time on engineering. But going back to Dan's, what Dan mentioned is like, there's this whole, we're walking this path of increasingly, I When I think about what you just said, I kind of harken back to what I said in 2019 when I was talking about WebAssembly and how WebAssembly is kind of just using the web ecosystem to bootstrap itself, having NPM, like being able to deploy WebAssembly at scale just makes a lot of sense and lets you gain a lot of dock-fooding experience from the effort. But as people are discovering the properties of AppAssembly that they could use for these other reasons that I mentioned before, it's going to spread out. But like that initial bootstrap, like just a huge scale of the JavaScript ecosystem. And as you mentioned, the fact that wherever, like in a modern browser or wherever you run V8 today, you can just run by AppAssembly. And that goes from Dino to Node.js to all the server side languages as well. pollinate. People are going to start writing code for the server side that people are going to start reusing on the client side, which is already happening today. Things developed for client side work move into edge computing. Versel is putting WebAssembly stuff into their edge nodes to make, what is that, server side rendering, to just in time server side rendering. What is the work for that? server. But basically you hit an endpoint and the server renders the page, the static page, and basically gives you back.

You mean SSR?

SSR, yeah, yeah, yeah. I mean, server-side rendering, but I thought, but this is not like, yeah, I guess that's server-side rendering, but that's basically, you could do this on the client side, right, in Node.js, when

Yeah...

you render your bundle, and then they moved stuff over to the server side, but then you would still have to run Node.js. But if you can compile the thing to WebAssembly, you can just deploy it to WebAssembly and just keep the things slow, and smaller footprint, all of that stuff.

One of the things about JavaScript, the way that JavaScript works differently than most other programming languages that most people use these days, is that JavaScript is a just-in-time compiler instead of an ahead-of-time compiler, which is what all the languages that compile to WebAssembly are. and doing the build process and generate WebAssembly, whereas with JavaScript, you write JavaScript and you deploy JavaScript. You might minify it or you might remove all the type information when you transform it from TypeScript into JavaScript. But effectively, it's essentially the same JavaScript code. And with JavaScript, because this compilation step needs to happen at runtime, it needs which means that it's hardly optimized. Because you don't want to wait while the compiler is trying to optimize the code. Instead, what usually happens with V8 and similar systems is they identify hot code during runtime and then optimize that over time. So your JavaScript code, while it runs, actually gets faster and more optimized over time. that they usually don't run long enough for anything to get optimized. You know, you call that backend service, it does whatever computation it does, returns the results, and it's done. And it's usually supposed to happen within, I don't know, a couple of microseconds. So there's no time for optimizing the code. So you're always running JavaScript in its most inefficient form. And that's where something like WebAssembly can really shine, because again, compiling it ahead of time. So you're getting the advantages of JavaScript, which is that it runs in a secure environment, that it can run everywhere, that it's wholly portable, and you can send the code over the wire very easily. But it's optimized from the get-go. You never are stuck with running inefficient and unoptimized code. So those are the benefits I see. I do have actually a question for you that I keep wanting to ask about WebAssembly running inside the browser. Does it run on the main thread, or does it when you deploy WebAssembly to the browser, or does it run in a separate thread like a worker?

Very good question. And I will have to... It is almost as if we conspired, because what you just said is really just giving me the perfect segue into something that I... This is the JavaScript Jabber podcast, so I wanted to talk about JavaScript in WebAssembly, which kind of sounds like kind of blasphemy, but there is a method to the madness, and you just explained why. But to answer your question, WebAssembly runs in the same thread that you're invoking it from. This is important because when you're calling into WebAssembly, so basically when you compile, there is a subtle difference here that is important to mention that when WebAssembly is compiled from a source language, such as Rust, into the WebAssembly bytecode, that generates bytecode. code. But inside whatever runtime you're using, be that V8 or Wasm time or whatever runtime that you're using, it still needs to compile in the same way that JVM needs to compile to the target architecture that your actual computer is running on. It still needs to translate the WebAssembly code, the byte code, into the native system code. So that compilation is, you know, You can do initial optimizations in the Rust code and compiling to WebAssembly, but certain optimizations can only be done when you're doing this bytecode to machine code translation. And what I mentioned is WebAssembly code has to do this compilation as well. And a lot of this compilation happens as WebAssembly streams in. A lot of WebAssembly runtimes actually have multiple different compilers to do this. tiered in the same way is that the quickest compilers compile to machine code. As your code comes in, as your bytecode comes in, the fastest compiler compiles it to the very basic optimizations and later individual functions of WebAssembly. And again, WebAssembly was explicitly built with this in mind. Everything in WebAssembly is built to be able to be compiled as it streams in, recompiled. There's a lot of very good blog posts about both how V8 does this tiered compilation, how the browsers do this basically. But at the end of the day, you still need to compile. Something interesting about WebAssembly on the server side in this case is the runtime of your choice can do this and cache the compiled native code. So, like you said, running something, be that JavaScript or even WebAssembly in this case, there is a way to cache that compiled or parsed and compiled code, both in JavaScript, I think they call them V8 snapshots or something like that, and in WebAssembly, there are multiple tools that basically just cache this compiled version, the native version of WebAssembly of the executing runtime. The interesting thing about this is what you mentioned earlier is that JavaScript is a just-in-time compile language. And that is mostly true today, but does not have been true always. And JavaScript at the very core doesn't have to be just-in-time compile. JavaScript at the very core can be interpreted. And I've been giving a lot of talks a couple years ago about embedded JavaScript runtimes. There are a bunch of them, JavaScript or Esprino. And there is a bunch of different tiny, tiny embedded system compatible JavaScript runtimes. You couldn't fit V8 or microcontroller, Raspberry Pico, or something like that. So do you exist that all these JavaScript implementations starting JavaScript from source to the point where you could put more spaces in your source code. And then when you uploaded it onto the embedded device, because these are 16-megahertz devices, it's reading those spaces. You could actually slow your JavaScript down by putting a long string in there. It was pretty, with Node.js and just-in-time compilation existing, people really didn't think

you

that was a thing. You could interpret JavaScript and you can interpret WebAssembly bytecode in the same way that Java bytecode, you

Thanks for watching!

can interpret and not have to compile it to the native source. Of course, you're losing performance there. But the question is there, like there comes a point, and this is why I keep telling people about how WebAssembly, if it was just fast enough or it was just secure, or if it was It wouldn't have made such an impact. It wouldn't have been exciting people as it seems to be exciting people a lot. What really comes at this point is all these properties kind of interact in a way that make it just fast enough and secure and low footprint that all of these kind of make it like an idea. that we have from a technology that provides all of these properties and makes all these things possible. It is

Thanks for watching!

secure enough. It is fast enough. And it's not as fast as native code. So if speed is your number one thing, you could compile a piece of Rust code, optimize the heck out of it, and then deploy it to some bare metal machine and crank up the threads. And you can do it. And it would be memory safe because Rust language that allows you to do that. But you'll have to write it in Rust. In WebAssembly, you could theoretically write it in any language. Or in WebAssembly, you get these other properties. You could put it on any device. You decide to switch to ARM services. As long as you find a runtime that runs in ARM services, it will just work. All of that stuff brings together properties instead of just focusing on one or the other of these properties.

So you're kind of talking about some of the reasons why it's attractive. I guess the question that I have, and I, you know, I talked to CTOs and, you know, people who are starting new companies or people who are trying to, you know, add some aspect of what they're doing. So when is the right time for them to start looking at WebAssembly and some of the technologies we're talking about here and saying, Oh, this is something I should at least be considering this project, right? As opposed to, I'm going to go play with this new whizbang thing and hope that I figure out why I want it.

Yeah, so a lot of the things that we see are related to edge computing or server-side WebAssembly in ways. So a lot of the things that I can see that are up and coming and that are like, if you keep your eyes out, you can catch a train that is on the rising edge. Docker, there was a conference called WebAssembly North America Days, something like that, a couple of weeks So two very important things from that conference got announced. One was the opening keynote by Luke Wagner, who talked about, and finally, Luke Wagner talked about WebAssembly interface types, and this was the thing that I was looking for, by the way. It just popped into my brain like five minutes ago. Luke Wagner talked about WebAssembly interface types Both of these are basically the light at the end of the tunnel for how do I interact with the outside world and across modules better in WebAssembly. And the second, I believe, that is not as interesting technology-wise. It's not as groundbreaking, but that was the conference where Docker announced that you can now run native WebAssembly workloads in Docker. run containers, you can still have your containers in Docker. What you can now do natively in Docker is use WebAssembly modules as their own basically payloads in Docker. And I think there is a very interesting thing. People keep bringing back, bringing up this like tweet from Solomon Higgs about how he wouldn't have to invent Docker if WebAssembly existed. or all WebAssembly things you have to mention or bring this tweet in. But people really like to exaggerate. And they're like, oh, yeah, WebAssembly is going to kill JavaScript. And WebAssembly is going to kill Docker. And WebAssembly is going to kill all technology. There's a really interesting parallel when people say, well, containers didn't kill virtual machines, right? Containers found a way to run some workloads in more energy efficient ways or more resource efficient ways or just found new ways to run workloads that previously you had to run in a virtual machine. You wanted isolation. You wanted to run easy scaling of a process. You had to put it into a virtual machine. That was no other way. And people then, they invented containers. And what happened is some of that work, some of those payloads for them. And this is exactly the WebAssembly path. WebAssembly is not going to displace containers and VMs and all the other virtualization technologies. But some workloads are going to make a lot more sense for WebAssembly than they make even for containers. Fastly, Cloudflare, there's a bunch of companies that talk about basically how running many, many, many Web in the same server very densely packed into very small resources. And being able to spin those WebAssembly modules up and dispose of them right after, like this is exactly what Dan mentioned earlier, is what WebAssembly is really good at. You can spin up WebAssembly modules in microseconds. There's orders of magnitude of difference between how fast you can run a Web a Cloud Fair worker that's in JavaScript, like a V8 isolate. There's orders of magnitudes of difference. And so when you have that orders of magnitudes of difference, it gives you basically superpowers. Like, you don't have to keep modules in memory for caching. You can just spin them up as the request comes in. And Cloud Fair has been doing a lot of these optimizations for JavaScript. When your request hits their edge network, they already start compiling that. JavaScript or whatever. They do all kinds of optimizations to reduce request latency, and WebAssembly just gives you an order of magnitude improvement for free. But you don't want to use this for, I don't know, the trivial workloads, right? You want to use this for something that really needs this latency advantage. You don't need this speed advantage. Something that puts WebAssembly at an advantage versus all the existing technologies that all your DevOps familiar with. So there's a switching cost, right? Like, there's a cost to when adopting this technology makes sense. And a lot of these talks, including the prime talk that I was mentioning, talks about a lot of these switching costs. It's like, when does, like, adopting a new technology, be it Rust or be it WebAssembly, make sense? And, like, it is, you know, it has to be individually selected, like, by the workload and by whatever that even find people who understand WebAssembly is a big problem. And it has been a big problem. It's slightly getting better. But it's a huge problem. It's like, how do you even get people who get WebAssembly who don't get it? You have to compile things. You do have to know a bunch of, if you want to create WebAssembly, not just use it. But then you will have to understand the specification. You have to understand how compilers work. Like kind of the things that I mentioned briefly like what are these tiering, like what is these like performance latency issues that crop up. And so that's not trivial to find people or not trivial to make that happen, but it is happening. And so, like I said, like the Docker thing is really like a very good example of like gaining mainstream traction is increasingly happening. The component model talk that I also mentioned, there's also a very good way Basically, everything that we talked about, how it's hard to share objects and to have interfaces. You have to do everything manually and rely on tools that may or may not do what you need. All of that stuff is going away and giving you a web ideal-ish interface. This is the interface types, specification that will make this almost trivial to interact, between each other. And at that point, you're not compiling a monolith. You're not just sourcing all these Rust libraries and grating your WebAssembly code from all these Rust libraries. But you can just pick up somebody's,

you

there is a company called Fermion who does a lot of like edge computing and like he's really batting on this technology. They have a VAP server written in Grain, a programming language one of my colleagues is working on. Like Grain is a programming language explicitly targets VAP assembly. They started writing, they started creating a programming language that explicitly compiles to VAP assembly. And so those people at Fermion picked up this language. They were like, this is a cool language. We're going to write a web server on it. And they can expose that web server as its own component. And you just pull it in and basically rely on that component to do your web servering needs. from inside your own WebAssembly module is what basically this component model feature allows us, which is orders of magnitudes of improvement and everything. Imagine having a WebAssembly code that needs to rely on some shared library. Your Cloudflare, you're an edge computing company. And for example, what could be a good example

you

is imagine that you're one of these image resizing whatever image webification providers. So what you would want to do, but you want to do it in WebAssembly. So now what you need to do is whenever somebody wants a Web Assembly module that resizes their images to 1080p, and if some other person, for example, wants their own Web Assembly module that resizes things to 720p, and also like, you know, like outputs in PNG, those two modules would individually have to be compiled and deployed. And those modules will include a giant library that is an image manipulation library, probably compiled from Rust or C++, and it's going to make that WebAssembly code like six megabytes. So imagine that you provide all of these customers of yours the ability of customize and WebAssembly and Edge, and it's going to be fast. You'll have to deal with all these people deploying megabyte WebAssembly bundles into your Edge infrastructure. In the future, this is the WebAssembly component model thing. You can just ship the image manipulation library as a separate WebAssembly module that is basically going to tie together on your servers. And so you only need one 5 megabyte image manipulation library, and all your clients will deploy 1 megabyte WebAssembly bundles. So every single time you're saving 5 megabytes of those. You don't have to load it, you don't have to compile it, you can just keep it pre-compiled into machine code. Like this is all the reason, basically why I made the kind of microservices comparison is like the gains can be similar of breaking up a model into a microservices. All those things just fall out of it automatically. So these are two things that are really marking around using some of these new features and prospects to kind of really push my web assembly forward.

All right, well, we're kind of at the end of our scheduled time, and I want to make sure that we're respectful of yours. What are kind of the, I guess, one or two big takeaways that people should get from this episode?

Yeah, probably. One of the things I keep telling people, you don't have to know what WebAssembly is. You don't have to care about it. You already benefit from it. And you can use a lot of the WebAssembly modules actually are packaged up in really nifty MPM libraries or whatever that you could just use without even knowing that internally it uses WebAssembly. So a lot of that is probably just If you're worried about whether that is going to take away your ver for whatever is a developer, it's fine to not know about web summary. It's fine not to jump on the latest new hype. You have already like 17 new front-end frameworks to watch out for every day anyway. So that's probably a big one.

If I can throw in one, we're

Yeah.

seeing already a lot of JavaScript tooling effectively moving away from JavaScript in order to make build processes, for example, a lot faster. Again, going up to the expensive startup time that's associated with JavaScript-based implementations. And, you know, so we're seeing JavaScript tools being written in Go or in Rust. written in Rust, they can already be compiled and deployed as WebAssembly. And if they're written in Go, well, they can't, but hopefully soon they can be. So I think we will see more and more of the JavaScript tool chain actually being implemented and using WebAssembly.

Yeah, there's also the flip side of that. A lot of people worried about WebAssembly taking over or whatever, and if they missed a boat, then they will not know how to develop. And I think WebAssembly on the flip side is opening up a huge swath of possibilities for many languages and many programming languages outside of what the usual place that you would use them. One of the good examples to this is Python. So one of the reasons Python was not really usable browser was because you had to use CPython and it had all kinds of issues, but Python proper you can't compile because the garbage collection and all of this stuff and slowly all of those hurdles are being moved and moved away and Python is now having an experimental browser version that is like 300 kilobytes. You could embed a Python interpreter in using news probably like one or two weeks and this is I think like a huge boon for like the entire web the entire ecosystem of like people are gonna have this ability of user-resistant skills in places that they've never imagined to and this is going to open up like a lot of possibilities in spaces where this was not possible before

Cool.

Well

Alright,

just because

well,

you

one-

can doesn't mean you should.

Ha ha ha ha!

So just for one moment, I kind of teased this, so I kind of want to get this out. So we run JavaScript in WebAssembly. We compile JavaScript to WebAssembly. We are not the first ones. Figma, who you mentioned, also does this. What Figma does this for is they use WebAssembly for isolation

you

for their plugin systems. We use it for a very different...

you

So that's in browser. We use it on the server side. And the reason we do it consistently, when you give people like here, you can write your own code. And like people are like, okay, but like what languages can I use? I was like, well, WebAssembly supports a bunch of languages. You can use Rust and Go and Swift and be like, can I use JavaScript? And you're like, no. And like everybody was asking for JavaScript because it's a language you're familiar with and everybody

Mm-hmm.

wanted JavaScript. So we took basically Quick JS, JavaScript implementation and just compile it to WebAssembly

Thanks for watching!

and put it into the server, like put into your Edge services. And so now you can use a full, it's AcmeScript 6 compliant, all the bells and whistles. And it kind of goes back to what Dan was saying earlier. It's like, you don't need incredible performance to handle an incoming webhook and post something into a Slack channel, right? bound subject. That's not a performance bound issue. But being able to do this in five lines of JavaScript versus having to learn Rust if you want to do it, it makes all the difference. And so people kind of think, you know, like when you look at it, you put JavaScript, like a runtime into WebAssembly, like you compiled an entire JavaScript runtime into WebAssembly. Why would you do that? You really shouldn't do that. And there are legitimate reasons to do to use your product. And people have been using our services constantly and consistently has been asking for it. So

By

there you have it.

you're saying we or us, do you mean your company?

Oh, yeah, I guess I never really ensured ourselves. I work at a company called Suburbable. We live and breathe this whole, we are super hyped about WebAssembly. Yeah, the product that we work on is extensible to using WebAssembly. How easiest to describe it is probably imagine that you could embed a code editor into a product, like as you work on some product. a code editor inside that is that people can write some JavaScript or Rust or whatever into it and create some custom code that will run inside your infrastructure. So what we do is we'll compile this to WebAssembly and you can either run it inside your infrastructure or we'll run it for you in distributed ways. But at the end of the day, basically we take care of people customizing your product, running with code, like with as much flexibility as a programming language can give them. And the only reason we can do this is because WebAssembly provides all this like source languages and all that stuff. And so that has been basically it. We were like, oh yeah, you can do this in Rust and AssemblyScript and people are like, but like, what if I want to write JavaScript code? And then we figured out how to let them do that in JavaScript.

Cool. Wish we could dig into that some more, but

Hahaha

maybe we'll have you back and we'll figure out how that all works.

When edge computing all blows up, you'll just, in WebAssembly is like, you can just like, Flaky, come back and tell us more about what just happened.

I have to say, just because you mentioned it, and I won't go into it too deeply, because as Chuck said, we're kind of out of time, but I'm still waiting for the killer app for edge computing. I mean, it's cool

Mm-hmm.

and whatnot, and there are certainly useful scenarios, but I've yet to encounter the scenario to which I would say, yeah, that's the killer app. Everybody is going to need that. Everybody is going to need edge computing. And yeah, maybe I'm just missing it, but that's where I am currently.

Yeah, I think microservices

or

kind of tells the story that you just like, you have different trade-offs that you still have to figure out how to make that work. If you have one server,

video.

you can have like one database, like you can have edge computing, right? Like if your data is still in the other part of the world, it's still. Yeah, it's like you just still have to figure out different trade-offs.

Yeah, I think what Dan put it really well, I mean, yeah, that's what I'm looking for is the thing that, you know, a good portion of the web apps out there are going to want or need to at some point adapt to that this kind of technology just knocks out of the park. And yeah, I haven't seen it yet either. But it's interesting because we kind of see some of these things kind of hit a hype cycle. that's where we find it. So anyway, let's go ahead and do picks. Dan, do you want to start us off with our picks?

Sure thing. So I've got two picks today, both of them technical. Well, kind of technical. The first one, you know, what with everything happening in Twitterland with

Thanks for watching!

Elon Musk being kind of a bull in a china shop and definitely shaking things up. We're seeing a lot of people that while that environment has a lot of advantages, one of them I guess being no Elon Musk, it

Thanks for watching!

also has a lot of disadvantages, certainly when everything, anything having to do with user experience. And I have found something which is a really useful utility to work with it. So currently I've got an account both in Twitter and in Mastodon and I'm effectively in both. Tweet and to to whatever they call it everything twice So there's this cool tool called more MOA and their URL is MOA dot party and it basically syncs between Twitter and Macedon so anything that you tweet can be automatically posted into Macedon and vice versa their way into Macedon, but not the other way around. It's not perfect, but it mostly works, and actually works surprisingly well. So if you're currently in that stage where you're kind of straddling both systems, I highly recommend it. So that would be my first pick. And my second pick has to do with podcasting. I've recently encountered an interesting app called Snipt. SNIPD and what it does it's a podcast player so you can use it instead of the Apple podcast player or the Google podcast application. But what's cool about it is that it uses AI to actually analyze the audio stream and first of all it creates a transcription so even if the podcast does not have a transcription it creates one for you. But it goes beyond that. breaks down that podcast episode into snippets and chapters that you can jump to directly or save. So for example, let's say, you know, somebody says something really insightful in a podcast, it will actually find it, kind of wrap it in a snippet that you can then save and send to others or maybe keep for posterity or whatever. It's a really interesting tool. I'm still playing around with it. I've not yet started using it exclusively as my podcasting app, but it looks to be really interesting. So that would be my second pick. And my third pick is that pick that I keep on picking. I'll keep it short this time. Ongoing war in Ukraine, still ongoing, still a lot of suffering. Anything that our listeners can do to help, I encourage them to do so. And those would be my picks for today.

Awesome. All right AJ, what are your picks? his pick is his mute button.

Thank you. Thank you.

I'm gonna have to pick Twitter because now that it's under new management, they're getting rid of the child prawn and unbanning accounts that were banned for no reason. And I can't pick Mastodon because they still allow child prawn, but don't allow you to have opinions.

Well, to be fair with Macedon, it really depends what server you're on, because

Yeah.

basically the server's administrator can decide what to have or not to have on their server. The weird thing about it being the fact that you even have to pick a server. Like you say, okay, I don't know, I'm worried about Twitter going away, I'm going to start using this Macedon thing, I want to create an account. What the heck is a server? What does it matter? And then you get...

Well, this is the email question, right? Are you going to use Gmail or Yahoo?

No, but

You

it's

know?

actually not exactly the same.

No, it's not.

I got that explanation as well, that it's really like an email server and like your email address, but then you find out that it's actually not the same because you see, because the level of exposure that you get to content that's on your server or not on your server is vastly different. And if you want to follow people who are not on your server, You know, it's it's not the same, you know, because you can send emails to any email address No problem, and it's not exactly the same with Macedon servers. That's you know At least from what I'm saying, but anyway

So I'm one of those mastodon self-hosting masochists.

Oh

And

my.

like, yes, sure, sure you can say, you know, like, oh, nobody can ban me from my own server is one thing, but honestly, like 99%

They can't,

of the... Oh.

they can! It's in their thing that your server must be banned unless you agree with all of their political nonsense.

Oh, yeah, you can ban me from your server, but like not from my own But like what I was getting at is like 99% of the reason I can choose and pick my own emojis like Twitter Can't let you do that. I have all my emojis that I ever wanted. It's like discord

Well,

but

that's

for

good.

but for Twitter

By the way, I have to say that

Yeah.

one of my issues with Twitter, putting aside all the political nonsense and shenanigans, and I won't even go into that, I have two main points here with Twitter. One was that Twitter was going down the drain or down the tubes before Elon Musk purchased it. It was just

Hehehe

doing it much, much more slowly. But it was still a failing company. able to save it. It's doubtful in my mind. He seems to be doing a lot of damage while he's trying to do anything else. But it was failing before he even got there. So that's one point. And the other point is that we, you know, looking at all the damage that he is or isn't creating, we're forgetting how much we were complaining about Twitter before he joined. And again, not about the political aspect. I'm talking about the technical stuff, like the fact that you couldn't edit direct messages, like the fact that you would be reading a tweet and then it would disappear and you would have no way to ever find it again. Stuff like that, which has been around for years and we've been complaining about

off.

it and all of a sudden all of us are so romantic and nostalgic about how Twitter used to be.

Monopoly is always bad. I don't think, like, you know, like a lot of people, oh, is Twitter dying? Like big companies don't die except that there are crypto exchanges, I guess. But like, you know,

hahahaha

what kind

hahahaha

of happens is basically that, you know, it gave a big boost to Macedon and like a Monopoly is always bad. But like just by having that boost, Macedon might be able to provide

By

like

the

kind

way,

of

did

a

you

counterweight

see

to Twitter.

that the Macedon is potentially going under because of this boost? Because all their financing is coming from Patreon and they're literally running out of money.

But like, you know, Macedon.social, like that server might run out of money, but like there is thousands and thousands of servers

Yeah,

that are

and

just doing

it's

fine.

open source.

Yeah,

There's

yeah.

thousands of servers?

Fuck, yeah,

There's

there

I,

thousands

is,

I.

of users?

oh no, no, no, there is seven

There are thousands

million,

of servers.

seven million users, two million active users, monthly active users of Macedon. That's eight million,

BOTS!

by the time this goes in, like, yeah, it could be a couple million.

Well,

boost.

my thing is, and I was gonna do a Mastodon pick too, so I may as well just chime

Yeah.

in. Because honestly, this week I was planning on setting up a Mastodon server, and I've been thinking about it for a while, and what tipped me over the edge was all the people saying, I'm considering moving to Mastodon. Now, a lot of those people are politically motivated, and I really don't wanna wait into that. I'm willing to wait and see what Elon Musk does, see where Twitter ends up, to use then I'll move and if not then I'll probably be posting there and posting to Mastodon but the thing I like

Hey,

about

Uncle

Mastodon

Bob got unbanned.

Hehehehe.

Oh, I didn't know he got banned.

Hehehehe. Hehehehe.

It

Hehehehe.

was Shadow

Hehehehe.

But

Band.

he retweeted me today anyway

Oh cool.

about the book club because we're doing his book first. But anyway, the thing that I'm seeing is that on a lot of these servers, you get groups of people that have something in common, right? So I saw Dan, I think on your profile, you had like webperf.social or something, right? And I want to put up a top-end devs.social, right? one for a while at ruby.social. It's not official.

But here's

It's not

the

the

thing

official

that

ruby

I don't

team.

get,

But,

and I'll interrupt

but

you for a second. I'm on web.social because I'm interested in web performance. And

Right.

some people there invited me, kind of invited me over. So I said, hey, cool, I'll go there. But then let's say you also, like you said, create a top-end devs.social server. Do I create an account there as well? Do I now have two accounts? What does that even mean? Oh no!

So

I think

a

that's a conversation

lot of the things

worth

you

having,

just, yeah.

but

Sorry.

your account will federate to mine as long as I allow it. And so I

You get-

don't see that you necessarily, unless there's a server that's just putting out 100% garbage or child porn as AJ's pointed out, is out there, right? Then you might wind up saying this can't federate to my server, but for the rest of it, I can see that if they're on then that means that they, you know, are fans of the community or want to be part of the community. That doesn't mean that if you have some other Mastodon account that you don't, but it gives people who identify with our community an opportunity to be a part of our

Sorry,

social network

I just don't get

and

that.

I can...

I just don't get it. I mean, how

So

can

I

I be a part,

think...

like be on this server if you wanna be a part of a community, but oh wait, you can be a part of our community

Thanks for watching!

without being on our server. So why do I need the server?

Yeah.

I don't get it, I don't get it.

I think there is the local timeline and the federated timeline that are two key pieces to this basically that you

Mm-hmm.

have to look a bit more into. Like if you come from Twitter especially, it's kind of the switch. You kind of have to switch over. You don't really discover these. Like a lot of them are hidden, like in the default new interface. So I kind of have to look for them. But this local timeline, which basically shows everybody's posts who are on your current server is really nice. Because if you're a web per social, by his webperf-related discussions or whatever without even having to follow them, right? That's kind of the fire hose, which wouldn't make sense for the entire Twitter, right? Like that doesn't make sense. But like for your local instance, it might be insightful. You can find

So

people

all of

to

a

follow

sudden we're

who you're

starting

not following.

to appreciate the Twitter algorithm basically is what you're

Hahaha

saying, even though we've been maligning

Maybe.

it for years.

I mean, you self-selected into Vepr Social, so you did the job for the algorithm, right? You ended up in a place that

Yeah.

you care about, but what you won't

But

see

I care

is like

about

other

multiple things,

people's

but

stuff.

that's the thing, I care

Yes!

about multiple things.

Yeah, but they don't have to be exclusive.

Well, they don't

Yeah,

have to

you

be

can

exclusive.

follow people from other servers.

But I'm

Yeah.

sure, but I can follow people on other servers, but I can't follow other servers. It's really weird.

This is a complaint and there is a bug about this.

Mm-hmm.

To do this. Hashtag

Yeah.

somewhat alleviate this, but like, yeah, that's a whole another, it's like baby steps. Like people are still getting eye-climated. But like

Yeah.

I think Mastodon has a bunch of concepts that you don't really get until you actually spend some time on it. And like you actually kind of looked

Then

into

I asked

it.

myself, do I really want to spend the time getting those concepts? I'm not sure.

Well, Mr. Musk has been a really good catalyst to make more people want to do that, so

And

Yeah.

by the way,

that's good

I have

for

to disagree

us.

with you, Chuck. I do think, or was it you, Flaki? I don't remember who said it. I do think that Musk can easily run Twitter into the ground. Not intentionally, but

Oh he may.

he definitely

Yeah.

may.

Yeah. Yeah.

I mean, you know, you don't, what, again, I apologize for kind of hijacking this episode and this discussion here,

Thanks

but

for watching!

what people don't get.

Hey, people are talking about it, so it's fine.

What

Yeah

people don't get about software developers is if you, I gave this analogy to one of the HR people in our company today over lunch. She was like wondering how Twitter can run after laying off so many people. And I was saying it potentially can run better. It kind of depends on who you laid off. Because if the whole intent is to just keep the current Twitter going any new capabilities, you can do that with a skeleton crew much more effectively because the ongoing development that you see in a lot of software as a service companies is like people, it's like engineers keep working on a running on a driving car and obviously you can you know have a car running much more efficiently if you don't work on it while it's going but that effectively that you won't ever get any new features and capabilities. So if you're good with what Twitter has and you don't want to add anything in terms of capabilities and features and whatnot, you could probably do it with the right skeleton crew forever. But I doubt

What?

that that's what Elon Musk is trying to do.

Technologically, it might not be changing, but the vibe on Twitter is changing. And this, Macedon is the perfect example of

Oh yeah,

that.

but that's

It's like

a totally

how,

different discussion. That's

yeah,

a totally different discussion.

you might still not wanna stay there even if technically it will still run, but by you not staying there, it is still losing a

Oh,

lot

for

of

sure.

money

And

Yeah.

I

and

totally

advertising.

respect that.

So,

If somebody

yeah.

says, I don't like Twitter anymore, I don't like Elon Musk, it's funny, by the way, to see this fall from grace from being this Tesla hero to the Twitter villain.

Right?

But I'm totally

、あの

fine with it. You know, it's a social network. If you're feeling that this is not the social environment that you want to be in, you know, it's totally legitimate to go away. I'm not talking about that aspect at all. technological aspect.

But a lot of people are saying that he's paying 4D chess and 5D chess because there's a method to his madness and stuff like that. But even he can't basically anticipate the chaos, like, you know, butterfly-winds flapping effect of this kind of networking effect of people really disliking the conversation, deciding to leave, managing to find a booming conversation on Vestadon, whatever. And we're like, oh, I don't have to go back. Like kind of that sort of thing that you can't anticipate because like this layer thing that that just keeps like feeding back

Yeah.

into it. Like even if he is playing

Yeah,

like

but

5D

the biggest

chess like

thing

you can't

is, the biggest issue is that on Twitter, I had an audience of, I don't know, several thousand people that I was interacting with, and there's no way for me

Mm-hmm.

to take that circle of people and bring them over to Mastodon.

True, true.

Yep, true.

Yep,

But that's

no doubt

true

about

of

it.

any social network, no matter how much is in parallel between the two. And

Yep.

people have

Yeah.

to find you again.

Yeah, no, it is kind of bootstrapping or rebooting, so

Yeah.

that definitely does not work.

Yep. But anyway, at the end of the day, yeah, I mean, if you want to come join us, topendevs.social, I'm going to have it up probably right after Thanksgiving. This will go out later than that, so that shouldn't be a problem. I did get the book club stuff up. First call is December 7th, so I'm going to throw that in as a pick. AJ, did you have other picks? Because we kind of

Yeah,

derailed.

yeah, no, this is great though.

Yeah,

I loved

I just

it.

have

It was

to say that fortunately I actually have to cut out. So,

Go ahead.

yeah, so Flakit was great seeing you again. Hopefully

Yeah.

we'll see you in person in a conference, you know, sometime soon. And guys, keep up with the good picks and see you all next time.

Yep,

Thank

absolutely.

you, thank you, bye bye.

All right,

Yeah.

AJ.

Um, so I'm gonna, this isn't really a pick as much as an update, I guess. So I finished the big short. I thought that that was excellent and scary, the audio book. And then I went on to snow crash and snow crash is kind of weird. It's like somebody handed a manuscript, a first draft manuscript that was just the thousand times and handed it to Dan Brown and told him to write Ready Player One. Hopped him up on drugs, he dies of an overdose three quarters the way through, and then Agatha Christie takes over but finishes with Ready Player Two instead. So overall,

Thanks for watching!

would not

player

recommend

2 was off.

Snow Crash. Huh?

I said Ready Player 2 was awful.

Yeah, yeah, I mean it about the three quarter mark. I don't know. I think there was two or three hours left of the book And then this dude who's kind of kind of you know, he's kind of grungy and he's got swords and he's a pizza delivery guy All of a sudden becomes an eloquent scholar and explains all of the pieces of information that you may or may not have picked up Through the entire book and takes a whole huge chapter to explain everything you were dumb and weren't actually reading the book and at that point I from from there forward I just I just had no interest anymore plus the it like I said Agatha Christie you know if you if you are familiar with oh gosh what what is it the train the train the train did

Orient

murder

Express, murder

murder

on Orient

on the Orient

Express.

Express yeah if you're familiar with mortar on the Orient Express When you get to the point where everything's being unraveled, it's just not very satisfying. And that's kind of how I felt about snow crashes when they... With science fiction, you have to pick your rules and you got to pick them pretty early on, and then you have to kind of stick to the rules of that universe. You know, like in Star Wars, you can have faster than light communication, but you can't... can't the last last Jedi it and then just break all of the rules, you know.

I'm laughing because that was yeah, that was anyway. I complained about that

Okay, so Snow Crash, Big Short. Also, there's a YouTube channel called Cold Fusion that I listened to some stuff about the Big Short and the FTX. And apparently there's a new form of obligation bond that's extremely similar to what caused the the the housing crash of 2008 that the Big Short stuff that apparently has been reinvented. type of bond that they're using to do exactly what they did in 2008 well I guess it was 2002 leading up to 2008 when it crashed or so and then but but good news I'm gonna pick my the company that I that I work for savvy savvy legal I if you are a startup founder and you hate doing the paperwork bits but you're at a point where you actually have to do them because you're getting investment or you're having some sort of business lifecycle event where you you must do the paperworky stuff savvy what we do is we make that easier so if you don't want to do it you know you still have to get from zero to one you still have to actually get your ducks in a row and get some of your documents together And then I'm also going to pick the Dash cryptocurrency. It makes me sad. All these scam cryptocurrencies. I guess that's all of them, except Dash. As far as I know, they they they get a lot of money. They get a lot of money. And then I'm going to pick the Dash cryptocurrency. And then I'm going to pick the Dash cryptocurrency. And then I'm going to pick the Dash cryptocurrency.

Thanks for watching!

get stupid people involved with a really smart people, I guess, and they do scamming things and they crash the market. Um, and I think that what Dash is trying to do is actually good. Um, unfortunately, because essentially the, the way the Ponzi scheme of cryptocurrencies works is diversify, diversify, diversify. And I won't go into the whole, how the, the, the staking and the interests in into this, but basically the rule is diversify, diversify, diversify because it in short makes it so that one cryptocurrency can prop up another so that its value raises so that Ponzi scheme.

It's almost as if people are the problem and not cryptocurrencies.

Well,

Yeah...

yeah,

Yeah.

the technology is a problem too, and Dash has problems

Oh yeah.

with its technology, but the community that's behind Dash, they have the, a right idea, the right idea perhaps, of trying to solve the problem of making it easier to have digital payments. And so, I would not recommend to anybody to invest in Dash because it's not the kind of thing you invest in, but if you're interested in using an online currency, Dash is probably got more. Connected pieces overall than anything else, it seems, in terms of you can go to your local coffee shop and you can spend Dash right there through there's an app called Dash Direct and some other stuff like that. There's a lot of things that are coalescing and coming together. It'll probably all get shut down and with as the regulation comes out from the FTX scandal and some of the other scandals and the central banks of the nations take over their own digital currencies and edge out the populist currencies. But at least for now, it's an interesting ride and I'd encourage anybody that's interested in that to check it out. And then of course, if you

Alright.

want to follow me on on Twitch or YouTube, beyond code for the the focused stuff in Cool Age 86 for the ramblings and live streams.

Thanks for watching!

Cool. All right, I'm going to throw in my picks, and then we'll let Flocky go. We've gone way over, but anyway. So yeah, I'm putting up topendevs.social. Feel free to go set up an account. I do plan on periodically purging in active accounts, so just be aware if you get on. I just want to make room for anybody who wants it. Yeah. Anyway,

You're gonna self-host? That's your plan?

I think so. some of the hosting options out there and I don't know anyway. So that's one pick. I usually pick a board game. And I think last time I picked Betrayal at the house on the hill. So this time I'm going to pick a game called 10 Penny Parks. And I'm not sure if I picked this one, actually. But anyway, we taught it at the board game convention. It was a lot of fun. And what you're doing is you have kind of a plot of ground that you're building your theme park on. And you take turns. It's a worker placement game. So you put your worker out and then you do whatever the space says. You can remove trees from your space or you can buy an attraction or you can set up concession stand or you can... What are the other ones? You can get money. Anyway, so at the end of the game what you're trying to do is you're trying to have attracted the most, they call them visiting persons, which is a play on VP, which in game lingo is victory points. So your VPs are your victory points. And you do that by building the attractions and then you get money every round or other advantages every round based on what you have in your park. And it's a lot of fun. board game geek weight of 2.21 which is you know it's right there in that kind of casual gamer setup there are a lot of pieces and it takes a little bit to figure out how to play it but the reason it's weighted low as low as it is is because the turns are really simple right you place your workers and do what they say and then you get money and you know you get your advantages you can do five rounds. So anyway, it's a lot of fun. It's very theme park themed.

It just

Really,

made me

really.

really want to play roller coaster tycoon again.

Yeah, roller coaster tycoon. Yeah, it's kind of the same idea in certain ways. So yeah. But yeah, we'll put a link to it in the show notes. And then the other thing is on Sunday, so yesterday, was game one of World Cup 2022. And I probably pick this every four years. So I've probably picked this two or three times so but I freaking love watching soccer and I really love watching World Cup. It's fun to watch the Women's World Cup because we've had such a terrific team for the last several years. The men's team does okay but I don't know that I have ever gotten my hopes up that they're actually going to win the World Cup. So anyway, the US team and then yeah I know people are wondering who else I root for. I'm disappointed that Italy hasn't been in it the last time or two, just because I lived in Italy and I love the Azzurri. But I do root for France and England. And then just kind of watch to see what else happens. I have warm feelings toward Argentina and Brazil as well. So anyway. And I like Japan. So yeah, there you go. Those are the five teams besides the US that I'm probably gonna watch. And we'll see how it all goes, but they're in group play right now. And here's hoping. So yeah, those are my picks beyond just letting folks know. We're gonna start doing the calls. We're gonna have a Q&A call and a resume review call as part of the membership on Top End Devs. And then I'm bringing some people to talk to us about how to read code or how to do different things. Maybe some people to show us tips and tricks on VS code and crap like that. So if you want to join, go to topendevs.com slash sign up. I think it was the first 10 people or 20 people. I can't remember. I think I said 20 people on the other shows. Anyway, the first 20 people get in at $39 a month and then it goes up from there. So then I'll raise it 10 bucks and $49 a month. I'm gonna stop when we get close to $150 a month. So that's where that membership's gonna end up, but we're gonna provide all kinds of valuable calls and content. There's gonna be a JavaScript monthly call that's part of that, and then calls for the other shows that we have as well. So Angular, React, Vue, Elixir, Ruby, DevOps, Machine Learning. So if you're interested in any of those, we're basically gonna have an online meetup group for people who are paying members on top-end apps. Yeah, and then the book club, obviously, and it's $17 a month, and we're starting with Uncle Bob's Clean Architecture. So those are my picks. Flakey, what are your picks?

Well, I mean, I'd be remiss if I didn't pick us as in suburbital.dev. Like I said earlier, if you're running a company, probably startup or more into something where you need something beefy and you've ever thought about, oh, gee, this would be really cool if people had a way to write code and customize some parts of our application that they want to. And we could do this without having to worry about somebody breaking your live infrastructure or something like that. Do check us out. We just released our SC2 customization engine or plugin engine. Part of this is open source. A lot of this stuff is written in Go. Some of this stuff is Rust and WebAssembly. So a lot of stuff to learn as well. So that's my first pick. My second pick, I have nothing to do with it, but it's a wonderful language. are G-R-A-I-N, I guess. Yeah. The programming language, grain-lang.org, perhaps. We're going to probably put it in the show notes. Our CTO has created this language way before he was CTO. It's inspired by a bunch of functional languages. So if you are a functional language nerd and want to explore how WebAssembly feels like from a perspective of a language caters directly to WebAssembly. That might be a cool thing. So check that one out. And I wanted to bring up something that is a big thing here. I don't know how that works on the other side of the big pond, but it's definitely in Europe that has been a thing. Since the start of the pandemic, a bunch of people have been taking on dogs and other pets, or kind of adapting them or whatever over the pandemic days. And that basically is gone. A lot of the world economy going down, all that stuff. Basically, what we are seeing, a lot of countries are experiencing this, is that animal shelters are really struggling. A lot of people are giving back all these pets. And not a lot of people are taking on you dogs, part of because being commanded back into the office from home, we have heard previously for Mr. Musk, or just simply the economical situation changing. So please consider supporting your local shelters. It's never a bad idea. And since Chuck brought a, what is that, like a game,

board game.

board game, thank you. Since Chuck bought a board game pick, I'm gonna give a shout out for Daybreak. like I have previously. It's from the creator of Pandemic. So that escalated quickly, but this game is actually about stopping climate change together. So if we can get it manifest itself through sheer will of people in a couple of years, that could only serve us right. So this is like, I think it's being crowd-funded, so I don't know if you can actually buy it or not. But it sounded real cool. I mean, like a background that. So if you're into board games, do check that out. That sounds really cool. And yeah, that's pretty much all my picks. I'm going to say, yeah, like I said, I'm a Macedon self-hosting geek. I kind of give it up on my Twitter account. So you will find me at Flokki, at Flok.is, F-L-A-K dot I-S. And F-L-A-K dot I-S is also where you'll find all my contacts. But if you're into Macedon, I'm sorry, self-hosting or want to talk about each other, have questions, I'm super happy to talk. So feel free to DM me there. Or if you're just like, really don't get what local and federated timelines are for. So I'm super happy to talk about message on stuff or that migration or self-hosting.

Very cool. Yeah. I said I'd have it up by Thanksgiving, but I'm probably gonna have it up today. So,

Hahaha!

it's just fun stuff. And

Yeah.

I love the community aspect of it. So,

Yeah, absolutely really cool.

and I really wanna make it easy for people to, in their social media consumption, get whatever it is they need. Whether it's from me and my team, or from the other hosts, or from people that just like the shows and wanna share. This is

And

just another way to do it.

honestly, as long as you're not an asshole about it, there are big servers like Microsoft and technology and whatever going down,

Uh huh.

that people use day to day. And it really is not another Twitter exodus, right? Oh shit, my server is going down. I guess I'll have to migrate to another server or spin up my own or something like that. And it really just changes the calculus. It's like, yeah, just choose pick a server that doesn't have literal right-wing Nazis on it or something like that. choose something maybe close to what you like. And if it doesn't work out, you can always just move on and find another one or host your own. It really kind of takes off the calculus and makes it kind of lower cost for people to experiment. So I encourage people to experiment with it. So I encourage people to experiment with it. So I encourage people to experiment with it. So I encourage people to experiment with it. So I encourage people to experiment with it. So I encourage people to experiment with it. So I encourage people to experiment with it.

And

Yeah,

don't forget, you

I'm

don't

just

want

gonna

to pick

chime

a server.

in.

Thanks for watching!

You don't want to pick a server with left-wing Nazis either

True, true.

Yeah, yeah

because.

I was gonna say I mean I kind of clock in on the right side right-wing side of the aisle but

Okay.

at the end of the day right it's you find you know if people bother you I don't have any problem with like a block feature or go

Thanks for watching!

somewhere where they're not going to bother you. So

Yeah, that's basically what I meant. It's like, just find a place that makes you not want to

Yeah.

pull your hair out. And if you chose wrong, you can always move on.

Yep. And at the same time, you know, be good to other people too. Right? So yeah, like, like AJ saying, there are people who are hardcore, you know, shut you down hard on both sides. And

Sure.

so, yeah,

Yeah.

you know, if, if they aren't your people and it's driving you crazy to be there, then don't be there.

That's kind of the whole point about it really, is

Well,

that...

that's why I like the federated nature,

Yeah.

because you can

Yeah.

choose. And then the other thing is that, yeah, anybody can spin up a server. So if it's not your cup of tea, you can other server it.

Yeah, this is totally something I just said like two days ago, somebody is like, we all have our bubbles, right? Like,

Yeah.

and just messed on, you can kind of make them a bit more explicit than like on Twitter, right? But in Twitter,

Yeah.

like the people you follow, the people you mute, the people you block, you still make you a bubble, right? Like

Yep.

make yourself a bubble. So it's like kind of the same idea at the end of the day.

Yep, I agree. And to be honest, I mean, I don't have a problem with people sharing their views, whether they agree with me or not. But if it turns into a giant war on the Mastodon server, yeah, I may come in and say, hey, knock it off, right? We're here to share. We're not here to attack each other,

And

but

like you're the boss, right? You can do

yeah.

it. And then somebody doesn't lie to you, like they can just move on.

Yeah.

That's the whole

Yep.

point about it. I mean, you're going to be an a-hole, and your message on server, like admin is not going to like what you're doing. They can just

Yep.

gently toss you out.

Right. And if you want to be in a hole, you can go spin up your own server and be in a hole over there.

Exactly, precisely. Yeah, at the end of the day, it's all bubbles.

Yep.

But here you have a choice, and here you don't have to burrow all the bridges. And here you can choose your own. It's

Yeah.

kind of what people say. People don't have to listen to you, right? This is not part of free speech. So if people don't want to listen to you, they can block you on Twitter, or they can block you on Massadon.

Yeah, I think the thing that I want to say about this at the end of the day is that top end devs, we're all about helping people figure out where they want to be at, figure out what fulfills them, connect those dots and then give you all the resources you need to get there in your career and then have that support the lifestyle you want. And so

Mm-hmm.

the main thrust of what I'm hoping people share on there is that stuff, right? It's, hey, I did this in my career, it really helped. I learned this thing in React, it really helped. wasm episode and it really helped. I had a talk with Flocky, he got on a call with me and he explained this to me and it made a difference. That's the kind of thing that I'm hoping we're sharing. And then yeah, if you're sharing your other life stuff too, it's, I can't believe that political blah, blah, blah, blah, blah, fine. But ultimately, this is a place I want people to be able to come and say, if I'm on the top end dev social The vast majority of the content i'm gonna get there is the stuff that's going to help move me ahead and help me reach my goals and be successful where i'm going.

But a lot of the time, moderation just comes down to whether you said that people should talk about this stuff and not that stuff, and whether you warned people if they were talking about too much of the other

Yeah.

stuff. And at the end of the day, there's always going to be somebody who will decide that they haven't been treated fairly or whatever. But

Yep.

that's just moderation everywhere. Because you inspired me.

Oh yeah.

That is literally about just what you said. It's a forum instance for people who are building a web assembly or building on web assembly. So really, you just go there, post your blog post or whatever. You just put a cool thing in web assembly. And it's collaboratively operated by some of the people in the web assembly, like ecosystem, like Fermion, the folks that I mentioned, us, Suborbital, and a bunch of other folks kind of came together to build exactly this, what you just mentioned. Come here, share your experiences. is like hang

Yeah.

out with people who build this stuff. So yeah, wasm.builders, I believe that's the website.

Yep, and that's the best thing about the internet, you know, no matter where or how we share stuff is the fact that we can put our heads together and make awesome stuff.

Cool. Yeah. Totally

I'm going to

in with that.

throw one more thing out because I mentioned World Cup. And that is that you can watch the World Cup videos. So the live streaming, you have to have a Fox or Fox News subscription. But after the fact, they are putting the replays up on Tubi for free. So it's T-U-B-I. And that's the way I'm gonna watch them because I'm freaking busy. And so I'm kind of picking the times when I can go watch the matches. and you don't care if you're watching them when they play, there you go. And they do start kind of early in the morning, so. Anyway.

I just hope people use content warnings and don't share spoilers. Or

Yeah,

message

that's

the doc.

the trick, right? Is, yeah, don't tell me who won, cuz...

Oh yeah. Yeah,

Yeah, anyway.

for the past two years, I've been doing a lot of digging around video streaming technologies. And at the end

Uh-huh.

of the day, a lot of the latency stuff comes down. It actually is in broadcast latency. When somebody is watching cable and somebody is watching satellite, and this actually came up with a VertCop, is that when you hear your neighbors and the city basically crying out a couple seconds earlier bit of gold or something, that sucks. So basically 97% of the broadcast industry is trying to reduce like stream latencies and shit like that, just so this does not happen. It's pretty fascinating stuff at the end of the day.

Yeah. All right, well, let's go ahead and wrap it up here. The Macedon talk wasn't what we were really on for, but it's something that people are on about, and I think it's worth having a discussion and just letting people know what their options are if they decide that Twitter's not a go for them, or if they're looking and trying to get validation on, hey, maybe I will stick with Twitter because I'm planning on it unless something drastic changes.

So this is gonna be up in

point

a couple

of view

days.

from somebody there too. What?

is that this is going to be up in a couple days.

I think it's going to be up in a week or two.

Yeah, it's going to be interesting to see how many users Macedon has by the time this goes.

Yeah.

This is a fast moving stuff. So by the time we arrive at that, half of the stuff is not even like half of

Yeah.

the predictions or result and stuff like

Yep.

that. There is a whole thread somebody put together on the 30 different ways this could go down. That's pretty fascinating, including it goes to shit or it goes on the way up.

Yeah, we'll see. We'll see what happens. Anyway, this was fun, flocky. Thanks for

Thank

coming.

Flaki:you for having

Good

me.

to see you again, AJ.

Yeah.

Until next time, Max out.

Yeah, thanks. Bye bye.