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