Welcome to the Drunken UX Podcast, everybody. This is episode number 94, and we’ve got three different things that we pulled from the web that we’re gonna be talking about with you tonight. We’re gonna be looking at different types of technical debt, some opinions on what we should be doing about sliders on web pages, and taking a look at some funky browser features folks. I am your host, Michael Fienen.

And if you’re enjoying the Drunken UX Podcast, be sure to check out our very kind sponsors over at the live@Manning conference series. APIs right now are the backbone of modern interconnected software systems. You can join them at the API Live at manning conference and ensure your APIs. Are flexible functional, end user friendly.

If you want to register for the API conference, it is August 3rd, which if you’re listening to this on release day that is tomorrow. But those tickets are free and you can go get one by going to drunkenux.com/apiconf. That’s drunkenux.com/apiconf.

Conference.

No it’s not an abbreviation. Let’s see. Uh I am trying to cool off a little bit this evening with a I have a glass that you pour your water into and then you shove a silicone mold into it and you freeze the whole glass. Uh Yeah. Uh and it gives you like this wedge of ice, uh this angled wedge of ice in it. So I’m drinking from that this evening with some gentlemen jacket.

Yeah, I kind of started melting already, but yeah, no, I haven’t used it in quite a while and I thought I’m going to get that out because it’s cold enough to hurt your hands when you’re holding it. But yeah, gentlemen, Jack, I’m running starting to run low on this bottle. So I figured let’s let’s see what I can do damage wise to it for this episode, although I am not finishing it because I do not want to die. Okay,

That the Orange one.

heart. Okay. Um, sure. I like to feel like I’m back in college sometimes too. So I mean I can’t, I can’t blame you. So we get three topics we’re going to tackle this evening. I have fun with these and went out and dug up some articles. This first article comes from Nicholas carrier. Um and I apologize if my french is not up to standard on that. Um this is from his blog post over at bite size theories dot com where he’s talking about three kinds of technical debt. You talked about

Yeah, back in episode 38. We did a whole episode on technical debt and what it is and how it can build up and what you can do about it. Um and it’s, it’s a topic that I think is nice to kind of revisit once in a while, maybe not as a whole episode, but you know, there’s a little part of this one because I did like the way he broke down sort of the theory because we didn’t do that, not to my recollection, but he kind of buck.

It’d technical debt in a way that I thought was kind of a useful way of thinking about it because depending on the type of uh you know, web professional, you are developer designer devops, type person, technical debt can take on different forms and those have trade offs, you know some of them are easier than others, some of them are more costly than others.

And so I thought let’s take a second look at what he talked about and see kind of you know what nomenclature we might add to, you know the breakdown that he has.

you can

Yeah, it’s yeah, I like the financial comparison to it because yeah, there’s good debt and there’s bad debt and the bad debt is the stuff that will really bury you and pull you down and hurt you. But part of good finances is simply debt management. You know, the richest people on the planet all have their own amount of debt and in different ways and and how they do it like you say, your house is a good example of that.

Houses are generally considered good debt for a number of reasons. Uh Whereas credit cards are typically considered bad debt. Their high interest, you have to pay them constantly and it’s easy to not pay them off because you’re making minimum payments on them and things like that. So this is something to think about.

The first bucket that he calls out is the most obvious one, which is code, technical debt weight. People

they put technical debt in code.

invited in in many cases,

It’s code debt is like a vampire. Once you’ve invited it in the damages, you know, he calls it though the cheapest form of technical debt because it’s it’s the easiest of the three that he calls out. He considers it the easiest to pay down fixing code. Technical debt is just a matter of changing the code.

Fuck,

So stick, stick that one on on the bulletin board. This idea of data modeling because that’s going to come back up in just a second.

Yeah, so,

No, you you’re absolutely right. And I think, you know, if any of these, we’re going to be able to sit here and carve out exceptions, you know? Yes, there are ways to make really expensive, bad decisions with code. Yes, they are going to be really cheap ways to do the other things and, and easy fixes I think, you know, looking at as a general, you know, a very broad generalization of the category and he does qualify a little.

I say one of the reasons code can be easier to deal with is because you can change your approach to the code on the fly and the example he gives is if you’ve got a lot of code technical debt, then if you take on a test driven development methodology to approach that, you can make it easier and cheaper to pay down that code debt. Okay, I would agree with that.

You start wrapping the work you’re doing in these tests and it lets you start isolating and compartmentalizing places where the bad code is and you can use those tests as the framework to winnow it down um, to management parts.

This the second bucket is architecture debt. This is a big one I think and probably the most expensive of the technical debts I think because when you start thinking about architecture and a lot of folks may never have to deal with the actual architecture that runs their stuff. But if you are an army of one or a freelance developer or you know like you and I, you know, we run our own little servers for personal projects and and things like that.

I run, you know, a server that hosts drunken U. X. And and this kind of stuff. You can make decisions about how you prop that stuff up. So for instance, let’s say you’re building a new application and you’re going to host it in AWS and you have a choice, I can just spin up an ec two instance. Okay.

And say, you know what now, I have a server, I can install exactly what I need on it, I can, you know, tailor it to how much memory and CPU I need in storage or I could contain arise it running with kubernetes or doctor or something like that and abstract away some of that easy to gives me a very powerful solution. It gives me a lot of flexibility and a year later I have 64 different patches. I need to apply to packages because I haven’t been logging into it.

Um I forgot to start failed band. So it’s been getting hammered by Russian hackers for you know, the last eight months and I didn’t realize it. Uh my logging server crashed on it and hasn’t been keeping any logs or working at all. Like the maintenance side of that begins to rear its head and you’re like crap.

I just wanted to build my application, I could have gone to harajuku and just split it up there and not have to think about is my operating system patched, what version of PHP am I on? Like those challenges begin to add up and they themselves start to create debt inside of the way you’re hosting whatever resources you have. I agree with that, You know, one, I think a bellwether for this. Do you have architecture technical debt?

one of the ways I think you can answer that question is and this is kind of specific, but if you’re building an application and in order to update that application you have to schedule downtime, then you have architecture technical debt. Sure. I mean that’s I think a measure of that. If you have built a good sort of robust supportive architecture, you can either swing set stuff, you can update in place.

You can, you know, pause services without taking down an entire application, things like that. But if you have to hard stop stuff and schedule a six hour maintenance window where nothing is accessible, you have architecture technical debt.

I think there’s a variation on that too, which is how many single points of failure do you have? You’re always gonna find some weird random single point of failure unless you’re somebody like netflix or amazon who has, you know, thousands of servers running across the country, most people are going to have single points of failure somewhere in their infrastructure.

yeah, so uh those single points of failure, your goal and it’s just like any debt, your goal isn’t necessarily to eliminate all your single points of failure, but you should know how many there are. Uh you know, is it a service and a p I that you are relying on that if that api goes down, your system does not fail elegantly. Um is it, you know, a load balancer? You have one load balancer? This, this is always a fun thing, right?

Well I have redundant servers behind the load balancer and then you say, well how many load balancers do you have it? And like I just have the one think about that for a second. You just

You still need something to tell the traffic which load balancer to go to it. So it’s like, yeah, you end up, you can force get around all of that with you know, some 53 stuff and things like this, but most people, like I said, we’ll have a single point of failure somewhere in their chain. Um and so that’s a good way to kind of measure your vulnerability to that.

The other thing to think about is out of all of these talking about like what kind of debt is the cheapest is sort of an abstract discussion. Except with architecture where bad architecture, technical debt can incur real debt on the business side of things. Because it’s easy, it is so easy to spend a lot more money on cloud services and things like that parochial gets expensive

wow, amazon gets real expensive real fast if you’re running like full size ec. Two instances if you have badly optimized um I a s infrastructure as a service. If you are farming out whether that’s the AWS or heroic or Digital Ocean or is your any of these places if you have not optimized your infrastructure, your cloud infrastructure, you could be spending as a company.

We’re talking tens of thousands of dollars that you don’t need to because you’re paying for a high memory instance of something that Doesn’t pass 30 consumption or something like that. Like there’s just a lot of ways that that infrastructure can give you actual debt that you need to look at and then changing it can then be problematic depending on how it’s set up. This move towards what we call um infrastructure as code. Right,

Chef Chef Chef is one. Yeah. Yeah, terrible, isn’t it? Mm pair forms out there uh care forms go, I think chef is ruby um puppet is ruby. I may be wrong. Um The other issue last on my list for architecture is just that architecture debt can hide very real issues on you that you don’t realize if your infrastructure is not logging stuff properly and alerting you on things and you don’t have no GOs or Prometheus or any of these application monitoring appdynamics, something like that.

If your application is throwing 500 errors 1000 times a second to users because of a mis configuration and you aren’t getting those that can really hurt you. Like that can hide all kinds of issues because emails aren’t getting to you and alerts aren’t getting to you. Um, and performance, you know, it may be something as simple as a page that should load in 70 milliseconds is taking 700 milliseconds because of a memory mis configuration.

Um, anybody who’s ever tried to performance tune Apache um, something I have unfortunately gotten my hands into a few times, trying to like really tune a low memory, low CPU Apache instance to be performant, man, it’s hard and if you don’t know what you’re doing, it’s real easy to have those servers slug like really drive along. Um The third bucket is data and modeling. So you mentioned this, he broke it out into its own thing.

The idea of data and modeling. Um This is like the idea and my example is a real world example. We built an application that had a database back in uh and we spent a week going back and forth trying to think about how we wanted to model this data and what would make the most sense. At the time we settled on dynamodb dynamo is a, what they call a no sequel solution.

Okay, basically one giant table with a bunch of columns and you, you build, uh, indexes on it based on different combinations of, of columns and that worked great until it didn’t. But our problem was the decision making we made at the start was changed by changing requirements. Okay. And instead of going ahead and going with a relational database, like my sequel or post Grace or anything else, um, we decided to build for what we thought was going to be the limit.

When the specs started changing and the need started changing, it became more and more difficult to modify data. Um, it became more and more difficult to change data and the issue we just ran into, which was entirely Michael’s fault. Michael did not deploy a production release a few months ago. And so the question came in about, hey, how do we get into the state? And I’m like, well, should just be there.

And I went and looked and none of the data was there. And I’m like, what’s going on? Well, Michael didn’t release the production code. And so we went back to our logs. So remember when I said architecture debt, are we had logging in place that stored all the raw submits. So we were able to go back through the data and extract all all of these submissions from the logs to find the lost data. And it

Oh yeah, no, it’s, it’s bad. So we’re going through it and we’re looking at, okay, so now we need to update the existing records with this data to insert the stuff that wasn’t being saved. And it’s a nightmare with dynamodb because of the way indexing and it works. And the fact that you can’t just, it’s not like a normal relational database where you can just throw query at it and it’s happy to give you back whatever matches the query dynamo doesn’t work that way.

Um and so our failure to anticipate that and there’s going to be uh we’re going to talk about something here in just a second that will help explain this, our failure to sort of anticipate that incur debt for us. Um and that goes for custom post types in WordPress. You know, you’re building a custom post type and thinking about what fields you need. Your data modeling doesn’t necessarily have to be like strict database, you know.

O.M.L. you know, things like that. Um this can be simple stuff. What does my structured content look like, you know, what information do I need in order to spit out these things on the front end and what starts as good ideas and good decision making can still lead to debt unintentionally. Um It’s just something that can happen

So when we switched from Maya’s quell to Postgres, I think there was maybe like one or two things we had to change because they were like some manual SQL queries. We had written their little complicated. Um but for the most part the entire app was like it was like a half a day migration to go from one to the other and most of that was just getting the data itself migrated from one database engine to the other.

There are two other types of debt that I think should be called out. Um one is designed that and the other is content that because I think those are things

so design debt can be incurred by like the use of patterns that leak into each other or that overlap without properly overlapping. So this gets into pattern library stuff and design system kind of work UX UI or areas where um one of my favorites is like talking about spacing on things and figuring out like, well I put top and bottom margins on these but they’re included with other things that have top and bottom margining.

Now these things are all fighting me and I have to figure out how to go in and rationalize them because the way I’m using box sizing, you know, is causing them to be additive instead of combining like design can leak and drift. You get designed drift on things over time and going back and trying to fix those after the fact or retrofitting can be very difficult and time consuming rather than building something from the ground up to be correct.

Um so where I see this happening is in areas like, you know, when you do a redesign, are you retrofitting design or are you actually re articulating your html? You know?

Well, and and one way that you incur that dead in those things too is being indecisive about them, right, grabbing foundation and using it halfway, but then also mixing it with some bend the methodology or something like that, you know, or somebody changes right. Another dev comes in and starts working on stuff and maybe you don’t do code review. And it turns out they’ve been writing CSS in a completely different methodology.

You can call that code technical debt, but I really feel it specifically designed technical debt,

Um, I’ll end on this. It’s a little bit of uh, thinking from martin Fowler, he had this uh, tech debt quadrant that he shared. The two columns are reckless and prudent and the two rows are deliberate and inadvertent.

And so this can kind of help you define where you’re, you know, when we talk about good or bad technical debt, we were talking earlier, it’s like if you have a prudent, deliberate technical debt that is significantly better than reckless inadvertent technical debt.

So he’s got examples in here like reckless inadvertent. You know, his example is what’s layering like building stuff and you just don’t know what you’re doing, right? So you just slap it together without any thinking for what makes sense. Architecturally your good, you know what good reckless inadvertent is. I’m just going to store these api keys right in my javascript file.

not storing keys in a secure way is pretty reckless and and if you don’t know, you know, if you simply don’t know better, that makes it inadvertent. You know, if you’re a new dev and you don’t think about key stores and things like that reckless inadvertent. Um okay, so

So prudent and deliberate is saying this is an ugly function, But this is a showstopper bug that’s going to take me three days to fix, right? But I can get a patch out right now that gets my service back up and I think,

Yeah, so that’s a little look into some different technet, thinking um go check out the article at their website and be sure to put some thought into how your technical that may be sneaking up on you.

over at Speaky Boy Mr eric carr kovac who I have a lot of respect for and uh I I am actually kind of um I feel like I almost need to have like a show with just all his stuff because I have quoted his article so many times over at Spec E Boy, he’s put up an article where he’s written about. Is it time for web designers to retire the slider? Um Now if you listened to me before and I was looking I thought we did an episode on this and I guess we had

not not very tiny hamburgers. Um this can be a carousel, like an image carousel or a content carousel, um a panel rotator. Uh And in my eyes, this takes many forms. For instance, the the tab um slider or the content Taber that can be on in the hero section of a page. Anything that basically is designed to Present multiple pieces of information inside of one container. It’s like a rotating billboard, rotating anything.

Yeah, yeah, rotating like led billboard going down the highway, things like that. Um My hatred for caress cells is matched only by my hatred for chatbots. That’s not a joke. Like I legitimately I have fought fights to keep sliders off of web pages. Um and I’ve given talks on like I have gone through conferences and presented on the fact that actually get rid of centerpieces.

Yeah. Uh, and in eric’s defense, he does make that note in the article. He does talk about how it is often not the designer’s choice to implement these things. It usually does come from elsewhere. There’s a separate article by joe Rinaldi over at Impact Plus.

Um, he’s, he has the comment that it’s an easy solution for telling competing departments within an organization that their messaging is on the website, which is another way of saying exactly what you just said, like, oh, they, they’re so important. They want to be on the homepage fine. You’re on the homepage

and you may not have the social capital to do it. Um you know, one of the, one of the things about those fights is capitulating on a feature like this is often done because you would have to burn a lot of social capital to fight it. But then that capital is gone for you now, now people don’t like you now, you’re the person who says no to things. And so when you have three more items on your list, that would have been better and easier to win.

Now they aren’t um it’s It’s a content problem. It’s an understanding problem. In 2021, you know, people still ask for them to be implemented on pages. Uh huh.

But in the real world, sliders represent performance problems. They represent accessibility problems they cause bloat on your page, especially if they are implemented badly or poorly. You know, you’re talking about sliders, I’ve seen sliders that load, not just all the content of every slide when the page loads, but they re download it. They don’t cash it.

You’ve seen this with me, we’ve covered this news episode and the episode about news sites where we found one of the news sites had had one of those rotator and it was repeatedly downloading the stuff over and over and over again.

It’s also a a problem with code bloat because in our, you know, speed to capitulate and just say fine, we’ll throw it up there but we’re going to do it as easy as possible.

I’m gonna, well it’s technical debt. Yeah, you’re absolutely right. It’s also something that I’m gonna go grab a library because it’s going to take me twice as long to write one from scratch and you’re just doing a vanilla jazz.

But the library I grab is going to be 75 kilobytes Of which I am touching eight kB of that code because the library is accounting for all these educates is all these different configuration settings, all these different approaches and uses, which is great for the plug ins builder. But As a result I’m loading 75 kB or the code. I don’t need.

Oh God, forget the java script. Let’s talk about CSS on that now.

So we’ve got a couple articles will be in the show notes on this from different places. My favorite is simply should I use a carousel dot com because it’s going to have all kinds of information in it. It also has all the data. When Aaron says things like people don’t click through paris cells that’s supported by research. Like A lot of research and it’s, it’s definitive.

Like it’s not maybe the drop off from the first slide to the second slide is like 93% or something like that. The

I don’t know what you’re talking about.

it always says no. That’s the joke. Oh, okay. I’m like, I thought you were talking about like, it actually like did something like, no, I’m not the way that works. I’m with you.

I’m there with you.

last article comes to you from the kind folks over at everybody’s favorite CSS site, CSS tricks. Um, this is from Ferrari Candia. The article is web features that may not work as you’d expect. This is kind of cool because it tackles and we’re only going to talk about a few of the items that are brought up in it, but there are several that are mentioned through it beyond this. So do go check that out and see the other things.

But this is kind of a look into things the browser does and, and features that are available that don’t necessarily do what you think they would under normal circumstances. And I thought that was kind of neat. And there were a couple examples that I even went, oh, I didn’t know that. And so there’s probably a little something here for everybody to learn.

And it’s one of those like figuring out idiosyncrasies, you know, we spent a lot of years figuring out like the difference between how I E nine would render something versus Netscape versus you know, firefox and Safari.

So, you know, that process has certainly gotten much, much better over the years, but that doesn’t mean that idiosyncrasies have gone away and in some cases and and with these a lot of these features, it’s often just a case of hey, the thing you’re doing doesn’t work how you would think because you’re used to it other ways um the first one being visited, colon-visited, so Aaron, what? We were just talking right about CSS specificity.

What is colon visited? Is it is it a pseudo element or a pseudo class?

Yes, because it defines state

it is single colon. So, so Colin visited the reason this does not work the way you would expect. There is a javascript function you can call on elements called get computed style, that will give you information on the way in element looks like this can be really useful for distilling out, like what settings are on something or if you’re, you know, if you’re changing the way something looks based on, you know, the state of something a user is doing in your application.

It’s a good way to pull it out and say, you know, is it visible? You know, is it bold it or is it, you know, is the alert highlighted? But with Colin visited get computed style does not work. And that is intentional, like it doesn’t work for a reason.

yeah. Why? Why would that be

Yes.

So imagine you’re running a more nefarious site and you wanted to know are the users using facebook and twitter and linkedin and google and things like that. You can make a whole block of links that you position you know absolutely negative 9999 pixels off the side and then use some javascript to get computed style and see if they’re showing the visited style and you can start collecting data about where people have gone

every direction you gotta go up negative 10,000 pixels down. It’s it’s a whole thing. Yeah. Yeah. So this goes back to about 11 years ago the CSS history lead um and there’s an article over at Mozilla that I’ll have links in the show notes that breaks this down. But basically come back to this idea that people started using the visited pseudo class as a means of breaking down where people had gone.

And so browsers collectively locked down get computed style against that specific pseudo class so it will never return, it returns null, I believe it doesn’t return anything. Um And so generally speaking, yeah, no the that one case just happened and I don’t, you know, it’s not necessarily that everybody’s out there. Like boy I really want to know what the visited state is on these links.

But it’s just a case of here’s something you would just expect to work and if you didn’t know why it wasn’t working for you it would be a pain in the butt to probably figure it out.

Well, let’s fold this into the next thing because the next one is about cross domain asset cashing. Okay, so going back to uh a few years back, right? Um remember when google released their javascript cd in?

right? Google had their Cdn set up and they had everything right, not just jake where you pull prototype, you could pull hell they had like mu tools and things like that still in there. Like you could pull anything you wanted to out of this. So the

that’s the intent and like web fonts were set up kind of the same way you can use google fonts to do that. And likewise, the other side of that though is also just the strict performance aspect, which was google C d s are super fast and your server probably was fast but not as fast. So there was a secondary benefit there.

But yeah, the cashing thing we all used to sit around and be like, well just use yeah, the google Cdn J query because then if they’ve been to, you know, popular site X and popular site X is also using it that I’ve saved them that download. That’s not true

You still get the speed

Yes. So there is no such thing as cross domain asset cashing

even from a Cdn for. So what

So the why behind it is actually for an almost identical reason to why colon visited doesn’t return a computed style because you can through javascript api s tell if ba files are being loaded from cache and use that to exploit people’s browsing history. Uh Yeah. And so for the pretty much the same reason now the approach is certainly different, but the rationale is basically the same. It’s a security and privacy concern.

because they could just

You need to think about it a little more fourth dimensionally. Okay. I’m not gonna do it with something as broad and basic as J query. I’m going to do something like load the sites.

A very specific sites javascript from them on my site to see if you’ve been to their site. Let’s say I’m a let’s say I’m widget company X and I don’t know if you have been going to widget company a well I’ll load widget company a’s, you know, CSS or something and when I see that loaded from cache, I know you’ve been there and maybe I will exploit that in some way, shape or form.

it’s easier to explain from a methodology standpoint. I think using that general thing, but you have to think about like if I want to be nefarious, how would I exploit that? And that’s how people exploited it.

right now. Cashing does work. You go back to the site, it will load from cash, but it just doesn’t cash cost domain like you you are, you are limited to what are called groups and we’ll talk about that in the section. Um, groups in storage, sort of compartmentalize all the side, you know, make silos for all this stuff. So yeah, one of those, yeah, not not going to give you the benefit. You think it does. Uh loading. This is a fun one.

So another topic we’ve covered this lazy loading, right? How and how to you know, get a little more performance out of your imagery and things like that loading is an html attribute you can put on things like images that will tell the browser to lazy load that image until you know it’s viewed. Uh Some people prior to this would use techniques that leveraged what’s called the intersection. Observer. A. P. I. A very cool. A. P. I. A very useful A. P. I.

That can tell you where on a page somebody is and can tell you if something is coming into view or out of you. So folks would say, well when an image that isn’t loaded is within 10 pixels of you know the intersection, then go ahead and load that image then. Mhm. That’s very cool. Except that there are two things about it. one is loading unless you are doing something with it. Outside of the realm of normal behavior loading does not work.

If the user has scripting disabled and

Right? Because here’s the thing people like to say, oh you don’t need to use javascript anymore in order to use lazy loading. Right? It’s kind of true, but it’s not really true. It’s true that you don’t have to write any javascript, but it is not true that you don’t need it

again, this comes back to a a privacy and a tracking issue because you can use the loading of images as a way of tracking a user.

Uh interestingly enough so

security security relations and so is the last one for what it sort of. Uh But yeah so if somebody has disabled scripting in their brows are you know using security settings, lazy loading won’t work. The other thing about lazy loading that was interesting to me the loading attribute you can’t poly fill it. Okay hold on

I can’t disagree with you.

Mhm. Um So you can’t powerful. Okay so what

So you can’t write javascript. So if you are using a browser and older browser that doesn’t support loading. So let’s let’s use the more classic example like ie 11 right? Ie 11 doesn’t support loading. Um And you want to write a piece of javascript that will do the same work. You know this is frequent for things like browser A. P. I. S.

Right? When when we didn’t have local storage, people would do things like write a poly fill that would mimic local storage using cookies or something like that.

you can write a poly fil for it, you can do it like you could write the code and the code would work sort of. The problem you run into is basically a race condition. The problem is in the time it takes your polypill to load and be useful. The images will have likely already loaded on the page.

like you would have to do something else on top of like the old solutions or things like instead of using a source on an image tag, you might use something like data source and you would swap those. But if you’re using like a vanilla approach, image source and then the loading attribute.

If the browser doesn’t support the loading attribute, it’s just going to load the image like normal and your polypill simply isn’t going to react fast enough to prevent that. So yeah, like I said, yeah, funny. Like it’s just kind of I hadn’t thought about it, but it makes sense. Our last little little thing doesn’t work the way you might think is web storage persistency. A lot of people think web storage and we’re talking about like local storage, right?

Local storage lasts until people clear their cache. Okay. By convention. Yeah, that’s mostly true. But it’s not. There are two exceptions to this one is the big one is Safari. Safari actually has a seven day limit on local storage. Okay. So After seven days, Safari just says, Nope, this is gone. Mhm. That’s just something I think a lot of people aren’t used to and aren’t necessarily considering.

Um Now obviously you can re up that you know people keep coming back to a side or something, but if somebody doesn’t come to your site for a week, you should not assume that that local storage is still there. Um Yeah, there is something else too because I said by convention, most browsers Let you store stuff and they have huge data caps, like local storage can take up depending on the browser, up to 50% of available storage.

So if you’ve got a 500 gig drive it can store 250 gigs in local storage if it’s allowed. Um Now there is a limit per group usually. And I I used that word earlier when we were talking about cross domain stuff. Right? Groups. A group is basically a domain. Okay. So you’ve got what is usually like a two gig limit per group. So it’s like a half your storage in total, determined by up to two gigs per group. And that that cap varies I think chrome is one gig.

Um It just depends. But if things start filling up the browser will just start the leading stuff and it uses what’s called an L Ru policy at least recently used. So the oldest stuff basically starts getting thrown away and it will just do that to make room. There is however, a persistent storage ap you can use to say, hey, this stuff should be protected, it shouldn’t get thrown away.

Um, and so we’ll have a link uh to, you know, where that works and how that storage, A P I and the permissions work. It’s a browser permission thing. You do have to ask for it. It does cause of pop up and all of that. But web storage persistency is kind of a funky little thing because local storage does not have an expiration built into it like a cookie does. So the browser handles it a little differently.

And Safari being the odd boy just says seven days we’re going to be different from everybody. Seven days it’s gone.

Uh huh. So go take out check out the article. There’s a few more things in there that we didn’t bring up, but I thought these would be some of the more interesting ones to folks were doing web development. Go look at those, it’s over at CSS tricks and we’ll have it all in the show notes.

folks, I hope you enjoyed the different topics from this evening. It’s I I enjoy kind of taking a break sometimes and just kind of running through a few different things just to dress it up and and change things up. Let us know any topics that are on your mind or things you think should uh come up in a future episode, you can connect with us on any of the social media that twitter or facebook at slash drunken you X.

Or instagram at slash drunken you X podcast and as always hit us up in our chat room, we have a discord server at drunken uX dot com slash discord. If anybody is interested to keep your ears to the wall because we have some pretty killer guests lined up. We’re gonna be talking about stuff like web vitals, we’re gonna be talking about content strategy for developers, we’re gonna be talking about something else that may be wordpress related and theme related.

Uh I’m not going to spoil all of it right now, but let’s just say we’ve got some pretty awesome folks in the pipeline so be on the lookout, we’ll announce some stuff coming up on on social media about those things.

Get subscribed if you’re not already hit the like button, leave us a review. It really helps us out because it’s important to us that when we are interacting with you and riding up these shows and coming up with these ideas that we keep our personas close, but our users closer. Bye bye.