How Holepunch Is Redefining Peer-to-Peer Apps with Bare.js — A New Era for JavaScript Developers -JSJ 681 - JavaScript Jabber

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:05):
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.

Speaker 2 (00:27):
But who are you?

Speaker 3 (00:29):
Like?

Speaker 2 (00:29):
What's your story? Sure?

Speaker 3 (00:31):
Yeah? First of all, thanks for having me. Awesome to
be here. I always love to talk about JavaScript basically.

Speaker 4 (00:38):
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

(00:58):
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.

Speaker 3 (01:14):
I usually say, if you.

Speaker 4 (01:15):
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,

(01:37):
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.

Speaker 3 (01:57):
So I've done a lot of that, and recently.

Speaker 4 (02:01):
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,

(02:23):
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.

Speaker 2 (02:31):
Awesome.

Speaker 1 (02:32):
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?

Speaker 4 (02:39):
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

(03:00):
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.

Speaker 3 (03:15):
On things to like another.

Speaker 4 (03:16):
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.

Speaker 3 (03:31):
HDP, you don't do TCP, you only use Pewter pre
data structures. But with JavaScript that do that.

Speaker 4 (03:36):
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.

Speaker 3 (03:52):
Moving terabytes all day around with that kind of stuff
media files.

Speaker 4 (03:57):
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

(04:20):
people to build applications. Obviously there's a lot of CN
and C plus plus and there also to make that.

Speaker 2 (04:26):
Stuff go right sounds good.

Speaker 1 (04:29):
So so yeah, so you're not doing web RTC, you're
doing you're building BitTorrent and Dropbox.

Speaker 4 (04:35):
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.

Speaker 3 (04:46):
Crazy cool experience.

Speaker 4 (04:47):
I always tell this to people if you ever, it
is really fun because bitturn has one.

Speaker 3 (04:52):
Of those things.

Speaker 4 (04:54):
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.

Speaker 3 (05:01):
Now I think it's probably blocked everywhere.

Speaker 1 (05:03):
Yeah, I don't know, but yeah, not that I've ever
used pirate a because I would never do anything illegal.

Speaker 3 (05:12):
It's good for donalding Linux, I heard. But it was
really cool. It was really cool for.

Speaker 4 (05:19):
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

(05:41):
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.

Speaker 2 (06:04):
Right makes sense.

Speaker 1 (06:05):
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.

Speaker 2 (06:19):
Yeah, for peer to peer stuff.

Speaker 1 (06:20):
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

(06:42):
little different. Why does that lead you to, oh, we
need another one of these things?

Speaker 3 (06:48):
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.

Speaker 4 (07:00):
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.

Speaker 3 (07:12):
To distribute them, right, so you make an app these.

Speaker 4 (07:14):
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,

(07:34):
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.

Speaker 3 (07:54):
So you end up just making one app.

Speaker 4 (07:55):
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.

Speaker 3 (08:14):
So it's two different things.

Speaker 4 (08:15):
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.

Speaker 3 (08:37):
So like you don't have to have any like hosting anything.
You can just kind of like.

Speaker 4 (08:39):
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.

Speaker 3 (09:00):
Just distributed putre peer like you know in bittern.

Speaker 4 (09:03):
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.

Speaker 3 (09:13):
It's super cool and.

Speaker 4 (09:15):
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

(09:37):
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.

Speaker 3 (09:41):
Ask you is like, cool, when is it nonmobile?

Speaker 4 (09:47):
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

(10:10):
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.

Speaker 3 (10:29):
So we're really missing that part. We're like, well, what
about the bag end?

Speaker 4 (10:32):
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.

Speaker 3 (10:49):
In the phone for modules.

Speaker 4 (10:51):
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,

(11:11):
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

(11:33):
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.

Speaker 3 (11:43):
The other stuff is.

Speaker 4 (11:44):
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

(12:04):
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

(12:25):
up into Bear. So that's why the pair bear Plunk
came in.

Speaker 3 (12:29):
So we.

Speaker 4 (12:31):
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

(12:52):
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.

Speaker 3 (13:09):
Uh.

Speaker 4 (13:10):
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.

Speaker 3 (13:25):
I think. So it's it's it's super cool and super.

Speaker 2 (13:31):
Yeah.

Speaker 1 (13:31):
So I guess what I'm curious about, just to start
off with.

Speaker 4 (13:35):
Is.

Speaker 1 (13:38):
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.

Speaker 4 (13:54):
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

(14:15):
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.

(14:38):
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

(14:59):
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

(15:20):
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.

Speaker 3 (15:29):
Eighteen.

Speaker 4 (15:30):
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

(15:51):
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

(16:13):
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

(16:35):
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

(16:55):
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.

(17:19):
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.

Speaker 3 (17:35):
It's based on jobasrip core I think the one from Webcait.

Speaker 4 (17:40):
And it has different profiles and it's very good at
other stuff, and like VA is better and other stuff.

Speaker 3 (17:45):
So it's kind of like there's like a major for you,
Like you want to use j's core, well, the.

Speaker 4 (17:50):
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.

Speaker 3 (18:08):
Except for that.

Speaker 4 (18:09):
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

(18:30):
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.

Speaker 3 (18:48):
On things like light bulbs and stuff. Bear runs with.

Speaker 2 (18:50):
That straight up, and that's cool.

Speaker 4 (18:53):
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.

Speaker 3 (19:07):
Affets, which is just a module you can donald.

Speaker 4 (19:09):
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.

Speaker 3 (19:22):
On people. Once people realize this is like this is
going to be crazy.

Speaker 1 (19:28):
That is crazy. Yeah, I'm imagining, you know, I mean
you kind of go nuts, you put spider Monkey on there, you.

Speaker 2 (19:40):
Know, whatever floats your boat. That that's interesting. Yeah, So.

Speaker 4 (19:49):
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.

Speaker 3 (20:06):
On iOS.

Speaker 4 (20:07):
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.

Speaker 3 (20:27):
It's insane.

Speaker 4 (20:29):
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.

Speaker 1 (20:46):
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

(21:11):
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

(21:35):
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

(21:57):
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,

(22:17):
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

(22:40):
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.

Speaker 4 (22:56):
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

(23:19):
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

(23:40):
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.

Speaker 3 (24:02):
It's it's not that big.

Speaker 4 (24:03):
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

(24:23):
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

(24:43):
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

(25:05):
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.

Speaker 3 (25:25):
The other way is like something not nothing to do
at all with with UI, but.

Speaker 4 (25:29):
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

(25:52):
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.

Speaker 3 (26:06):
About honestly, and this is like really true, we.

Speaker 4 (26:08):
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

(26:30):
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

(26:50):
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.

Speaker 1 (26:57):
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

(27:18):
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.

Speaker 4 (27:29):
Yeah, exactly, And and and the cool thing is that
then by shipping it together like you make these kind
of APIs.

Speaker 3 (27:37):
But like obviously the latency.

Speaker 4 (27:38):
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,

(28:04):
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.

Speaker 3 (28:20):
And on desktop to use I think some video thing
and whatever.

Speaker 4 (28:26):
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,

(28:47):
it's one hundred percent the same thing on mobile.

Speaker 3 (28:48):
We moved on. We never looked back.

Speaker 4 (28:51):
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.

Speaker 3 (28:56):
Doing wrong or backing development is doing wrong.

Speaker 4 (28:58):
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.

Speaker 2 (29:04):
Awesome.

Speaker 1 (29:05):
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.

Speaker 2 (29:12):
They use.

Speaker 1 (29:14):
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.

Speaker 2 (29:33):
Then.

Speaker 4 (29:34):
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

(29:55):
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

(30:19):
time for FS, you just require FS and you install
it like you do any other module.

Speaker 3 (30:23):
That's the only difference.

Speaker 4 (30:26):
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.

Speaker 3 (30:36):
So super flexible, super easy, and yeah, so we just
bang through all of it.

Speaker 4 (30:39):
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.

Speaker 3 (30:58):
You can just import us anything else.

Speaker 4 (31:00):
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,

(31:22):
you can do more, which I think is really.

Speaker 3 (31:24):
The key to everything.

Speaker 1 (31:26):
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

(31:50):
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

(32:10):
the you know, running things and doing things, and do.

Speaker 2 (32:14):
I have to check this in order to run that?

Speaker 1 (32:16):
And so yeah, you know, just having those you know,
you still do that with I'm sure with your modules.

Speaker 2 (32:22):
But the difference is is.

Speaker 1 (32:23):
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

(32:45):
is not should you.

Speaker 2 (32:46):
Use bear all the time?

Speaker 1 (32:49):
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

(33:11):
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.

Speaker 3 (33:27):
Yeah, exactly.

Speaker 4 (33:27):
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.

Speaker 3 (33:35):
I think in the UI development you want to.

Speaker 4 (33:36):
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

(33:57):
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.

(34:18):
It's very like it doesn't change a lot. It's a
big process to change it.

Speaker 3 (34:23):
When you.

Speaker 4 (34:27):
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

(34:49):
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.

Speaker 3 (35:08):
It's never going to break anything.

Speaker 4 (35:10):
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

(35:31):
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

(35:52):
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.

Speaker 3 (36:04):
My opinion.

Speaker 4 (36:06):
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.

Speaker 2 (36:18):
Right.

Speaker 1 (36:19):
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

(36:41):
like on the desktop.

Speaker 4 (36:43):
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

(37:03):
this module system.

Speaker 3 (37:04):
So that's the Bear thing.

Speaker 2 (37:06):
And Bear is b A R E like naked, not
b E a R like.

Speaker 3 (37:10):
Somebody called it the bear naked one time.

Speaker 1 (37:12):
I kind of like that.

Speaker 4 (37:17):
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

(37:40):
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.

Speaker 3 (37:55):
Becomes really easy.

Speaker 4 (37:55):
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

(38:16):
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.

Speaker 3 (38:37):
To be true.

Speaker 4 (38:38):
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.

Speaker 1 (38:55):
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.

Speaker 2 (39:09):
It just runs, it does what it does, or it does.

Speaker 1 (39:13):
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?

Speaker 2 (39:21):
Because sure, I mean yeah, so.

Speaker 4 (39:25):
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

(39:47):
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.

Speaker 3 (39:59):
Peter Pier things. But you can do whatever you want.

Speaker 4 (40:02):
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

(40:24):
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.

Speaker 1 (40:34):
Right So I can install Pair and it has UI
libraries that I can use that probably what do they
bind into native?

Speaker 4 (40:44):
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.

Speaker 2 (40:54):
I got you. So I can bind to Nome or Katie.
For Linux, I can bind too.

Speaker 3 (40:58):
I don't think there is binding for mac os exactly,
and like.

Speaker 4 (41:05):
Probably a lot of those bindings have to be made
for Bear like I like you have to make like Gluco.

Speaker 3 (41:10):
That's something we're working on.

Speaker 4 (41:11):
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.

Speaker 1 (41:18):
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.

Speaker 3 (41:26):
That makes sense exactly.

Speaker 4 (41:27):
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.

Speaker 3 (41:48):
The bag ends.

Speaker 4 (41:48):
Because I think that's for JavaScript ironically really shines. It's
also good for front end, but it's especially good for.

Speaker 1 (41:55):
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.

Speaker 4 (42:18):
Just honestly, just let me just turn on the light
you because see it gets come and the mind.

Speaker 3 (42:23):
And gets.

Speaker 4 (42:28):
So next for us is it's actually really simple because
we have the the API now right.

Speaker 3 (42:33):
It is the module system.

Speaker 4 (42:35):
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

(42:56):
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,

(43:17):
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.

Speaker 3 (43:25):
So if like you can imagine if you just made a.

Speaker 4 (43:27):
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

(43:49):
fast calls, which is like they have this API where
you can do some native stuff and.

Speaker 3 (43:54):
Then you can actually make this basically free. That was
very recently added.

Speaker 4 (43:59):
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,

(44:19):
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,

(44:41):
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

(45:05):
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

(45:25):
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.

Speaker 1 (45:34):
So it's awesome, Right, I had another question, but I
get so tied into what what do you do with this?

Speaker 2 (45:45):
I forgot where it was going with it.

Speaker 1 (45:47):
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,

(46:08):
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?

Speaker 4 (46:18):
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

(46:40):
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.

Speaker 3 (46:49):
The only real time it doesn't work.

Speaker 4 (46:51):
Is if it's like if that module is obviously requiring
like the standard.

Speaker 3 (46:54):
Library like FS. But then you can we have this
on our website.

Speaker 4 (46:58):
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

(47:19):
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

(47:43):
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

(48:05):
so yeah, so we just reuse all the existing infrastructure
for that, because why not, it's awesome.

Speaker 3 (48:10):
There's a lot of it.

Speaker 1 (48:12):
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.

Speaker 4 (48:19):
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

(48:41):
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

(49:01):
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?

Speaker 2 (49:15):
Awesome? All right, so.

Speaker 1 (49:20):
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.

Speaker 2 (49:38):
How do people get connected with you? For any ear
and all of that?

Speaker 4 (49:41):
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

(50:03):
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

(50:24):
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,

(50:48):
they probably know everything about it.

Speaker 1 (50:51):
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

(51:12):
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

(51:32):
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.

Speaker 2 (51:51):
Where the sheriff starts.

Speaker 1 (51:52):
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

(52:13):
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

(52:33):
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

(52:55):
down instead of face up, right, because if everyone's playing
face up, you can sort of plan for what's coming, right.

Speaker 2 (53:02):
It's like, Okay, I.

Speaker 1 (53:03):
Know they're gonna move here, so i'm gonna move there
and I'm gonna punch them kind of thing.

Speaker 2 (53:07):
Right.

Speaker 1 (53:08):
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.

(53:28):
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,

(53:49):
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

(54:11):
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.

Speaker 2 (54:20):
You don't have to spend an action to pick it up,
you know, on your next for your next move.

Speaker 1 (54:26):
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.

Speaker 2 (54:34):
So anyway, lots of fun. My buddy had the.

Speaker 1 (54:39):
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.

(55:05):
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.

Speaker 2 (55:21):
And it was Tim McGraw and Faith Hill.

Speaker 1 (55:23):
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.

(55:45):
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.

Speaker 2 (56:04):
And then.

Speaker 1 (56:06):
They also carry Serie A soccer from Italy, so I'm
excited about that too.

Speaker 2 (56:11):
So I think.

Speaker 1 (56:15):
That's mostly all I've got, So Matthias, why don't you
go ahead and give us some picks?

Speaker 3 (56:21):
Cool?

Speaker 4 (56:21):
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.

Speaker 3 (56:31):
Kind of what kind of genre is that? Actually? Is
that like sci fi?

Speaker 1 (56:34):
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

(56:57):
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

(57:19):
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.

(57:39):
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

(58:00):
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.

Speaker 2 (58:10):
I really enjoyed it.

Speaker 4 (58:11):
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.

Speaker 3 (58:20):
There's this.

Speaker 4 (58:22):
Big famous Western series. I watched them. I think I
was in Netflix a while ago.

Speaker 1 (58:26):
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.

Speaker 3 (58:40):
But yeah, anyway, nice, Yeah, I don't, like I said,
I don't.

Speaker 4 (58:47):
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.

(59:09):
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

(59:30):
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,

(59:53):
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

(01:00:19):
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

(01:00:40):
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,

(01:01:02):
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.

Speaker 3 (01:01:09):
Everything happening at once.

Speaker 4 (01:01:10):
And and yeah, you should check out that book series
by the offer if you're into that.

Speaker 3 (01:01:13):
That's probably like one person out there that's gonna be like,
that's awesome a lot to do that.

Speaker 4 (01:01:19):
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.

Speaker 3 (01:01:28):
So that's my.

Speaker 4 (01:01:29):
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.

Speaker 3 (01:01:38):
That's my period. I'm very fixated on very very.

Speaker 2 (01:01:41):
Cool stuff, very cool. Yeah.

Speaker 1 (01:01:43):
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.

Speaker 3 (01:01:54):
In I live in the south of Switzerland.

Speaker 4 (01:01:55):
I live I live very close to to nominatally obviously,
it's like ten minut rights.

Speaker 1 (01:02:02):
Yeah, so I I was a missionary there the furthest
north I got was Portanone and Verona.

Speaker 2 (01:02:12):
But.

Speaker 1 (01:02:14):
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.

Speaker 4 (01:02:21):
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.

Speaker 2 (01:02:34):
Yeah, that stuff is all so fascinating.

Speaker 3 (01:02:37):
Yeah.

Speaker 1 (01:02:38):
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

(01:03:01):
it's really really interesting.

Speaker 4 (01:03:03):
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

(01:03:25):
of the Western world.

Speaker 3 (01:03:25):
I think that's like insanely fascinating.

Speaker 1 (01:03:28):
So yeah, yeah, I don't I don't think people know that,
like the popes had their own kingdoms down there for.

Speaker 2 (01:03:36):
Centuries. Yeah yeah, yeah, so very very interesting.

Speaker 1 (01:03:42):
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.

Speaker 2 (01:03:54):
So I mean it's.

Speaker 1 (01:03:56):
It's interesting too because people from the from southern Italy
actually look different from people from northern Italy.

Speaker 4 (01:04:03):
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

(01:04:26):
history almost.

Speaker 1 (01:04:27):
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,

(01:04:48):
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.

Speaker 4 (01:05:11):
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

(01:05:34):
we like with the Pope and all that stuff, and
at least somebody needs to make that.

Speaker 1 (01:05:38):
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

(01:06:00):
times we kind of forget to go beyond the technology
into what makes the you know, the people in.

Speaker 2 (01:06:07):
The ecosystem just so interesting.

Speaker 1 (01:06:10):
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

All Episodes

How Holepunch Is Redefining Peer-to-Peer Apps with Bare.js — A New Era for JavaScript Developers -JSJ 681

Episode Transcript

Popular Podcasts

Dateline NBC

Stuff You Should Know

Law & Order: Criminal Justice System - Season 1 & Season 2

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}How Holepunch Is Redefining Peer-to-Peer Apps with Bare.js — A New Era for JavaScript Developers -JSJ 681