Hey, folks, welcome back to another episode of JavaScript Jabber. This week, I'm your host Charles max Wood, and we are here with Matthias Matts and Matthias. Do you want to just let people know who are I know you're the CEO at Whole Punch. You do the peer to peer stuff, right, You've got some other stuff going on.
But who are you?
Like?
What's your story? Sure?
Yeah? First of all, thanks for having me. Awesome to be here. I always love to talk about JavaScript basically.
So yeah, like I said, I'm the CEO a Whole Punch not but first and foremost, I'm always like a JavaScript hacker. I've been doing JavaScript for ten fifteen years now. I started when I was in university. That's when I started programming. We had a mandatory Java. At some point, you know, I google Java and I got JavaScript and I started doing that and I never looked at ever since. I've been a pretty significant contributor to the no jets project.
I've done tons of open source modules for NPM. I think I have around fifteen hundred on there now, like quite a significant amount.
I usually say, if you.
Have box, I'm sorry because I've probably made some of those and I am a big lover of JavaScript because I think it's one of those languages that just oddly enough that people use it to make things where the point is not to write code, is to write things, if you know what I mean. Like it's not art,
it's like engineering, which I can't. I used a lot to do all kinds of things, like I said, fifteen hundred modules, but I'm especially in love with it for doing distributed systems and peer to peer because I think it's a perfect candidate for that because it runs everywhere, it's easy, it's very good at moving data around with the abstractions.
So I've done a lot of that, and recently.
Before years ago, I started a company with a couple of friends called Whole Punch that is focused around Peter peer engineering with JavaScript. So it's really fun. We've been going for a while with accurring a lot. Yeah, and so now we're just doing all kinds of things with JavaScript and native code and mixing that name with the JavaScript and making like crazy Pewter peer things and yeah,
tons of fun and tons of really cool projects. We're really trying to disrupt the status coe and it's it's it's yeah, it's going quite low.
Awesome.
Yeah, I'd love to dive into some of the peer to peer stuff. Are you doing like web RTC or is it different than that?
So it's really funny because I actually think when I think about my transition in JavaScript is kind of like like experience in JavaScript. The more I've done JavaScript, the more I moved away from the browser and more like just writing JavaScript outside outside the barrows APIs, which I think is a journey. There's a lot of people have
because the language is just really good for that. So as anybody else, I've done a lot of dabbling with to see and building things and then at whole punching me and general I'm very into like building serious the technology that is like not that repudcy isn't serious, but like things where we can kind of like reporty Cy is usually meant build to like tag.
On things to like another.
It's kind of like you know, uh, it has like a chat video thing and stuff like that, but it's not really meant to be the backbone of your applications. So we're like more about building things where everything is peer to peer is like as a primitive build into everything, so you don't like you actually don't do.
HDP, you don't do TCP, you only use Pewter pre data structures. But with JavaScript that do that.
So so we actually don't do any of that, but we build a ton of primitives out for doing like you know, like hope punching. That's part of our name in the company that connect. That means connecting people behind firewalls, like you do in webar dec but like much better because the report se stuff is a bit dated there.
Moving terabytes all day around with that kind of stuff media files.
And then and then, and this is my favorite thing about JavaScript, presenting that to like users with some manpis that are somewhat familiar with them so they can just do what JavaScript is also really good at, like building your eyes and plugging that data in, which is very hard skilled to have. Also, and we have a lot of talent people in the community obviously, so we're like about like JavaScript and to end and then like allowing
people to build applications. Obviously there's a lot of CN and C plus plus and there also to make that.
Stuff go right sounds good.
So so yeah, so you're not doing web RTC, you're doing you're building BitTorrent and Dropbox.
Yeah, and I actually started when I first started dabbling in Pewter peers. I built that peer client for for bitttern because I was like, that's like a fun little thing to do, and that was a.
Crazy cool experience.
I always tell this to people if you ever, it is really fun because bitturn has one.
Of those things.
I did it like that was like ten fifteen years ago when bittern was really really big and it was everywhere and like you know, rate day was a website you could go to.
Now I think it's probably blocked everywhere.
Yeah, I don't know, but yeah, not that I've ever used pirate a because I would never do anything illegal.
It's good for donalding Linux, I heard. But it was really cool. It was really cool for.
That whole you know experience where you just sit on your laptop You're like, what should I play with? But all the data is actually out there because it's distributed and everywhere, so you can can't just sit there and build a little program on your computer. You can go to Wikipedia and just read this BAC. It was It's like it's actually not very complicated once you you know, understand the first bits of it. I just went a
couple of weekends in a row doing that. But I and I've mentioned this many times on all interviews, but like that whole feeling of like it's just me my computer, JavaScript, everything is everywhere. Once I can just sit here and write code and never have to give you anything else. That was like that triggered triggered me massively to to dive into this, and uh, yeah, I build a little
torn client from that that's still out there. Was called the pure Flex pretty popular, but yeah, it was like a crazy good experience and I've never looked back ever since.
Right makes sense.
So we're going to be talking about the Bear JavaScript run time. But you were talking before about the pair system that you have for.
Yeah, for peer to peer stuff.
And one thing that I was curious about is it because I'm gonna ask you what it is, but I also want to figure out what it is. And then how that led to you creating another runtime because it seems like, you know, we've got Node and Dino and bun and so you know you're doing something maybe a little different. Why does that lead you to, oh, we need another one of these things?
Yeah? Excited? Oh yeah, Like I said, I've been doing not what I love Node for a long time, and we build out our high stack that's like no modules like anybody else, native code of the stuff.
Note has a really good native language or facing with C and stuff that we're big fans of. We build all stuff out was great and at some point, as anybody else who builds no GS apps, you want.
To distribute them, right, so you make an app these.
Project modules modules are really easy, and you want to make an application, and actually, like make an application is I think still surprisingly tricky. It's like where if you're building a web application, there's tons of stuff out there for that, Like you can you can make a little app and maybe you can go and get a server and you can host engine X and or whatever. But if you want to make something that's like a desktop app,
you can use Electron. But it's it's it's it's the process that once you start doing the end all the bits, like you know, making the app, packaging and uh, getting the stuff in there, getting the native stuff to Ron, distributing and getting updates in there, getting that to Ron, it's like it's not as simple as making a Note module, and like it's a real investment.
So you end up just making one app.
Where I would normally make like one hundred modules, I probably made like one or two apps because that that investment, it's just so intense every time. So so we had all the code for pew tore peers, so we decided, like why not make an engine. That's what the pair system is, pair and bear we'd like like to make puns on that.
So it's two different things.
But the pair pair system was like an idea to say, what if we instead you could just make kind of like you make a module and like a website. You can just make a little thing on your computer. It just has the modules. You run it through this cool thing which is called pair that you can go to pairs dot com and you can you can try it out and it just packages up into like a little app with all the tooling, and then that app is distributed to peer on our PTP network.
So like you don't have to have any like hosting anything. You can just kind of like.
You do with like like I said, with you know, normal normal things. You just package it up, run at a simple command and you get a link out and that link. If anybody else has this this run time install, they can just paste it and they can run the ABB anywhere. And then instead of spending in tons and tons of time making and you can just make them as easier as you make modules. And like again no hosting costs no in think because it's.
Just distributed putre peer like you know in bittern.
So so so we deep that on that quite a bit and we made something really cool for that, which is, like I said, called pair that does all that stuff.
It's super cool and.
As part of that journey for us, and I think this is actually a huge missing step up the gaoscript, We're like, it's super cool to make these apps, right, So we have an app that we build that called Keat, which is a chat app. We do that as a puture pewer chat aup is super cool. Also, let's building all this stuff as no just developers. As soon as you make an app like that and you make it and it's cool, looks great and it has all the cool stuff, the first thing people.
Ask you is like, cool, when is it nonmobile?
The answer was always like, oh, yeah, you know, we don't have a mobile team yet and I can kind
of scale it up. And it was like you know that that whole feeling when it's like a fork in the in the in the process come to a degree like we have all this stuff figured out for doing desktop development and make a cool notejas things for this top and for servers, but like getting that stuff to run our phone, just like you will find some like two year old project and maybe got something to work at some point and it hasn't been maintained because it
was an experiment and stuff like that. So and there was already really good you know, UI tooling on mobile like reac native is really good. All the things are really good on on on on phones to make UI apps kind of like react this really good on this stup for making UY apps.
So we're really missing that part. We're like, well, what about the bag end?
So in period, the back end runs everywhere, like you don't want to run it on a server, You want to run that ud the device. But the bag end has much different capability needs than than a front end, Like you need to be able to load native code so you can like you know, do stuff like video trends coding if you want to do that on the phone, do stuff like native networking if you want to do that.
In the phone for modules.
So so we very quickly decided like, let's try to get not jets running, and we just couldn't do it because it's like it's just not made for it, and the module system is not made for and like making bills for like again, I totally started to understand why these partics pop up and never really go anywhere because there's there's too much stuff, there's too much things to fight, and so instead we were like, well, actually, what is the thing we want to we really love from no
DS And for us, that's like the module system MPM. That's amazing, it works. It's like one of the most well designed things ever. Uh and and the native system for know like how to interface from note to see the thing not not a lot of people do, but when you do it, you're you know, it's it's amazingly well designed. No years, so we're like, what if we just made a new run time that actually didn't have any of the other stuff, because all the other stuff is actually what made it hard.
The other stuff is.
Like things like AGP bindings, things like fastest and bindings. Even though that sounds kind of insane not to have it, that's the thing that makes it really hard to port, and instead just had a module system. So no APIs a module system, a native system. And then it had a stated goal of saying, with those two things, how can we make something that actually runs everywhere, So like something that you can write a module once it runs on this top a mobile phone, your smart light bulb,
if it has to run time anywhere. And we made this little thing for for our PTP engine pair and at some point we were like, wow, this is actually insanely cool by itself, so we decided to split it up into Bear. So that's why the pair bear Plunk came in.
So we.
Officially released this I think it was last week. It's been really exciting, so that's that's the bear JAS run time. It's bare because it does nothing but but does everything, so it only ships a module system. It only ships this native thing and then it just we just made I think we already made like two hundred modules for it. So if you want to use like file systems, you just install a file system module that runs again, because it's using these bindings everywhere. On mobile we use a
binding for doing push notifications. That's the thing you obviously don't want to use that on desktop. Then on desktop you want to do other things like maybe we on an HTP server, you can do that. You can also do it the mobile.
Uh.
And we just did this because you know, we wanted to unlock our own development. I am a big believer in modular design, and that's that's part of it. But I was very excited when we did it because I'm like, Wow, this is actually what I've been missing my entirety is career.
I think. So it's it's it's super cool and super.
Yeah.
So I guess what I'm curious about, just to start off with.
Is.
So it it's it's a bare bones JavaScript implementation as opposed to say note or bun or whatever that pulls in a ton of stuff. I mean sometimes that ton of stuff is nice to have, but yeah.
Yeah, it's basically saying it's flipping in it around a little bit, saying it's just JavaScript, what anything? So like JavaScript without anything, it's actually hard to define, right. I don't even think like where does the specs stop and end? Because you know, stuff like where the people might think that's part of JavaScript because it's there in the browser, but it's not really, it's something it's like a different
spec it's not a language thing. But then there's other things where you're like something like a type the array in JavaScript, you know, like you and AI that ray is that part of the language, and that's that's very part of the core of language. Is it's actually really hard as unless you really going through like what this JavaScript is. So for us, we're like, we just want something that just runs the JavaScript and has the only
thing bigd in is like a module system. You want to be able to somehow load things, so like import. It's very important and clear rules about how that import works. So we still follow the note note modules algorithm, which means you can stall things from MPM because then you
get free compatit and stuff. But everything else, and this might be a little bit controversial, but everything else actually just makes your life harder because like if you have something like a file system build in like you know in NOGS you can do require f as you get a file system. Right, that's something where you're like, wow,
that's the feature, and it is a feature. But for me as a SUM as a developer, it's also a what's the word liability us If you just get that from the runtime if the runtimes give you that API, what's the version of that API you're getting, Like, are you getting the latest one? That's like in NOE twenty four A, you're getting into one from No.
Eighteen.
Well you might know it because you're installed note on your computer, but if you're running it on somebody else computer, you don't know. As that API changes, it becomes actually really hard to code against. And the only solution is that that ABHI basically never changes, which is then why we have a lot of this stuff in nogs will. Really why is the FS module still using callbacks for example as the default, Well, that's because we don't want
to break all stuff. If instead there is nothing built in only the javas respect which is very build around never changing. And you then load modules, then modules can just change. You can just kind of like React changes all the time, right, You can just publish a new major version and then people on the old major version can just stay and now one that's fine, and then people who want to get the new stuff can just
move a new on and you never break anything. So you can just have this rapid rapid iteration of like crazy designs that never break anything. In practice, The plot side of that is then you also don't have to ship that code around. So that's really useful for stuff like mobile where you have different kind of footprints, like
a mobile. If you're running an application that uses JavaScript on mobile, maybe you don't want to load like open ass a cell from not yes because you're not using and that's a big dependency and liability and also something you have to get approval for in the app stores and things like that. Or if note adds something else, you just want to run run the JavaScript and then you just want to pull in exactly what you need.
So that was our design goal from the beginning. And for me, that's one of those things again when you hear about it sounds like an empty feature, but I think it's you know what I mean with the normal distribution with the guy in the middle, it's kind of like no modules on both ends. And the guy in the middle is like, I love all the modules, Like you actually want to have nothing ship with rue time.
You want to have nothing ship with your run time, and then you just want to pull in all the things. And and I'm talking a lot, but I'm excited about it. But like and add the benefit of that is like again, if you look at something like Bond, I think Bond it changed course a little bit, but one of the original things about Bond that was like a cool thing was like, it's not based on V eight.
It's based on jobasrip core I think the one from Webcait.
And it has different profiles and it's very good at other stuff, and like VA is better and other stuff.
So it's kind of like there's like a major for you, Like you want to use j's core, well, the.
Need to probably use Bond, you want to use VAH should probably use note when you do a runtime like this where basically saying there's nothing in here except the language and the module system, then changing jouascrip inmentations and all of a sudden really easy because you're not really doing much.
Except for that.
So our guys made a cooler library called lip jas, which is basically just like a binding an abstraction layer for any engine because that's really easy, easy to define, okay, and that means that in there we can support any JAS engine basically. So we already have it working on MB eight because we is awesome. We have it working on JavaScript core. So you know, if you want to use that on iOS. It can just run that seamlessly.
Am Song made this really cool JavaScript engine I don't know if you know what, called jerryscript, which is like a JAS engine based for embedded systems, so it runs in like have a Megabytom memory obviously like slower and other things, but like it means that they can actually run.
On things like light bulbs and stuff. Bear runs with.
That straight up, and that's cool.
And you as a module offer when you write modules to Bear, you don't know any of this. You just run you just write JavaScript, but it just runs on this straight up. So you can actually take any band module out there, so you can take out we haven't you know, We've made a module for five systems called Bear.
Affets, which is just a module you can donald.
So you can actually install that and run that on Jerry script and run it on a light bulb. But you can install that and run it on jais corn, run on Iris, or you can run it on V eight or whatever. And I think that's like that to me was like wow, this is where this is gonna you know.
On people. Once people realize this is like this is going to be crazy.
That is crazy. Yeah, I'm imagining, you know, I mean you kind of go nuts, you put spider Monkey on there, you.
Know, whatever floats your boat. That that's interesting. Yeah, So.
It's like just to add on that because it's almost like I think it's one of those things where people don't realize almost like the implications of that. But for example, like if you do move Mobile development and you want to run something that reacts to a push notification on iOS, that's something you can do.
On iOS.
You only have like twenty megabytes of memory to do that, not to be nerded, but like that's a requirement. So if you run if you run V eight with that, it's like V eight takes fifteen megabytes of memory. You have five five megabytes of memory for application. You feel like the guy who's like programming the program to go to the moon, right You're sitting there optimizing every line to like make it fit memory right in like twenty twenty five.
It's insane.
So what we do is we just swap it out for jerryscript, same code. Boom, memory goes down. It's the same as writing it and the sea basically because now it's like footprint is very small and Rue's slower, but doesn't matter. It's in the push notification and now we can do all the things, right, So it's like you can pick your battles at a reason.
Yeah, that's that's really interesting. So let's talk about mobile for a minute, because I mean we've done shows on things like Capacitor or Ionic, right, and so those those just use the web WebView, right, and then they connect to stuff through the JavaScript core bridge on iOS and you know it kind of does the things. And yeah, running some of these other engines, I mean, there are languages you can't run on iOS because you know it does.
There are various reasons. I'm not going to get into them, but some of it's because it opens the gate to certain security things they can't sandbox it properly. And sometimes it's because, yeah, those languages just take up too much in the way of resources. But when you get down to other things like React Native, I mean, they work almost exclusively across that JavaScript bridge, but they're still using
the runtime JavaScript that's built into the phone. And it sounds like what you're doing here is you're actually saying, hey, we've got this other JavaScript engine that you're going to run as part of your app, and I'm assuming if you ploy an app to the app Store, it ships with the JavaScript run time embedded in the app along with everything else. And so my question is you're nodding, so I'm assuming I'm getting it right. My question is, yeah,
what kind of limitations are there to this? And then the other question is is what kind of advantage does it give you? Because I'm aware that some apps, depending on if it's JavaScript, the iOS for example, thinks of it as an as an asset, a static asset, as opposed to or at least they used to as opposed to you know, part of the app, and so you could actually do a hot reload and things like that
with it. And I'm just so I'm wondering, like what doors does this actually open beyond sort of performance and having my app run there and on the desktop.
So yeah, super interesting. It's actually you're very very much under my track here and in general. So so for example, our app, we our chat up key, which is our flagship app, will we deploy orders. It's a RAG native app, and we have a bunch of reagnative developers. We're very good at making stuff REACNATD. I'm big, I'm a big fan of Reagnative and the way they do stuff, and
like it's it's it's it's a really cool project. Very very still very underrated project because people just sar JavaScript and sometimes you know how people are to freak out, but it's like it's it's incredibly well designed. So we actually run the way you describe where we run, and we have a module for this with React native that just integrates the runtime with reacnative, so dot the hot reloadings and whenever you update the code order stuff. It
works like magically. World is super cool. So we run the run our runtime next to the Regnative runtime, kind of like you would run a back end normally, right, so you have like a separate process normally runs on a server. You run it on device because we use it mainly for future peer but we use all kinds of things where you then ship the run time with it.
It's it's not that big.
It's like I think it's like ten megabytes. The reason why to do this is many many reasons. One is like, yeah, like you said, you can do all kinds of performance things. The runtime has a very clear defined native interface, so you can you can make native modules, which is very important for us. Like, for example, we just made some bindings for we need our app for fmpech for doing like video conversion and stuff like that. So we write them. You write a what module wants for Bear, you write
bind to the native language. It runs, and nodias and runs and Bear. Then it also runs on the phones immediately because that's by part of that contract, assuming like that the phones can you know run thus that that CE library, but honestly almost always they can, and you never touched that code again, and it's like globally universal everywhere, and that's that's the true unlock. So like we're iterating so much fast now because we never really think about
that bridge of crossing the things. I think people are overfixated on making cross platform UI things, you know kind of like somebody will probably say, well, you can run reagnative on the desktop also, and then you can maybe do some of the same things, and like to some degree that's true, but it's also like by overcoupling things to U I react native visit your I framework, you're not getting that like massive iteration speed that you get from like making no jezz modules where no jets modules.
The other way is like something not nothing to do at all with with UI, but.
It's just like making functionalities that then you know, enhance your app and enhanced your back And so we do the same thing with Bear modules. So you just write them once they run everywhere. By composing your app logic for these modules, you're actually just making an app ad logic thing that does all kinds of things like image scaling like I said, or like just run your engine
for us. It's running like a whole piece of peer stack and you literally doesn't change it between desktop and mobile or embedded devices, is exactly the same code you run it for us. That's been like one of those like wow, we went from like working you know one x ten x now one hundred x faster, Like it's crazy how fast we can literate now because we never think.
About honestly, and this is like really true, we.
Never think about those boundaries anymore of like where else this run and we just right it and then runs everywhere. And for the deployment stories and all that, it's just meant that our teams are just so productive because we so we have the way we start to that it's like we have a mobile team they work on really native that's obviously very focused on mobile. We have a
desktop team. They've worked more like making like webuiyes that you do more on thisktop through our run time and then they all share this beare code that upsets for a team does that enhances all the apps with all the functionality, and that's like just the best kind of app development I've ever seen. And that's that's really exciting to me. And it's the first time I've seen just like those two prongs just accelerating that way together as one team basically, and I think that's that's the true
unlock and that's yeah. Again, it takes a little wrapping your head around, but it's like it's it's.
Really yeah, it it feels a little bit to me almost Like so people who listen to the show know that I'm primarily actually a back end developer, and I'm typically working in Ruby on rails and not on a JavaScript back end. But in fact that's that's what I I just got a new job working doing that for price Picks. But what's interesting is with this is it almost feels like you're shipping it with a highly performant, localized back end.
Yeah, exactly, And and and the cool thing is that then by shipping it together like you make these kind of APIs.
But like obviously the latency.
Between your applications kind of like and this you know threadie running to the worker and is basically non right, it's kind of like it's the same device. So so those kind of overheads disappear. It's very easy to integrate. And again you get this like integration of all kinds of native enhancements that you want to do for your apps, and it's all through JavaScript and scenes plus plus because
that's what you write the bindings in. And yeah, it's like, uh, you know, I don't want to come up too many examples, but like for example before we so no, like it's a very simple thing we do in our app is like somebody shares a video and we want to generate a preview of that that video, and we have that in our desktop ap We have that in our mobile app and our mobile to use a reagnative library.
And on desktop to use I think some video thing and whatever.
And the problem we always had was like you know, they would be a bog where mobile did it a little bit differently than this stop because there was like differences in the libraries and the and the stacks, and it would always come back, and we'll always come back, and we'll always come back. And now we moved it just to like it's in the Bear worker. It's olympic. It just takes it in. It produces the same thing
every time. It's exactly what we want. We tested on desktop, it's one hundred percent the same thing on mobile.
We moved on. We never looked back.
So it's not even like that that you know, you know, anything Reagnative is doing is wrong, or anything that that desktop development is.
Doing wrong or backing development is doing wrong.
It's just that difference is low you down and they don't need to and I think that's what's really exciting for me.
Awesome.
So I want to talk a little bit about the modules for a minute, because you did mention that you can for example, no JS.
They use.
V eight, but they've added other things on right because V eight was originally built for Chrome and so like you said, like file system for example, like V eight did not need that for your browser, and so you know you've got these other things bolted in. So you I'm assuming you just have modules for Bear that do some of those things.
Then.
Yeah, so it's pretty crazy because when you do this kind of like modulo development where you kind of split things onto these like piece meals, like you know, say, it's kind of like you can imagine like the tickets and your ticket ticket tracker, like magfs module, make mag module make it. Also, it's really easy to implement actually
because it comes so scoped. So our team was originally just two people, now three people, and those two guys just went through all libraries notes and just re implement them as modules. So we actually have the entire note is standard library just as modules you can pick from the shelf and install. But again, you just the difference is that if if you make another module, so let's say you made a module that's like you know, read
some file and converted. Instead of you asking the run time for FS, you just require FS and you install it like you do any other module.
That's the only difference.
So then like the standard library you use is not really standard library, but like you know, is basically just the union of what your dependency issues.
So super flexible, super easy, and yeah, so we just bang through all of it.
We have all the noe gs once, but then because it's like there's no cost to adding anything. There's no like committee where we have to discuss is this worth adding? Is this like going to make it to blow it? We just added because you can just choose not to use it. We also added all kinds of our stuff, so we have for example, like you know, database bindings to rocks top if you like that, we use that a lot boomed on.
You can just import us anything else.
I think we have some Bluetooth stuff now also, and all the things, like all kinds of things. I know we're working on some USB you know, interaction libraries also with USB sticks and stuff. So because there's no now that as soon as that cost goes away from maintainability and stuff, it's just basically all of a sudden, by doing nothing, you can do more, which I think is really.
The key to everything.
Yeah, I find I find that kind of interesting just from the standpoint of you know, like I said, I primarily do Ruby, but you also see it with Node and butN and some of these other things where yeah, they have a standard library. You know, whether they think about it that way or not, you do you get all this functionality in the language that they've added in
to make it useful. But yeah, when you start really thinking about a standard library, especially when the standard library gets large, then that then it's okay, how does this interoperate with all eight zillion other things that the the system does? You know, does it add overhead to installation right to the app size? Does an ad overhead to the you know, running things and doing things, and do.
I have to check this in order to run that?
And so yeah, you know, just having those you know, you still do that with I'm sure with your modules.
But the difference is is.
That I'm only pulling in the handful of things that I need, and so those are the only things I really have to worry about. And then it keeps my app size small right when it bundles the app and all those things, And so I can imagine that, Yeah, that it definitely has its payoffs. And to me at least, the thing that stands out here is what we're discussing is not should you.
Use bear all the time?
It's hey, where does this really come in and brings a host of benefits and where maybe you still want to use node or bun or something else that kind of has the fully functional thing or in the case of like React Native, right, You're you're going to do a whole bunch of the UI stuff in React Native, and then you're going to hand off the things that make sense to to pair or to bear sorry, and then you're you're also probably going to be working through some of like the API calls and stuff that you
typically do on a mobile app anyway, and probably keep all of that and React Native and so as it comes together, it makes sense.
Yeah, exactly.
And I think actually it's interesting to think about you said read Native. I think UI development it's almost like the complete opposite of what I said.
I think in the UI development you want to.
Have a lot of stuff being given to you because UI is really stateful by the time, like you know that spots and stuff. You want to not style those. You know, you want things to look based on the device. You want to have that give into you. It's a whole different thing. But this this model really really shines
for like, like you said, classic bag and development. It shows that we do we don't We kind of like just want to get a bit of the definition of BAG in development just say, well, it's like a worker. It's like how you do your application logic always something interesting about thinking about Chrome, Like you said, they're also I think because Chrome to some degree does the same thing, right because Chrome, sure ships will wear part to see
in these things, but the ship it's pretty minimal. Still like there's some stuff in there, but it's pretty minimal. It's very like it doesn't change a lot. It's a big process to change it.
When you.
Update your browser, Chrome doesn't ask you, It just updates it. Because Chrome comes with it comes with a guarantee that that doesn't matter. They're not going to break things going forward. The reason they can do that is because of that contract. Ask anybody who has ever upgraded on no jazz per program, and again this is not your no jets at fault.
It's just like something that happens for software. That's every time you upgrade a major is like incredibly anxious because you're like, you know, it's probably gonna break at that worst possible time because something that that API I used has change slightly. Right if you instead say, well, the run time's come with nothing, it's free jog wade because it's the same as the comium.
It's never going to break anything.
So we aggressively upgrade our bare run time every day just to get that latest V eight, get those latest things in because those guys are insane, they're shipping things all the time. So we are always on the latest, latest V eight because there's no cost to that. It's not going to break anything like those they have contract nailed down. That just means that you can again also just ship things fast to iterate fast, so you're not
stuck in that upgrade anxiety. You can kind of park old code just as being old and just bump those majors. So if we want to, if we want to make a better design for fast systems like only support promises, we just do that. We don't think about it. Uh and and just and just finally, like you said there, Yeah, I'm a big you know again, big fan of no js, A right tons of no js. I think no JAZ
has a big place in the world always. I haven't used much of JR ones because I'm I'm a classic person, but I do think, like even saying that, I think the entire in.
My opinion.
Back in development can't go towards this like small core model. I think that is the future. It's a little bit harder to market it's harder to talk about, but the benefits just greatly outweigh the disciplines.
Right.
So you we've kind of talked about mobile, and I think that back end story is pretty well understood because you know, if you're writing note or something else for your back end, you know that this can sit in there, next to it, or in place of it. My question is you also mentioned desktop, So what does this look like on the desktop.
So, so the cool thing is it's the code always looks the same because it's just Bear code we have on desktop. We have and if you go to our website bearpairs dot com, we have an installable CLI. That installable c cli is actually just our compilation of bears is just like a basically kind of like as minimum of a bill of v age you can get with this module system.
So that's the Bear thing.
And Bear is b A R E like naked, not b E a R like.
Somebody called it the bear naked one time.
I kind of like that.
So, and our logo is a bear like a ror or bear. Just to make everything more confusing, we like we like to to be smart ass. So you stall that one again, you just you can just install it every day, get the neatest one because nothing will ever
break and it's really good, really powerful. And the cool thing is then if when you want to like package your app, because this is all self contained like that, you can you can even do stuff like compile it, compile this into a single binary because when there's no standard library and there's nothing in that.
Becomes really easy.
If we have some examples and that on the website for how to to compile it yourself. Just get a binary art like you would go so you can have your entire program and one thing, or you can embed
it in other things. For our peer to peer run time pair, we actually ship our version of pair which is just the same thing just embedded into another thing, because you don't want to ship like many binaries that it's really hard, and that just becomes really easy, and you can even do things like so it's like it's minimal. It doesn't support typescript because of minimal, but you can easily just go in and make your own distribution that just supports typescript by adding that in into the into
the into the thing. So it's really really flexible and it sounds really good, and it sounds too good.
To be true.
The only reason is too good. Only reason that that is the case is because it does nothing. So it's very to support all the things when we do nothing, it's very hard to do anything, do anything. Just all at least to do is support those like what you're loading, which is again is a hard problem, but at least it's like much easier than doing all kinds.
Of Right, So if if I were to I guess the question I'm wondering about, because yeah, it sounds like you distribute it mostly the same way. Right, you embed the run time in whatever it is you're shipping, and then it right.
It just runs, it does what it does, or it does.
What you loaded in on a module and then called so on a desktop app, what what kind of UIs can people put on it?
Because sure, I mean yeah, so.
On a desktop ap if you want. It's kind of like the same story on desktop in general. As like something like no, it's like it's not it's not a r I framework. You can we actually have a native EI framework we build that just binds to like native UI, but our just to do an experiment. It's not something
people should do just to see. Can you actually make adiplication that just would load things, so you would if you wanted to make like an actual desktop app, you would probably use our Pair framework for making Peter peer apps because that's actually what it does. It actually just embeds bear as UI libraries and uses bare to load.
Peter Pier things. But you can do whatever you want.
It's basically similar in a flow to like making an electron app if if you know that, but you can also make native apps with that. You can also do the same tricks. I don't know if our tooling works with yet, but that's definitely on our roadmap to do like a desktop rag native app that uses Bair. Also, like we wanted to, it's very easy to invest if we want to embed it everywhere. Like I said, we launched it last week, right, so so we have a
long road map. But again by doing very little, we have a lot of time to do a lot of other stuff. And like this project is moving crazy fast every day, so it's super cool.
Right So I can install Pair and it has UI libraries that I can use that probably what do they bind into native?
They do so you can bin into anything if you wanted to. For modules, the modules we have right now just because that's easy, Like, so it's kind of like an electron like experience.
I got you. So I can bind to Nome or Katie. For Linux, I can bind too.
I don't think there is binding for mac os exactly, and like.
Probably a lot of those bindings have to be made for Bear like I like you have to make like Gluco.
That's something we're working on.
But like the program myself supports that we have something that the loads like just an electronic review because that's easy and that's what.
Okay, that makes sense, and so then it plays the role of the back end for the electron exactly happen kind of the same way.
That makes sense exactly.
But we want to take this to the full scale, like you know, either write those bindings ourselves or the community can do it. But the foundations is there for now, and I think, uh, like I said in the beginning, I think for me, like the most exciting future for JavaScript in general is like actually that it doesn't really run the UI anymore, but it just runs all.
The bag ends.
Because I think that's for JavaScript ironically really shines. It's also good for front end, but it's especially good for.
BEG yeah, it kind of started out doing the front end work, but it was almost a utility to make the front end do what you wanted. And so yeah, I can kind of see that and I can definitely see where it shines on the back end. So so so what's next for for bear.
Just honestly, just let me just turn on the light you because see it gets come and the mind.
And gets.
So next for us is it's actually really simple because we have the the API now right.
It is the module system.
So for us, every time we shift something, we're just making it faster and better, making more modules. For example, I think a really cool success. Sorry to how to under stand this stuff is like this is a little bit nerdy maybe, but like when you write things like native add ons in with V eight and we use VA mostly. Again, we can run on any engine, but we'd like to use the eight because it's just a
good engine. For sample, if you wanted to do some cryptography, you usually make bindings for a cryptolibrary because you don't
want to do that JavaScript you call. Those people don't realize that calling from JavaScript normally in these engines into like a native library has a cost, Like there's a transaction cost here because it has to Google between engines, and that cost means that it's actually harder to program for it, because it means that native code you call has to do more stuff to be worth it.
So if like you can imagine if you just made a.
C program that just added two numbers, if that cost is high, then it's not worth it, and then you're like, I need to do more. I don't like those limitations because it messes with how you think about programming. It's like you have like premature opianizations stuff. The engine that Google makes made a really cool solution for this called fast calls, which is like they have this API where you can do some native stuff and.
Then you can actually make this basically free. That was very recently added.
But because Bear does nothing else except this, the guys just decided to let's just write buying for this next post that through the module system, because again it's like
super flexible, you can do it. And we just added that and that was all the in our app key, which is like using a bunch of these calls to do ciography because Pewter pew uses a lot of photography, Like all those calls became I think it was like the three X faster, but just like you know, shipping that one pathing, like no code changed, right, just like because the guys can just focus on this engine part. Every time you make the engine faster, everything becomes faster.
So so for us, it's just about iterating even more and more of that stuff, like pushing all those bits out of these engines to make everything as fast as possible, stay on the very late as eights and then just like like I said before, expanding the module scope so we have more and more modules. We want to basically bind to everything we want to get like bindings for for like all those like cool eye libraryes you just mentioned.
That's the cool project. We want to get that done and just help people build, then help people expand, and also at the same time like uh yeah, just make it run. And then we're very very serious abound actually deploying the stuff like two light bulbs and stuff in the future. I think that's like you know, we do peer to peer and peter peer means like connecting things directly. If you think about like smart homes and stuff like that.
That's where that stuff is brilliant because you don't want to send all the data to Google or whatever, so running out and all your devices Peter peer stack. That's like the perfect worldface. So so we're pushing in all consideraction on this. But it's just really easy because it's it's so coop.
So it's awesome, Right, I had another question, but I get so tied into what what do you do with this?
I forgot where it was going with it.
You said, hey, you can pull in these modules typically have to do like an NPM install in order to get those things. And you said that you can use NPM to get some of them, but for sort of the fundamental modules that kind of do the basic stuff, like the node level stuff, right, the file system, you know, whatever other things it has to do. How do those come in? Do you have a separate app store or they just you pull them in via NPM? Is there some other way or what?
So, because we just so our module system again, I don't want to get tunerated, but our module system just follows the same contracts as the no modules. Because there's so many no modules, right, it's like amazing. It's I don't know if it is the biggest, but at least it's one of the biggest ecosystems and modules. So we decided, like why why we relivent that it's perfect or at
least like the things that are not perfect. It's like Liverpool, So we just replemented the same thing, which means that if you install something from an MPM it normally works.
The only real time it doesn't work.
Is if it's like if that module is obviously requiring like the standard.
Library like FS. But then you can we have this on our website.
You can use a trick to have MPM map FS to our FS which is compatible on APIs right now, and then you can make things work. So our website has a list of all of our mirrored packages of standard libraries like you know f S and Node means disn't bear, but it's all just MPM modules. You just install them from MPM. You would add them to your
package Jason. And then I think a really cool thing is that I think this is an AGMAS standard, but I'm not sure, but like the important map stuff in Node recently in package Jason, where you can kind of like describe I think this was added for Barser's originally, so we can say in this environment, load this packages and stuff like that that makes engineering for multiple run
times really easy with NPM. And also note just so you can really easily describe in bear when loading this thing from bear load bear fs, but in nodeload fs, and then your program just becomes very runtime neutral, which is at least like the work on node end bear, which is like how you want to run things. So so yeah, so we just reuse all the existing infrastructure for that, because why not, it's awesome.
There's a lot of it.
Right, So if I want to use like the f S module, like just NPM install what bear fs, bear dash fs or something like that.
Yeah, exactly exactly that, and then that's just like an open source library and like you know, it aims to be under pretend compared I'm sure there's slight differences here and there, but like and if you want to use like streams, we have the streams in limitation if you
want to use et cetera, et cetera. So yeah, it's like again it's like, you know, there's a little hurdle that that's the cost of like doing like small core development like you have as the first step, and this is why people don't do it, because it's harder to market you have like that marketing piece that's first step is annoying, but that's how you get the flexibility. And we don't care about marketing. We just make this because it's really cool. So so yeah, so that's how we
do it. And the cool thing is then if you want to install instead of some of the noticest of if you wanted to install a cool puture peer module, it's the same flow. So you learn this flow once and that's how you do everything. So how do you get like puter peer modules? How do you get it's per modules? How do you get whatever modules do you want?
Awesome? All right, so.
Yeah, I guess the last question I have before we do picks is if people want to learn more or they want to connect with you, or I mean maybe there's somebody out there who's like this sounds really great, sounds like you know what you're doing. I want to hire a whole punch to make my peer to peer app and I'm not going to do it myself.
How do people get connected with you? For any ear and all of that?
So if you go to the website, bear the pair of the com and I think maybe we can share that on the on the podcast and as a link. People don't hear my mumbling. But there's all kinds of contacts then there we we do we have so all so it's all open source misid licensing. We do everything they open on this in general. We have our chat up key where we do all our chats about implementing Bear and open their's links on the on the website to join those. You can actually just follow it in
real time. I don't think you should hire us to make that. I think we should hire people to work on Bear so and on Peter Peers. Maybe that's going into your pick session, but like, please reach out if you're interested in working with this stuff. That's a very cool ecosystem. That's very viprant stuff going on. But yeah, join all the things there. We have a website there. The documentation is very light because it doesn't do much. We have a very active help and a small team.
Cool thing about having a small team is that when you talk to somebody, it's like the pizza problem. You you can eat a pizza and the entire team can be in the room. So so when you talk to somebody, they probably know everything about it.
Awesome, all right, Well I'm going to push us into picks. Now, if you not listen to the show, Picks is just shout out about stuff we like. I think most of the time it's not technology related, but that doesn't keep us from picking technology stuff when we like it. So I'm going to jump in and do a handful of picks here. My first pick is almost always a board game.
And my friends and I last week we played a game called Colt Express and what it is is it actually has a train with cars that it's set up so it's like a three D train that sits on the table, and so you've got the locomotive and then you've got however many players there are basically put that many cars on the train. And then there's loot on the train, right, so there are little gems, there are bags of money, and there's a lock box in the locomotive, which is.
Where the sheriff starts.
And then what you do is you can move from the car you're into the roof. You can move laterally from one car to another. You can punch another player because all the players are robbers train rubbers. You can punch another player and that makes them drop loot, or you can shoot another player, and what when you shoot them, you add a bullet card to their deck of cards, And bullet cards are basically blanks, right, so they don't have an action associated with them. And when you take
any of the other actions, you've played the card. And so when you draw a hand, if you've been shot a lot and you get a whole bunch of bullets, you just don't have as many options, and so you may wind up spending one of your actions to draw more cards to try and get the card you want.
And the way it works is you go around the circle and everybody plays a card and there are different sequences that you can play that maybe they allow you to play two cards in a row instead of just one, or you know, they allow you to place it face down instead of face up, right, because if everyone's playing face up, you can sort of plan for what's coming, right.
It's like, Okay, I.
Know they're gonna move here, so i'm gonna move there and I'm gonna punch them kind of thing.
Right.
So, but if you're playing face down, right, then you have an advantage because it's it's anonymous. Of course, everybody else plays face down anyway, So then what you do is once everybody's played for the whole round. So there's usually you go around the circle like three or four times, then you flip them over and you just play it out. So you know, you play my card and I move, You play his card and he shoots, you play his card and right, and so anyway, it's a lot of
fun board game. Geek waits it at one point eight three. I tell people that two is about as complicated as the casual gamers really get, sometimes a little bit more, but two is about where it has enough complexity to make it fun, but it's not so complex that that the people who aren't avid gamers are not gonna want to play it. So anyway, so this was a one point eighty three so it's reasonably simple game. But yeah, oh, also, the each player has a character that they're playing, and
those characters have special abilities. Right, So the one I played, when you punch somebody and make them drop loot, you can catch it, right.
You don't have to spend an action to pick it up, you know, on your next for your next move.
Other people like one guy had such a powerful shot that it moved a person back a train car or I mean all kinds of stuff.
So anyway, lots of fun. My buddy had the.
What was it, like a super box or something, and so I had two expansions in it, and the expansions allow you to play this is typically two to six players. His expansion would allow you to play up to nine players. So anyway, way, fun game. Highly highly recommend it. It came out in twenty fourteen, so it's not a new game by any means. But anyway, really really enjoyed that. As far as other picks go. Finished in nineteen twenty three,
it's the Yellowstone spin off. I really liked Yellowstone, so I watched eighteen eighty three, which was the first spin off, right kind of the origin story of the family, I have to say.
And it was Tim McGraw and Faith Hill.
Where the parents of that one, which you know, I grew up listening to country music. So I enjoyed that too. Eighteen eighty three was terrific. E twenty three was even better, and they're both better than Yellowstone. And I really really really like Yellowstone. So if you're looking for something to watch, some Paramount Plus and so I'm going to pick that.
Speaking of Paramount Plus, one other thing I just figured out is that I didn't realize that Champions League in Europe was running, and so then I was asking questions like how do I watch it? And apparently those are on Paramount Plus in the US. I'm gonna go watch the finals whenever those are on.
And then.
They also carry Serie A soccer from Italy, so I'm excited about that too.
So I think.
That's mostly all I've got, So Matthias, why don't you go ahead and give us some picks?
Cool?
I was actually looking at that Yellowstone show because I haven't I don't get a lot of time to watch shows anymore, but I thought that one and I was like, that's interesting.
Kind of what kind of genre is that? Actually? Is that like sci fi?
Or it's a Western? But it's a modern Western. So the premise of the show is there's there's a ranch that takes up like half of Paradise Valley in Montana, and it's all owned by one family and it's been owned for like one hundred and something years, and there are all these people who are trying to get a piece of it right, so that the Native American tribe that's there right, they do all this stuff to like steal cattle in a way that's you know, semi legal
from the ranch. There's they're like developers that want to build stuff and that affects the ranch. At one point, eminent domain is claimed and so they actually take some of the land to build an airport, right, and so they're trying to fight back to keep their ranch. And so I'll warn you it does get a little bit violent. Sometimes there's definitely language, there's a little bit of nudity. If none of that's going to bother you or turn
you off, then it is a terrific show. Some of that does bother me, and I kind of wish that it was on vid Angel. I think some of the older seasons are vid Angel will actually let you, like you can say, don't show me any of the nudity, or you know, it'll cut the sound for the words you don't want to hear the curse words. But anyway, it's it's a really really good series.
I really enjoyed it.
Nice I check it out. I actually I love watching a good Western. I watched what's that show Darkwoard or something I can't remember that's like this, let's not call that.
There's this.
Big famous Western series. I watched them. I think I was in Netflix a while ago.
But yeah, yeah, so most Westerns are like Old West Westerns, and this one gets into like state politics and yeah, there's plenty of shooting and horseback riding and wrangling cows and all that too.
But yeah, anyway, nice, Yeah, I don't, like I said, I don't.
Unfortunately, I don't get to watch a lot of TV right now, but because I've been working really hard on this kind of stuff. But I do when I had some down sign So I'm a huge history buff and anybody who knows me were really tired of the fact that I'm very, very big medieval history nerd. I read everything from my year one thousand to like twelve hundred.
I don't know why this triggers me in a nice way of because it's like a if you don't know about history, it's kind of like we basically don't know. We know about the Roman and paranoia stuff, and then there's like a basically there's like a gap because of all the the changes in times, and then around year thousands when things actually start getting getting done against it as good good records around that, and I recently this
is super nerdy. But I recently went on like a deep dive on on Southern Italy medieval history and I read a really really good book series by I think it's an English author, John Julius Norwich, and it's very old books from like the sixties, but he writes this amazing trilogy about like Sicilian history in the Middle Ages, and it's it's interesting if you're very nerdly and you're into that kind of stuff. For me, so I don't read a lot, but that the kind of book where
I just started reading. I couldn't stop and I ended up actually just almost buying everything that I made because it's really good. I don't know, hopefully he's not controversial or something because I just I just read the books, but really really good stuff, and it's it's like from a point in time where you know people move from different countries. Today we're very like like what is also to be mean to be American? What does it mean
to be European? But basically in the Middle Ages, and this is like a communist conception, people actually just travel a lot and move from many places to many places, and people's from other places to all the places like southern Italy for me, as I'm from the Norrix, like it has like a history of like vikings and kings settling and like the Roman Empire's history and the Eastern Roman and all that clashing in like the Middle Ages and all those culturist mixtion and the Arabs and like
becoming like a half of everything. And obviously you have the Sage, which is like has a bunch of history, but like that all went through there, so like it's just like that period for me is insanely interesting to read about because it's just like.
Everything happening at once.
And and yeah, you should check out that book series by the offer if you're into that.
That's probably like one person out there that's gonna be like, that's awesome a lot to do that.
And if you then if you're into that, just google those the stuff from that and you'll find all this like really nerdly really good YouTube content that people made on that about the history of like in Italy.
So that's my.
Minority pick for today. I'm I'm and if somebody has good recommendations of any kind of like other deep dies on that, I'm very interested on.
That's my period. I'm very fixated on very very.
Cool stuff, very cool. Yeah.
I lived in Italy for a couple of years, and really which part of it, Mostly in the north actually, so you're you're talking about areas that I didn't see, but I live.
In I live in the south of Switzerland.
I live I live very close to to nominatally obviously, it's like ten minut rights.
Yeah, so I I was a missionary there the furthest north I got was Portanone and Verona.
But.
Where I actually lived, but I mean we went up into Trento and Bolzano and some of those that are kind of up that way.
So yeah, it's like that area obviously, you know, but like that's just so rich of all kinds of history or all places like the church and like the the peoples and you know different.
Yeah, that stuff is all so fascinating.
Yeah.
Well, and you get into the eighteen hundreds when Italy formed as a country as we know it now. I mean again, there were still there were like three or four kingdoms, and you know, I mean all all of the different fact factors that went into it. Yeah, there were people from the Church that played a pretty major role in Italy coming together as a country. Yeah, it's it's really really interesting.
Yeah, it's kind of like again if you like, if you know, I think people like to you know, like you know, you read about the Romans and that kind of stuff, but it's like you can just you can keep diving and you can get more and more niche and like it's all these areas and yeah, and like with the Popes and also like the history of the South that's like a huge interlapt there and like with different massively important events that's basically shaped the entire history of the Western world.
I think that's like insanely fascinating.
So yeah, yeah, I don't I don't think people know that, like the popes had their own kingdoms down there for.
Centuries. Yeah yeah, yeah, so very very interesting.
And yeah, southern Italy especially Yeah, like you said, I mean they got invaded by everybody on the Mediterranean and some outside the Mediterranean, like you mentioned the Vikings.
So I mean it's.
It's interesting too because people from the from southern Italy actually look different from people from northern Italy.
Yeah, it's like when you travel in Italy also, it's kind of like you can kind of food of food, you can sense when those boundaries, Like the food is very different than an Orthern food and like that's and like the Arabic culture in Sicily and like they have amazing you know, Arabic chocolate and things like that lighted. Yes, it's a crazy beautiful place and like, yeah, rich in history almost.
Yeah, in some ways some of the stuff is homogeneous, right, So you know there are things that are generally true of Italy, you know, including within the food, but then every region has their own take on a lot of that stuff too, and so then it's it's okay, well, you know, they're they're making kind of the same dish, but they've got their own flair, right they put a different meat or spice or something else in it, or they eat it with a different kind of bread or
you know. I mean anyway, it's it's really really fun and fascinating to get into the dialects very widely across the country. I mean, it's it's really really yeah, it's fun.
If anybody's watching this, probably not, but like this, and like an executive producer and the Netflix or something, please make a show about that whole region about like those time periods. I'll watch all of it, right, right, yeah, it's really missing. It's a huge missing gap. And like this overproduction of all things, Like there's so many intense, you know, straight to TV movie amazing stories about us we like with the Pope and all that stuff, and at least somebody needs to make that.
I think, yeah, absolutely, all right, well I'm gonna go ahead and wrap us up. But this was fun and I I I kind of love the meandering historical discussion that we it's I'm I mean, but I'm totally in this, not just for the technology, but for the people and the interests and and I feel like a lot of times we kind of forget to go beyond the technology into what makes the you know, the people in.
The ecosystem just so interesting.
So so yeah, so thanks for opening up on the stuff that you're interested in beyond tech, because that's fun. And uh yeah, we'll wrap up here until next time, folks, Max Max out