Slightly Caffeinated

TJ Miller (00:00)
Hey, welcome back to the slightly caffeinated podcast. I'm TJ Miller. So Chris, what is new in your world?

Chris Gmyr (00:05)
and I'm Chris Gmyr.

Yeah, busy busy. We talked a little bit about the HVSC work last week, so we got that all buttoned down and scheduled. So that will be next week, Monday through Wednesday. It'll be a crazy three days, but at least at the end of it, everything will be working and brand new. So not really looking forward to getting the work done. I'm looking forward to it being completed, and they'll be out of the house because.

where you gotta figure out how we're gonna shift around, you know, working from home and then a toddler and a dog and people going up everywhere in the house and it's just gonna be a little crazy. So trying to cancel like as many things and meetings and stuff like that. But it'll be good once it's done. I'm looking forward to that.

TJ Miller (00:53)
Man, all that work in three days, all I can imagine is just like a swarm of people, like just moving through the house, knocking everything out. that's, it sounded like pretty extensive work. So to get all of that done in a couple of days, like, mean, I guess they're experts, right? If like people can strip and reroof a house in two days, you know, you might as well be able to redo an AC in three.

Chris Gmyr (01:20)
Yeah, and I think it's going to be like mostly straightforward. Everything in the crawl space is easily accessible. A good portion of the attic is easily accessible except for like over like where the office is and the garage, because I have like a bonus room on top of the garage where the office is. And there's like a small little hallway leading into like one of the bedrooms and like the main section of the upstairs. So within there, like there's not really any sort of accessible.

TJ Miller (01:37)
Mm.

Yeah.

Chris Gmyr (01:49)
or anything else like that. So they're going to have to figure out some way to pull the new stuff through or pull the new old stuff out, get attached to the new stuff like I don't know how they're going to do it, but they said they get it done. So we'll see how that works out. Yep, yep, totally. So yeah, it can be a little crazy week. So I'm going to try and probably keep it a little chill on the weekend and prep for that, make sure everything goes smoothly. So yeah.

TJ Miller (02:03)
Yep, that's on them to figure out, you know?

Chris Gmyr (02:18)
How about you? What's new in your world?

TJ Miller (02:20)
man, wrestling with also joys of homeownership, found out this weekend is I was like rearranging some stuff in the basement that, there's our, our, we have like one of those big chest freezers, like for down here where we store just our like longer term cold storage and like food supplies and surplus. and found out that for some period of time, at least like a week that it's

became like the plug was still in the wall, but it was about three quarters of the way pulled out. So completely defrosted, like it was leaking out onto the floor through the drain. just maybe for context, we've had our sewer backup twice in the basement. And I think this was maybe grosser than dealing with that. Like this was disgusting. like just liquefied ice cream.

Chris Gmyr (03:08)
that's terrible.

TJ Miller (03:12)
and popsicles, there was frozen chicken wings in there. Like it's just, it was nasty. I'm still finishing like deep cleaning it. think I've, I think I've scrubbed it with bleach like two or three times. I'm going in for a fourth cause gave me the willies. and I have no idea how this happened. Like I have no idea how it came like most of the way unplugged, but not completely.

Chris Gmyr (03:29)
Yeah, yeah, I don't want to be messing around with that.

TJ Miller (03:38)
So just by happenstance, I moved something and was like, there's some weird sludge on the ground. And like decided to open it up and like, didn't get blasted in the face by cold air. Started feeling around. like, my gosh, this is room temperature. horrible. and so got that sort of dealt with. I mean, like, we didn't lose anything critical, but, it's all replaceable. So just gonna have to like restock that.

Chris Gmyr (03:53)
Wow.

TJ Miller (04:06)
And then we were rearranging stuff in our laundry room and my wife noticed some drippy sludge on the, like, stuff was wet. And it happened to be around my home lab where I have my internet come in and any of my server stuff, that's all sitting there. Apparently it was being dripped on by a leaky joint. And looking at all the copper plumbing, it was just like, joint.

followed by a joint connected to another joint and all this multi-directional stuff. So nothing can easily be spliced and repaired because it was all just joints and valves in this little knot of piping. So I called out the plumbers and they're coming tomorrow to replace this glob of copper and stuff.

Chris Gmyr (04:59)
man, sounds like a mess.

TJ Miller (05:01)
It's well within the like, my ability to replace copper. Like I've swatted copper before. I really prefer not to, but like I could do it, but I really don't want to. And I want to like, definitely make sure it's done right. So, yeah, I just decided to have the plumbers come out and do it. not looking forward to that, but just, it's just like joys of homeownership, know, like.

unavoidable stuff that'll happen, but I'm glad, look, I'm glad we caught it dripping rather than the joint coming completely undone and just spewing water into my basement all over my servers.

Chris Gmyr (05:40)
Yeah, yeah, destroying all your stuff, like, frying the internet connection coming in, like, who knows what else around there, so.

TJ Miller (05:47)
Yeah, and like, who knows if that could have caused like a house fire or something, right? Like water drip on something, it short out and like spark up my basement. Like, I don't know. So again, glad we caught it when it was a drip, like the freezer. I'm glad we caught it before it got like super rotted out and nasty. So.

It is what it is. Like both situations could have been way worse. And so I'm just, you know, being thankful. It's like, it's that time of year anyways, right? Just, just being thankful for things going the way they did.

Chris Gmyr (06:22)
Yeah, totally. And good thing it's not, you know, a lot worse. And you guys didn't lose a whole bunch of stuff in the freezer too, because that's always my concern. We have an old refrigerator that came with the house that we just moved out into the garage for just, you know, overflow type of thing. And we get butcher box usually about like once or every other month with a whole bunch of frozen meat. So that's like my biggest concern is like

TJ Miller (06:38)
Mm.

Chris Gmyr (06:52)
you know, my son will go out there because we have some cereal that we keep frozen for him just to take out because we kind of buy it in bulk. So he goes out there once in a while. And you leave that door open for a little while. And if no one checks, it's like a bunch of stuff is just going to go bad. So that's one of my big fears is just dethawing some of the food out there.

TJ Miller (07:15)
It makes me want to get like, I'm, it makes me so tempted because with my fridge, I got a newer fridge because ours died earlier this year. And that's got like all wifi alarmed out that, you know, if the door gets left open on either like the freezer or the fridge, like it reminds me of the office. I get, I get woofed. It like starts beeping at me that like my watch goes off, my phone goes off, like, Hey, the fridge door is open.

Makes you want to grab like a Pi Zero and a temperature sensor and just like drop that in there. you know, use like a thin wire so it can like just go through the seal nice and easy, but like put a temperature sensor in there and just give me a warning if it's not cold anymore. I don't know, it's probably excessive, but it'd be a fun project, like a little fun STEM project for me and Alice to do. So maybe.

Chris Gmyr (08:04)
Yeah, totally. And I wonder if like door or window sensors could work too, because I know some of them, you have like one half of the sensor on the door jam and then one on the door that actually moves. So when it's closed and connected, you won't get an alert. But if you leave the door open or the window open or something like that, it'll give you an alert or multiple alerts.

I don't know if you have any other smart devices around. I know you guys have some likewise cameras, but I know Ecobee and Arlo and some of the other big ones have the window and door sensors that probably could be used for that too.

TJ Miller (08:48)
Yeah, it's not so much about the door being open, which we have had that problem before, but it came unplugged. So like, I need to know if it's like warm or cold in there. speaking of Ecobee.

Chris Gmyr (08:59)
Yeah, you need one on the door, like one on, one on the inside, like one on all the things.

TJ Miller (09:04)
Yeah. Speaking of Ecobee, that's right. My thermostat died. got like, it got bricked and stuck in some sort of like restart loop. And we had one of the Google nests. And so like, I guess there was a preexisting issue that like nests can lose their wifi. Like, I don't know what happens. It's just like their wifi stops working. So ours stopped working. So we lost like app access to it, but it still worked as like a regular thermostat. So we left it.

Chris Gmyr (09:25)
That's weird.

TJ Miller (09:31)
But yeah, it bricked and got started in some restart loop. So I had to go out chasing down a new thermostat and decided to switch it up with Ecobee. And gosh, that was a very pleasant install. It's been working great so far. The app's nice. I love that it actually natively works with Apple Home, too, which is kind of the bummer about all the wise stuff I've got is just it doesn't work with Apple Home at all.

Chris Gmyr (09:59)
Yeah.

TJ Miller (09:59)
I think we could do a whole episode about home automation and this kind of stuff. yeah, was another Adventures in Home Ownership, our fancy thermostat. Just took a digger.

Chris Gmyr (10:12)
Yep, we have the two EcoBees. I think they're EcoBee 4s. And we also got three sensors per unit. And then we spread them out across the rooms. And it just helps even out the temperature of the house a lot better. But apparently, with the new HVAC work, they have to install new thermostats. So they're actually putting in new EcoBees because it

goes along with the warranties that they have. They don't want any customized or personal equipment on there. So I'm like, well, as long as it could be for or newer, and it works with the sensors. Because I know they have the regular one, and they have a light one that doesn't have the HomeKit and the voice control, which we don't really use anyways. But I just want to make sure everything's the same or better.

TJ Miller (10:44)
They don't want any like wall do.

Chris Gmyr (11:07)
But sucks that you just bought one because I probably could have sent you these.

TJ Miller (11:11)
Yeah. I mean, it was like, it's getting cold enough here too, that it was, I had to go hunting around for it. The first two places I went didn't have any in stock, even though like the apps said they did. So I had to like hunt around for it because I wasn't going to replace it with another nest. And, and it was like, I don't know, it gets down into like the mid thirties right now. So I had to have like something, but yeah, that was a.

fun little install and still have to like tighten things up because we painted around the old one and now the new plate like the backing plate for it's a different size and got to paint around it again.

Chris Gmyr (11:50)
totally. When I did our installs a couple of years ago, we had one of the, I don't know, just the old Honeywell or something like that, which is a rectangle. And then the Ecobee's are just a little like squarish. And if you put the plate on there, it's just a bigger squarish, but it didn't cover all the rectangular area of like the different color paint. I'm like, well, eventually I'll paint this, but it's

TJ Miller (11:50)
All sorts of fun.

like they're squarish.

Chris Gmyr (12:17)
Like both of them are in this kind of area, and it's like a two-story loft type area in the front of the house. And there's no way that I'm going to paint in there because you need scaffolding and all that. So I'm just like, eh, I'm not going to worry about it.

TJ Miller (12:30)
yeah.

Yeah, I'm going to go in with a like artist paintbrush and see if I can just make it make it happen. Cause really I went from like a rectangle to this one too. And it covers almost everything except like the corners, like the little corners are peeking out. So I'm thinking I could maybe just touch it up without having to do the whole wall again.

Chris Gmyr (12:54)
Yeah, totally.

TJ Miller (12:55)
So looking at some of the topics we wanted to touch on, you had added something about creating a GraphQL SDK. And I'm really interested to hear about this. I've not worked a ton with GraphQL. I've mostly kind of stayed away from it, primarily because it doesn't seem like the most fun thing to work with in PHP. Like I know there's stuff around.

But none of it at the last time I looked into GraphQL was a handful of years ago. And at least at that time, there really wasn't any eloquent tooling. Not necessarily eloquent Laravel, but just nice, concise, feels good, vibey tooling around. So I don't know, man, I'd love to hear a little bit more about just this, I guess.

Chris Gmyr (13:44)
Yeah, and unfortunately it hasn't really gotten much better, at least from what I'm seeing and have researched or even some of the packages that are out there because there's lots of first party and also like Laravel specific packages for craft QL services. like Facebook or Shopify or Google and whatever is out there. But typically the basic SDK has the

client already pre-configured for you, just throw in your keys like anything else. But then when it comes to really anything, so you can query things, so you get data back from the service, or you can mutate things, create or update records. So it's either queries or mutations, and then there's some other things outside of that. But those are the two main mechanisms. And when it calls out to the graph

QL endpoint, it's basically always a post. And then you're sending in like a query or a mutation or some sort of generic data. So it's basically just this blob of text that you have to send over in the simplest terms. So typically what I've seen in a bunch of these packages is you just create a PHP here doc, which is just a long chunk of text, which has

all of your data and queries and stuff like that in there. So the GraphQL queries, at least to get data, it's basically like a function call within text. So if you're getting a user, it would start off with a user and it looks like a function. And then you have an argument for that of like the user ID, right? And then you would have a parentheses and everything that you're requesting from the service.

TJ Miller (15:33)
Mm-hmm.

Chris Gmyr (15:40)
So my user query is calling a user function, passing in an ID for the user, and then I'm requesting like first name, last name, email, phone number, right? So basically like all of that is in a here doc, and then that gets just passed through to the post endpoint and returns that data of whatever you pass through it. So it's variable input and variable output, and you can't really

TJ Miller (16:02)
Eww.

Chris Gmyr (16:09)
always know what you're getting back, especially if this is wrapped around other things or in jobs or services or something like that. usually with REST, or RESTful services, you can create DTOs that map specifically to data. You can use the Laravel data package. You could roll your own DTOs. But it's very easy to say, hey, this endpoint for a user only returns

ID, first name, last name, email, phone number. Boom. You got your DTO. You have maybe nullable properties, you know, on that. And that's fine. You can pass that around in your application and you always know that you have those fields available. You would know some might be null. In the GraphQL world, you don't really always know what was passed through to that and what you're always going to get back. So I've been trying to wrangle this and

see if I could make the querying and also the response like a much better mechanism for engineers to use and make it as layer valley as I can. So I got pretty far with actually like pushing data or requesting data from the API endpoint. So basically like creating a resource class

TJ Miller (17:22)
Yeah.

Chris Gmyr (17:34)
for user, so we'd have a user resource. And that's attached to a string variation of that. So the string is just resource for user, because that's what the user function is going to be called in the query. Then you can pass in as many arguments or whatever you have that you need. And then within this query class,

I ended up creating a custom collection of what I'm calling fragments. And the fragments are the data in the query that I want back. Because these fragments could also be used across multiple resources and multiple queries. So it's a way to get away from the very hard-coded, like, here doc and make these a little bit more reusable in the future. So you can imagine

For a user, I have a first name, last name, email, and phone number, right? But maybe in an order resource, there's also a sub-customer block of data that I want that same information. So I can now reuse that customer fragment within the collection for the query in an order.

Or even like an address or something like that. So I don't have to have like the same fragment or the same hard-coded First name last name email phone number in all these resources So where that leaves me is how do I take? these distilled fragments because it's a collection of Classes which basically each of them to return an array

And how do I generate a DTO from that? Or maybe not like as strict as a fully like referenced and typed DTO, but like utilizing either DocBlocks or generics or some sort of reflection or something like that that I can get like better static typing and IDE compatibility with these.

without going full code generation. Like the last thing that I want to do is like scan this directory for all these queries and resources and things like that and spit out specific DTOs for each one of them. Because this is also going to be heavily used in the application. So I can see lots of different variations and kind of like an explosion of

these like one-off DTOs, which isn't super great. So kind of struggling with like the whole process of wanting to make the GraphQL SDK for not only like the service that we're working with right now, but like could probably use this with like any services and make it a little bit more generic. That it's ideal for the application code, the engineers and you know, more reusable across the board.

TJ Miller (20:14)
Yeah.

Man, what a challenge. Like, I think I would just like swing in the other direction and just try to like make things strict and like just make graph QL, like an implementation detail of something strict. it's like, you define what this like user DTO and like this customer DTO like look like and

you just stop being flexible and you just say, this is what this object is. Here is how it maps to a user, user, customer. Let's just consider those the same thing for sake of argument. That'll have first name, last name, email address. We just remove the dynamicism. Maybe that's a new word. We make them not dynamic anymore.

that just maps straight to a query. So that kind of just maps to how you query for it. And then that's also how that gets returned. And you fill that up when you create these objects. So you would have your order object. then that's only dynamic by adding in a user. And I think you just make that decision of what does an order look like? An order has a user.

has all the order information. And so you just compose what that looks like. It kind of defeats the purpose of GraphQL, I think, but it gives you that.

that strictness I think you're looking for. I don't know if that makes any sense, but like you're kind of treating GraphQL sort of like REST in that case.

Chris Gmyr (22:14)
Yeah, that totally makes sense. Because right now, it's still the beginning stages of actually using this. We're not using it right now. I'm trying to build it out. So I think, generally, your use cases are more or less limited. They're going to expand when you first start using something or start integrating with the service. But it's eventually going to stop or slow down. So it wouldn't be too big of a deal later on to

implement a new query or a new DTO or any sort of thing like that in the future. So like you said, very similar to Rust. And then you can utilize properties either directly on those queries or resources or use like a DocBlock like mixin type of thing or something like that to get the static typing in various places.

Yeah, that might be an option for sure.

TJ Miller (23:12)
It's like your DTOs are strict, but composable, if that makes sense. So you can compose an order of an order DTO, and that order DTO has a user DTO as part of it. And I think this comes back to the same way I talk about building RESTful APIs is you sit down and you define all this stuff first, like spec-driven development, right? You define what these like

at least a decent first pass, like, cause it's going to churn a lot in the beginning. Like you just said, like you do figure out what these like details are going to look like, what an order detail looks like, what a user detail looks like is a user DTO and a customer DTO any different, like, and kind of just like define what those are in like, here's all the properties that make that thing up. And then you can kind of like compose them together of like,

All right, well, this order has a customer, which is just like a user DTO. We compose those together and then like each DTO kind of knows how to like fulfill, like knows how to fill itself. So you can like basically like put all those strings together and like build that query for an order DTO by just like taking the order DTO, converting that to a GraphQL query, and then doing the same with like the user DTO is like for the customer.

I don't know. You're basically creating a strict layer on top of it and then treating it as rest in a way. Because rest, are getting deterministic responses. And so now you're basically doing that through the code layer of, here's what we're getting from this object.

I don't know. Like I said, like that definitely feels like that defeats the purpose of like being able to dynamically query GraphQL, but.

Chris Gmyr (25:08)
It does a little bit, but also how dynamic do you need it realistically, right? Because you're going to have a set amount of use cases for the most part. And you can still, like if you wanted to go like real crazy and go real specific with what you're needing, then yeah, just throw a here doc in there. You don't have any typing, but we would assume that you would know what you're doing with that. And, you know, ideally maybe try and keep that limited.

in the scope of the app. So that might be an idea too.

TJ Miller (25:40)
And I don't think you need to hyper optimize, right? If you're talking about the difference between a customer and a user is two or three fields that are nominal performance-wise to add on, just use the same thing. You don't have to have a user and a customer. And the difference is two or three fields. I think you can get into that where

The difference is like two or three fields, but there is a performance hit. Like you're adding on a whole bunch of additional profile information, like for a user as part of an order query. But, you know, I think you do, that's why you do that, like design stuff up first. Like you kind of spec out what these objects are going to look like, just define what they are. And then that maps to like a single GraphQL query to like.

You kind of have like a query builder as part of this composition. And then you get all the nice like types and everything. I don't know. It's like a little bit of a different approach, but I definitely like the direction of where you're heading to of like creating these reusable fragments. I think that's like really smart.

Chris Gmyr (26:43)
Thanks. I think because what these fragments are right now are just invocable classes and it just returns the array shape of what you want the data to be. So for that customer is just an array of first name, last name, email and phone number. But then you can have almost like an account info fragment. And then that is like a top level.

TJ Miller (26:57)
Mm-hmm.

Chris Gmyr (27:11)
account info and then it has a sub array of you know six month revenue or total orders or you know whatever so you can have like nested data under there but I think the string based arrays are it seems like something that's like holding me back right now I think if I elevate those two properties and then have related

DTOs for each of those. So the customer DTO would just have the first name, last name, email, and phone number as properties, and then maybe make that class arrayable, which would then convert it back to the query array that can be used. And then the account info would just have maybe a collection or something like that of

the number of orders and like total revenue or something like that as their own DTOs. So as all these fragments get merged together, then we'll just have like a mechanism to just grab all these like two array methods and mash that up to equal the query that needs to get passed to the graph endpoint.

TJ Miller (28:28)
Right, you just walk the tree of objects and just start casting everything to arrays. And then that end result, that tree, is what your query looks like.

Chris Gmyr (28:41)
Yeah, yeah. And I think starting at the DTO level and then adding on the two array instead of just trying to work from kind of static arrays, I think that's where I didn't go far enough before. So yeah, I think converting that and seeing how that looks, I think will work out a lot better.

TJ Miller (29:02)
Yeah, think it's tough because, yeah, GraphQL is this very dynamic thing, but we want to add this layer of strictness on top of it. And before we started recording, I remember Chris Morell talking about something at some point on generating GraphQL types, or he was doing something with GraphQL.

And it looks like there was a Laravel linear package that came out of that. And I shared that link with you, and that's something that we can toss in the show notes to you. That might be something to look at for how he's handling it. And the thing that I like is it's using Saloon, which I think we all have a soft spot for. Really cool package. And I think we talk about it a lot in our Telegram group, I feel like.

And so it's using that as a pattern. And there's looking like some interesting stuff in here. So there might be some patterns to extrapolate from this. But it looks like there is a data or schema generation step or something in here that's being done. And I'm not sure what that is or what that looks like. So don't know. It could be interesting.

Chris Gmyr (30:14)
Yeah, my other thought was the code generation. Like you would create these query objects and then you'd have like an artisan command to scan this directory and then, you know, pop out your DTOs and things like that. But I don't know, I wanted that as an absolute last resort because the more tooling and steps that you have for developers, like it's just going to be a much harder process and not as good in my mind. So.

TJ Miller (30:15)
So they'll get.

Sure. Yeah.

Chris Gmyr (30:43)
Like it's definitely an option. I'm just trying not to take that step if I can get away from it. But we'll see how it turns out. Might have to do that because I think a lot of the front end technologies that we're looking at and also integrating with these GraphQL endpoints, they do have like a build step that will generate the TypeScript types and do like a bunch of other things. So everything's.

you know, passing on the front end, but it's a little bit different in the back end and the PHP Laravel space. yeah, definitely have to look into it more. I think we got enough things for me to chew on for at least another week or so. So, a lot.

TJ Miller (31:20)
Yeah. And I mean, I don't know, that doesn't feel good to me either, like mentioning that of like, I wouldn't be querying the GraphQL in both places. Like my personal stance would be any API requests that you're making from the front end are to layer of all endpoints. And then behind that abstraction, like behind the layer of all endpoints are all the GraphQL queries that were like,

treating, however, to get like the strictness out of, I think, querying GraphQL in both places is just like adding complexity. And I think that's, that's something that bit those, like a lot of the front ends there was that there was just like so much like logic happening in the front end and a of logic happening in the backend, a whole bunch of duplicated stuff in between. And that just like, I'm a big fan of as dumb of front ends as you can make and pushing like all the complexity to one spot.

I don't know. Opinions, food for thought, I guess.

Chris Gmyr (32:19)
Yeah, yeah, totally. Definitely something that we can talk about as a team, because there's some different complexities going on in the front end of the project and some different constraints there. So we'll definitely have to see how that works out. But yeah, this is all very new in a different direction with some of these projects. So TBD on a lot of things.

TJ Miller (32:40)
for sure. For sure. Cool, man. You want to talk browsers a little bit?

Chris Gmyr (32:44)
Yeah, let's do it.

TJ Miller (32:46)
so we were talking a little bit before the show and you had mentioned using Arc. I'm a real big fan of Arc. I've been using it since, since it came out, since it was like invite only. Like I've been long time Arc user. because I'm also like a big TMUX and Vim user, I'm all about, you know, apps that can enable hotkey, like keyboard shortcut workflows. and Arc is definitely that. Like I've...

really fallen in love with all the different like, you know, key enablement and then like split views I'm big on. I love having the containered workspaces, you know, like I have like a personal one, work one, you know, I've got one for Prism where I can just kind of like bookmark and pin a bunch of stuff that's like specific to Prism. And then I've got like a social one and like all of those have like

their workspaces and they all have their own cookie containers. So if I go to my personal one and go to Gmail, that's my personal email. Go to my work workspace, go to Gmail, that's my work email. And none of that stuff's logged into social. So social tracking really isn't the thing I have to worry about. So I go to my social tab and logged into Blue Sky, LinkedIn, whatever. And I've loved having that.

And that's been something that's held me back from using really any other browser. And the whole reason this comes up is because I think a few weeks ago, the company that makes Arc had announced that they really kind of considered Arc as a complete product and more or less are putting it in maintenance mode while they work on something else. Like it's not going to be a replacement for Arc, but I guess just like...

I think they build it as like a newer way to browse the web with heavier AI integrations. And ARK does have some pretty decent like AI integration, but it sounds like this is something that they're like going to pursue like heavier AI integration. And so, I don't know, like I love ARK. There's really, there's nothing wrong with it. But I feel like I'd rather be using something that's like

under active development and something I saw rolling across like blue sky and I've been on like Twitter a lot less as of late. But I did see it there too. People talking about Zen browser is kind of a replacement for Arc and they've implemented a lot of similar features. They've got like cookie containers. They're currently like iterating on like workspaces. So like that feels sort of similar.

But it's Firefox based, which is an interesting change to finding out things like Riverside don't work in there. Because of Firefox's preference towards privacy, self-signed cert experience is really not great. And I've experienced some issues trying to develop in that and access local network utilities. So that's been kind of.

a rough play, but overall I've, I've been using it as my main browser for, I don't know, last like week or so. And so far I like it. Like it feels pretty good. Definitely feels a little bit clunky compared to Arc, I said, like something just feels weird about continuing to use something that's been put in maintenance mode. I don't know, man. What are your, what are your thoughts?

Chris Gmyr (36:18)
I really like Arc2. And I think you're the one who sent me the invite way back in the day. And I didn't really jump into it fully initially. I was still using Chrome. And I think I had either multiple profiles or Windows or something like that, because I had personal versus work versus other things on there. And it just seemed like a mess. And not that great. Yeah.

TJ Miller (36:42)
Yeah, they've got like profiles, like you can do different profiles.

Chris Gmyr (36:45)
Yeah, so every day I would have to open up different profiles and make sure I was logged into it. It was just not great. So when fully making the switch to ARC and getting all the bookmarks and stuff like that moved over and sorted out plugins and extensions and stuff like that, it was really nice because you just set up a new profile and I have a whole bunch in the bottom left.

section for personal work, some scout stuff, some house things. And it's just all nice and separated in there and just one program on a window. Because that's what I also noticed about Chrome 2 is that it would spin up so many processes for each of those. And it was just a lot. Yeah, I definitely like Arc. I'm a little sad that it's not going to be

fully maintained in the future, but I don't know. I hope that if there was some sort of issue or something that they're working on with their other project or browser that they would maybe backboard it in here. Because like you said, it has decent enough AI capabilities. I don't know what their new project is going to entail, but I don't know. I'm a little bit more leery on the AI side and wanting to make sure that

I'm still picking, I don't know, the best tool or response or search query or something like that, the browser compared to, I don't know, what something else thinks that I should get. So I don't know. We'll see on the details, but I'll probably be sticking around with Arc for the foreseeable future.

TJ Miller (38:10)
Yeah.

Yeah, that's kind of how I've, I'm still like a toss up whether I go back to Arc or not. I'm really trying to give like Zen browser the college try. And I know they've been putting a lot of like work into like the workspace experience, which is like key to me. Like I have pin tabs per workspace that like, that's kind of like, you know, I hop into that workspace. These are the things that I'm commonly going to go to. And they're making a lot of improvements there.

But I mean, for me, the whole maintenance mode aspect is not so much like churn on new features for the browser, but standards. Standards and functionality across browsers and browser engines is constantly changing. And I'm a little concerned that our going into maintenance modes means that it's going to fall behind on web standards. And that's my biggest concern is like,

not so much like, this browser is not going to get any more features, but like, is it going to fall behind on the like, can I use list? I mean, it's Chromium backed. like, don't, I just like, I don't know what like maintenance mode like means for them. Like is, are you going to be keeping the engine up to date in it? Like if that's the case, then maybe I don't abandon ship. I've also seen that people are, have been experiencing

performance hits and like if you're to get a performance hit in your browser and it's not actively being maintained then like are you just going to be dealing with poor performance because no one's working on improving it.

Chris Gmyr (39:56)
Yeah, that's kind of a death sentence right there if it just slows you down significantly.

TJ Miller (40:00)
Yeah, I haven't experienced that, but I'm, you know, both my personal and work machine are pretty, pretty heavy hitting Mac books. Like they're both M3 pros. you know, it's, I've got more than enough performance to like make a browser work. So like, I haven't really experienced a difference, but, I have heard like, especially on windows, people have been noticing like a recent ish performance hit.

And that's not going to get addressed if it's in maintenance mode, probably, I guess. So to know. We'll see. I'll report back. I'm going to give this, like, Zen probably another two week go as my default browser, and then probably make a decision. I still haven't migrated all of my bookmarks even.

just kind of seeing how it feels and what kind of road bumps I bump into. But their roadmap looks good and every update has, I've seen like definitely noticeable improvements in like the functionality. So.

Chris Gmyr (41:03)
Nice, yeah, let us know how it goes. And we'll also keep an eye on any sort of ARC updates. I feel like there wasn't one too long ago, like last week or something like that. So maybe it's the engine updates, like you said, because that's what I was thinking too. Like they probably push engine updates behind the scenes and be up to date with that. But I know, I have to keep an eye on it.

TJ Miller (41:27)
Yeah. I meant, well, looks like we're pretty close on time. You want to call it at that? Cool. Thank you so much for listening to another episode of the slightly caffeinated podcast show notes and all of the links that we talk about, you know, in our social channels and everything will be able to be found at slightly caffeinated.fm. Yeah. Thanks y'all for listening this week. We'll catch you next week.

Chris Gmyr (41:32)
Yeah, let's wrap up.

Thank you.