Collin (00:36)
Yeah. So you know how when you interview at places, a lot of times they're like, we want you to do this little test project. you know, and they're oftentimes basically the same project of like on iOS, it's usually we want you to download some Jason and then show it in a list. And there's like a few different kinds of objects because most iOS apps are essentially downloading Jason and then showing it in a list. It's like, I think I've said, it's like the song of my people.

Joel Drapper (00:44)
yeah.

Right.

Collin (01:07)
And so I got the idea that I would just use like an open API that I could use and make a really complete version of that. And then when people ask for it, I'll be like, I already made this one and they can just look at it. And I'll like put a read me in the repo so that it, you know, explaining the parts that I think are interesting. I mean, they probably,

Joel Drapper (01:13)
Mm.

you

they still want you to make. Make a special

one just for them, just to waste some more of your time.

Collin (01:36)
Yeah, they're probably

still gonna want me to spend seven hours making them an app that's not even as good, that does the same thing. But, you know, it was still a fun project. It helped me prepare for this interview for this job I just got, which is good because basically they wanted me to make that same app, but during like a two hour technical interview, but because I had just made it, essentially, I did the whole thing in like an hour and they were like, that was amazing. And then I got the job. So.

Joel Drapper (01:39)
Yeah.

Mm-hmm.

you

Collin (02:04)
So it really worked out that I did this regardless. It was really good preparation. And it is interesting just because of my Ruby experience now. I've talked about this many times, but just seeing when I do an iOS app, how differently I approach it now. A lot more little utility objects and a lot of testing and a lot of dependency injection. And just my vision.

Joel Drapper (02:21)
Mm-hmm.

Collin (02:31)
for how to write code which will become testable later, right, is much more clear than it used to be. Like, that was the hardest part is that because the, you know, people I came up in, the area I came up in didn't have like the culture of testing as much. I feel like a lot of people just don't really know how to write code that is going to be easily testable. And...

Joel Drapper (02:35)
Yeah.

Mm-hmm.

Collin (02:56)
You know, and so Ruby has really, really made that evident to me, which I think is great. It's, you know, which I don't know, my thing is like pretty much.

I have a very simple kind of little rule for myself, which I don't know if this makes sense to you, but it's the idea is that anything my current class has to know the name of to operate, like if I instantiate it within there, I'm now coupled to that. So if I'm doing that, I want to break those pieces of functionality out and then create a protocol or a duct type or whatever you want to call it and then inject it. And so I used to end up with a bunch of little objects that I inject everywhere.

Joel Drapper (03:22)
Mm-hmm.

Okay.

Right.

Collin (03:38)
You know, and there's, and you know, there's like limits to that, but essentially, yeah, essentially I'm just creating interfaces and then injecting them. And I take that as far as I can to where it doesn't feel, you know, like it's making the code less cohesive or whatever. And also, you know, I use a lot of like defaults. So if I have like, in my iOS app, I have like API client. So I have a live API client and a mock API client.

Joel Drapper (03:56)
Yeah. Yeah.

Collin (04:06)
So the default is just to use the live one. like when you're using the code, you never even really see this, but it does make it testable. And, and then what is the other thing? Yeah. And then basically I just do that until if I ever reached the degree to where I'm creating objects that are kind of just like middle person objects that just sort of go, you know, get called and then make the exact same call to another thing. I hate that. That's like.

So if I ever have an instinct to do that, then I stop. But that's broadly, I feel like, one of the main things Ruby has taught me and has been very useful.

Joel Drapper (04:48)
find that those kinds of things that just like receive a call and then make a call, obviously if it's exactly the same that doesn't make sense, but they're useful only really as adapters where like you have your own design you want to adapt to someone else's design for something you can sometimes I find it's useful rather than like updating your thing to know about them or updating their thing to know about yours.

Collin (05:17)
Yeah. Yeah. But I would count that as doing something. Like if it's a transformer of some kind. Yeah, if it's transforming the data so that two things can communicate, that's fine. What I'm thinking of is we used at Apple, we used this iOS kind of, I don't know what you call it, architecture called Viper that we...

Joel Drapper (05:17)
to use those but yeah.

Right. Yeah, it's actually making a... yeah.

Collin (05:44)
I think maybe has fallen out of favor now with SwiftUI and all of that, but in favor of more declarative kind of things. But essentially what drove me crazy about it was that you did end up with objects where it's like, this is doing, because each of those letters in Viper is a layer of the architecture and you have to go from one into the other very frequently. And so a couple of those in the middle very often end up being like just

Joel Drapper (05:48)
Mm-hmm.

Mm-hmm.

Collin (06:12)
take this call and then make the exact same call to the next thing. And I remember just like sometimes I would go into work and I'd look at this architecture that we were using for this and I would just be like, this is gonna suck. know, like whatever, it just like sucked the joy or it just sucked the joy out of it. Cause like writing that kind of code isn't fun for me. Where like coming up with little objects that like communicate together and kind of this like beautiful symphony of object calls, that is fun for me.

Joel Drapper (06:25)
Yeah, how am gonna maintain this? Yeah.

Collin (06:42)
And so, yeah, yeah, honestly, it kind of ruined my life for a couple of years there. Really, really didn't make me happy. Rails doesn't seem to have as many of those because like Rails is sort of has something built in. So people aren't applying things like they might use service objects or whatever, but like they're not, there's not some other architecture. Like it's the Rails architecture is the architecture. So that's nice. Anyway, how are you doing?

Joel Drapper (07:11)
Yeah I'm good. Yeah, still applying for jobs and interviewing and things. So that's been fun. Nothing, no news to speak of.

Collin (07:20)
Good. Interviewing is great.

Joel Drapper (07:27)
Though we did launch Flex 2.

Collin (07:32)
you did, what's new?

Joel Drapper (07:35)
I honestly can't remember what it's been so long we've been working on this for so long since we kind of Decided we're not gonna do any updates to flex one anymore We'll obviously debug fixes if they come up or security fixes, but Yeah, like I can't necessarily remember definitely In fact, let me just bring up the website because it says so it is faster it is

Collin (07:38)
Good.

Joel Drapper (08:05)
not quite twice as fast as flex one but it is faster. I don't know why or how but something to do with that. We have improved the integration with Ruby tooling quite a bit so Ruby LSP is great and I'm using that a lot and so we've basically there's like there's a trick you can do where you

Collin (08:19)
That's good.

Joel Drapper (08:32)
when you define methods, can, it's like Flex defines a bunch of dynamic HTML elements and Flex Rails defines a bunch of adapters for the Rails view helpers. And so we actually define real methods and then override them with the kind of generated methods from our macros. But...

By defining real methods, Ruby LSP can of detect that and pick it up and show it to you as like an auto complete prediction. So, and then that allows us to basically put some documentation in there. So for example, for every method that is an HTML element, we show a link to the MDN docs and a link to the HTML spec for that element and a link to can I use in some cases where it's relevant, like some of the new elements like details.

And then for the Rails helpers, we show a link to the Rails docs for that. It's a real pain to do, because there's like over 200 of these and you really have to just do them by hand. But there's that, we improved kits quite a bit, which is just a fancy, it's basically syntax sugar for rendering without using so much syntax. And then we added fragment caching.

Collin (09:38)
That's amazing.

Joel Drapper (09:59)
in a way that I'm pretty happy with. It's basically like completely separate from Rails caching, but you can use Rails as the cache store, or you can use our thing as the cache store, but also if you're using our thing as the cache store, you can still use Rails cacheable objects because it uses the same interface. So basically like the cache store interface that we have,

is very similar. It's like a subset of the cache store interface that Rails has. And I think that's gonna be pretty useful. And then the last thing was, well, actually just on this, this is probably the most interesting thing. We've had this selective rendering feature for a while. I think we previewed it in V1. might have that wrong. It might just be a V2 thing. It might've just been a V2 beta.

And it was basically that you could say to Flax, render this component, but just these IDs. And it would kind of look for them. We decided to change that. So instead of looking for IDs, you actually have to declare like a special kind of fragment that doesn't exist in the DOM. It's just kind of declaring this chunk of code is this fragment. And that means there isn't...

we don't have to deal with, you call out from Flex to a partial and you're rendering somewhere else, right? We don't have to try to pass that HTML to figure out if it contains any IDs we're looking for. So we can't kind of search it structurally like we can in Flex. So this, think disambiguates that. But it also makes it bit easier for us to deal with the integration between the caching feature

Collin (11:49)
Mm-hmm.

Joel Drapper (11:57)
and the fragments feature. So if you think about it, if you have lots of layers of caching in your view and you're looking for just one tiny fragment, how are you going to find that? If you get back the whole string from the cache, it's larger than the fragment you're searching for, you might then have to like...

I don't know how you would do it right. You'd have to pass it to figure out like, where is that fragment? Or you'd have to ignore the cache and just keep searching. So what we've done is basically make it so that as you're building the cache, so on a cache miss, we not only cache the string of HTML that was generated, but we also store in the cache a list of all of the fragments that we found and their byte ranges.

into the cache string. So when it comes to rendering, if you're looking for fragment ABC and you get a cache that's much bigger than that, you can just check immediately, does it have the fragment ABC on it? If not, skip and move on to the next thing. If it does, slice that byte range out of the cache string. And that's the range of markup to respond with.

as that fragment. So that's like the main thing. But we also launched like new Doc site and we're continuing to update that and make that better.

Collin (13:40)
I remember when a year ago you were like, flex is done. I forget when you said that, but at some point you were like, flex is done. I don't really think I'm gonna have to work on it that much anymore. It's pretty funny.

Joel Drapper (13:45)
Yeah.

Yeah I did. And then

I had a- and the main one was like kits basically like that's what made me think there's more to do here. Yeah now I'm happy I think flex is basically more done now. Maybe yeah I don't know I'm well

Collin (14:04)
Mm-hmm. It'll be exciting in a year when you're telling me about Flex 3.

It's like needing more

things for your, it's like needing to buy more stuff for your hobby of like photography or whatever. That like, you're like, I've got all the lenses I need. And then you're, you know, you're on Reddit or whatever. You're like, maybe I need that one too.

Joel Drapper (14:19)
I know,

Yeah.

The thing is it has a limited... like I could see a world in which I tried to make flex do more and more things like maybe there's ways that you could... I don't know people have talked about getting flex to run in the front end which I think is a cool idea but I also just don't think that it could ever be great

the front end. So I think its use case is pretty limited.

Collin (15:03)
What would that be doing for the front end? Like a web assembly thing or what are we talking about?

Joel Drapper (15:06)
Well, yes.

I guess you would either have to transpile the Ruby into JavaScript with something like... I think Opal could do that. Or you would have to have some kind of WebAssembly version of Ruby running, which would be massive. Or you would have to have some kind of Ruby implementation written in JavaScript.

Collin (15:14)
huh.

Yeah.

That sounds like a good task for somebody else. I bet Marco Roth will have it done in a week.

Joel Drapper (15:38)
Yeah.

Yeah,

I, yeah, honestly, I just think it's whatever you do to try to get Ruby in the browser. I mean, I might, I might be wrong if someone could prove me wrong, but I just don't think it's going to be ever as good as, as what can be done natively and just embracing the native tools. I think it's kind of like that. We talked about this with iOS, like, there's all these like react native and stuff trying to

Collin (16:03)
Yeah.

Yeah, but now there's a layer. so, like a good example of that is, I don't know if this is a React issue or not, it could not be, but there are things in, because I've been using the Blue Sky App a lot, that's so funny. You went to drink your cup and the camera just did like a dolly panning on you like we're in Jaws. Yeah, there are, sorry, what'd you say?

Joel Drapper (16:10)
Yeah. Yeah.

Collin (16:37)
there are things like in the blue Skype where I look at it and I'm thinking like, was this made harder because they didn't have direct access to the real API's like, like there's something where you want to be able to reorder and instead of it being like drag and drop, they have like some dumb little arrows you have to tap. forget where the, yeah, there's stuff like that in there. And I'm like, there's a lot of things where it's like 90 % of it seems great and is like pretty unrecognizable, know, pretty indistinguishable, there's

Joel Drapper (16:47)
Mm.

yeah. Yeah, yeah.

Mm-hmm.

Collin (17:07)
If you go looking for the edges of them, like, it doesn't restore your spot in the timeline, or it doesn't do this or that. And so I start to wonder, did they not do that? Because doing that this way, which is going to be more annoying, it also just makes, I don't know, anything that takes you adds a layer. To me, it's always just like, debugging is going to suck now. If you ever want to set a break point, the debugging is going to suck, your tooling is more complicated.

Joel Drapper (17:20)
Mm-hmm.

Collin (17:36)
You know, and things like, you know, svelte exist, which seems pretty nice. yeah, I watched, I watched a couple of videos that were like svelte in 90 seconds. So I'm basically an expert now and, yeah, no, but I'm saying like, there's already really good front end frameworks. I don't know if I would want something that's like, we're going to transpile Ruby to do something else. Cause then when you have a bug in the browser, like you're going to have to get back to the Ruby to figure out what actually caused the issue. And it just seems.

Joel Drapper (17:42)
Yeah, we need to talk about that today.

Awesome.

Collin (18:06)
seems super annoying.

Joel Drapper (18:08)
I mean, I can see the appeal if you love Ruby and you want everything to be in the same language. It kind of makes sense. But yeah, there'll always be a translation layer. Like even down to you look something up, some like new JavaScript API up on the MDN docs, and you now have to think, well, how do I do this in Ruby?

Collin (18:27)
Mm-hmm.

Joel Drapper (18:32)
Right? This is going to be not camel case, it's going to be underscored. someone hasn't read the adapter for that yet. So now I'm to go figure out how to do that.

Collin (18:42)
I

I understand the, I understand and I even sympathize with the idea that I would rather be writing Ruby than JavaScript given the choice. I just think there is a point where that switches over to like, this is actually gonna be way more annoying than if I just bothered to get kind of okay at JavaScript first.

Joel Drapper (18:53)
Yeah.

Yeah, yeah.

What differentiates it for me from what might seem like a very similar comparable thing of like flex is a way to write HTML in Ruby in a sense. But for me the reason that that is important

is I'm generating that HTML in a Ruby file with a bunch of Ruby stuff. Like I am working with objects in Ruby, I'm iterating over lists of things, I'm constantly outputting data from my database, from my Ruby application, and by modeling HTML in Ruby, I can reduce...

the kind of like complexity of going back and forth between sort of like two different modes of operation. And because HTML is such a simple API, like essentially you've got comments, elements, attributes, and content. I think that's basically it.

Collin (20:25)
sounds right.

Joel Drapper (20:26)
I don't think there's really anything else. You could break attributes down into keys and values, Yeah, doctypes, I guess, is that an element. It's probably something special. It's pretty limited. And there's even stuff like c tags and stuff that no one ever uses. And Flex doesn't even have a thing for them because you can just use raw output if you're doing that. No one does. I've never heard of anyone using that.

Collin (20:39)
It's pretty limited. Like there's a lot, but there's not that much.

I've never heard of anybody

using c tags. I mean, I use it in XML, but I've never heard of using it in, I guess I didn't even realize that was a part of HTML. I always think of it as an XML thing.

Joel Drapper (20:57)
Yeah. Yeah.

Yeah.

I mean, there's also, can do loads of different kinds of doc types, but Flex just has a doc type method that outputs an HTML5 doc type, and that's it. So it's not completely...

Collin (21:15)
That was a good change they made in HTML5. Remember pre-HTML5

where had to like, had the really long string and then it's just HTML5 or whatever. That was a good change.

Joel Drapper (21:21)
Yeah.

Yeah,

yeah, so for me it was worth it to do that where I think it's almost it runs into the same kinds of problems though is in integrating with Rails is very difficult that's more akin to what I feel like it would be like to try to integrate with like JavaScript APIs in the front end because the Rails helpers are very

they just work in a very different way to the way that Flex works. With Flex, if you call a method that produces HTML, you expect it to push that HTML immediately out. You don't expect to have to pass your form with to raw, but that's essentially what you're doing in ERB when you do % equals. And...

and ERB just works in a completely different way where everything returns a string and it might be HTML safe or not. yeah, it's just, I mean, it's basically string concatenation, but so like, fair enough, like in Flex, we can kind of adapt. Is this a helper that's meant to be returning HTML to be output or is this a helper that's meant to be returning a value?

Collin (22:27)
ERB seems like a very simple kind of approach to that sort of thing. Yeah.

Joel Drapper (22:48)
that you can use, say, in an attribute, like a path helper, for example, you're going to want to pass to an href of an attribute. You don't want it to immediately push that path out to your buffer. distinguishing that, but then some helpers yield, right? They're going to yield this form helper, right? And on the form helper, you've got text fields, but you've also got value fields, like the form.model.

Collin (22:59)
Mm-hmm.

Mm-hmm.

Joel Drapper (23:17)
or something like that that gives you the model name. And so now we need a way to, okay, take the thing that the original form helper yielded, wrap it in this adapter interface that needs to know which of the methods called on it need to be buffered and which ones don't need to be buffered. And it gets very complicated. Anyway, long tangent there, but for the most part, I felt that

Writing HTML in Ruby really works very well for a lot of applications. you have an application that is very Ruby heavy and you have full stacked engineers and you've got lots of Ruby tooling and Ruby expertise, then it could be good.

Collin (24:02)
mean, it's a

flex to HTML. It's like a pretty one-to-one thing, too. I don't know if you consider HTML a programming language or not, but it does not have a lot of the thing other programming languages have, like variables and loops and stuff. JavaScript is a full programming language, and it's very dynamic, and it has a different kind of object model than Ruby has, and it does things in a different way. And so...

Joel Drapper (24:06)
Yeah, right.

Right, yeah, yeah.

Right.

Collin (24:31)
That just seems like a thousand times more complicated to transpile Ruby to JavaScript.

Joel Drapper (24:35)
Yeah. Yeah. Yeah. So,

so for me, I think that we're always gonna want something like Flex for Ruby applications because you always need to build at least some stuff on the backend, right? That first page needs to be rendered from somewhere. Even if you go all in on like a single page application. But you also...

Collin (25:01)
a spa,

Joel Drapper (25:05)
I think there's a lot of applications where it doesn't really make sense to have a spa.

Collin (25:09)
Do we say

spa? I actually just said that as a joke. Is it SPA or spa? Okay. Well, you're British.

Joel Drapper (25:11)
I say, I say spa. I don't know. Am I, are

we the only people who say spa? Am I the only person who says, have you? Now I'm questioning myself. Yeah, I always call it a spa. So when we say spa, we mean single page application.

Collin (25:17)
I don't know. I don't know. You eat those weird peas. So I'm not going to, I'm going to question everything British people do.

Okay.

Yeah, yeah,

SPA, SPA, whatever. Do you say SQLite or SQLite? Correct. I think that's correct. I think that's how the guy who created it calls it. Sorry. We're talking about, yeah.

Joel Drapper (25:35)
I say SQLite. Yeah.

Yeah, because it's actually

referring to... it's meant to be like a kind of rock.

Collin (25:49)
Really?

Joel Drapper (25:49)
It's not a misspelling of light, I think.

Collin (25:54)
like SQLite, like, okay. Well, that'll be a fun exercise for me to look up later. We were talking about if you were going to write a single page application, you need Ruby HTML, but yeah.

Joel Drapper (25:55)
Yeah. Yeah, I think so.

Yeah, but

also a lot of apps just don't need to be single-page applications. And I think that that makes a ton of sense for certain things. especially with like Turbo, things like HTMLX, things like DataStar, there's lots of options.

Collin (26:09)
Mm-hmm.

Yeah. You can get

almost what you need just from something like Turbo. And then if you need something heavier like Svelte or whatever, you know, you do that.

Joel Drapper (26:24)
Yeah.

You can also, like, people go, when they're working with Turbo, they typically will reach for Stimulus for like the bits that they can't do in Turbo, but I've, I tend to find that that's a mistake and that if it's too tricky to do with like just Turbo, you really should need something more powerful than Stimulus. Stimulus forces you to

Collin (26:40)
Mm-hmm.

Mm-hmm.

Hmm.

Joel Drapper (27:02)
I wouldn't say forces you, stimulus controllers I think are just... they don't really fit with the way that the Ruby mind works. They don't allow you to think about the problem in terms of modeling the different objects that interact with each other. Yeah, it's just procedural and it's like procedural but also where you have

Collin (27:22)
your code becomes very kind of procedural.

Joel Drapper (27:32)
really really tight coupling between the HTML that you render on the server and the JavaScript, procedural JavaScript that you're running on the client without any actual cu- yeah.

Collin (27:44)
Because you have to set all these, because you

have to set all these values and like variable things and yeah.

Joel Drapper (27:48)
Right, you're doing like DOM selectors, you know,

grab this thing with this ID and then get its children and you're building all of these really implicit dependencies between different parts of your application that can very easily break.

Collin (28:03)
I

guess the thing that, and maybe it's just because I'm not good at JavaScript, but I think maybe the thing with stimulus that sort of gets me is just how much of it is actually.

You know through setting attributes in your HTML that'll get past a stimulus because then there's something that like It's not compiler, but you know what? mean like the tooling can't check now, you know, there's no it's what I would call like it's not string It's not strongly typed. It's not weakly. It's stringly typed because it's just stuff in a string somewhere and I I don't usually love that. I stimulus is fine. But yeah turbos really like they call they put them all under hot wire, right but like

Joel Drapper (28:17)
Right. Yeah.

Mm.

Mm-hmm.

Mm-hmm.

Mm-hmm.

Collin (28:42)
They're separate libraries. You can use... yeah.

Joel Drapper (28:43)
Yeah, yeah, they are. And they're very different. Turbo is like, we've got this pre-built JavaScript that can take certain kinds of responses or even, you know, pushes from the server and apply them to your current page.

certain way like we can insert we can insert something we can remove something we can morph something and it's a great yeah and

Collin (29:14)
Which is great. when

that's all you, if all you do need, if you can do it with Turbo, like...

Joel Drapper (29:20)
Yeah and sure

you've got some coupling there where like your backend maybe knows that it's looking for this div with this id and it's going to insert something at the end but the coupling is pretty minimal and I found to be pretty manageable.

Collin (29:36)
seems mostly, it's mostly at the view layer for me and that's fine.

Joel Drapper (29:38)
Yeah.

The

problem with stimulus is also because it's basically designed to work with your... It's like a way of working with the DOM. It's...

Collin (29:58)
It's like one step above just like regular vanilla JavaScript, right?

Joel Drapper (30:00)
Yeah, yeah,

I it's basically jQuery 2.0, but it basically lets you, instead of thinking about what actors do I have in this play and what messages are they sending each other and doing object oriented programming like we're all used to in Ruby, you're just...

Collin (30:24)
Mm-hmm.

Joel Drapper (30:26)
Yeah, you're just writing these procedural scripts and then they're also... When you do need to store stuff, you store it in the DOM, which is just not a great... Yeah.

Collin (30:34)
Yeah, that's the part that I don't love is that like

the variables and stuff get stored in the DOM and that feels very strange to me. The thing that...

So I think the thing that they ideally want to do with stimulus is that you have these like very generic types of controllers, which you put together. so like each controller, you know, and that's how you get that sort of object oriented thing. And I've seen one person, my former coworker, John,

Joel Drapper (30:55)
Yeah.

Collin (31:08)
could think this way and do it that way and it was amazing. Like it was so cool like when he actually did it and you had all these very generic, you know, stimulus controllers, but I haven't gotten my brain to really work that way and I think he's the only person I've seen whose brain did work that way easily. He was also great at turbo. He was really, really good at a lot of that stuff.

Joel Drapper (31:10)
Mm-hmm. Mm-hmm.

problem is people who just like they religiously just want to do the rails way right you know they're import maps all the way they're hotwire it's stimulus erb for the win they don't realize that stimulus is designed for these very minimal like

just sprinkle on a tiny, tiny bit of extra and that Basecamp, their applications are incredibly simple, right? The UI interactions with our applications are very, very simple. So when Basecamp do something like make a text editor like tricks or what's the new one, I think there's a new one. I haven't really paid attention to it. I'm not really sure.

Collin (32:00)
Yeah.

Is there a new one?

it better? Because Trix

was not great. It was so limited.

Joel Drapper (32:28)
But

yeah, but I mean it did what they wanted and that's...

Collin (32:33)
It did what they wanted. Like, if you need like, if

you need a rich text, like comment box on your webpage, like, it's great. But if you need anything more than that though, there's just like no hooks.

Joel Drapper (32:38)
Yeah. Yeah, I've used it a bunch.

Yeah, but they didn't write tricks in turbo and stimulus. Like, tricks was written, you know, in a very different way and in an object-oriented way, if I'm not mistaken. Yeah, but I don't know. From my experience working in places where people have, you know, been given

These are the libraries you've got. This is the Rails way. But then also, can you build this, you know, insert very complex piece of UI? It just, it's so bad. Like.

Collin (33:28)
Yeah, well,

I think even the example I was talking about with the last thing, when he would do it, he had those stimulus things for the, you know, where that made sense. But then when he had a more complex thing, he was not, you know, he did pull in something. Yeah, he, when he's like doing this in stimulus would be ridiculous. He did pull in something like, I forget which one it was, but he did pull in one of these other things like for that part of it. And that seemed really good.

Joel Drapper (33:39)
Mmm.

Yeah, this is not what stimulus is for.

Yeah.

Collin (33:58)
because stimulus was great when, know, if it's not this like hundreds of lines giant thing, when it was just these tiny little components, it worked great for that. And he, don't think he even tried to do anything more complex than that. And I feel like that's sort of explicitly what they say though, of like it's for if you just need a little interaction like sprinkled in.

Joel Drapper (34:13)
Yeah.

I'm sure it is, and I'm sure that the way that it's used at Basecamp is exactly that. Yeah, I'm sure it's beautiful. But that is not the way that it is used in the majority of Rails applications that I have witnessed.

Collin (34:24)
is beautiful. Yeah.

Yeah. No.

Yeah, no, I mean, you

get real dipshit programmers like us, and I mean, we're just gonna... We're gonna... You know, we're gonna end up... You know, the thing about programmers is they will eventually figure out how to write C in any language and just have it be totally procedural. Yeah. Because every language has that trap door. Yeah, yeah. Every language you have the trap door where you're just writing C. Not literally. I mean, you can, but like...

Joel Drapper (34:50)
Interesting. Yes! It can ultimately do that, Eventually. Yeah.

Collin (35:03)
and

Joel Drapper (35:04)
Yeah,

mean, sometimes if you just keep trying to make certain things, like you're working on some algorithm in Ruby and you are trying to make it as fast as possible, you'll eventually end up with something that I think looks fairly similar to C. You probably won't be creating any objects. You'll probably be just calling methods and passing very simple primitives around.

Collin (35:28)
I mean, parts

of flex are like this, right? Where you're just adding up the string. Like, you could do that and see. Yeah.

Joel Drapper (35:30)
And yeah, and you'll probably be using lots of while loops instead of like,

you know, dot each blocks. Yeah, it all eventually.

Collin (35:40)
Yeah, mean,

yeah, I mean, sometimes I mean, I try and think in a very object oriented way, but also, you know, like if you're doing what, yeah, if you're doing like what Flex does where you're just like adding to a string and like, you know, it's kind of like a state machine, I guess, right? If you're kind of just figuring out like, where am I, what do I do?

Joel Drapper (35:51)
It's not always the right solution.

Yeah.

It's not even,

so where it started was Flex was, it had like two steps it would go through. The first one was it would build up a tree of HTML elements, right? So each as Ruby objects, right? And they would have an array of children, which would be Ruby objects. And then there'd be a final step that would walk through that tree and turn it into HTML.

Collin (36:17)
as Ruby objects and then they'd each output. Yep. And it was slow.

Joel Drapper (36:29)
but it was so much cheaper to just have when you call the method, if you call div, it pushes the open tag to a string and then it yields the block and then it pushes the close tag to the string. And it's the same when you render, it just passes the buffer down. So everything's just pushing on to the end of this one string in the correct order and then that's it. There's no tree.

Collin (36:53)
Yeah, like.

Yeah, I mean, I think for flex, obviously that works great, you know.

Joel Drapper (37:02)
Yeah, object oriented programming is great when it's right. my opinion is that it's very right for a lot of things on the front end. Complex UI on the front end does very well to be built using object oriented programming.

Collin (37:11)
Mm-hmm.

If

you did have to write a complex UI on the front end, are there any libraries you'd recommend?

Joel Drapper (37:27)
Absolutely, yes. So, try to think how I would, how I want to get into spell. Maybe I'll start by saying...

Collin (37:39)
So I can tell it changed a lot recently. They went from, yeah, and there's something called Runes, because I watch basically, there's this YouTube channel called Fireship, which I watch it sometimes because they have these really good things that are like, know, XYZ in 100 seconds, right? So I watched, and I like those, but then also sometimes they'll be like, here's the coder news. And for the past two years, it's basically been like AI is going to steal your job. And so I kind of had to stop watching the channel.

Joel Drapper (37:41)
Yeah, yes, VELT5 came out.

Mm-hmm.

Collin (38:09)
But when I do need to find something like what is the deal with Svelte, that is also going back to the Viper thing. How I knew that architecture was not going to be for me was after one of my first days, I was like, I'll go look up a YouTube video for this. And all the videos that were like a basic introduction to whatever were like 90 minutes long. And I'm like, if there isn't a how this in five minutes or less, like what is like the idea of it, that that's not gonna work for me.

It's not gonna be for my brain. It's gonna be too complicated. Sorry. Yeah, so they had this big change where they had this like dollar sign operator thing that everybody loved. But then that was, there were some disadvantages to that. Now they have this thing called runes. I don't know you can explain it.

Joel Drapper (38:54)
Right.

Yeah, honestly, I never used Svelte 4, so I'm brand new to Svelte 5, but I've seen some of the stuff that was available in Svelte 4 and why they changed it, and I think it all makes a ton of sense. yeah, we can get into that. There's going to be a long episode, by the way. Like, we're just going to have to... It's going to be like double this. Let's just go.

Collin (38:59)
Perfect. Well then we don't have to explain it.

Okay, well we're already 40 minutes in, so.

Okay, let's go. I'm ready. I'm jacked in.

Joel Drapper (39:23)
Now we should pause for a sponsor slot.

Collin (39:27)
Yeah,

actually, that's a good point. So I sent you this picture the other day where I said I was at the group. This is the this is the sponsored slot. I was at the local Fred Meyer, which is like kind of the Pacific Northwest, you know, big box like Target type store. But I don't think you have Target, but you know what it is, I'm sure.

Joel Drapper (39:46)
We

have Asda which I think is similar. no, that's Walmart.

Collin (39:48)
Yeah,

it's like a store that sells everything. You know, it's one of those. But it's kind of our local version of it. I was buying groceries and all of a sudden I saw like, you know, they'll have like the racks and they had like a one unit sized rack. And I looked in it and there may have been other, know, maybe it was a miscellaneous, but as far as I could tell, it was all British food. So we have a very small

Joel Drapper (40:15)
interesting. What was

that? You should have taken a picture. Wait, did you? You did.

Collin (40:18)
I did. Do you want me to send

it to you right now? Yeah, so, because I took two pictures for you and I'll send you both of them. So, one moment. Should only take a second. Okay.

Joel Drapper (40:34)
We should make this a regular bit, the intermission to talk about.

Collin (40:37)
British food. I mean, we kind of do. I don't know if you've noticed, we,

I do bring this up almost every episode. Okay, where is it? Okay. So here's the two things I saw. Here's the thing I saw of our very small Brit. I just texted it to you in iMessage.

Joel Drapper (41:00)
I still haven't got it.

Collin (41:02)
That should be showing up any second. Okay.

Joel Drapper (41:04)
Here we go.

Wow, Heinz baked beans. I'm pretty sure that, are they British? I'm pretty sure they're not made in Britain.

Collin (41:08)
Yeah, so that that

So this blew my mind. thought

I've never seen them outside. No, Heinz is clearly not, but it's it's this is that I always thought you guys and I say you guys, I'm not trying to put you into this box. I always thought when they said that, you know, beans on toast or whatever, that people reading like Heinz like like baked beans, like, you know, with like the brown sugar and it's like kind of smoky and like those are.

Joel Drapper (41:17)
Like, Heinz Sutley isn't a British company.

Collin (41:41)
good, I think it's weird to eat them for breakfast, but whatever. And then I realized, no, they're eating these weird, like bean beans, just like plain ass beans in like, you know, tomato sauce, which I'm told tastes like the kind of tomato sauce you get in like Chef Boyardee or something. And I'm like, that's so much worse than what, like I thought it sounded a little weird before, but you know.

I've heard this referred to as a struggle meal, Of like, don't know the, British people don't know the blitz is over. so, and then I read something like, that is a struggle meal. That's sad. Yeah. It's just like how you call cookies biscuits.

Joel Drapper (42:10)
Uh-huh.

It's great! So, we actually call them baked beans. But I think baked beans for us means...

Right, so I think it means something very different. They're not very sweet. They are honestly probably full of sugar, but they're not very sweet. Uh-huh. Coleman's mustard. That's... Yeah, that's good.

Collin (42:34)
Mm-hmm.

Yeah, so I've never seen those before. And then, is it good?

So I did find one thing, these McVitty's Digestive Biscuits. I've never had these before, and I got some. And I was a little annoyed because I think I texted you and you didn't respond. I was like, why have you been gatekeeping digestive biscuits from me? Because it turns out these things hit.

Joel Drapper (42:54)
Yes.

Yeah.

Yeah, they're great with tea.

Collin (43:09)
Those

are, yeah, those are pretty good. People dunk them in their tea. They're like a weedy sort of lightly sweet cookie, right? Like they're not, they're not, it doesn't feel like you're eating cookies for breakfast, but you kind of are.

Joel Drapper (43:18)
Yeah.

Yeah, you could...

there's a very similar thing to this. They're not technically the same, but to me they taste identical. That comes with like, you know, those variety pack crackers we call them? Which you would have with cheese. Like it's that kind of thing, it's not that sweet. You could literally put a slice of brie on this and some chutney. It would be... I mean, it would be pretty sweet, but like...

Collin (43:29)
Mm-hmm.

Mm-hmm.

Mm-hmm.

Yeah, I tried

putting Nutella on them, because I thought that would be very European, and that was pretty good. So I've been eating those, like, those are now a thing I buy. And so it's funny because, yeah, British food is, on the whole, seems terrible. Except, every, there's a couple of things, they're probably baked, and those are good. But.

Joel Drapper (43:50)
Nutella.

Yeah.

You

Yeah.

Collin (44:15)
few and far between. So I did take one more picture for you, because I thought in the interest of like cultural exchange, I wanted to take a picture of something that we have that you don't have. So I just sent that to you. And maybe you can say what it is.

Joel Drapper (44:29)
This is so random. Spices, okay.

Collin (44:34)
Yeah, I took a picture of the spice aisle at the grocery store, since as far as I can tell, British people don't have spices.

Joel Drapper (44:37)
Yeah.

What are you... wait...

that is not true at all. No, what are you talking about? Right, okay, I'm... the next time... I was gonna say, like, we... aren't we, like, the experts in stealing spices?

Collin (44:42)
huh. No, you have Piper and salt. that's true. You did steal them from the rest of the world, but no, that that's

No, that's the joke that people on the internet will say is they're like, British conquered the world for spices and then didn't use any of them. So anyway, so that's our segment on this. The main point, actually no, there's one more thing. I found that Digestive Biscuits, and maybe it was McVitty, because I know there's a couple other brands, are one I saw that when York or something flooded, they like...

Joel Drapper (45:02)
But they don't know how to use them. That's true. Yeah.

Collin (45:22)
helicoptered digestive biscuits in because that's how essential they are for people to live. Which, yeah, it was definitely true. The other thing I saw though was it's estimated that 70 of these things are eaten every second in the UK. And I did the math and I'm like, all right, if you take 30 seconds to a minute to eat one of these things, right? I'm like, that means about

Joel Drapper (45:29)
This doesn't sound true.

That does sound true.

Collin (45:51)
4 to 6,000 people in somewhere on somewhere on this tiny island on this island smaller than the state of Oregon are eating a digestive biscuit. And I was like, and also I can't blame them because they're they like I said, they you are definitely kind of eating cookies for breakfast, but you don't quite feel like it. You feel like you're eating something a little healthy. And and I appreciate that anyway. So that's that. So that's our that's our

Joel Drapper (45:53)
I'm one right now.

That's true, and dunking it in there too.

That's our sponsor

segment.

Collin (46:21)
That's our sponsor segment of McVitty's Biscuits. You know, if other people have a weird small British section in their grocery store, I recommend it. Like I said, I just get these now. So I'm on like my second or third box.

Joel Drapper (46:35)
This was like a proper sponsor section. This is great. Now I sound like professional. Yeah. Yeah. So let's see. Where to start? I think the first place I want to start is you don't have to go all in. I want a single page application.

Collin (46:37)
Yeah, they should pay us. Yeah. All right, so I've svelte.

Joel Drapper (47:00)
to start using something like Svelte. You can build it in a way. And I think that there's a thing, I can't remember the name of this library, but I'm gonna put it in the show notes. It's like Turbo, man, I can't remember what it's called. It's not called Turbo Svelte, because it works for like different things, not just Svelte, I think. But I haven't actually used this one.

Collin (47:15)
Turbosvelte, something or other.

Mm.

It's something for using these giant JavaScript front-end frameworks with Turbo. Yeah, yeah, that makes sense. Marco probably wrote it.

Joel Drapper (47:28)
Yeah.

I- no, I don't think he did, but-

Collin (47:35)
I know, it's just my joke, like a third of the time I'll be like, this is kind of neat, if I'm looking at Ruby stuff. And then I'll look at the author and it's like Margot Roth.

Joel Drapper (47:39)
You have mark, I read it.

Yeah, yeah. So, the way that I have been using these kind of like embeddable spelt components is to have an HTML, like a custom HTML element that initiates the spelt component. And so from the backend, can just say, like say you have like a text editor, right? You can just like output an HTML element that has all the parameters that you want to configure it with.

Collin (47:50)
Mm-hmm.

Yeah, yeah, that's the smart.

You could just wrap this in a flex

object or view component or even a partial or something. You just like stick it here.

Joel Drapper (48:18)
And then you just hydrate the Svelte component in that section.

Collin (48:24)
And then you could

use a stimulus controller to control it. then I'm kidding. That'd be crazy. But yeah, no, you can just stick it in. like you're almost, so somebody on your team who's not doing this felt like almost could just ignore it. It'd just be like a component.

Joel Drapper (48:27)
You could, but why would you?

Right,

you could still have like mostly service-side rendered application, but then have these, know, these spelt components, you know, your date picker, your text editor, whatever. It's just like this minimal spelt component. And actually you would think that there'd be a lot of overhead, but the overhead for doing that, I believe it's like much less than the overhead of just requiring stimulus. Because...

Collin (48:46)
Mm-hmm.

Well, my interest...

Yeah.

Joel Drapper (49:03)
Well, because if you're using build system, you're not going node.js, your Svelte is basically looking at your code and figuring out which parts does it depend on and compiling it. And then it's tree shaken. So there's in theory, no code that you don't need or not too much code that you don't need in the actual output.

Collin (49:26)
Yeah, and then my understanding of one of the big advantages of Svelte versus React or whatever is that React and some of these other things, they all have a runtime that's running in the browser, where Svelte actually just compiles itself to regular JavaScript. So it's much more amenable to a lot of these things, it would seem like. Yeah.

Joel Drapper (49:36)
Mm-hmm.

Yeah, it's got a much more minimal runtime, I think, yeah.

So a few disclaimers before I talk too much about Svelte. I am not really an expert. I don't know how Svelte is implemented. And I honestly haven't really spent much time using many other frameworks. I haven't got a ton of experience with React.

Collin (50:08)
That's never stopped us before, Joel.

Joel Drapper (50:13)
I have been watching this space for a long time looking for... basically looking for this. Looking for the one that I actually like and kind of sensing that they were getting closer. The key thing that Svelte gives us, and to be fair they didn't invent it, this was I think in... was it Backbone originally had an original idea of this and then...

Collin (50:20)
looking for one you liked. Yeah.

Joel Drapper (50:43)
Solid has like

I don't know where this came from. I'm not going to give anyone credit. But this idea of signals have been heavily embraced by Svelte 5. signals are a... I'm trying to think the best way to explain them. They're similar to variables. So the problem with variables is they are in JavaScript.

It's like they're passed by value. If you look at a variable and then you make a decision and then you do something, that doesn't mean that when that variable changes, you're gonna reassess your decision, right? Or if you look at a variable and you render some part of the view, that variable changing doesn't mean that the view gets updated.

Collin (51:44)
It's like a state variable where it, when it changes it triggers your view to re-render the parts that need it. SwiftUI has this and we declare them with that state. And I just realized I will, it's probably where they stole it from is one of these JavaScript frameworks. Which is why whenever I've had to look at one of these now, cause somebody's like, this job might use it. I'm like, it's like the same thing.

Joel Drapper (51:51)
Yeah, so

Yeah, they're probably signals.

Maybe, yeah.

Collin (52:10)
And I will let you continue, but I do realize that a lot of times on our Ruby podcast, I will use the reference of something you're saying and be like, it's like this thing in Swift or Objective-C. I'll use the thing I know that probably almost no one listening to our show has ever seen before. So like, I'm saying that to be like, so since we all obviously are experts in SwiftUI, I can relate this, but it's actually just me. So yeah. Yeah, yeah. So.

Joel Drapper (52:21)
huh.

Yeah.

Yeah.

Well, it might not be. I don't know, I

bet we've got some iOS listeners.

Collin (52:41)
Probably, yeah. So it's like a published variable, though, where it

can then look at it and update your view or your component. And it's probably even smart enough to be like, just update the part that needs it or whatever.

Joel Drapper (52:52)
Yeah, so it can track basically like dependencies. So you can think of it as like an object that wraps a value and it knows when that value has changed. And it also knows what depends on it. So it these functions depend on it. These other pieces of state depend on it. These derived values depend on it.

Collin (52:56)
Mm-hmm.

Joel Drapper (53:18)
And it also integrates with the view templating and the CSS stuff that's built into Svel. And so this is the really powerful feature that I think has made a big difference to why are these front-end frameworks so compelling now? The ones that embrace signals,

it just completely changes what it's like to code. Like you don't have to think about, okay, now I've put this counter up here in the corner. Yeah, or like when I insert something down here, I need to remember to go and update that counter. You can just have a derivative of the array of items that gets its length.

Collin (53:57)
And now I have to go update the label.

Yeah.

huh.

Joel Drapper (54:15)
and you can render

Collin (54:15)
Yeah.

Joel Drapper (54:15)
that in your view. And whenever you insert an item into that array, the counter gets updated. You don't have to think about that.

Collin (54:21)
Yes.

Yeah, so the way I've heard this is it's like you'd have like a binding type, which I think is kind of what you're saying where it kind of wraps it. And then I would be like, give this the binding for this thing is this, and then it will sort of update. Is that similar or is this more complicated? It just does it.

Joel Drapper (54:27)
Right.

You don't even need to think about that.

In Svelte, it just does it because they're a framework, they're controlling the whole... Yeah, it's the whole thing. let's talk about a Svelte component. So, a Svelte component is kind of like HTML. So by default, you're in the HTML mode, but then you can have a script tag.

Collin (54:45)
This is all it does, it's the whole thing.

Joel Drapper (55:05)
inside and typically these are put at the top and you can also have a style tag and so your component is in one place like markup, behavior and style and they're all connected so for example if you write a CSS selector to select some part of your markup so you've got a div with the class card and then you go and remove that

class, Svelte is gonna be like, hey, this selector isn't used anymore. So everything is connected and the developer experience is just great. Like it's so simple. It feels like what HTML should always have been. This just dynamic thing. And how it works is in your JavaScript, you create, if you use the state rune,

which is basically a it looks like a function call but the compiler treats it differently so you say dollar state and then in parentheses you put in the initial state of that object so you might have yeah yeah so this could be this could be a string and a number it could be an array it could be an object it can literally be anything so you can say something like

Collin (56:14)
It's actually literally the same syntax as SwiftUI, sorry.

anything that could change.

Joel Drapper (56:33)
dollar state and then pass it an object that has a bunch of settings, right? And then in your view, you maybe have some conditionals that against that state. if the setting is that it is dark mode, then the background color is gonna be this or whatever. Or if, I don't know, whatever. If the setting is that this thing is enabled, then show this toolbar. And that's it.

Collin (56:50)
Mm-hmm.

Joel Drapper (57:03)
your behavior is done. you then have a piece of... if you then have events that change that data then your view is going to be updated automatically. You don't have to think about it.

Collin (57:18)
And I assume

it can be two-way. So like if I had a text field that was bound to this thing, you have two-way data binding. So if I update the text, can update the value.

Joel Drapper (57:23)
Yeah. Yeah.

Yeah, so any form fields you can say for any of their or essentially any of their attributes you can you can bind them to that value. So you might say like you know name equals state and then empty string and then you could have an input and you could say bind the value to the name and now when I type in that input field that state is being updated with every keystroke.

Collin (58:00)
Yeah, exactly. And can you add like, can you add like, I'm trying remember the name, but like modifiers to that sort of so you can be like, you know, as they do this, have it sort of filter through this thing or have it, do you know what I'm saying? So like if I wanted this, when they type it, but I want it be all caps or something in my thing, like.

Joel Drapper (58:01)
And it's great.

Yeah, so

Right?

You can have derived state. So you can use the derived rune, which is just dollar derived, and then you write an expression. And if that expression references some state, then it will be rerun when that state changes. And if it changes, then anything that depends on it will also...

Collin (58:25)
Mm-hmm.

Joel Drapper (58:51)
be updated. And this is so fine grained that if we're in the view, like a change to some value in your JavaScript, it could mean that a specific attribute in the DOM or a specific text node in the DOM gets updated. It's not like...

Collin (59:17)
Mm-hmm.

Joel Drapper (59:19)
they have to regenerate the component and then diff it against the original one and figure out what changed. And there's no virtual DOM. It is that their compiler, this is the way I understand it, I may have this wrong, I'm pretty sure this is correct. Their compiler actually knows this is the structure of the DOM, these are the elements that are connected to this state and this is how they need to be connected.

Like this exact text node is bound to this state. So if the state changes, this text node changes. And it's just incredible how it works. If you have an array, you can iterate over it. And if you insert things into the array, if you delete things from the array, your view updates. Like it's just incredible.

Collin (59:58)
Mm-hmm.

Joel Drapper (1:00:16)
Now, a lot of libraries have components. I don't think many of them do components very well, but Svelte does. but if you look at Svelte, might, I don't know, you might think that like, yeah, but the view isn't like the best abstraction for the kind of thing I'm building. And I completely agree. I don't want to put too much logic in my components.

what makes Svelte really, really interesting for me is that you can, you can use stuff like state from regular CSS classes. So I build my Svelte stuff like, kind of like an MVC app. So I'm thinking about like, what, how can I model this problem? What kinds of classes can I make?

Collin (1:01:08)
Mm-hmm.

Joel Drapper (1:01:17)
and you can actually say that this class has a property that is state and when you do that the compiler will define setter and getter methods for you so when you have like an object an instance of one of your classes you can just change you know change properties assign values to properties

and all of the state is tracked. So if I have an array of people objects and the people have a state that is the name, right, and I have iterated over this array in the view and rendered out the names, all I have to do is change the name property on one of these items and the view updates. I don't have to think about anything else. And that is just...

I think especially for Rails developers, the way that we think about Ruby code, it's just such a better way to think about complex front-end UI. If that makes sense. Kind of losing my voice, I think.

Collin (1:02:28)
Yeah.

Have you ever heard of something called MVVM or a view model? You ever heard of this other than me tweeting about it or whatever I do about it? Yeah. So what this kind of makes me think of is when I'm doing a, thinking about having like front-end components, but then be able to do it in sort of very object oriented way is in with my Swift UI apps. What I'll have is I'll have my

Joel Drapper (1:02:36)
No. No.

Mm-hmm.

Collin (1:02:56)
view that has my component, that has all my stuff in it, and I bind my values to the different fields and whatever that I want. And then the component usually, I usually have it, it's injectable or it will just create it itself, will create something called a view model, which is sort of like a very lightweight controller. And what it's responsible for is taking basically

the model data and then manipulating in any way that it needs to be, you know, or doing whatever. And then that is a, that has all these published, you know, variables and stuff. And, you know, to sort of abstract those apart. I don't know if that's a useful thing to think about. can show you more later, but it's kind of reminded me what you were saying of like taking this sort of component thing, but then getting some of that logic out of the view so that it's in this other thing.

Joel Drapper (1:03:28)
Yeah.

Yeah.

The way that I tend to do this is I think of my regular classes, they are like my model, and then the script tag in my components, that's like my controller, right? So that's working with possibly multiple models, and it is bringing together everything that it needs for the view that it's responsible for. It's a component, like a flex component.

and then those once that the the variables that that makes available are then read in your the html part of your component and the css part of your component and that constitutes the view so you can really do the whole model view controller thing just between models and then components because components are both the view and the controller

Collin (1:04:35)
Yeah, I.

Yeah, yeah, think this is, I think we're kind of saying something similar, where you're saying like your script tag is sort of responsible for that. Where I feel like the difference is as opposed to that being there, I just have an object that sort of codifies that. So, kind of the same thing. Yeah, I'll show you later what I'm talking about, it'll make more sense, but I was just thinking that it sounded like a very similar sort of mindset.

Joel Drapper (1:04:54)
It's like that's, yes.

Right. Yeah, you could do that too.

Yeah.

Collin (1:05:16)
I

think if people like, I think if you like MVC, which famously we both do, you can make anything MVC. If you try hard enough and you squint your eyes, you know.

Joel Drapper (1:05:22)
Mm-hmm.

Yeah. Yeah.

Yeah, one of the things I want to highlight is that this is the state is two way as well. So,

Collin (1:05:36)
Yeah, yeah, Which is actually,

by the way, when we go back to when I wrote my blog post about MVC and all that, in the original MVC stuff, that was actually how it was supposed to work, that it would communicate both ways. Like in Small Talk, it was supposed to be a two-way street, as opposed to having this thing in the middle that's sorta, anyway, continue.

Joel Drapper (1:05:42)
Mm-hmm.

Yeah. Right. Right.

I mean yeah and it's a live two-way street like every character you type you're updating that state and you can obviously if you need to put the brakes on that slow things down you could you can have some kind of like what would you call that there's a word for that you know what I mean yeah yeah you can do that

Collin (1:06:11)
Mm-hmm.

If you need to find your trapdoor to write your C code, you can do that. Yeah, so,

which is good because my experience with these things where stuff updates automatically is you will, when things get complex, you will end up in a point where it's like, the performance went to trash or whatever. And you're like, why is this updating so much? What's going on? It's good to be able to figure that out.

Joel Drapper (1:06:36)
Mm-hmm.

Yeah.

Yeah, by default, the performance is extremely good though. Just because it's not doing any query selectors, it's not doing any DOM diffing, it's just, knows the structure of your DOM already. It has references directly to the parts of your DOM that need to change.

Collin (1:07:04)
Yeah. mean, the

kind of thing I was thinking of is I would just de- this isn't, this is a totally different thing so we don't have to any time on it, but I was thinking of something where it was tracking the mouse pointer and so that like every movement of it, so it's coming through like thousands of times a second and like, yeah, yeah, debouncing and it wasn't debounced. so like the view was just updating way more than like the screen could update. Um, and that is the kind of thing where you really want to be able to figure out why that's happening.

Joel Drapper (1:07:15)
Mm-hmm.

Yeah, debouncing is the word I was looking for. Yeah.

Right.

Yeah, exactly. Yeah. But yeah, so my experience has been that building, you can build incredibly complex front-end UI in a way that is just really fun and natural. And yeah, it takes a bit of getting used to if you're a Rubyist, but honestly, it's much easier than...

Like getting your mind into building svelte, think, for someone who's used to rails, is so much easier than getting your mind into building stimulus.

Collin (1:08:12)
Hmm. mean, yeah, stimulus is not, I don't feel like knowing Rails helps me be good at stimulus. Yeah, it doesn't help me be better at stimulus. And I think that the evidence I have for that is I'm pretty good at Rails and I'm terrible at stimulus. And so I feel like it's not helping me that much.

Joel Drapper (1:08:19)
Stimulus is just procedural, like...

Yeah.

Yeah, what was the other thing I was gonna say?

Yeah, I can't really remember. I highly recommend checking it out because they have a great little demo.

Collin (1:08:46)
I think it is the most,

I think it's Elixir Phoenix because there's like six Elixir Phoenix users and they all love it. And I think after that is considered like the most loved UI framework. Yeah.

Joel Drapper (1:08:53)
Yeah.

Yeah,

yeah, okay, so one of the things, the thing I was gonna say is the kind of principles behind the way that Svelte is built, I think, are really accessible to Rubyists. So it doesn't have very many dependencies. They're very, very thoughtful about the API design and the developer experience.

Collin (1:09:14)
Mm-hmm.

Joel Drapper (1:09:26)
you don't need to include a bunch of extra stuff to be able to do things. Like it has built in an animation, you know, animation things, it has built in like so many things that you would need, like state management, things that you would need to go to an external library in something like React, where you might need to have like these 20 different, that's probably an underestimate.

Collin (1:09:43)
Mm-hmm.

Joel Drapper (1:09:56)
extra libraries to... yeah exactly. You can basically like... you basically don't need anything other than a spell and if you do need to use a library in React you need to find like a React wrapper for that library usually or make one and then you've added another library to the...

Collin (1:09:57)
JavaScript people love libraries. I just import npm.

Yeah.

You think it would speak

to Ruby is because it's a little more batteries included, basically. So like the basic stuff, if you need to use a library like you can, but generally it's kind of there.

Joel Drapper (1:10:19)
is very batteries included.

But if you need to use

a library, you can just use the library. You don't need to use a wrapper around the library either because they've made everything so easy, like it's so easy to integrate with different things. It's just great.

Collin (1:10:32)
Right.

Yeah,

one thing, not really used these kind of things a lot, is I saw in the old version of Svelte where it had like the dollar sign stuff everywhere. So, and I think maybe this is part of why they changed it to make it more like standard JavaScript. Tell me if I'm wrong. So are these things sometimes like when they're compiling, is there stuff in there that isn't, it's like a dialect of JavaScript or is everything in Svelte still?

Joel Drapper (1:10:49)
Mm-hmm.

Collin (1:11:09)
valid JavaScript. Does that make sense? Or are they taking some things and like then compiling it to real JavaScript?

Joel Drapper (1:11:16)
So everything in Svelte, I think, is valid JavaScript, but it wouldn't actually execute that way. So for example, $state, it's technically just, if you were to interpret that as JavaScript, then JavaScript would be like, there's a function called that there to the function $state.

Collin (1:11:27)
Mm-hmm.

It wouldn't work because

you don't have felt, but it would compile. would not compile. It would run in some way.

Joel Drapper (1:11:38)
Yeah, but I believe that state

that spell is is taking that and it's compiling it in a very different way. So so if it sees you say on a class, you know, foo is dollar state one, it's going to actually define, you know, get foo and set foo and make them update that state. So it's going to remove the original code completely and and create new valid JavaScript code.

Collin (1:11:46)
Mm-hmm.

Yeah.

That makes sense. So kind of both then, I guess. It's sort of valid JavaScript, but it's also kind of compiling it to JavaScript.

Joel Drapper (1:12:11)
Yeah.

Yeah, and it also

supports TypeScript. So I love using it with TypeScript. I think TypeScript is a very, very good language. I've talked about this a bunch before. I think that they've just done such a fantastic job building TypeScript and making JavaScript actually nice. Yeah.

Collin (1:12:25)
Yeah.

I like the TypeScript's pretty simple.

I knew all the concepts in TypeScript of interfaces and generics and stuff. And so was like, I guess if you were coming from a language where you didn't already know all of those, then it would probably be a lot. Steep learning curve. Yeah, because I'd already spent a few years in a language that had that, I was like, I get it. They just added all this stuff.

Joel Drapper (1:12:47)
Mm-hmm.

Steep learning curve. Yeah, but so worth it. I would say

Yeah,

you need to learn it because it will make you a better Rubyist. Like even though I love the dynamic aspects of Ruby and I love that, I think that that is actually Ruby's superpower. I don't like the idea of constraining Ruby with like Sorbet. But the way that learning more, like using these more type safe, type strict languages,

Collin (1:13:20)
Yeah, nobody put 3B in a corner.

Joel Drapper (1:13:32)
has helped me think about my objects and interfaces and things and protocols, I would... it's so worth it. Yeah, 100%.

Collin (1:13:38)
I mean, you're saying the same thing I said at the beginning of the episode, right?

Of like, you know, knowing a language like Ruby makes me think about those exact things that I can then apply. But then also, if you're a Rubyist, knowing about types and working in a language, you really have to think about types and you have generics and you have all this kind of stuff and you have to declare your interfaces. And then...

or working in a language, this wouldn't be TypeScript, then, or trying a language where you have to think about memory. Understanding memory and understanding types in a different way will be beneficial to you writing a language that doesn't really make you worry about those things. It's still helpful. Yeah.

Joel Drapper (1:14:21)
right? Yeah.

Because you still have a sense of what it's probably having to do under the under the hood.

Collin (1:14:27)
Exactly.

That's what I always think. Like if you don't know how, like it was an interview question I used to ask people of like, how do you think a garbage collector works? Right. Because if you don't know how a garbage collector works and you're working in a language that has a garbage collector, like, you know, that's, that's going to have an impact on you, you know? and so being able to at least, you know, even if the thing you come up with maybe isn't exactly how it works in whatever language.

Just having a sense for like, how could it work? What kind of things do they do? I think that's useful.

Joel Drapper (1:14:58)
Yeah.

Yeah. So there's.

Like I said, can use Svelte with Rails and you can kind of embed these little Svelte components, but also you can go all in and you can use either you can have like a separate API that your Svelte app consumes or there's this really cool tool that I haven't really used yet, but it looks amazing called Inertia and...

Collin (1:15:15)
Mm-hmm.

Good name.

Joel Drapper (1:15:33)
Yeah and it basically lets you say from your controller you can just say like these are the this is the data that I want to pass to my component that represents the view for this page and it will kind of magically handle

setting up the application if it's the first load and then passing that data in as properties to your component. And you can build entire views using, your entire front end using Svelte. I think that can be a really good option for some kinds of applications as well. like, I a good example, like if I was building a spreadsheet app maybe, or like,

to-do list app or something maybe I'd do that something really really like lots of drag and drop e Yeah, yeah, you've got lots of experience doing this

Collin (1:16:30)
Never make a to-do list, App Joel.

as the number

one to-do list app maker in the world. I might make one. I don't know. I want to make a time tracking app. Are we still talking about Svelte? Do we have more Svelte? Can tell you about this app? OK. I want to make a time tracking app. So I've realized is that the automatic ones, like rescue time and stuff, they're OK. They're kind of bad, though.

Joel Drapper (1:16:37)
Don't do it. Not worth it.

No, tell me.

Okay.

Collin (1:16:59)
because they're all based on, you know, it's automatic. So they're all based on like what app you're using or whatever. And I'm like, yeah, you can't tell what I was doing. Like was I focusing or was I not? And the things that are like Pomodoro based, you know, they want to enforce you taking breaks at certain times. Like that's sort of annoying sometimes. Like they're all a little too complicated or a little too automatic. And I realized what I really want is something that sits in my mind.

Joel Drapper (1:17:23)
Mm-hmm.

Collin (1:17:27)
What's actually been helpful for me is this, is I basically just, I'm like, how many hours a day of real work do I need to do to like have done a real day of work? You know, to like get everything and basically just start a stopwatch and then start and stop it when I'm like doing my work and just be like, at the end of the day, it has to be this number. Like this is my number for the day. And I kind of want to make an app that

lets you put in some things of what you're working on, you know, of this client or this personal project, but is essentially not a lot more complicated than that. And I think that would be pretty useful. It's an app I was thinking about, because all these timing apps are very, for something that seems simple, they all have a lot going on. And I really just want a good way to start and stop a timer. So.

Joel Drapper (1:18:08)
Yeah.

Yeah.

I'm related

to that, but just on Pomodoro. The trick with that, in my experience, is use a sand timer. So you get the same effect of there's a timer running, so I have to focus on this thing. And when that time is done, I can think about something else. But when it's done, it doesn't tell you loudly.

Collin (1:18:28)
Mm-hmm.

so you can just keep going.

Joel Drapper (1:18:48)
so you

can just keep going if you're really into it. And it's for me like that's so much better than setting a timer on like your phone or something that's going to actually interrupt you and take you away. Like if it's something you need to do lots of work on right and you're using Pomodoro to like I hate this and I just want to like but I'll spend half an hour on it I can convince myself to do that.

Collin (1:18:50)
Yeah.

Mm-hmm.

I guess it depends on what your method of not getting your work done is, right? So my issue is like, my issue will be like procrastination of just like, I'm not quite sure how to do this, I, what, and it just takes me too long to get started. Once I get started though, I'll keep going. I just need to get started. And I won't usually forget to take a break here and there.

Joel Drapper (1:19:32)
Hmm.

Mm-hmm.

Collin (1:19:41)
where

if your problem is you get like in and then you forget to not do anything else for seven hours, then yeah, mean, for me the thing is is like, yeah. And the other thing is that when I say like I wanna hit a certain amount, I've tried to figure out I'm like, what is that number? And it's not as high as you think. You know what I mean? Like if you got, I don't.

Joel Drapper (1:19:45)
Right, and you forget to take breaks.

But that's so productive.

Collin (1:20:10)
My feeling is if you got somewhere between, you know, because you're gonna have meetings, you have just like general administrative stuff, you have all this other stuff you do that doesn't really work. If you got somewhere around four to five hours of like real programming done every day, like actual whatever, like actual some version of coding, I think that's a lot more than most people get who don't track this at all. Like I think that would be very productive.

Joel Drapper (1:20:19)
Mm-hmm.

Yeah.

Yeah, completely agree.

Collin (1:20:37)
I figured this out

from freelance, which is I'm like, it is really hard to bill more than a certain hours a week if you're really tracking your hours because like the hours just fly away at a certain point. anyway.

Joel Drapper (1:20:51)
Mm-hmm.

Yeah,

I always found it very difficult to actually, even though I work like 12 hour days, to actually build eight hours of like, I feel comfortable saying that this was focused on your thing. Impossible.

Collin (1:21:02)
Mm-hmm.

It's the idea

that I could do eight hours every day where I could say I was focused. Like that even seems crazy. I feel like the number most people hit is between 20 and 30, depending on like how.

Joel Drapper (1:21:16)
Yeah.

Yeah, but it's

it's like this lie that everyone is telling though because no one's doing that. So

Collin (1:21:24)
yeah. I mean, if,

if we all just accept that we're billing $150 an hour or whatever, and that however many hours we just say it's a, I'm great with that. I'll do that. Like if I've just been under billing myself, but my thing is like, I try and bill for the amount of time I'm actually like doing something related to the, maybe I should charge double. or I should just get a job where they just pay you and you just go to work and do it. I mean, I think another realization for me is that like,

Joel Drapper (1:21:41)
Then you should charge double.

Yeah.

Collin (1:21:53)
You don't get rich doing freelance. The benefit of freelance isn't that you'll make a lot of money. It's that you will, like I think if you want to make a lot of money, you should go work for Google or something where they give you a bunch of stock, assuming they don't let you off. But you should go work for one of the big tech companies because they pay a lot and they give you a lot of stock and the stock is worth a lot of money. I think the benefit of freelance is it can give you a lot of flexibility. You you take off for two hours in the middle of the day sometimes.

Joel Drapper (1:22:04)
Mm-hmm.

Mm-hmm.

Collin (1:22:23)
But it's not the most money you can make. Unless you get so successful at it that you're like subcontracting and you're taking a percentage of, then obviously it's different. Then you're thought bot or something. Then you're like a real agency. But I don't think I'm ever gonna do that.

Joel Drapper (1:22:35)
Yeah. Right.

Collin (1:22:44)
Anyway.

Joel Drapper (1:22:45)
Can I take it back to spell real quick? One thing that I have been thinking about and I haven't really made any progress here except just to think about it is I think it would be really cool if there was a way to have a piece of state that was a proper signal in spell. So had all this fine grain reactivity and whatever.

Collin (1:22:48)
Yeah.

Joel Drapper (1:23:13)
but also was live synced to Ruby and had like a Ruby API. And I'm not sure exactly how, probably WebSocket.

Collin (1:23:23)
like a web socket or something.

Yeah. I mean, isn't that

how like turbo streams work?

Joel Drapper (1:23:31)
No. Well, they use WebSockets, but they do.

Collin (1:23:32)
Well, mean, they can. Well, I mean, they can.

There's the thing where it's just like making a call and then patching in HTML. And I think that's just JavaScript or whatever. But then there's the thing where it's like actually observing your models and it will actually push it. I think that uses WebSockets.

Joel Drapper (1:23:40)
Right.

Pushing stuff.

Yeah,

so I don't know exactly what this would look like, but I also imagine there being probably different types of data and different types of syncing mechanisms. And the one that I'm really interested in is a conflict-free replicated data type for strings. So you could have then through this abstraction,

You could have multiple people say working in the same text editor, typing in the same box. And I think you could abstract a lot of the complexities of that away.

Collin (1:24:26)
Oh, so that's funny, because what I was thinking, I mean, that makes sense. What I was thinking was that you could have your modeling controller type layers in Ruby and then just have the view at that level. Because your views could be communicate. If you had two-way communication between your views and your Ruby controller, then you could.

Joel Drapper (1:24:38)
Right.

interesting.

Right? Yeah, you could totally do that. So for something

like a boolean or an integer or an array of strings or whatever, right? But I'm also thinking like, what about inside the string? What if it could have conflict resolution where, I don't know, I just feel like the, yeah.

Collin (1:25:11)
mean, kind of the same thing then probably, because you'd still be

saying like, call into this thing, and then it's going to do some stuff, and then it's going to pass it back in some way.

Joel Drapper (1:25:18)
Yeah, I mean, ultimately,

like, when you have a conflict-free replicated data type for a string, you are just using a more complex data type. It's actually an array with objects and whatever under the hood, and it's just like a write-only thing. And you just need to have the same algorithm on both sides, put the thing back together into a string. But yeah.

sync like a syncing mechanism that enables that like with a great API in Ruby and a great API in in Svelte I think would just be so good.

Collin (1:25:58)
I mean, once you have two-way syncing, can just two-way data binding. just do anything. I mean, except that if your connection gets messed up in some way and then your whole website breaks.

Joel Drapper (1:26:02)
Yeah.

It doesn't though, because... well, it doesn't...

Collin (1:26:11)
You could probably do some clever

stuff with caching or whatever in the browser, maybe.

Joel Drapper (1:26:16)
The

whole point of a lot of these replicated data types is that you can lose the connection, make independent changes, and then reconnect and they sync in a deterministic way. Yeah, so I'm really interested in exploring that further. I don't know. I think we're gonna try to do a lot in that direction in YIPPY because I think that...

especially now that it's not just other people that we're collaborating with it's also a lot of the time it's large language models and we're interacting with them through text. I think having better abstractions over real time you know presence and you know text-based collaboration I think are going to be really important.

Collin (1:26:50)
Mm-hmm.

I

sent a message to chatGPT the other day that if had a face I'd punch it.

Joel Drapper (1:27:15)
What did it say?

Collin (1:27:16)
Well, because

sometimes these things is you're like, it'll like help you and it's like, wow, this is amazing. Like I got this done so fast. And then sometimes you'll be like, how would you do this kind of thing? And it'll be like, you could do it like this. And then you'll spend six hours going on that. And at the end, you're like, this isn't working. It's like, obviously that was never going to work. That's not how this works at all. And I'm like, but you're the one who told me that. it's like, it's like.

Joel Drapper (1:27:24)
Mm-hmm.

Ha ha ha

Collin (1:27:44)
You're right, I was too whatever when I said that and I'm like, well, if you had a face, I'd punch it. You asshole. Because it'll just say stuff sometimes.

I don't know, do use it though, but...

Joel Drapper (1:28:01)
Yeah.

Have you um... You don't... Do you use Zed? At all? No? Okay. They... It's so good. They launched their like uh their co-pilot competitor. Yeah. Uh it's so good. Yeah it's so good. Um...

Collin (1:28:07)
Mmm, not really. I've you a little bit. I try it out every time we talk and you're like go look at Zed and I'll use it for five minutes and I'll like forget about it.

they have their own co-pilot now? Is it good?

It's not

like we have copilot, it's not like copilot from Tmoo.

Joel Drapper (1:28:28)
No, so it's like, no.

Collin (1:28:30)
Do you know that meme where they're

like, yeah, where it's like, you know, wish.com. It's like, or the other one I like is, I don't know if this is a thing that you experienced as a kid where you grew up, but we have sort of a thing where, you know, you'd say to your parents, like, can we get McDonald's when you're in elementary school? And they'd say like, we have McDonald's at home. Like that's the thing parents would say. So a lot of times when I see like the JetBrains version of Co-Pilot, it's we have Co-Pilot at home.

Joel Drapper (1:28:49)
Mm. Mm-hmm.

Mm-hmm.

Collin (1:28:59)
It's, but it's actually good. Cause I'll try it. I'll try it if it's good and it's not, is it an extra charge that, I mean, I I'm okay paying $10 a month. The thing that I don't like is that they all are like, go into your API key from chat GPT and then.

Joel Drapper (1:29:01)
It's actually great. Yeah.

Right now it's free.

Yeah,

this one doesn't need that. I'm gonna, you know, even if I had to pay for this, I'm probably gonna cancel my Supermaven account as a result of this coming out. Supermaven is the other chat GPT alternative, which is pretty good.

Collin (1:29:25)
Your super who? I don't know that one. I've been using, somebody called us

out for not talking about, but I've also used cursor a little bit. Have you looked at that one? Cursor's fine. It's VS code basically, so if you don't like VS code, like that's what it is. But what's nice with, what's cool with cursor is that it will actually look at your whole project, which a lot of these things are kind of only looking at like your file or the files you have open, where you can hit a command and be like.

Joel Drapper (1:29:34)
Yeah.

I hate it.

Right?

Collin (1:29:53)
how does this app architect it exactly? How is this model connected? And it will just go figure that out for you, which is kind cool, but you have to use this weird electron app to do it.

Joel Drapper (1:29:56)
Yeah.

I think Zed is gonna do some pretty amazing stuff in this space. No, they won't run out of money. They have, they have, I mean, I would, would so invest in Zed. They have such good technology and potential. Like there's so much better position than VS Code and all of these other VS Code forks because they put the work in to building their

Collin (1:30:08)
or run out of money.

Yeah. Yeah, I hope they start.

Joel Drapper (1:30:34)
CRDT, sorry, conflict-free replicated data types buffer, right? If you're gonna collaborate with AI, that's what you need. Yeah, yeah, because it's making edit, it's not just predicting what you're about to type, where you're typing. It's like, I think the prompt is essentially asking, given that I just made this change, what other changes should I make, right? So it might be like you change a variable from

Collin (1:30:35)
Yeah.

Mm-hmm.

is it like in line kind of? Like, that's neat.

Mm-hmm.

Mm-hmm. Mm-hmm.

Joel Drapper (1:31:03)
being one thing to being multiple things. Now it's an array. So now somewhere where you're setting it, you actually want to push into it somewhere where you're, know, it just gives you all of these predictions. And the interface is really nice. They've done quite a good job. I think they can do better going forward, but like it's a really great strong start. But

Collin (1:31:06)
Mm-hmm. Mm-hmm.

Oh shit. Yeah. I'm gonna have to give it a shot.

Joel Drapper (1:31:32)
The way that they're doing it is so clever. They're doing, the way I understand it, it's like branch prediction. So essentially, if you think about it, if you have your file and they've got like, I don't know, 10 lines above, 10 lines below where you're typing, and they put this into this LLM and ask it to predict, you've just made this change, what's the next thing?

Collin (1:31:50)
and loading Z update, installing Z.

Mm-hmm.

Joel Drapper (1:32:02)
they

can guess that as it's generating these tokens that the next token is going to be the same that probably most of the code that it's going to generate is exactly the same as you already have. Yeah.

Collin (1:32:13)
Is this edit prediction?

Okay. I'm agreeing to their thing. Maybe I should, I'll read the blog post too. Okay. I mean, eventually I hope Zed gets, I mean, maybe it won't, but like it would be cool if eventually it got something where you could like run your tests from it and stuff like that. You can now? I don't mean in a terminal. I mean like a UI. When did they add that?

Joel Drapper (1:32:18)
Yeah, do it. It's so good.

You can. Yeah, you totally can.

You can in a UI.

I don't know, but you can you can do it. It's I don't like it. I prefer to do it in a UI Because I like to just run my tests in watch mode so every time I save they just rerun

Collin (1:32:43)
They have a test runner?

Right.

But they have some kind of a, what is this? Channels? What is channels?

Joel Drapper (1:32:56)
Yeah, they have a test runner.

channels is

like for collaborating with people. Yeah.

Collin (1:33:05)
Jesus. Okay.

Well, this all looks great. I'm going to have to go check this out and we can... hey, Joel's online. All right, we can talk about this later. But anyway, maybe I'll take another look and then we can dive into like the details of all of... Seems like there's been progress in Zed since the last few months that I looked at it. So maybe we can go do that. Okay.

Joel Drapper (1:33:28)
Yeah, it's come a long way.

Collin (1:33:34)
Well, we promised this to be a long one and I think it is. there is one more thing I want to bring up because we have a lot of Australian friends and I've been, I heard somebody else ask this question and I need, I wanted the answer. So you know how some, not all, not all Australian people, and I love Australian people, but you know how some people for no will say nar, like are nar, right? This is the thing. And if you say this to Australian person, they'll be like, no, we don't.

Joel Drapper (1:34:04)
They'll say, now we done.

Collin (1:34:04)
But like, some of them do.

Nah, we don't. So here's my question that I really want, Tim, or one of our Australian friends, who accepts the truth that some Australian people do talk this way? Do not tell me they don't, because I've heard it.

Joel Drapper (1:34:21)
you

Collin (1:34:23)
When you pronounce the word, when you pronounce the name of the film, Pinocchio, is it Pinarchinar?

Or something like that? Pinarkony. Pinarkinar? I think it'd like Pinarkinar. Pinokio?

Joel Drapper (1:34:41)
This

doesn't even sound like Australian.

Collin (1:34:43)
Well, they say, if you say no, if you say nar for no, puh no, puh nar.

Pinar... Pinarkino? But yes, I want to... Somebody can get back to us on this and we'll talk about it next week. Pinarkinar. Disney's Pinarkinar.

All right, so we want to thank McVitty's original Digestive Biscuits and we will see you soon.

Joel Drapper (1:35:13)
Right.

Yeah, and also if you have any questions, then jump into the Discord.

Collin (1:35:25)
Yeah, we

have a Discord. I'll put the link for it in the thing. I should just make sure it's included every time. So look at the show notes, go join the Discord. It's been really popping off lately because I'm there and Joel's there and a couple other, so there's a couple messages a day now, which is great. So go chat with me and Joel in the Discord and we will talk to you there and then also back. Okay, bye.

Joel Drapper (1:35:35)
It's been like one message.