August 28, 2025 • 46 mins
In this episode of JavaScript Jabber, I sit down with Delaney Gilliland to dive into why most of us are building the front end wrong—and what a faster, leaner, and simpler alternative could look like. We explore his background in game development and military applications, which gave him a unique perspective on web performance and real-time data challenges. That perspective ultimately led him to create Datastar, a new framework designed to rethink the way we approach front-end development.
We talk about the limitations of SPAs, the promise (and pitfalls) of tools like HTMX and Turbo, and how Datastar builds on web standards to deliver speed, efficiency, and simplicity without the baggage of heavy state management. Whether you’re curious about server-sent events, morphing strategies, or just want to see how front-end development could be done differently, this conversation will get you thinking about the future of the web.
Links & Resources
Become a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.
We talk about the limitations of SPAs, the promise (and pitfalls) of tools like HTMX and Turbo, and how Datastar builds on web standards to deliver speed, efficiency, and simplicity without the baggage of heavy state management. Whether you’re curious about server-sent events, morphing strategies, or just want to see how front-end development could be done differently, this conversation will get you thinking about the future of the web.
Links & Resources
Become a supporter of this podcast: https://www.spreaker.com/podcast/javascript-jabber--6102064/support.
Mark as Played
Transcript
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 Maxwood, and we are
talking to Delaney Gillileen. We're going to be talking about
how everybody's doing the front end wrong and how it's
super slow because we all do it wrong. So do
you want to introduce yourself and we can dive in
and talk about how we could do it better.
Speaker 2 (00:27):
Sure.
Speaker 3 (00:27):
Yeah, as you said, my name is Delaney.
Speaker 2 (00:30):
I have a kind of a weird background.
Speaker 3 (00:32):
I've done a lot of stuff in game development, military
applications and all that, and I've always found that the
web is an amazing sandbox for doing security and deployment
and so it's almost its own little os and I
love the ideas of it, and I've done some pretty
big applications in it, but I've always had this weird ditch.
Speaker 2 (00:50):
That things are being done wrong. I really had.
Speaker 3 (00:54):
Issues with spas and how you're basically sitting down in
all your state and Jason and recreating the world each
time you do an update, and so I started getting
into hypermedia and the HDMX stuff, but I ran into
issues with that too, and long story short, I ended
up with my own framework called data Star that is
trying to solve all those things of being there's the
(01:17):
line of like the MPa style of HTMX, and then
there's the SPAS and I think we really are on
a different plane. We're doing stuff that's not in between.
We're doing both and more. So okay, I can talk
about it. Yeah, it makes sense.
Speaker 1 (01:31):
My weapon of choice in this space is Turbo, which
is part of hot Wire, and.
Speaker 2 (01:36):
It does a lot.
Speaker 1 (01:37):
It doesn't do exactly what HTMX does. You know, the
same kind of idea where you're you know, you're streaming data,
you know, back and forth and you only rerender what
you got back and it sends back HTML instead of JSON,
and so it doesn't have to go and figure out
what all of your components are and then redraw it
like React does.
Speaker 3 (01:58):
Well, if if you've Turbo, then I've already worked with
mckel and the guys over the Turbo team to work
on a new version of the morphs stuff. So we
actually use uh vomit. Yeah, we have our own version
that we started from working with Michael. In fact, he
was on our podcast a while ago and we worked
on that for quite a while. But we have the
fastest morph being strategy in the world. So if you've
(02:19):
already used turbo, are getting some of the benefit, You
getting some of the benefits of the work that has
been done in data ironically.
Speaker 2 (02:25):
Oh interesting.
Speaker 1 (02:26):
So yeah, so it sounds like there's a story here
right where you're saying, Hey, I wanted to do a
thing and the tools out there were not the best
tools for it, or I thought there could be better
tools for it. Do you do you kind of want
to just back up and give us some conflict on
where this all came from.
Speaker 3 (02:41):
Yeah, So I was working on a project and it
ended up being in view and mostly three D. So
project was basically a military thing where we sent every
radar blip from every radar station in the continental United
States in real time to the browser, and they wanted
to be able to scrub back in time over and
now like live. So you're talking about a million updates
(03:02):
per secon about nine hundred thousand updates per second and
being able to scrupt to any point in time within
a second to any point in time. So that's a
hard problem if you don't know, like, that's a lot
of buffers and a lot of gl stuff.
Speaker 2 (03:14):
And so I'm mostly a web guy like my backgrounds
in three D.
Speaker 3 (03:17):
So I was knocking that out and I was like, man,
there's got to be a better way because I'm basically
sending all this spas. You're sending the entire state of
your application to the front end. All your state lives there,
and then you're trying to keep those the state of
the back end the front end in sync. Right on
sort shirt, I started searching around more to do different things.
HTMX I thought was a really interesting idea in that
it's going back to kind of hypermedia of the two thousands.
(03:40):
But one of the things I ran into is that
A it wasn't fast enough and B it didn't include
things like the morphing out of the box.
Speaker 2 (03:47):
So I was like, well, why isn't that included?
Speaker 3 (03:48):
And then I was like, well, I want to be
able to pick and choose, because some of the choices
they made I didn't think were very good. So I
wanted to have a plugin system. They have extensions, which
means you can add stuff on top of HTMX. Right,
you can't replace anything in HTMX right, it's its one
big five K file and you kind of left with it.
So I went through and said, okay, if I was
writing a game engine but for the web, what would
that look like, Everything being module, everything being kind of
(04:09):
an ECS style, like a different way of looking at
it from a data oriented perspective. And so once I
started getting into it, it long over time basically morphed
into its own thing. But in data Star, for example,
everything is a plug in, literally everything, And one of
the major plugins that we have is this thing that
does service set events. And people really have not understood
service set events, and they think it has to be
(04:31):
a stream, it has to be this extra cough thing.
All it is is a chunked response and that's it.
That's literally all it is. It's a data type, which
means as soon as you can send down a response
with it data event, you can send down signals, you
can send down elements, you can send down different parts
of the page, so things like HTMX.
Speaker 2 (04:47):
It's a kind of a it's not the norm to
say I'm going to.
Speaker 3 (04:50):
Update this part of the page or this part of
the page, or I want to pin this signal, I
want to merge this thing like you kind of do
a whole Just the way it works doesn't kind of
jive with what I wanted to do. Basically just sat
down and started writing out these pieces and lo and
behold ended up being way smaller. So, for example, we
include the fastest signal library in the world. It's built
off alien signals if you're into that space at all,
(05:12):
and we have the fastest moreporting library by far, and
we're ten kilobytes.
Speaker 2 (05:16):
Wow.
Speaker 3 (05:17):
Yeah, the whole thing, And so it's a pretty crazy
thing that we basically just if you don't rely on
other people's lives, everything's there's no MPM, there's no vendoring.
It's just all written for those specific needs. So every
plugin is completely independent, and it makes it so that
it's really fast, really small and really tight code, and
then you don't have to think about it anymore, which
is kind of a neat thing. And also we're the
(05:38):
only one that's really relying on the specs. So there's
a thing that's built into the to the HTML specs
called data dash Star, which basically allows you to put
data astributes.
Speaker 2 (05:47):
So data star is just.
Speaker 3 (05:49):
Hooking into that and reading up the key value store
that it gives you and then implementing its own modifications
and stuff. So basically everything is like data dash class
data dash on, data dash load these.
Speaker 2 (06:00):
Kinds of things.
Speaker 3 (06:01):
So we're living within the spec So it's not that
we're trying to replace it with a whole new spa
framework or something. We're literally just using the things that
already built into the browser, which means that we're very
small and very fast, because the fastest thing you can
do a jobascript is not.
Speaker 2 (06:15):
Do jobascript, I'm true.
Speaker 1 (06:17):
So I guess you know, seeing this particular use case,
you know, or you've got millions of you know, blips
on radars across the US, and you know kind of
doing a lot of that real time stuff, which I
think is a different thing. You probably handle a lot
of that on the back end, but then making it
all show up the way that you need it to
on the front end is the challenge we're talking about.
(06:37):
Is this something that you would recommend just for people
who are doing that kind of a thing, or is
this a better fit for other problems as well.
Speaker 3 (06:44):
Yeah, so I think that the way the Data Start
builds things now is the best way to build the
websites barn On.
Speaker 2 (06:51):
And the reason why is people.
Speaker 3 (06:53):
Say, well, yeah, I'm not building a game, I'm not
building will time stuff. Yeah, but if it can handle that,
then it can handle your other issues so much EASi.
Speaker 2 (07:00):
So for example, there's a one of our.
Speaker 3 (07:02):
Users made a it's really a rendering demo because it's
the dumbest way to build this kind of thing. But
he took the Game of Life and he made every
cell a DIV and then colored the div with CSS,
and then when you click on it, it updates to this, so.
Speaker 2 (07:16):
You have twenty five hundred divs.
Speaker 3 (07:17):
He's updating in it like between five and ten primes
a second, and it's it's a shared state, so everyone
in the world's he's the exact same version of it
at all times, and it's rendering in like eight milliseconds,
So if you can handle twenty five hundred dives, yeah,
So it's it's fast enough that it's just a non
issue for what you're doing. And the other thing that's
interesting about this approach, which we can get into, is
that he's not sitting down new like if you were
(07:40):
doing that in a normal spot, you would be sitting
on Jason all the time.
Speaker 2 (07:44):
He's sending down the finished HTML.
Speaker 3 (07:48):
But the thing is, like, for example, in a Game
of Life, it's not that different from the last approach
so he's getting between four and five to one compression
ratios with no extra effort.
Speaker 2 (07:57):
So he ended up being on.
Speaker 3 (07:59):
The top of Hacker new Is on a five or
ten dollars machine and it ran fine.
Speaker 1 (08:04):
Yeah, that makes sense because essentially what you're doing is
you're saying, instead of here's the whole Game of Life
board visible space, you can just say, hey, these handful
of ones are the ones that got updated right, changed color.
Speaker 3 (08:18):
Well, so here's the thing that's really nice is that
he's sitting down in that case, all twenty five hundred
dips because it's fifty by fifty grid, he's sitting all
of them down every single time. Oh really, because yeah,
So the thing is you just think about it as
this big fat morph and it is smart enough to say, hey,
I already had a compression window that had bits and
pieces of it, so you mentally can.
Speaker 2 (08:36):
Think of it. It does.
Speaker 3 (08:38):
Yeah, that's what the morphdomb and also the Broadley compression
and all these things, like we've thought about this stuff
at a deep level where we can send down things.
So if you had a board that you know how
in Game of Life, if it's just sitting there kind
of switched between two states, like if it gets to
a stable state, that change over since it's already in
the window of the Broadley stuff is like twelve bytes
bytes twelve bytes, so sending down twenty five hundred things
(08:58):
just a twelve byte change. Depending on how much data
that is shared in your updates, you can get these
crazy compression rangions, like we've seen up to four thousand
and one compression. So it's better than web sockets because
you get all this compression stuff, you get the proper
headers and cookies and all that stuff. It's better than
standard crud stuff because you're halfing your polling. So instead
of requesting something and getting back and requesting something and
(09:19):
getting it back, we're having that RTT because we can
just send down as we decide on the back end
right when you need it, so you can send it
every second or speed it up or slow it down,
it does not matter. Everything else works the same. So
it is by far the best way to build any website.
And I will take on anyone with that challenge.
Speaker 1 (09:34):
So let me kind of back up a little bit
because I know that a lot of people, you know,
if they're doing front end, so and to give you
a little bit of a context. I mean, my weapon
of choice again, like I said, is the hot wire stack.
So I'm usually using something like stimulus and so and it.
You know, you're talking about the data attributes and stuff,
and stimulus just basically gives you a convention on top
(09:55):
of that to you know, to scope your changes.
Speaker 2 (09:58):
And to track your events.
Speaker 1 (10:00):
So I guess what I'm wondering here is, you know,
you've talked about a game of life. You've talked about
so those are both kind of visual things. I mean,
I guess the one is kind of a poor man's
you know, pixelated thing, and then the other one is
like a full on what is it, you know, just
a graphical visualization of the radar and things.
Speaker 2 (10:23):
So is there is there a data driven you know.
Speaker 1 (10:26):
You know, dashboard or user interface or admin panel or
something like that that's been built with data Star.
Speaker 2 (10:32):
Yeah.
Speaker 3 (10:33):
The thing is I work at Sanadia on that's as
a day job, and so I'm building literally that right
now as a real time dashboard thing for all the
interconnected sets of contexts on global superclusters.
Speaker 2 (10:43):
That's what I'm working on right now.
Speaker 3 (10:44):
So I can tell you by far it's the easiest
way to do that because you can think of things
in these large fat more basically thinking of it in
immediate mode. If you've ever done game development, your UIs
are generally they're so interactive that it doesn't make sense
to hold on to state because you're basically re rendering
the whole thing in a new state every frame anyway.
So the immediate mode is more the sell of data start,
and it is by far the simplest way to build
(11:05):
those kinds of complicated dashboard. If you go to the
website data star or data dashtar dot dev and go
to for example, the DBMD like, that's not like it's
techniquely it is interactive, but we're actually updating that dashboarding
thing in micro seconds, not milliseconds, not seconds like you're
used to seeing in a dashboard. We're doing it in microseconds,
(11:26):
so we're able to make updates to the back end,
make it very efficient, and actually make shared state.
Speaker 2 (11:31):
So one of the things I think is going to
be coming in.
Speaker 3 (11:33):
Web poor point zero kind of thing is much more
collaboration and the idea that all the state should be
living in the right place, which is most primarily the
back end, means that everyone can have these collaborative shared states,
and it's actually cheaper because you're sending down just the
parts that have changed.
Speaker 1 (11:47):
So it's way faster, right, So what does the approach
look like then? So let's say that I'm like, all right, well,
you know, and I use rails on the back end,
but you know, so I'm going to use it. You know,
I'm going to use rails on the back end, or
maybe I'll use no or something. I don't know, but
you know, so I set all that up. You know,
I have ways to get data from my back end
from my front end. So what what does the workflow
(12:09):
actually look like when I'm building this out?
Speaker 3 (12:11):
Sure, so if you've already used similar or if you've
already used the turbo stuff, basically you could start with
a skeleton page that just says, hey, here's my like
layout and here's IDs for things I want to hook
into the same kind of way that the morph works,
you do the same thing, except for now you're basically
all you do is when you send back these we
have a SEKS to make.
Speaker 2 (12:31):
It a little bit easier, but it's literally just a
helper on top of SEC.
Speaker 3 (12:34):
You'd say I want to patch element and you give
it an element with an ID.
Speaker 2 (12:39):
That's it. That's all you do.
Speaker 3 (12:41):
Everything else is handled for you. It knows where to
grab it, what to update, how to morph. So the
defaults are if it has an ID, I'm going to update,
I'm gonna select on that and grab that ID, and
I'm going to morph by default.
Speaker 2 (12:50):
So in most cases that's all you do.
Speaker 3 (12:53):
You just like send a patch that says here's the
new stuff for that area that has an idea, and
you're done. And the nice thing is that most of
the state in the back end becomes really really simple
because you're just sending down win things shame.
Speaker 2 (13:04):
So your locality of behavior.
Speaker 3 (13:06):
Instead of saying I'm trying to build up adjacent object
and then send down, you're saying I got something from
the database. And what I do is I literally get
the row from the database and then I render on
the next row. Like I render, I get the data
and I send it to the template library and then
I'm done.
Speaker 2 (13:22):
Like the locality behavior can be the same.
Speaker 1 (13:24):
Line, right, So you use the template library on the
front end or do you know in the back end
that's because the thing is up to your back and
I tend to use GO most of the time. It's
it has a lot better tooling the sea for you know,
webright kind of stuff and so yeah, I just have
Temple and I have Temple components and you render the
stuff and you send it down.
Speaker 2 (13:42):
That's it. Like there's it's very simple.
Speaker 3 (13:44):
We have SDK's and I think twelve languages to make
this easier so you can just get up and running quickly.
But the nice part is like Turbo and HGMX have
the idea of like sending stuff in the back end,
Like I think that's a good idea of a general thing,
but the problem is they don't have the concept of
signals and reactivity and things on the front end. So
data Star also includes things like data class, data style,
(14:05):
data on click, all the signal libraries, data computed data,
effect like all the things you need to build front
and stuff it's up because there's times where there's client
side state and there's times when there's not, and being
able to know which it's which makes it a lot easier.
Speaker 2 (14:17):
Yeah, that makes sense.
Speaker 1 (14:19):
So to talk through some of this when you're talking
about the front end state, right, you don't need a
state library because you just put it all into the
data attributes and you just updated as you go.
Speaker 2 (14:28):
Yeah, so there's one familiar to me with stimulus. Yeah.
Speaker 3 (14:33):
So there's one basically global reactive store, kind of like
you see in redocs or any of these kinds of things,
where you have a global store. As you make changes,
it automatically updates and gives you signals and all this stuff.
And then what happens is whenever you do actions inside
you think, we have an at sign for basically actions,
So if you do it at GET or not at post,
it automatically compiles all the signals and sends it back up.
(14:55):
There's filtered on that you can say I want to
subset it and all that, but the point is that
you basically you can keep things in sync by sending
that state back up to the server. And because you
have so much of your states on the back end,
there's very few signals on the front end. Right There's
things like doing two a binding two an input or
a text area or to some kind of timer thing
or some user local setting of a theme that you
(15:15):
don't care about, Like, there's some of that stuff, but
most of the time you send all that up to
the server and then you know the exact state of
what the front end is doing.
Speaker 1 (15:22):
Right, So then if I need to send a signal
back from the back end, how do you manage that?
Speaker 3 (15:27):
So with the nice thing is that we support all
of it again in ten kilobyte.
Speaker 2 (15:31):
So if you want.
Speaker 3 (15:32):
To do a request against an HTML page, we'll morph
that in.
Speaker 2 (15:36):
If you do it against adjacent object, we'll morph that in.
Speaker 3 (15:38):
If you do it against a jobscript object, we'll execute
that jobscript for you. But in your SEC you could
be sending down, hey, I want to update this patch
of this page, or.
Speaker 2 (15:46):
I want to update these signals.
Speaker 3 (15:48):
So you have patch signals and patch elements and then
there's technically read signals. When this stuff comes in, that's
the entire SDK. You just like that's it. So you
just patch things in whether there's signals or element, and
you update your page and that's it.
Speaker 2 (16:02):
Like it's fast because there's very little of it. If
that makes sense, right, Yeah, that makes sense.
Speaker 1 (16:06):
On the other end though, like if something changes on
the back end, does it just push the data through
a web socket or how do you manage that?
Speaker 3 (16:13):
So the thing that people have this has been a
big issue with the HTML five spect People are so
used to seeing SEC because that's that's I kind of
think everyone should be using SD for basically everything. And
the reason why it is because it's just a response type.
Like you know how you get tests, that's service side events,
service center events. Yeah, okay, yeah, So the thing about
(16:34):
service and events is like, for example, if you went
to the front page of data start, you'll see on
the second like the second little example, it's just a
response type. So just like you have text HML or
application JS, there's another one called event or text slash
event stream, and all it is is, you know how
when you're sending a request like a if you're sending
(16:54):
up a big file and it's it chunked SEC the
same thing it's EFT for it's a chunked response. So
it's still just one request response, but you're basically leaving
it open and saying when there's a set of new lines,
flush the buffer and send what I have so far
so you can. So it's just a standard fetch request.
There's nothing special about it. There's no like that's the
(17:16):
he sticator to help you set up the flusher and
all that stuff, but there's nothing special about it. In fact,
the irony is most of the time most browsers are
doing AHGTP streaming already for you.
Speaker 2 (17:26):
You're just getting explicit control of that.
Speaker 3 (17:28):
So it's just an event type and you're just saying
new line, new line, and then you're saying flush like
my response to the network.
Speaker 2 (17:36):
It's basically what's happening. That's it.
Speaker 3 (17:37):
There's nothing special. There's no web sockets, there's no sticky sessions,
none of that stuff that all goes away. It's just
a standard web request. So that makes it's easier. So
are you managing that on like the service worker or
something or.
Speaker 2 (17:51):
No, it's just native and the brother.
Speaker 3 (17:52):
The thing about the service worker stuff that I found
is that it can add a bunch of issues around
having that extra thread can cause a bunch of issues
with the UI and trying to get things back and forth.
Like all the benefits you're supposed to get from it,
you don't. Like, you just don't. And the thing is,
we're so fast, Like if you go ahead and look
at your net, like if you're running a data Star website,
like if you go like for example, Dbmond, which you're
doing stuff in the microsecond, and you actually click your
(18:14):
performance tab and look at our renders. They're such tiny
slices that you're you're gonna laugh, Like it's just a
non issue for most anything that you do.
Speaker 2 (18:22):
Yeah, that makes sense.
Speaker 1 (18:23):
So at the end of the day, I'm just trying
to visualize how this works. I mean, I kind of
have it in my head, but I guess I'm wondering
on the other end. So with something like React, you
have React components and things like that, you don't need
any of that. You just render all that on your
back end, and yeah, it works.
Speaker 3 (18:42):
I Mean the beauty is is that you're you still
have components, you still have things, but they're in your
They're next to your database most of the time, right,
Like you're just changing from your database directly to the
thing you want to render. That's easier in every way.
Like all the RSC stuff is a nightmare. All the
Abernoff stuff around tail to computers, all this stuff is
completely misguided. And that's the thing I think it was.
(19:04):
It's the fact that I don't consider myself a web
deev at all, Like I just happen to use it
as a tool, but I'm a lower level guy, Like
I feel much more comfortable in GLSL shaders than I
do in browsers, And I think it was just if
people have been going in the wrong direction for a
long time. You have very smart people solving the completely
the wrong problem, right, And if you solve that problem,
it can be very small and very efficient.
Speaker 2 (19:25):
The browsers are really fast.
Speaker 3 (19:26):
But the thing is it's the C plus plus and
the lower level stuff that's fast, not the JavaScript right.
Speaker 1 (19:32):
So at the end of the day, if you do
have a performance bottleneck with this, it's going to be
on your back end and its ability to respond quickly.
Speaker 3 (19:39):
Yeah, And I mean I've tested it out to like
forty thousand connections on actively live on in a go
back and I think a lot of times the problem
is JavaScript developers are tend to try to have a
full stack to try to keep and I think it's
not a bad thing.
Speaker 2 (19:53):
It's just that it's because they're trying to keep track
of state.
Speaker 3 (19:56):
Whereas if they care about performance, pick a lower level language,
pick something that's even bun with the zig stuff is
a better choice than what most people do.
Speaker 2 (20:04):
Like that's where I want to see people go.
Speaker 3 (20:06):
And it's not like the jobscript goes away, Like if
you're doing a charting or some kind of three D
engine thing.
Speaker 2 (20:11):
You're still in our world. You're still writing web components.
Speaker 3 (20:14):
You're actually embracing that, whereas in the normal spat world,
web components don't make any sense. They just don't like,
already have I stay in my front end? Why do
I need to share it with some other projects? Like
why do I care? Where's all of a sudden, If
you're saying I can make a data start application and
it looks the same whether it's in PHP and go zig,
it does not matter closure, it doesn't matter. All that
looks the same, then web components. Now you can have
(20:36):
a shared library that every web developer is using with
these web components that you're driving with data star, so
it props down events up with web components. So you
just drive it with data star. Now you're all on
the same page. All your templates look the same with
web components. Now where's the current staffs quo? You just
it doesn't make sense.
Speaker 1 (20:53):
So I guess the other question that I have is,
you know, let's say that somebody adopts this. I'm a
big fan of the idea of somebody being able to
to like build and keep track of all of this
stuff on their own, right, It's like, hey, look, you know,
I mean I work on a team, I think most
people do, but on my own projects, right, I want
something that I can just maintain myself right without having
to build a team and you know, face all of
(21:15):
that complexity and keep track of what everybody's doing.
Speaker 2 (21:20):
Right.
Speaker 1 (21:21):
Eventually I may have to get there, but you know,
the longer I can hold out, the better. So is
this something that somebody can just slam in on their
own and just go for it?
Speaker 2 (21:29):
Yeah?
Speaker 3 (21:29):
So we're actually really good in brown fields because we're
using the spec complant stuff. We're not using special tags,
we're not using special things. There's no there's no build step,
Like we're built in typescript because I love static analysis
and I get as much of it I can. But
the final thing is just a single CDN link and
it's one ten K JavaScript file Like that's all you
got to do to put.
Speaker 2 (21:49):
It on a page.
Speaker 3 (21:49):
For most people, it like it's smaller than the fave
icon that they use. Like, so you just drop that
on your page and you can get to work. And
the thing is, it's it works. It's a spect complaint things.
So if you just say I just want to use
it for the data class. In fact, like a person
that run the podcast was actually using us instead of
Alpine for their AGMX stuff, even though we completely replace it.
(22:11):
Like it's one of the things of like sure you can.
It's actually smaller than an Alpine and it does all
the stuff Alpine does as well, and all the stuff
that Turbo does and all the stuff that Stimulus does.
So like, yes, you could start dropping it in and
then changing out things as you see fit. So there's
real value in that in my mind is that it's
it's meant for brown Field and if you can start
from fresh, then you're just gonna be deleting code, Like
(22:31):
that's the neat thing. I've done enough stuff in Alpine
and AHGMX, and I haven't done a lot of Turbo
because I bounce off of it. If you're not a
Ruby person, it's a little hard to use in my opinion,
And I will say I guarantee you, like I will
take any bet that your code. You're gonna have less
code on the page just because it's there's less that
has to.
Speaker 2 (22:49):
Go on to solve the problem.
Speaker 3 (22:50):
And I think people just overcomplicated it because they kept
working the wrong side of.
Speaker 2 (22:54):
The problem, honestly.
Speaker 1 (22:56):
Well, one thing that I've seen, you know, just speaking
to that is far as working the wrong side of
the problem, is that a lot of times we come
from the context of the wider web world, and so
we look at it and we say, Okay, we have
this solution, how do we make it better? Instead of
saying we have this solution. Okay, we've banged on it,
we've made it better. But if we had these underlying
(23:19):
underlying things different, then the whole solution changed and it
got better. And so yeah, I think a lot of
this just kind of comes from the momentum of the
web world. I'm kind of curious. You mentioned the plugins,
and you've also mentioned like just pulling it in from
a CBN and not using NPM. So a lot of folks, yeah,
they have a build step on their front end, so
(23:40):
they pull in and then they use something.
Speaker 2 (23:42):
Like webpac or the or bite like that or something whatever.
You know.
Speaker 1 (23:46):
In the rails world, we've kind of embraced import maps,
and so I'm just curious you're saying I don't do
any of that stuff.
Speaker 2 (23:54):
Don't need to is a non issue.
Speaker 3 (23:56):
We have a version, we have started doing a pro
thing and we can talk about that in a bit.
But I have a bundler built in and because the
web app is actually built in Go, I just use
es build as a library.
Speaker 2 (24:07):
So vitn all that is using es build under the hoods.
Speaker 3 (24:10):
You know, it's a lot faster not doing any JOBASCRIPT
and just using Go directly.
Speaker 2 (24:15):
Like for me, it's just a library thing.
Speaker 3 (24:16):
So we actually have a bundler built into the page
when you log in and stuff, so you can actually
do all that stuff and make exactly the version you
need and it's just built into the browser and it
takes microseconds and then I cash it and do all
that kind of stuff.
Speaker 2 (24:26):
Right, We like, that's the right answer. You don't need
all these other steps.
Speaker 3 (24:30):
Like there's a lot of times where people like bounce
off a type script, but I think it's one of
those things.
Speaker 2 (24:35):
But it depends on what you're doing.
Speaker 3 (24:36):
So for things like building an entire framework that it's
static analysis and there's a plug and thing, it's great
at that. If you're doing a small web component, you
don't need it. So people like they think that they
need to have a one stop solution for all these things,
whereas most of the time, like what the library author
need to do versus what they need to do to
get stuff on the screen is a very different problem.
Speaker 1 (24:56):
So so what I'm hearing is, U, I pull this
in and it basically just works out of the box.
I don't have to go right stimulus controllers or components
or anything like that to get functionality onto my page.
If I need custom stuff you mentioned plugins, is that
(25:16):
the way to do that or so it's funny.
Speaker 3 (25:19):
At first, I made the plugins because I thought there'd
be like a bizarre like almost like the Unity Asset
store where everyone write a million plugins. But what we
found is there's not like the browsers are gotten good
enough that there's not that many things that you need
to kind of hijack and make better, like setting up
classes and having the string manipulation there and for styles
and for like there's other things like data on RAFF,
for doing request animation frames. There's certain things that are
(25:42):
this easier in that expression language. But every time someone said, hey,
I want to make a plug, and we say, hey,
like talk to us, because if it's a good idea,
we'll do it.
Speaker 2 (25:50):
So it ended up that I wanted it to be
this thing everyone uses.
Speaker 3 (25:53):
But the irony is there's not that many plugins to write,
and if you come and talk to us, we'll just
write it in build it into the library. In fact,
it just happened because we use everyone says to use
styles or classes because of tail end and all that.
But someone came in with some really good ideas around
how to do animating of styling and stuff, and they
wanted to use this have a style thing and we
had had it for two years.
Speaker 2 (26:14):
In a day we had it and we're like, oh no,
that's a good idea.
Speaker 3 (26:16):
And now it's part of the latest rc is data
ash style is now just a built in thing. So
it's yeah, it's more of an implementation detail at this point.
Speaker 2 (26:25):
The plugin system because you have to know.
Speaker 3 (26:26):
Like it is a little bit harder to write plug
ins because we're very code golfy and we try to
make it as efficient possible. There's that, but anyone can
write a plug in, but you right now you basically
four can kind of go on your own route. But
the whole system's there. You have access to everything, it's
just getting it into the core. We're a little finicky
with that stuff.
Speaker 1 (26:45):
So effectively, because I know some people are just going
to kind of have trouble wrap their head around it. Okay, well,
I have this custom behavior that I need to blah
blah blah blah, and so it has to do.
Speaker 2 (26:54):
All this stuff.
Speaker 1 (26:54):
And what you're telling me is that essentially the way
that the framework works, you can do probably ninety nine
percent of that stuff just with your data attributes and
then leaning on the framework.
Speaker 2 (27:07):
Yeah.
Speaker 3 (27:07):
And the thing is that when you run into something
really company like I built an entire three D engine
for one of the things that I'm doing, and that
was just one web component, Like it's are a couple
of web components and they just nest in tide each other.
Then you drive it with data start and it's not
that bad, and you just are updating props and you're
handling events.
Speaker 2 (27:24):
The thing is that.
Speaker 3 (27:25):
The browsers already have a native way to do that,
the way to encapsulate JavaScript.
Speaker 2 (27:30):
So a lot of people just like, well, how do
I add this one little JS thing?
Speaker 3 (27:33):
Most of the time it's they're trying to interact with
some other charting library or some other thing that they
didn't wrap that in a web component. Then now you
have something that can be shared anywhere all the time,
and that's the right way to do it in the
modern web, Like that's just easier for everyone, and now
you have something that's sharable, whereas right now we don't
have a lot of sharing going on between frameworks and stuff.
Speaker 2 (27:51):
Whereas with data start, we embrace the like what the
or what the web is already good at.
Speaker 3 (27:56):
And what's also nice is if you are using Spelt
or Reactor and you're want to move towards that, all
of those support web components of the box, Like you
can turn things a view component into a web component,
say wass Felt, all these thing in facts felts a
pretty good option if you want to live in that
world and still do SPAT stuff, you can turn those
things in wet components and now drive them a data
star and be so much more efficient in.
Speaker 2 (28:16):
How you do that. Right when you say web components,
you're talking about like the spec that's out thereah then
native spec. Yeah, yeah, it's really good.
Speaker 3 (28:24):
Like there's some things that are kind of clunky about it,
but like we're working on a thing we're calling internally
calon rocket right now, which is a way to make
it to it's kind of like our version of lit
where you have your own little thing that automatically does
a hook up of signals and does some niceties for
you to make the code smaller. But just writing the specs,
like writing spec compliant web components is not that hard.
You get props down, you make changes, and then you
(28:46):
render your HML.
Speaker 2 (28:47):
That's it. Like, it's not rocket science.
Speaker 1 (28:49):
So just to kind of recap because I'm just thinking
through this and it sounds pretty awesome. Now I want
to go play with it, and I want to go see,
you know how I can kind of plug this into
my rails apps because I mean sometimes writing the stimulus
controllers or you know, kind of getting some of the
custom behaviors, just like it's not exactly what I want
or yeah, there's a little bit of ceremony around, not
(29:11):
a ton, but a little bit.
Speaker 3 (29:13):
No, and there shouldn't, especially in a language like Ruby,
there should be basically no ceremony. In fact, we have
a very vibrant Ruby community already built, and we have
a Ruby SDK. I would highly recommend joining the discord,
joining the Ruby side and saying, hey, you know, I
talked to Delaney and like I'm interested, what do I
gotta do, and you'll see that we have a lot
(29:34):
going on already, like it's it's already vibrant for being
a small community.
Speaker 1 (29:38):
So yeah, I guess what I'm interested in is just
to see how it stacks up and how much of
the stuff I wind up doing in a stimulus controller
that I can just.
Speaker 3 (29:49):
You probably can trug the right almost all of it.
And the nice thing is that we have a guide end. Yeah,
and the we have a guide and it's actually written
with all the examples in different languages. So if you, oh,
the guy, you can just go to the ruby one
and literally step through and say does this match my needs?
And again it's not that like we don't make anything
from this, but it's more of it, like we want
to see the web be a better place. In fact,
(30:10):
we actually set up a nonprofit. We have a five
ZHO one C three that's already set up for it,
so like we actually have a mission in a goal.
There's not going to be some vercell rugpool play some later.
Like we literally did the nonprofit to make people understand
we don't have stocks or anything like that, Like we're
stewards of the project. We're trying to do the right things,
and we want to see the web be better because
(30:31):
I want to get back to I dog food this.
I use it for work. It's not like this is
my right gig. I just want to make it better
and have more people involved so they can make it
better with me.
Speaker 2 (30:40):
Right. So you mentioned vercell.
Speaker 1 (30:43):
You know you've also got Netlify and a bunch of
these other ones that you know they'll host your your
front end. They'll host your back end too, depending on
how it's put together. And so is this something that yeah,
I can just throw it together and have out there,
I guess if you're just pulling it off the CDN.
Speaker 2 (30:59):
Yeah, you just like you just copy paste to local
if you want. Like what I do is I use GO, So.
Speaker 3 (31:04):
I use the embed stuff so I can bet all
my file system directly into my binary. Right, So I
just make it so it locks loads like copies in
as part of my build stuff from the CDN stuff
from just delivered, and then I have a binary version
that works anywhere in the world. So I have a
single binary that I can to play with SEP and
have it on a thing, no problem. So it's actually
(31:27):
simpler in every way. You don't need DevOps to do
most things. You need SEP and a system cuddle file
and that's it, Like that's all you need. So it's simpler,
but it works in the big scale teams too, Like yeah, yeah.
Speaker 1 (31:40):
It sounds like you can just serve it, you know,
depending on what your back end is and how that
stuff works. Yeah, you can just you can run it
through whatever asset pipeline or management you have, and yeah,
you just serve it up and run it.
Speaker 3 (31:53):
Well, that's the thing I wanted to get back to,
like I remember when in fact, it's funny, the more
of the stuff I do more, I'm like, man, Jay
Curry was so close to being right.
Speaker 2 (32:02):
Like it had a lot of these ideas, but.
Speaker 3 (32:04):
It was it got so muchy passed and so crazy
because the problem is that the data dash Star actually
weren't there. CSS nesting wasn't there, Like it was the
best version of its time. But we were so close
to something that was really about because you just like
throw j carry on the page, you make the changes
you need, and then most of the stuff was in
the back end. It's like that's pretty close. But we
kept saying, well, we want to do more and more
(32:25):
in the browser, and part of that is, at the
time you had like for example, glass Fish in the
Java world, where every every request was its own thread, right,
and that was like you couldn't wait on the server.
It was like seconds of time between Right now you
can have forty thousand connections per core on a normal
like async server. Like the problem is that things like
(32:45):
issue next to me are yearning for the style of
the two thousands, But I want some of that style
with all of the features of now, Like people don't
realize that we've gotten a lot better, and I want
to have that betterness.
Speaker 2 (32:58):
So you and.
Speaker 3 (32:59):
Da Well, in fact, the very first version of this,
or when I committed it, I was like, DHH will
hate this because when it's doing his whole typescript sucks
diatribe thing.
Speaker 1 (33:09):
Yeah, but the ideas that you're talking about and the
things that you're pulling in, and you know, the niceties
of how we did things, you know fifteen twenty years ago,
you know where a lot of this stuff was a
lot simpler. I mean, he does push back to that,
and that's a lot of the idea that he's a
guy I wish, Yeah, he would typescript.
Speaker 2 (33:30):
That's a different thing. Well, the thing is that it's
a most people are completing.
Speaker 3 (33:34):
I want to write my daily like updating of my
page in typescript, Like, no, you don't need to do that.
If you don't need to write any Like in the
data R way, you basically write no JavaScript most of
the time you don't need to.
Speaker 2 (33:45):
And when you do, it's the little little snippets of expressions.
Speaker 3 (33:48):
Right, you're going back to almost the the the on
click days of like you're doing a little expression and
so that's a lot easier. I would love if you
would try it out, because I bet he, like he
seems to be very motivated by getting to good answers,
and I actually think he might see it and say
this is better than Turbo, Like if he actually spend
time with data Star, he might Actually I think that
(34:09):
could be an actually a possibility because Turbo is only
focused on Ruvie. It's only it's kind of a piecemeal thing.
It's not really their focus. It's just kind of like,
this is good enough, it's better than the other tools
out there. Cool, we're done, whereas data Star went hard
on hard problems and we're faster or smaller and we're better.
And like he seemed to be one of those people.
So I would love for him to try it out.
(34:30):
I just don't have the context to know, like I'm
a nobody on it, Like I'm just a guy in
a whole kind of thing.
Speaker 1 (34:35):
So so, so the other thing I wanted to throw
out there is a lot of folks use I mean,
you mentioned tailwind, but on top of that, and I
think tailwind is offering one.
Speaker 2 (34:45):
Now if you have tailwind plus or pro or whatever
they call it. I do have that.
Speaker 1 (34:48):
I just haven't used their library because I don't use
React on the front end. But they have these component libraries, right,
and so it's you know, you've got your accordion dropdowns,
and you've got your menu stuff, You've got your you know,
you've got your scrollers and all that stuff, right, And
so what you're advocating, if I'm understanding correctly, is you
put all that stuff into your into a web component
(35:10):
and you build the behavior and then you make it
do the thing that you wanted to do.
Speaker 3 (35:15):
So that's that's a great question in that like okay,
like how will you do how do you do stuff
with it? Like, great, you got the base stuff, how
do you do things? So one of the things now
that data Star is done would be ones out. Technically
we're an RC so in case the SEK author is
need to change something, but everything's it's as V one
and so now that that's done, we can start building
things on top of it. So it's not like data
(35:35):
Star as we actually literally created star Federation, which is
a set of tools and things because I do want
to make the web better now, Like, even though I'm
not a web gag, I know Star Federation and it's great.
It's actually star Federation is the actual nonprofit name.
Speaker 1 (35:48):
It.
Speaker 2 (35:49):
Oh nice, it's the best, dumbest name.
Speaker 3 (35:51):
But the thing that's interesting, at least from my perspective,
is now that we have this foundation, we can build
a million interesting tools. One of the tools that I'm
building right now is called stuff, and I think it's
a tailwind killer, like one hundred percent will just murder tailwind.
Speaker 2 (36:05):
And the reason why.
Speaker 3 (36:06):
Is because basically I'm taking a lot of the ideas
from open props, which I think is a really good
thing because it's basically just a bunch of CSS variables
that someone from the Google team out of Margout made
that basically you're doing stuff with standard CSS because now
nesting's there, all the functions and mix ends are coming.
CSS has gotten a lot better, so just use variables
to do a lot of the things you were doing
(36:26):
in Tailwind. So it's a mixture between you know, CSS,
tailwind and open props. And basically what I'm doing is
I'm building a live editor where you are making changes
to all the kind of things that you would do
in tailwind canfig.
Speaker 2 (36:39):
You actually have a live editor.
Speaker 3 (36:41):
It's actually going back to the server and depending on
what you've changed, automatically has cashes of all this stuff
and then generates the styles and stuff on the fly,
and then at the end basically gives you a full
set of variables and all the canfigs and all this
so you actually are able to play with it live
in real time even though it's going back to the server.
Because we cash everything, we can actually get really really
fast and say three or four is has not been
(37:02):
modified all those kinds of things, and I'm making it
and it's going crazy fast and you can basically point
at this thing from anywhere, and now you have a
full CDN version of Tailwind with no build, no setup,
works on any back end. That's where I think the
future is going to be is getting this collaborative stuff
that is shared, and you can't share stuff if all
your state's in the front end. That's just like the
(37:24):
local first thing to me, I think is a hot nightmare.
Like it's just the wrong approach to the web. It's
not that if you want to do that, go do native,
Like there's nothing wrong with native.
Speaker 2 (37:31):
I'm like a game guy like I like C and
C plus plus they're great at that. But the web
is not that.
Speaker 3 (37:36):
The web is about sharing collaboration and only having the
state of your page at that time. That's what the
whole hypermedia thing was about, like not API is not Jason.
Speaker 1 (37:45):
Okay, I'm not sure if you completely answered the question though.
So you know you do have these different components that
have different behaviors, right, and so yeah, as your approach
to that, just to put them into web components.
Speaker 2 (37:56):
Or if you need to.
Speaker 3 (37:58):
Most of the time, most of your components act live
in your back end because it's about what state I'm
changing in my bad Like if you're taking about a
database like row and you're saying I'm updating something, all
the state is right there. You shouldn't have to send
down Jason, you can just send down HTML. And the
irony too is that people don't realize this HTML is
much more efficient to create and send than Jason. And
(38:20):
what I mean by that from a technical standpoint for
anyone that doesn't know, is like with Jason, you're basically reflecting.
For most languages, you're reflecting through and creating a tree structure.
So you're making a tree structure, whereas with HML you're
just having static pieces and you're basically filling islands. So
you have these big, large buffers and you're able to
update things way faster. And if you're using the compression
stuff we do, where you have like Broughtley windows or
(38:43):
zelib standard or these standard windows, all that stuff is
already in the buffers. So now you're getting really really fast.
You're getting between two hundred to two thousand to one
compression ratios and it's not recursing a tree. So yeah,
you're still making components, but you're making mostly the locality
here it becomes the same line in my world, So
that makes a huge difference.
Speaker 1 (39:04):
Right, that makes sense. And then as far as I mean,
some of them are just visual things, you know, so
you've got like your your drop down menus and things
like that, you know, so you put those in and
with those you're literally just adding and removing CSS classes
and so so you just put that into your your
events and your your data attributes and it just does
the right thing.
Speaker 2 (39:24):
Yeah.
Speaker 3 (39:24):
So when you have like, for example, you do a
data class and then you give the class is open,
and then you hook that into a signal done like
and then if you taggle that, you can talk it
from the back end, you can talk it from the
front end.
Speaker 2 (39:34):
You can do all kinds of stuff like.
Speaker 3 (39:36):
It just simplifies that because you're just hooking into the
signals properly. It makes us a little expression and you're done.
I mean, it's a lot of what Alpine was doing
from that from the front instance side, but it's way more.
Speaker 2 (39:49):
I've seen that in well there was another one too anyway,
But you.
Speaker 3 (39:54):
Don't need veto On to do that stuff, and you
don't need the way that Outpline is doing things, and
you can actually be a lot smaller and a lot
more efficient.
Speaker 1 (40:01):
That's true because you're just directly poking the dom yep,
it's just dumb events.
Speaker 2 (40:07):
Yeah, so yeah, that's cool.
Speaker 1 (40:10):
Well, my calendar just told me that I have a
meeting for my day job here in like seven minutes.
So if people want to go check out data Star,
you said, is data da start dot debt.
Speaker 2 (40:21):
Yep, that's the website. Go check it out. And then
you said there's a discord channel as well, and they're assuming.
Speaker 3 (40:27):
Oh yeah, no, we have around twelve hundred users right now,
maybe a little bit more.
Speaker 2 (40:32):
So, Yeah, it'site.
Speaker 3 (40:34):
Yeah, yeah, you can enjoy. The discord is right on
the main page. Let us know if you have any questions.
But yeah, it works in every language, and if you
have questions, come holler at us.
Speaker 2 (40:43):
We're happy to help you.
Speaker 1 (40:44):
It's cool. Well, so we do have a segment at
the end of the show. It's called Picks, and we
just shout out about stuff we like. So I'm going
to jump in and I'll do some picks and then
I'll let you do some picks. My first pick, I
always do a board game. My wife and I we
went on a trip. We had our twentieth anniversary in March,
and we couldn't quite get out for the trip we wanted,
(41:05):
and so we did it a week or so ago,
right before the fourth of July. And one of the
games that we've been playing. Some friends got it for us.
We watched their kids while they went to a board
game convention and they brought it back for us, and
so we've been playing it. It's called gloom Haven Jaws
of the Line. It's very good. Yeah, so they were
telling us they've played all three of them. I guess
there's gloom Haven, there's gloom Haven Jaws of av a prequel,
(41:29):
and then frost Haven and so yeah, so this is
our first foray into the gloom Haven world. I've played
D and D before, but my wife really hadn't even
done that. So we've been playing that and we're about
halfway through the fourth scenario. That's the only complaint I
had about it was that the scenario took longer than
we had and so.
Speaker 2 (41:46):
We've kind of had to like move the whole table aside.
We didn't want to take it down. But that said,
it's been a lot of fun.
Speaker 1 (41:53):
So if you kind of like D and D and
you you know, you don't need a dungeon Master game master.
It just kind of that's the scenarios up and you
follow the rules and you know, you fight the bad
guys and complete the scenarios and it is.
Speaker 2 (42:07):
It is really fun and we've really fun.
Speaker 3 (42:10):
So I actually have a They have a Steam version
just so you know that you can actually run as well.
That's actually really solid, so you can get the Jaws
of Lane stuff on that version as well.
Speaker 2 (42:21):
I'm a board game nerd as well.
Speaker 1 (42:25):
Yeah, my one of my daughter's friends is way into
board games, and so she and her friends were over
here and he wandered into our pantry where we have
half the pantry full of board games and he was just, yeah,
we have we have plenty and I get together with
my buddies and we play every week.
Speaker 2 (42:43):
So yeah, anyway, so that that's a fun one. Uh.
Speaker 1 (42:48):
And then other picks. I just picked up some new microphones.
I'm gonna grab the box. So these are the road
if you're watching the video Wireless Pro. It has two
receivers or two transmitters with the lapel mics and then
a receiver and they're awesome. So gonna I'm gonna pick those.
It's just gear. They're not cheap, but they're great. And yeah,
(43:10):
I've been in this scenario where I needed to do
more than two people with these, and so I also
have a mixer that I bought for one hundred bucks
off Amazon and that's been great, so really really happy
with that stuff.
Speaker 2 (43:20):
I don't know if I have any other picks, but yeah,
if you've got some ex sure I'll do two quick ones.
There's a book that I've read multiple times.
Speaker 3 (43:29):
With a few books i've read multiple multiple times, but
it's actually being turned into a movie, so I'd highly
recommend reading the book first.
Speaker 2 (43:35):
I know what it is, Oh do you? I bet
I know what it's going. Okay, let's go for it.
Tell me is it Project tail Mary? Yeah, that's it's
a great book. So excited for that.
Speaker 3 (43:48):
I hope they get Rocky right, So that's going to
be a hard one, but it's a good team behind it,
so I have high expectations.
Speaker 2 (43:56):
But it's a great book.
Speaker 3 (43:58):
And if you haven't read that, there's also another good
one called Recursion that I just read that was a
solid pick. I don't know the author, but quite or
it's a big yellow front cover.
Speaker 2 (44:08):
It's an interesting book. So yeah, those are the books choices.
Speaker 3 (44:12):
And when it comes to it, if you did board games,
I have to say that I've been kind of getting
deep into the Arcs world I haven't done the whole
campaign thing, but if you haven't heard of Arcs yet,
it is a challenging, interesting board game of trying to
control the uncontrollable. It's a very interesting take on it's
technically I guess people take called a space game, but
it's not really. It's it's not like Twilight Imperium or
(44:34):
anything like that. It's a very interesting thing, especially with
four players. So I would highly recommend looking at Arcs.
I love to check it out. So Project Hail Mary,
I think people are more familiar.
Speaker 1 (44:45):
With The Martian, which was another book that he wrote,
and so it's the same author. I will say that
I liked Project Hail Mary better than The Martian, so
by far, yeah, easily it is a better book. So anyway,
I'm super were excited. The second I saw the the trailer,
I sent it to my wife and she, wait.
Speaker 2 (45:06):
There's a trailer. I haven't even seen the trailer.
Speaker 1 (45:07):
Yeah, yeah, yeah, yeah, and yeah, so she watched it.
Speaker 2 (45:14):
She's like, so, I'm like, you got to read the
book first.
Speaker 3 (45:17):
Well, in fact, that the Recursion book was a recommendation
from anywhere saying hey, what books do you what are
you reading that you think are interesting, and he recommended
the Recursion one, and I was like, I was like, yeah,
it's actually a pretty solid book.
Speaker 2 (45:28):
It's very interesting take. So yeah, I highly recommend taking out.
Now have to go watch the trailer, I apparent last.
Speaker 1 (45:35):
Yeah, I had just gotten off of a terry goodkind
binge doing all the sort of truth books, and so
I wanted kind of a different pace.
Speaker 2 (45:42):
You know.
Speaker 1 (45:43):
It's like, Okay, I've kind of taken on a ton
of this, Like I read everything that Brandon Sanderson writes,
but I can only do like five or six of
his books, and it's like, okay, I got to cleanse
the palette with something else, right.
Speaker 2 (45:56):
So so that that's what this was. You know.
Speaker 1 (45:59):
I saw the the trailer and then I just started
listening to that one on audible.
Speaker 2 (46:03):
Yeah.
Speaker 3 (46:03):
It's actually one of the few books that you really
want to listen to it. It's a great as an
audible because they actually do the voices. I can't go
without spoiling things. It's really good as an audiobook, I'll say.
Speaker 1 (46:14):
Yeah, yeah, the vocals with Rocky in particular, Yeah, all right,
good deal. Well let's go ahead and wrap this up
so that I'm not late for my meeting. I'm arguing
for my meeting, but this was a ton of fun.
Definitely something I want to go check out. If people
want to follow you on the internet, where do they
find you?
Speaker 2 (46:31):
Data started?
Speaker 3 (46:31):
I'm on Twitter? Is Delaney Gillilan. I know it's kind
of hard to say, but if you look for data
star you'll find me. Really, don't be interested in me,
there's nothing interesting going on there, but I will say
data star has.
Speaker 2 (46:42):
An interesting community. Now, so come join all
Speaker 1 (46:45):
Right, folks, Well we'll wrap up and until next time,
max out
Hey folks, welcome back to another episode of JavaScript Jabber.
This week, I'm your host, Charles Maxwood, and we are
talking to Delaney Gillileen. We're going to be talking about
how everybody's doing the front end wrong and how it's
super slow because we all do it wrong. So do
you want to introduce yourself and we can dive in
and talk about how we could do it better.
Speaker 2 (00:27):
Sure.
Speaker 3 (00:27):
Yeah, as you said, my name is Delaney.
Speaker 2 (00:30):
I have a kind of a weird background.
Speaker 3 (00:32):
I've done a lot of stuff in game development, military
applications and all that, and I've always found that the
web is an amazing sandbox for doing security and deployment
and so it's almost its own little os and I
love the ideas of it, and I've done some pretty
big applications in it, but I've always had this weird ditch.
Speaker 2 (00:50):
That things are being done wrong. I really had.
Speaker 3 (00:54):
Issues with spas and how you're basically sitting down in
all your state and Jason and recreating the world each
time you do an update, and so I started getting
into hypermedia and the HDMX stuff, but I ran into
issues with that too, and long story short, I ended
up with my own framework called data Star that is
trying to solve all those things of being there's the
(01:17):
line of like the MPa style of HTMX, and then
there's the SPAS and I think we really are on
a different plane. We're doing stuff that's not in between.
We're doing both and more. So okay, I can talk
about it. Yeah, it makes sense.
Speaker 1 (01:31):
My weapon of choice in this space is Turbo, which
is part of hot Wire, and.
Speaker 2 (01:36):
It does a lot.
Speaker 1 (01:37):
It doesn't do exactly what HTMX does. You know, the
same kind of idea where you're you know, you're streaming data,
you know, back and forth and you only rerender what
you got back and it sends back HTML instead of JSON,
and so it doesn't have to go and figure out
what all of your components are and then redraw it
like React does.
Speaker 3 (01:58):
Well, if if you've Turbo, then I've already worked with
mckel and the guys over the Turbo team to work
on a new version of the morphs stuff. So we
actually use uh vomit. Yeah, we have our own version
that we started from working with Michael. In fact, he
was on our podcast a while ago and we worked
on that for quite a while. But we have the
fastest morph being strategy in the world. So if you've
(02:19):
already used turbo, are getting some of the benefit, You
getting some of the benefits of the work that has
been done in data ironically.
Speaker 2 (02:25):
Oh interesting.
Speaker 1 (02:26):
So yeah, so it sounds like there's a story here
right where you're saying, Hey, I wanted to do a
thing and the tools out there were not the best
tools for it, or I thought there could be better
tools for it. Do you do you kind of want
to just back up and give us some conflict on
where this all came from.
Speaker 3 (02:41):
Yeah, So I was working on a project and it
ended up being in view and mostly three D. So
project was basically a military thing where we sent every
radar blip from every radar station in the continental United
States in real time to the browser, and they wanted
to be able to scrub back in time over and
now like live. So you're talking about a million updates
(03:02):
per secon about nine hundred thousand updates per second and
being able to scrupt to any point in time within
a second to any point in time. So that's a
hard problem if you don't know, like, that's a lot
of buffers and a lot of gl stuff.
Speaker 2 (03:14):
And so I'm mostly a web guy like my backgrounds
in three D.
Speaker 3 (03:17):
So I was knocking that out and I was like, man,
there's got to be a better way because I'm basically
sending all this spas. You're sending the entire state of
your application to the front end. All your state lives there,
and then you're trying to keep those the state of
the back end the front end in sync. Right on
sort shirt, I started searching around more to do different things.
HTMX I thought was a really interesting idea in that
it's going back to kind of hypermedia of the two thousands.
(03:40):
But one of the things I ran into is that
A it wasn't fast enough and B it didn't include
things like the morphing out of the box.
Speaker 2 (03:47):
So I was like, well, why isn't that included?
Speaker 3 (03:48):
And then I was like, well, I want to be
able to pick and choose, because some of the choices
they made I didn't think were very good. So I
wanted to have a plugin system. They have extensions, which
means you can add stuff on top of HTMX. Right,
you can't replace anything in HTMX right, it's its one
big five K file and you kind of left with it.
So I went through and said, okay, if I was
writing a game engine but for the web, what would
that look like, Everything being module, everything being kind of
(04:09):
an ECS style, like a different way of looking at
it from a data oriented perspective. And so once I
started getting into it, it long over time basically morphed
into its own thing. But in data Star, for example,
everything is a plug in, literally everything, And one of
the major plugins that we have is this thing that
does service set events. And people really have not understood
service set events, and they think it has to be
(04:31):
a stream, it has to be this extra cough thing.
All it is is a chunked response and that's it.
That's literally all it is. It's a data type, which
means as soon as you can send down a response
with it data event, you can send down signals, you
can send down elements, you can send down different parts
of the page, so things like HTMX.
Speaker 2 (04:47):
It's a kind of a it's not the norm to
say I'm going to.
Speaker 3 (04:50):
Update this part of the page or this part of
the page, or I want to pin this signal, I
want to merge this thing like you kind of do
a whole Just the way it works doesn't kind of
jive with what I wanted to do. Basically just sat
down and started writing out these pieces and lo and
behold ended up being way smaller. So, for example, we
include the fastest signal library in the world. It's built
off alien signals if you're into that space at all,
(05:12):
and we have the fastest moreporting library by far, and
we're ten kilobytes.
Speaker 2 (05:16):
Wow.
Speaker 3 (05:17):
Yeah, the whole thing, And so it's a pretty crazy
thing that we basically just if you don't rely on
other people's lives, everything's there's no MPM, there's no vendoring.
It's just all written for those specific needs. So every
plugin is completely independent, and it makes it so that
it's really fast, really small and really tight code, and
then you don't have to think about it anymore, which
is kind of a neat thing. And also we're the
(05:38):
only one that's really relying on the specs. So there's
a thing that's built into the to the HTML specs
called data dash Star, which basically allows you to put
data astributes.
Speaker 2 (05:47):
So data star is just.
Speaker 3 (05:49):
Hooking into that and reading up the key value store
that it gives you and then implementing its own modifications
and stuff. So basically everything is like data dash class
data dash on, data dash load these.
Speaker 2 (06:00):
Kinds of things.
Speaker 3 (06:01):
So we're living within the spec So it's not that
we're trying to replace it with a whole new spa
framework or something. We're literally just using the things that
already built into the browser, which means that we're very
small and very fast, because the fastest thing you can
do a jobascript is not.
Speaker 2 (06:15):
Do jobascript, I'm true.
Speaker 1 (06:17):
So I guess you know, seeing this particular use case,
you know, or you've got millions of you know, blips
on radars across the US, and you know kind of
doing a lot of that real time stuff, which I
think is a different thing. You probably handle a lot
of that on the back end, but then making it
all show up the way that you need it to
on the front end is the challenge we're talking about.
(06:37):
Is this something that you would recommend just for people
who are doing that kind of a thing, or is
this a better fit for other problems as well.
Speaker 3 (06:44):
Yeah, so I think that the way the Data Start
builds things now is the best way to build the
websites barn On.
Speaker 2 (06:51):
And the reason why is people.
Speaker 3 (06:53):
Say, well, yeah, I'm not building a game, I'm not
building will time stuff. Yeah, but if it can handle that,
then it can handle your other issues so much EASi.
Speaker 2 (07:00):
So for example, there's a one of our.
Speaker 3 (07:02):
Users made a it's really a rendering demo because it's
the dumbest way to build this kind of thing. But
he took the Game of Life and he made every
cell a DIV and then colored the div with CSS,
and then when you click on it, it updates to this, so.
Speaker 2 (07:16):
You have twenty five hundred divs.
Speaker 3 (07:17):
He's updating in it like between five and ten primes
a second, and it's it's a shared state, so everyone
in the world's he's the exact same version of it
at all times, and it's rendering in like eight milliseconds,
So if you can handle twenty five hundred dives, yeah,
So it's it's fast enough that it's just a non
issue for what you're doing. And the other thing that's
interesting about this approach, which we can get into, is
that he's not sitting down new like if you were
(07:40):
doing that in a normal spot, you would be sitting
on Jason all the time.
Speaker 2 (07:44):
He's sending down the finished HTML.
Speaker 3 (07:48):
But the thing is, like, for example, in a Game
of Life, it's not that different from the last approach
so he's getting between four and five to one compression
ratios with no extra effort.
Speaker 2 (07:57):
So he ended up being on.
Speaker 3 (07:59):
The top of Hacker new Is on a five or
ten dollars machine and it ran fine.
Speaker 1 (08:04):
Yeah, that makes sense because essentially what you're doing is
you're saying, instead of here's the whole Game of Life
board visible space, you can just say, hey, these handful
of ones are the ones that got updated right, changed color.
Speaker 3 (08:18):
Well, so here's the thing that's really nice is that
he's sitting down in that case, all twenty five hundred
dips because it's fifty by fifty grid, he's sitting all
of them down every single time. Oh really, because yeah,
So the thing is you just think about it as
this big fat morph and it is smart enough to say, hey,
I already had a compression window that had bits and
pieces of it, so you mentally can.
Speaker 2 (08:36):
Think of it. It does.
Speaker 3 (08:38):
Yeah, that's what the morphdomb and also the Broadley compression
and all these things, like we've thought about this stuff
at a deep level where we can send down things.
So if you had a board that you know how
in Game of Life, if it's just sitting there kind
of switched between two states, like if it gets to
a stable state, that change over since it's already in
the window of the Broadley stuff is like twelve bytes
bytes twelve bytes, so sending down twenty five hundred things
(08:58):
just a twelve byte change. Depending on how much data
that is shared in your updates, you can get these
crazy compression rangions, like we've seen up to four thousand
and one compression. So it's better than web sockets because
you get all this compression stuff, you get the proper
headers and cookies and all that stuff. It's better than
standard crud stuff because you're halfing your polling. So instead
of requesting something and getting back and requesting something and
(09:19):
getting it back, we're having that RTT because we can
just send down as we decide on the back end
right when you need it, so you can send it
every second or speed it up or slow it down,
it does not matter. Everything else works the same. So
it is by far the best way to build any website.
And I will take on anyone with that challenge.
Speaker 1 (09:34):
So let me kind of back up a little bit
because I know that a lot of people, you know,
if they're doing front end, so and to give you
a little bit of a context. I mean, my weapon
of choice again, like I said, is the hot wire stack.
So I'm usually using something like stimulus and so and it.
You know, you're talking about the data attributes and stuff,
and stimulus just basically gives you a convention on top
(09:55):
of that to you know, to scope your changes.
Speaker 2 (09:58):
And to track your events.
Speaker 1 (10:00):
So I guess what I'm wondering here is, you know,
you've talked about a game of life. You've talked about
so those are both kind of visual things. I mean,
I guess the one is kind of a poor man's
you know, pixelated thing, and then the other one is
like a full on what is it, you know, just
a graphical visualization of the radar and things.
Speaker 2 (10:23):
So is there is there a data driven you know.
Speaker 1 (10:26):
You know, dashboard or user interface or admin panel or
something like that that's been built with data Star.
Speaker 2 (10:32):
Yeah.
Speaker 3 (10:33):
The thing is I work at Sanadia on that's as
a day job, and so I'm building literally that right
now as a real time dashboard thing for all the
interconnected sets of contexts on global superclusters.
Speaker 2 (10:43):
That's what I'm working on right now.
Speaker 3 (10:44):
So I can tell you by far it's the easiest
way to do that because you can think of things
in these large fat more basically thinking of it in
immediate mode. If you've ever done game development, your UIs
are generally they're so interactive that it doesn't make sense
to hold on to state because you're basically re rendering
the whole thing in a new state every frame anyway.
So the immediate mode is more the sell of data start,
and it is by far the simplest way to build
(11:05):
those kinds of complicated dashboard. If you go to the
website data star or data dashtar dot dev and go
to for example, the DBMD like, that's not like it's
techniquely it is interactive, but we're actually updating that dashboarding
thing in micro seconds, not milliseconds, not seconds like you're
used to seeing in a dashboard. We're doing it in microseconds,
(11:26):
so we're able to make updates to the back end,
make it very efficient, and actually make shared state.
Speaker 2 (11:31):
So one of the things I think is going to
be coming in.
Speaker 3 (11:33):
Web poor point zero kind of thing is much more
collaboration and the idea that all the state should be
living in the right place, which is most primarily the
back end, means that everyone can have these collaborative shared states,
and it's actually cheaper because you're sending down just the
parts that have changed.
Speaker 1 (11:47):
So it's way faster, right, So what does the approach
look like then? So let's say that I'm like, all right, well,
you know, and I use rails on the back end,
but you know, so I'm going to use it. You know,
I'm going to use rails on the back end, or
maybe I'll use no or something. I don't know, but
you know, so I set all that up. You know,
I have ways to get data from my back end
from my front end. So what what does the workflow
(12:09):
actually look like when I'm building this out?
Speaker 3 (12:11):
Sure, so if you've already used similar or if you've
already used the turbo stuff, basically you could start with
a skeleton page that just says, hey, here's my like
layout and here's IDs for things I want to hook
into the same kind of way that the morph works,
you do the same thing, except for now you're basically
all you do is when you send back these we
have a SEKS to make.
Speaker 2 (12:31):
It a little bit easier, but it's literally just a
helper on top of SEC.
Speaker 3 (12:34):
You'd say I want to patch element and you give
it an element with an ID.
Speaker 2 (12:39):
That's it. That's all you do.
Speaker 3 (12:41):
Everything else is handled for you. It knows where to
grab it, what to update, how to morph. So the
defaults are if it has an ID, I'm going to update,
I'm gonna select on that and grab that ID, and
I'm going to morph by default.
Speaker 2 (12:50):
So in most cases that's all you do.
Speaker 3 (12:53):
You just like send a patch that says here's the
new stuff for that area that has an idea, and
you're done. And the nice thing is that most of
the state in the back end becomes really really simple
because you're just sending down win things shame.
Speaker 2 (13:04):
So your locality of behavior.
Speaker 3 (13:06):
Instead of saying I'm trying to build up adjacent object
and then send down, you're saying I got something from
the database. And what I do is I literally get
the row from the database and then I render on
the next row. Like I render, I get the data
and I send it to the template library and then
I'm done.
Speaker 2 (13:22):
Like the locality behavior can be the same.
Speaker 1 (13:24):
Line, right, So you use the template library on the
front end or do you know in the back end
that's because the thing is up to your back and
I tend to use GO most of the time. It's
it has a lot better tooling the sea for you know,
webright kind of stuff and so yeah, I just have
Temple and I have Temple components and you render the
stuff and you send it down.
Speaker 2 (13:42):
That's it. Like there's it's very simple.
Speaker 3 (13:44):
We have SDK's and I think twelve languages to make
this easier so you can just get up and running quickly.
But the nice part is like Turbo and HGMX have
the idea of like sending stuff in the back end,
Like I think that's a good idea of a general thing,
but the problem is they don't have the concept of
signals and reactivity and things on the front end. So
data Star also includes things like data class, data style,
(14:05):
data on click, all the signal libraries, data computed data,
effect like all the things you need to build front
and stuff it's up because there's times where there's client
side state and there's times when there's not, and being
able to know which it's which makes it a lot easier.
Speaker 2 (14:17):
Yeah, that makes sense.
Speaker 1 (14:19):
So to talk through some of this when you're talking
about the front end state, right, you don't need a
state library because you just put it all into the
data attributes and you just updated as you go.
Speaker 2 (14:28):
Yeah, so there's one familiar to me with stimulus. Yeah.
Speaker 3 (14:33):
So there's one basically global reactive store, kind of like
you see in redocs or any of these kinds of things,
where you have a global store. As you make changes,
it automatically updates and gives you signals and all this stuff.
And then what happens is whenever you do actions inside
you think, we have an at sign for basically actions,
So if you do it at GET or not at post,
it automatically compiles all the signals and sends it back up.
(14:55):
There's filtered on that you can say I want to
subset it and all that, but the point is that
you basically you can keep things in sync by sending
that state back up to the server. And because you
have so much of your states on the back end,
there's very few signals on the front end. Right There's
things like doing two a binding two an input or
a text area or to some kind of timer thing
or some user local setting of a theme that you
(15:15):
don't care about, Like, there's some of that stuff, but
most of the time you send all that up to
the server and then you know the exact state of
what the front end is doing.
Speaker 1 (15:22):
Right, So then if I need to send a signal
back from the back end, how do you manage that?
Speaker 3 (15:27):
So with the nice thing is that we support all
of it again in ten kilobyte.
Speaker 2 (15:31):
So if you want.
Speaker 3 (15:32):
To do a request against an HTML page, we'll morph
that in.
Speaker 2 (15:36):
If you do it against adjacent object, we'll morph that in.
Speaker 3 (15:38):
If you do it against a jobscript object, we'll execute
that jobscript for you. But in your SEC you could
be sending down, hey, I want to update this patch
of this page, or.
Speaker 2 (15:46):
I want to update these signals.
Speaker 3 (15:48):
So you have patch signals and patch elements and then
there's technically read signals. When this stuff comes in, that's
the entire SDK. You just like that's it. So you
just patch things in whether there's signals or element, and
you update your page and that's it.
Speaker 2 (16:02):
Like it's fast because there's very little of it. If
that makes sense, right, Yeah, that makes sense.
Speaker 1 (16:06):
On the other end though, like if something changes on
the back end, does it just push the data through
a web socket or how do you manage that?
Speaker 3 (16:13):
So the thing that people have this has been a
big issue with the HTML five spect People are so
used to seeing SEC because that's that's I kind of
think everyone should be using SD for basically everything. And
the reason why it is because it's just a response type.
Like you know how you get tests, that's service side events,
service center events. Yeah, okay, yeah, So the thing about
(16:34):
service and events is like, for example, if you went
to the front page of data start, you'll see on
the second like the second little example, it's just a
response type. So just like you have text HML or
application JS, there's another one called event or text slash
event stream, and all it is is, you know how
when you're sending a request like a if you're sending
(16:54):
up a big file and it's it chunked SEC the
same thing it's EFT for it's a chunked response. So
it's still just one request response, but you're basically leaving
it open and saying when there's a set of new lines,
flush the buffer and send what I have so far
so you can. So it's just a standard fetch request.
There's nothing special about it. There's no like that's the
(17:16):
he sticator to help you set up the flusher and
all that stuff, but there's nothing special about it. In fact,
the irony is most of the time most browsers are
doing AHGTP streaming already for you.
Speaker 2 (17:26):
You're just getting explicit control of that.
Speaker 3 (17:28):
So it's just an event type and you're just saying
new line, new line, and then you're saying flush like
my response to the network.
Speaker 2 (17:36):
It's basically what's happening. That's it.
Speaker 3 (17:37):
There's nothing special. There's no web sockets, there's no sticky sessions,
none of that stuff that all goes away. It's just
a standard web request. So that makes it's easier. So
are you managing that on like the service worker or
something or.
Speaker 2 (17:51):
No, it's just native and the brother.
Speaker 3 (17:52):
The thing about the service worker stuff that I found
is that it can add a bunch of issues around
having that extra thread can cause a bunch of issues
with the UI and trying to get things back and forth.
Like all the benefits you're supposed to get from it,
you don't. Like, you just don't. And the thing is,
we're so fast, Like if you go ahead and look
at your net, like if you're running a data Star website,
like if you go like for example, Dbmond, which you're
doing stuff in the microsecond, and you actually click your
(18:14):
performance tab and look at our renders. They're such tiny
slices that you're you're gonna laugh, Like it's just a
non issue for most anything that you do.
Speaker 2 (18:22):
Yeah, that makes sense.
Speaker 1 (18:23):
So at the end of the day, I'm just trying
to visualize how this works. I mean, I kind of
have it in my head, but I guess I'm wondering
on the other end. So with something like React, you
have React components and things like that, you don't need
any of that. You just render all that on your
back end, and yeah, it works.
Speaker 3 (18:42):
I Mean the beauty is is that you're you still
have components, you still have things, but they're in your
They're next to your database most of the time, right,
Like you're just changing from your database directly to the
thing you want to render. That's easier in every way.
Like all the RSC stuff is a nightmare. All the
Abernoff stuff around tail to computers, all this stuff is
completely misguided. And that's the thing I think it was.
(19:04):
It's the fact that I don't consider myself a web
deev at all, Like I just happen to use it
as a tool, but I'm a lower level guy, Like
I feel much more comfortable in GLSL shaders than I
do in browsers, And I think it was just if
people have been going in the wrong direction for a
long time. You have very smart people solving the completely
the wrong problem, right, And if you solve that problem,
it can be very small and very efficient.
Speaker 2 (19:25):
The browsers are really fast.
Speaker 3 (19:26):
But the thing is it's the C plus plus and
the lower level stuff that's fast, not the JavaScript right.
Speaker 1 (19:32):
So at the end of the day, if you do
have a performance bottleneck with this, it's going to be
on your back end and its ability to respond quickly.
Speaker 3 (19:39):
Yeah, And I mean I've tested it out to like
forty thousand connections on actively live on in a go
back and I think a lot of times the problem
is JavaScript developers are tend to try to have a
full stack to try to keep and I think it's
not a bad thing.
Speaker 2 (19:53):
It's just that it's because they're trying to keep track
of state.
Speaker 3 (19:56):
Whereas if they care about performance, pick a lower level language,
pick something that's even bun with the zig stuff is
a better choice than what most people do.
Speaker 2 (20:04):
Like that's where I want to see people go.
Speaker 3 (20:06):
And it's not like the jobscript goes away, Like if
you're doing a charting or some kind of three D
engine thing.
Speaker 2 (20:11):
You're still in our world. You're still writing web components.
Speaker 3 (20:14):
You're actually embracing that, whereas in the normal spat world,
web components don't make any sense. They just don't like,
already have I stay in my front end? Why do
I need to share it with some other projects? Like
why do I care? Where's all of a sudden, If
you're saying I can make a data start application and
it looks the same whether it's in PHP and go zig,
it does not matter closure, it doesn't matter. All that
looks the same, then web components. Now you can have
(20:36):
a shared library that every web developer is using with
these web components that you're driving with data star, so
it props down events up with web components. So you
just drive it with data star. Now you're all on
the same page. All your templates look the same with
web components. Now where's the current staffs quo? You just
it doesn't make sense.
Speaker 1 (20:53):
So I guess the other question that I have is,
you know, let's say that somebody adopts this. I'm a
big fan of the idea of somebody being able to
to like build and keep track of all of this
stuff on their own, right, It's like, hey, look, you know,
I mean I work on a team, I think most
people do, but on my own projects, right, I want
something that I can just maintain myself right without having
to build a team and you know, face all of
(21:15):
that complexity and keep track of what everybody's doing.
Speaker 2 (21:20):
Right.
Speaker 1 (21:21):
Eventually I may have to get there, but you know,
the longer I can hold out, the better. So is
this something that somebody can just slam in on their
own and just go for it?
Speaker 2 (21:29):
Yeah?
Speaker 3 (21:29):
So we're actually really good in brown fields because we're
using the spec complant stuff. We're not using special tags,
we're not using special things. There's no there's no build step,
Like we're built in typescript because I love static analysis
and I get as much of it I can. But
the final thing is just a single CDN link and
it's one ten K JavaScript file Like that's all you
got to do to put.
Speaker 2 (21:49):
It on a page.
Speaker 3 (21:49):
For most people, it like it's smaller than the fave
icon that they use. Like, so you just drop that
on your page and you can get to work. And
the thing is, it's it works. It's a spect complaint things.
So if you just say I just want to use
it for the data class. In fact, like a person
that run the podcast was actually using us instead of
Alpine for their AGMX stuff, even though we completely replace it.
(22:11):
Like it's one of the things of like sure you can.
It's actually smaller than an Alpine and it does all
the stuff Alpine does as well, and all the stuff
that Turbo does and all the stuff that Stimulus does.
So like, yes, you could start dropping it in and
then changing out things as you see fit. So there's
real value in that in my mind is that it's
it's meant for brown Field and if you can start
from fresh, then you're just gonna be deleting code, Like
(22:31):
that's the neat thing. I've done enough stuff in Alpine
and AHGMX, and I haven't done a lot of Turbo
because I bounce off of it. If you're not a
Ruby person, it's a little hard to use in my opinion,
And I will say I guarantee you, like I will
take any bet that your code. You're gonna have less
code on the page just because it's there's less that
has to.
Speaker 2 (22:49):
Go on to solve the problem.
Speaker 3 (22:50):
And I think people just overcomplicated it because they kept
working the wrong side of.
Speaker 2 (22:54):
The problem, honestly.
Speaker 1 (22:56):
Well, one thing that I've seen, you know, just speaking
to that is far as working the wrong side of
the problem, is that a lot of times we come
from the context of the wider web world, and so
we look at it and we say, Okay, we have
this solution, how do we make it better? Instead of
saying we have this solution. Okay, we've banged on it,
we've made it better. But if we had these underlying
(23:19):
underlying things different, then the whole solution changed and it
got better. And so yeah, I think a lot of
this just kind of comes from the momentum of the
web world. I'm kind of curious. You mentioned the plugins,
and you've also mentioned like just pulling it in from
a CBN and not using NPM. So a lot of folks, yeah,
they have a build step on their front end, so
(23:40):
they pull in and then they use something.
Speaker 2 (23:42):
Like webpac or the or bite like that or something whatever.
You know.
Speaker 1 (23:46):
In the rails world, we've kind of embraced import maps,
and so I'm just curious you're saying I don't do
any of that stuff.
Speaker 2 (23:54):
Don't need to is a non issue.
Speaker 3 (23:56):
We have a version, we have started doing a pro
thing and we can talk about that in a bit.
But I have a bundler built in and because the
web app is actually built in Go, I just use
es build as a library.
Speaker 2 (24:07):
So vitn all that is using es build under the hoods.
Speaker 3 (24:10):
You know, it's a lot faster not doing any JOBASCRIPT
and just using Go directly.
Speaker 2 (24:15):
Like for me, it's just a library thing.
Speaker 3 (24:16):
So we actually have a bundler built into the page
when you log in and stuff, so you can actually
do all that stuff and make exactly the version you
need and it's just built into the browser and it
takes microseconds and then I cash it and do all
that kind of stuff.
Speaker 2 (24:26):
Right, We like, that's the right answer. You don't need
all these other steps.
Speaker 3 (24:30):
Like there's a lot of times where people like bounce
off a type script, but I think it's one of
those things.
Speaker 2 (24:35):
But it depends on what you're doing.
Speaker 3 (24:36):
So for things like building an entire framework that it's
static analysis and there's a plug and thing, it's great
at that. If you're doing a small web component, you
don't need it. So people like they think that they
need to have a one stop solution for all these things,
whereas most of the time, like what the library author
need to do versus what they need to do to
get stuff on the screen is a very different problem.
Speaker 1 (24:56):
So so what I'm hearing is, U, I pull this
in and it basically just works out of the box.
I don't have to go right stimulus controllers or components
or anything like that to get functionality onto my page.
If I need custom stuff you mentioned plugins, is that
(25:16):
the way to do that or so it's funny.
Speaker 3 (25:19):
At first, I made the plugins because I thought there'd
be like a bizarre like almost like the Unity Asset
store where everyone write a million plugins. But what we
found is there's not like the browsers are gotten good
enough that there's not that many things that you need
to kind of hijack and make better, like setting up
classes and having the string manipulation there and for styles
and for like there's other things like data on RAFF,
for doing request animation frames. There's certain things that are
(25:42):
this easier in that expression language. But every time someone said, hey,
I want to make a plug, and we say, hey,
like talk to us, because if it's a good idea,
we'll do it.
Speaker 2 (25:50):
So it ended up that I wanted it to be
this thing everyone uses.
Speaker 3 (25:53):
But the irony is there's not that many plugins to write,
and if you come and talk to us, we'll just
write it in build it into the library. In fact,
it just happened because we use everyone says to use
styles or classes because of tail end and all that.
But someone came in with some really good ideas around
how to do animating of styling and stuff, and they
wanted to use this have a style thing and we
had had it for two years.
Speaker 2 (26:14):
In a day we had it and we're like, oh no,
that's a good idea.
Speaker 3 (26:16):
And now it's part of the latest rc is data
ash style is now just a built in thing. So
it's yeah, it's more of an implementation detail at this point.
Speaker 2 (26:25):
The plugin system because you have to know.
Speaker 3 (26:26):
Like it is a little bit harder to write plug
ins because we're very code golfy and we try to
make it as efficient possible. There's that, but anyone can
write a plug in, but you right now you basically
four can kind of go on your own route. But
the whole system's there. You have access to everything, it's
just getting it into the core. We're a little finicky
with that stuff.
Speaker 1 (26:45):
So effectively, because I know some people are just going
to kind of have trouble wrap their head around it. Okay, well,
I have this custom behavior that I need to blah
blah blah blah, and so it has to do.
Speaker 2 (26:54):
All this stuff.
Speaker 1 (26:54):
And what you're telling me is that essentially the way
that the framework works, you can do probably ninety nine
percent of that stuff just with your data attributes and
then leaning on the framework.
Speaker 2 (27:07):
Yeah.
Speaker 3 (27:07):
And the thing is that when you run into something
really company like I built an entire three D engine
for one of the things that I'm doing, and that
was just one web component, Like it's are a couple
of web components and they just nest in tide each other.
Then you drive it with data start and it's not
that bad, and you just are updating props and you're
handling events.
Speaker 2 (27:24):
The thing is that.
Speaker 3 (27:25):
The browsers already have a native way to do that,
the way to encapsulate JavaScript.
Speaker 2 (27:30):
So a lot of people just like, well, how do
I add this one little JS thing?
Speaker 3 (27:33):
Most of the time it's they're trying to interact with
some other charting library or some other thing that they
didn't wrap that in a web component. Then now you
have something that can be shared anywhere all the time,
and that's the right way to do it in the
modern web, Like that's just easier for everyone, and now
you have something that's sharable, whereas right now we don't
have a lot of sharing going on between frameworks and stuff.
Speaker 2 (27:51):
Whereas with data start, we embrace the like what the
or what the web is already good at.
Speaker 3 (27:56):
And what's also nice is if you are using Spelt
or Reactor and you're want to move towards that, all
of those support web components of the box, Like you
can turn things a view component into a web component,
say wass Felt, all these thing in facts felts a
pretty good option if you want to live in that
world and still do SPAT stuff, you can turn those
things in wet components and now drive them a data
star and be so much more efficient in.
Speaker 2 (28:16):
How you do that. Right when you say web components,
you're talking about like the spec that's out thereah then
native spec. Yeah, yeah, it's really good.
Speaker 3 (28:24):
Like there's some things that are kind of clunky about it,
but like we're working on a thing we're calling internally
calon rocket right now, which is a way to make
it to it's kind of like our version of lit
where you have your own little thing that automatically does
a hook up of signals and does some niceties for
you to make the code smaller. But just writing the specs,
like writing spec compliant web components is not that hard.
You get props down, you make changes, and then you
(28:46):
render your HML.
Speaker 2 (28:47):
That's it. Like, it's not rocket science.
Speaker 1 (28:49):
So just to kind of recap because I'm just thinking
through this and it sounds pretty awesome. Now I want
to go play with it, and I want to go see,
you know how I can kind of plug this into
my rails apps because I mean sometimes writing the stimulus
controllers or you know, kind of getting some of the
custom behaviors, just like it's not exactly what I want
or yeah, there's a little bit of ceremony around, not
(29:11):
a ton, but a little bit.
Speaker 3 (29:13):
No, and there shouldn't, especially in a language like Ruby,
there should be basically no ceremony. In fact, we have
a very vibrant Ruby community already built, and we have
a Ruby SDK. I would highly recommend joining the discord,
joining the Ruby side and saying, hey, you know, I
talked to Delaney and like I'm interested, what do I
gotta do, and you'll see that we have a lot
(29:34):
going on already, like it's it's already vibrant for being
a small community.
Speaker 1 (29:38):
So yeah, I guess what I'm interested in is just
to see how it stacks up and how much of
the stuff I wind up doing in a stimulus controller
that I can just.
Speaker 3 (29:49):
You probably can trug the right almost all of it.
And the nice thing is that we have a guide end. Yeah,
and the we have a guide and it's actually written
with all the examples in different languages. So if you, oh,
the guy, you can just go to the ruby one
and literally step through and say does this match my needs?
And again it's not that like we don't make anything
from this, but it's more of it, like we want
to see the web be a better place. In fact,
(30:10):
we actually set up a nonprofit. We have a five
ZHO one C three that's already set up for it,
so like we actually have a mission in a goal.
There's not going to be some vercell rugpool play some later.
Like we literally did the nonprofit to make people understand
we don't have stocks or anything like that, Like we're
stewards of the project. We're trying to do the right things,
and we want to see the web be better because
(30:31):
I want to get back to I dog food this.
I use it for work. It's not like this is
my right gig. I just want to make it better
and have more people involved so they can make it
better with me.
Speaker 2 (30:40):
Right. So you mentioned vercell.
Speaker 1 (30:43):
You know you've also got Netlify and a bunch of
these other ones that you know they'll host your your
front end. They'll host your back end too, depending on
how it's put together. And so is this something that yeah,
I can just throw it together and have out there,
I guess if you're just pulling it off the CDN.
Speaker 2 (30:59):
Yeah, you just like you just copy paste to local
if you want. Like what I do is I use GO, So.
Speaker 3 (31:04):
I use the embed stuff so I can bet all
my file system directly into my binary. Right, So I
just make it so it locks loads like copies in
as part of my build stuff from the CDN stuff
from just delivered, and then I have a binary version
that works anywhere in the world. So I have a
single binary that I can to play with SEP and
have it on a thing, no problem. So it's actually
(31:27):
simpler in every way. You don't need DevOps to do
most things. You need SEP and a system cuddle file
and that's it, Like that's all you need. So it's simpler,
but it works in the big scale teams too, Like yeah, yeah.
Speaker 1 (31:40):
It sounds like you can just serve it, you know,
depending on what your back end is and how that
stuff works. Yeah, you can just you can run it
through whatever asset pipeline or management you have, and yeah,
you just serve it up and run it.
Speaker 3 (31:53):
Well, that's the thing I wanted to get back to,
like I remember when in fact, it's funny, the more
of the stuff I do more, I'm like, man, Jay
Curry was so close to being right.
Speaker 2 (32:02):
Like it had a lot of these ideas, but.
Speaker 3 (32:04):
It was it got so muchy passed and so crazy
because the problem is that the data dash Star actually
weren't there. CSS nesting wasn't there, Like it was the
best version of its time. But we were so close
to something that was really about because you just like
throw j carry on the page, you make the changes
you need, and then most of the stuff was in
the back end. It's like that's pretty close. But we
kept saying, well, we want to do more and more
(32:25):
in the browser, and part of that is, at the
time you had like for example, glass Fish in the
Java world, where every every request was its own thread, right,
and that was like you couldn't wait on the server.
It was like seconds of time between Right now you
can have forty thousand connections per core on a normal
like async server. Like the problem is that things like
(32:45):
issue next to me are yearning for the style of
the two thousands, But I want some of that style
with all of the features of now, Like people don't
realize that we've gotten a lot better, and I want
to have that betterness.
Speaker 2 (32:58):
So you and.
Speaker 3 (32:59):
Da Well, in fact, the very first version of this,
or when I committed it, I was like, DHH will
hate this because when it's doing his whole typescript sucks
diatribe thing.
Speaker 1 (33:09):
Yeah, but the ideas that you're talking about and the
things that you're pulling in, and you know, the niceties
of how we did things, you know fifteen twenty years ago,
you know where a lot of this stuff was a
lot simpler. I mean, he does push back to that,
and that's a lot of the idea that he's a
guy I wish, Yeah, he would typescript.
Speaker 2 (33:30):
That's a different thing. Well, the thing is that it's
a most people are completing.
Speaker 3 (33:34):
I want to write my daily like updating of my
page in typescript, Like, no, you don't need to do that.
If you don't need to write any Like in the
data R way, you basically write no JavaScript most of
the time you don't need to.
Speaker 2 (33:45):
And when you do, it's the little little snippets of expressions.
Speaker 3 (33:48):
Right, you're going back to almost the the the on
click days of like you're doing a little expression and
so that's a lot easier. I would love if you
would try it out, because I bet he, like he
seems to be very motivated by getting to good answers,
and I actually think he might see it and say
this is better than Turbo, Like if he actually spend
time with data Star, he might Actually I think that
(34:09):
could be an actually a possibility because Turbo is only
focused on Ruvie. It's only it's kind of a piecemeal thing.
It's not really their focus. It's just kind of like,
this is good enough, it's better than the other tools
out there. Cool, we're done, whereas data Star went hard
on hard problems and we're faster or smaller and we're better.
And like he seemed to be one of those people.
So I would love for him to try it out.
(34:30):
I just don't have the context to know, like I'm
a nobody on it, Like I'm just a guy in
a whole kind of thing.
Speaker 1 (34:35):
So so, so the other thing I wanted to throw
out there is a lot of folks use I mean,
you mentioned tailwind, but on top of that, and I
think tailwind is offering one.
Speaker 2 (34:45):
Now if you have tailwind plus or pro or whatever
they call it. I do have that.
Speaker 1 (34:48):
I just haven't used their library because I don't use
React on the front end. But they have these component libraries, right,
and so it's you know, you've got your accordion dropdowns,
and you've got your menu stuff, You've got your you know,
you've got your scrollers and all that stuff, right, And
so what you're advocating, if I'm understanding correctly, is you
put all that stuff into your into a web component
(35:10):
and you build the behavior and then you make it
do the thing that you wanted to do.
Speaker 3 (35:15):
So that's that's a great question in that like okay,
like how will you do how do you do stuff
with it? Like, great, you got the base stuff, how
do you do things? So one of the things now
that data Star is done would be ones out. Technically
we're an RC so in case the SEK author is
need to change something, but everything's it's as V one
and so now that that's done, we can start building
things on top of it. So it's not like data
(35:35):
Star as we actually literally created star Federation, which is
a set of tools and things because I do want
to make the web better now, Like, even though I'm
not a web gag, I know Star Federation and it's great.
It's actually star Federation is the actual nonprofit name.
Speaker 1 (35:48):
It.
Speaker 2 (35:49):
Oh nice, it's the best, dumbest name.
Speaker 3 (35:51):
But the thing that's interesting, at least from my perspective,
is now that we have this foundation, we can build
a million interesting tools. One of the tools that I'm
building right now is called stuff, and I think it's
a tailwind killer, like one hundred percent will just murder tailwind.
Speaker 2 (36:05):
And the reason why.
Speaker 3 (36:06):
Is because basically I'm taking a lot of the ideas
from open props, which I think is a really good
thing because it's basically just a bunch of CSS variables
that someone from the Google team out of Margout made
that basically you're doing stuff with standard CSS because now
nesting's there, all the functions and mix ends are coming.
CSS has gotten a lot better, so just use variables
to do a lot of the things you were doing
(36:26):
in Tailwind. So it's a mixture between you know, CSS,
tailwind and open props. And basically what I'm doing is
I'm building a live editor where you are making changes
to all the kind of things that you would do
in tailwind canfig.
Speaker 2 (36:39):
You actually have a live editor.
Speaker 3 (36:41):
It's actually going back to the server and depending on
what you've changed, automatically has cashes of all this stuff
and then generates the styles and stuff on the fly,
and then at the end basically gives you a full
set of variables and all the canfigs and all this
so you actually are able to play with it live
in real time even though it's going back to the server.
Because we cash everything, we can actually get really really
fast and say three or four is has not been
(37:02):
modified all those kinds of things, and I'm making it
and it's going crazy fast and you can basically point
at this thing from anywhere, and now you have a
full CDN version of Tailwind with no build, no setup,
works on any back end. That's where I think the
future is going to be is getting this collaborative stuff
that is shared, and you can't share stuff if all
your state's in the front end. That's just like the
(37:24):
local first thing to me, I think is a hot nightmare.
Like it's just the wrong approach to the web. It's
not that if you want to do that, go do native,
Like there's nothing wrong with native.
Speaker 2 (37:31):
I'm like a game guy like I like C and
C plus plus they're great at that. But the web
is not that.
Speaker 3 (37:36):
The web is about sharing collaboration and only having the
state of your page at that time. That's what the
whole hypermedia thing was about, like not API is not Jason.
Speaker 1 (37:45):
Okay, I'm not sure if you completely answered the question though.
So you know you do have these different components that
have different behaviors, right, and so yeah, as your approach
to that, just to put them into web components.
Speaker 2 (37:56):
Or if you need to.
Speaker 3 (37:58):
Most of the time, most of your components act live
in your back end because it's about what state I'm
changing in my bad Like if you're taking about a
database like row and you're saying I'm updating something, all
the state is right there. You shouldn't have to send
down Jason, you can just send down HTML. And the
irony too is that people don't realize this HTML is
much more efficient to create and send than Jason. And
(38:20):
what I mean by that from a technical standpoint for
anyone that doesn't know, is like with Jason, you're basically reflecting.
For most languages, you're reflecting through and creating a tree structure.
So you're making a tree structure, whereas with HML you're
just having static pieces and you're basically filling islands. So
you have these big, large buffers and you're able to
update things way faster. And if you're using the compression
stuff we do, where you have like Broughtley windows or
(38:43):
zelib standard or these standard windows, all that stuff is
already in the buffers. So now you're getting really really fast.
You're getting between two hundred to two thousand to one
compression ratios and it's not recursing a tree. So yeah,
you're still making components, but you're making mostly the locality
here it becomes the same line in my world, So
that makes a huge difference.
Speaker 1 (39:04):
Right, that makes sense. And then as far as I mean,
some of them are just visual things, you know, so
you've got like your your drop down menus and things
like that, you know, so you put those in and
with those you're literally just adding and removing CSS classes
and so so you just put that into your your
events and your your data attributes and it just does
the right thing.
Speaker 2 (39:24):
Yeah.
Speaker 3 (39:24):
So when you have like, for example, you do a
data class and then you give the class is open,
and then you hook that into a signal done like
and then if you taggle that, you can talk it
from the back end, you can talk it from the
front end.
Speaker 2 (39:34):
You can do all kinds of stuff like.
Speaker 3 (39:36):
It just simplifies that because you're just hooking into the
signals properly. It makes us a little expression and you're done.
I mean, it's a lot of what Alpine was doing
from that from the front instance side, but it's way more.
Speaker 2 (39:49):
I've seen that in well there was another one too anyway,
But you.
Speaker 3 (39:54):
Don't need veto On to do that stuff, and you
don't need the way that Outpline is doing things, and
you can actually be a lot smaller and a lot
more efficient.
Speaker 1 (40:01):
That's true because you're just directly poking the dom yep,
it's just dumb events.
Speaker 2 (40:07):
Yeah, so yeah, that's cool.
Speaker 1 (40:10):
Well, my calendar just told me that I have a
meeting for my day job here in like seven minutes.
So if people want to go check out data Star,
you said, is data da start dot debt.
Speaker 2 (40:21):
Yep, that's the website. Go check it out. And then
you said there's a discord channel as well, and they're assuming.
Speaker 3 (40:27):
Oh yeah, no, we have around twelve hundred users right now,
maybe a little bit more.
Speaker 2 (40:32):
So, Yeah, it'site.
Speaker 3 (40:34):
Yeah, yeah, you can enjoy. The discord is right on
the main page. Let us know if you have any questions.
But yeah, it works in every language, and if you
have questions, come holler at us.
Speaker 2 (40:43):
We're happy to help you.
Speaker 1 (40:44):
It's cool. Well, so we do have a segment at
the end of the show. It's called Picks, and we
just shout out about stuff we like. So I'm going
to jump in and I'll do some picks and then
I'll let you do some picks. My first pick, I
always do a board game. My wife and I we
went on a trip. We had our twentieth anniversary in March,
and we couldn't quite get out for the trip we wanted,
(41:05):
and so we did it a week or so ago,
right before the fourth of July. And one of the
games that we've been playing. Some friends got it for us.
We watched their kids while they went to a board
game convention and they brought it back for us, and
so we've been playing it. It's called gloom Haven Jaws
of the Line. It's very good. Yeah, so they were
telling us they've played all three of them. I guess
there's gloom Haven, there's gloom Haven Jaws of av a prequel,
(41:29):
and then frost Haven and so yeah, so this is
our first foray into the gloom Haven world. I've played
D and D before, but my wife really hadn't even
done that. So we've been playing that and we're about
halfway through the fourth scenario. That's the only complaint I
had about it was that the scenario took longer than
we had and so.
Speaker 2 (41:46):
We've kind of had to like move the whole table aside.
We didn't want to take it down. But that said,
it's been a lot of fun.
Speaker 1 (41:53):
So if you kind of like D and D and
you you know, you don't need a dungeon Master game master.
It just kind of that's the scenarios up and you
follow the rules and you know, you fight the bad
guys and complete the scenarios and it is.
Speaker 2 (42:07):
It is really fun and we've really fun.
Speaker 3 (42:10):
So I actually have a They have a Steam version
just so you know that you can actually run as well.
That's actually really solid, so you can get the Jaws
of Lane stuff on that version as well.
Speaker 2 (42:21):
I'm a board game nerd as well.
Speaker 1 (42:25):
Yeah, my one of my daughter's friends is way into
board games, and so she and her friends were over
here and he wandered into our pantry where we have
half the pantry full of board games and he was just, yeah,
we have we have plenty and I get together with
my buddies and we play every week.
Speaker 2 (42:43):
So yeah, anyway, so that that's a fun one. Uh.
Speaker 1 (42:48):
And then other picks. I just picked up some new microphones.
I'm gonna grab the box. So these are the road
if you're watching the video Wireless Pro. It has two
receivers or two transmitters with the lapel mics and then
a receiver and they're awesome. So gonna I'm gonna pick those.
It's just gear. They're not cheap, but they're great. And yeah,
(43:10):
I've been in this scenario where I needed to do
more than two people with these, and so I also
have a mixer that I bought for one hundred bucks
off Amazon and that's been great, so really really happy
with that stuff.
Speaker 2 (43:20):
I don't know if I have any other picks, but yeah,
if you've got some ex sure I'll do two quick ones.
There's a book that I've read multiple times.
Speaker 3 (43:29):
With a few books i've read multiple multiple times, but
it's actually being turned into a movie, so I'd highly
recommend reading the book first.
Speaker 2 (43:35):
I know what it is, Oh do you? I bet
I know what it's going. Okay, let's go for it.
Tell me is it Project tail Mary? Yeah, that's it's
a great book. So excited for that.
Speaker 3 (43:48):
I hope they get Rocky right, So that's going to
be a hard one, but it's a good team behind it,
so I have high expectations.
Speaker 2 (43:56):
But it's a great book.
Speaker 3 (43:58):
And if you haven't read that, there's also another good
one called Recursion that I just read that was a
solid pick. I don't know the author, but quite or
it's a big yellow front cover.
Speaker 2 (44:08):
It's an interesting book. So yeah, those are the books choices.
Speaker 3 (44:12):
And when it comes to it, if you did board games,
I have to say that I've been kind of getting
deep into the Arcs world I haven't done the whole
campaign thing, but if you haven't heard of Arcs yet,
it is a challenging, interesting board game of trying to
control the uncontrollable. It's a very interesting take on it's
technically I guess people take called a space game, but
it's not really. It's it's not like Twilight Imperium or
(44:34):
anything like that. It's a very interesting thing, especially with
four players. So I would highly recommend looking at Arcs.
I love to check it out. So Project Hail Mary,
I think people are more familiar.
Speaker 1 (44:45):
With The Martian, which was another book that he wrote,
and so it's the same author. I will say that
I liked Project Hail Mary better than The Martian, so
by far, yeah, easily it is a better book. So anyway,
I'm super were excited. The second I saw the the trailer,
I sent it to my wife and she, wait.
Speaker 2 (45:06):
There's a trailer. I haven't even seen the trailer.
Speaker 1 (45:07):
Yeah, yeah, yeah, yeah, and yeah, so she watched it.
Speaker 2 (45:14):
She's like, so, I'm like, you got to read the
book first.
Speaker 3 (45:17):
Well, in fact, that the Recursion book was a recommendation
from anywhere saying hey, what books do you what are
you reading that you think are interesting, and he recommended
the Recursion one, and I was like, I was like, yeah,
it's actually a pretty solid book.
Speaker 2 (45:28):
It's very interesting take. So yeah, I highly recommend taking out.
Now have to go watch the trailer, I apparent last.
Speaker 1 (45:35):
Yeah, I had just gotten off of a terry goodkind
binge doing all the sort of truth books, and so
I wanted kind of a different pace.
Speaker 2 (45:42):
You know.
Speaker 1 (45:43):
It's like, Okay, I've kind of taken on a ton
of this, Like I read everything that Brandon Sanderson writes,
but I can only do like five or six of
his books, and it's like, okay, I got to cleanse
the palette with something else, right.
Speaker 2 (45:56):
So so that that's what this was. You know.
Speaker 1 (45:59):
I saw the the trailer and then I just started
listening to that one on audible.
Speaker 2 (46:03):
Yeah.
Speaker 3 (46:03):
It's actually one of the few books that you really
want to listen to it. It's a great as an
audible because they actually do the voices. I can't go
without spoiling things. It's really good as an audiobook, I'll say.
Speaker 1 (46:14):
Yeah, yeah, the vocals with Rocky in particular, Yeah, all right,
good deal. Well let's go ahead and wrap this up
so that I'm not late for my meeting. I'm arguing
for my meeting, but this was a ton of fun.
Definitely something I want to go check out. If people
want to follow you on the internet, where do they
find you?
Speaker 2 (46:31):
Data started?
Speaker 3 (46:31):
I'm on Twitter? Is Delaney Gillilan. I know it's kind
of hard to say, but if you look for data
star you'll find me. Really, don't be interested in me,
there's nothing interesting going on there, but I will say
data star has.
Speaker 2 (46:42):
An interesting community. Now, so come join all
Speaker 1 (46:45):
Right, folks, Well we'll wrap up and until next time,
max out
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Crime Junkie
Does hearing about a true crime case always leave you scouring the internet for the truth behind the story? Dive into your next mystery with Crime Junkie. Every Monday, join your host Ashley Flowers as she unravels all the details of infamous and underreported true crime cases with her best friend Brit Prawat. From cold cases to missing persons and heroes in our community who seek justice, Crime Junkie is your destination for theories and stories you won’t hear anywhere else. Whether you're a seasoned true crime enthusiast or new to the genre, you'll find yourself on the edge of your seat awaiting a new episode every Monday. If you can never get enough true crime... Congratulations, you’ve found your people. Follow to join a community of Crime Junkies! Crime Junkie is presented by Audiochuck Media Company.
NFL Daily with Gregg Rosenthal
Gregg Rosenthal and a rotating crew of elite NFL Media co-hosts, including Patrick Claybon, Colleen Wolfe, Steve Wyche, Nick Shook and Jourdan Rodrigue of The Athletic get you caught up daily on all the NFL news and analysis you need to be smarter and funnier than your friends.