These Things Make Your App Feel Like Crap on Mobile

Your mobile apps might feel like crap, and we're gonna tell you what are the main things that make a mobile app feel worse than a native mobile app? All of our pet peeves, all of the things that web developers could be doing better to improve their web apps on mobile. My name is Scott Tolinski. I'm a developer from Denver. With me, as always, is Wes Bos. What's up, Wes? Hey. I I'm excited to talk about this because, like,

I was talking to some people from actually, from Google, and they're just like, like, why are everyone is still so hung up on, like, native being better? And there's some clear things like access to APIs and and whatnot. But I think, like, there's a lot of the reason why people like a mobile app better is simply just because it doesn't feel janky. And I I watch my kids use websites sometimes, and it's just like, oh my gosh. What have we done? You know? They're clicking the wrong thing. They're three d touching everything. They're they're highlighting text by accident. It's just it's a nightmare. And these things are all fixable if you if you know what you're doing. So that's what we're gonna talk about today.

That's right. And a lot of these things can be fixed with Sentry. This episode is presented by Sentry at sentry.io/syntax.

I know you get two months for free. Use the coupon code tasty treat, all lowercase, all one word. But Sentry is really cool for a lot of these things like, rage click detection. Man, if you click a button a whole bunch of times, Sentry will alert you that, hey. Your users are rage clicking this button, and that's usually for a number of reasons. Your app is nonresponsive.

Your app isn't,

showing the user what it's doing. It's not making the button disabled while it's doing something. There's a number of reasons as Wes. Do you know the difference between a dead click and a rage click, Scott? Tell me. Little trivia? School me. Speak on that. So a rage click is what you just expect explain. Right? People clicking over and over and over again. And a dead click is when somebody clicks something and there is no nothing happens after there's a certain threshold. I think it's, like, two hundred fifty milliseconds.

So if there's no, like, UI that has has updated or there's no network detection, network detection, that has has been fired off, you know, there's you can't tell that something happened. That's that's called a dead click. So either, literally, nothing happened or you have like like, we're talking about today, your UI sucks, and and you need to know that something's going on. And and maybe you don't have things wired up properly or your UI is is lacking.

And the coolest part about all this, you get access to a session replay, which shows the user trying to interact with your thing.

So, man, that is so handy instead of just getting an error saying, alright. The user rage clicked or the user did this or that. You could see why or visually what's going on. And, man, it's one of the most useful tools there is in debugging. So check it out at century.io.

Let's get into it, Wes. You have the first one here, which is zooming inputs.

Yeah. This this has been around for so long, and it still drives me nuts on website. And that is if you have an input and you click on that input or you tap on that input to go ahead and type, what the browser will do is it will zoom it up, for you. And then when you close the keyboard because you're done typing, it doesn't zoom it back. So now all of a sudden, you're in this, like, slightly zoomed version of a website.

You've got horizontal and vertical scroll, and it just things are cut off, and it just doesn't feel good. It's a very easy problem to solve. All you need to do is set your inputs to 16 pixels or larger, and the browser simply will not scale those on up. So please please do this. A lot of people have this problem is because 16 pixels is too large on the desktop when they're designing it. Right? You they they put it to, like, 12 or 13.

That's crazy. Yeah. So what you can do is just just throw a little media query in there that will detect, you know, you could do, like, like, a width and height media query, or you can look for a device pixel ratio, whatever media query you need to be able to detect that this is a mobile device,

and then simply just select all of your inputs and say, font size 16 p x. 16 pixels isn't too large. Man, 16 pixels is old Scott. Base. No. That is the standard. No. That is it, man. I I don't like it. 16 pixels is the default, right, on browser. That's what I'm saying. That's insane.

Yeah. I'd be dead. Come on. Yeah. Come on. Who's setting it to 14 or 12? Like, Node. Thanks. I I I don't have bad vision. I can see things, but I never I don't even need like, I usually have everything set to be pretty high Vercel density and stuff like that on all my stuff.

But text, text 16 pixels tracks. Yep. That tracks. Things

should not move when I input it unless you're moving the input so that it's not hidden under the keyboard, which is another one of my, pet peeves. You know? It just that doesn't happen on mobile, and it's so frustrating when it when it sorry. It doesn't happen on native very often, and it happens so often to me Wes you you focus an input. And now you have, like, what, 30 pixels of screen, and you gotta, like, you gotta scroll the the website up so you can see what you're typing. Come on. I gotta say,

before we get into a lot of these, the best way to find a lot of these things is to just use your stupid app on on your phone. Use your app on your phone. Use your app on, your mom's phone. Use your app on other people's phones. Just use it because so many of these things, I think, are just attention to detail,

that that people just aren't aren't aren't trying. Totally. People are just resizing the browser till it's small enough and then say it looks good, ship it. Yeah. And they're not actually using it on a real device. And when you're building a a native app, the only way to test that is on an actual either a native device emulator or an actual device.

Totally.

Next one here is horizontal scrolling. Now let me tell you. Horizontal scrolling JS a trackpad primarily user I've been using just the trackpad on my desktop for a long time.

I hate horizontal scroll bars in my sites, in my apps, mobile or otherwise.

Like, when I develop things, I'm, like, never it's it's a it's a blockage of mine because I know there's there's mouse users out there. I personally have just, like, gotten so used to swiping on everything that, like, I never want a horizontal scroll bar in anything. So for me, having horizontal scrolling, feel snappy using scroll snap, these types of things, and not having a stinking scroll bar. Horizontal scrolling to me is is so natural, especially on native apps. Every single app you use has native scrolling in some sort of way, horizontal scrolling. And you can get that,

Like you said, scroll snap, overflow scroll. Horizontal scrolling is not necessarily bad. It's great for things where you you wanna, like, hide maybe, like, a list of tags. You wanna see more. You can scroll them over. It's when you're causing the entire body element

to have a horizontal scroll. Like, an overflow

I'm I'm having that it's almost always accidental horizontal Scott. And then when you're scrolling the website up and down, you're accidentally going side to Node. That drives me nuts. And I've had it on my own website many times because it's, like, the most pain in the butt thing to debug. Like, what the hell is actually causing It's obnoxious.

Scroll. Scroll. Pardon? Yeah. It's obnoxious It is.

To to debug. And so JS a solution to that just to make an an app window, like wrapper that fills the entire thing and puts overflow

hidden on everything? Like Overflow x hitting. Yeah. You like, you don't Yeah.

Want to do that because there are use cases where you want to allow your user to scroll, and now you've you've broken your website. Right? But there's so many use cases where just some random thing, you know, a German name or whatever. We had it on the web on the Syntax website maybe about a year ago or just, like, we had long links that were causing horizontal Scott, and we had it apply some weird CSS thing to make the links break and wrap onto the next line. Pain in the butt, but Yep. You gotta make sure you gotta make sure there's no horizontal scroll on on your websites because it's On the on yeah. Don't let the site itself It feels j overflow the the window. Yeah. For sure.

Proper use of pointer events Node and user select none. So this is this is another one where on native apps and this is probably a bit of a hot take because Yeah. On native apps, they restrict you from doing things a lot more and to a point where it's very frustrating. You ever try to copy text out of a comment on Facebook? Oh. It's it's impossible. You can't do it. You know? Like, it's just like drives me nuts. Drives me nuts. It's a little better now that you can just, like, screenshot and select it, but you shouldn't have to do that. Pain. Yeah. But on the other side of things, if I watch my kids try to use a website, the amount of times they're accidentally double tapping things or or or accidentally selecting text or doing that three d press or whatever or, like, causing some horizontal scroll because they they zoomed it in by accident. Native apps disable all of that stuff by default, and users opt in. Whereas in browser land, that stuff's just all enabled by default, and a lot of people don't spend the time to actually fix it. And that's why these websites feel kinda kinda janky.

So turning it off, I understand that this is this is a hot take, and I think a lot of there's a huge accessibility thing here as well as, like, you should be able to let everybody select text on it. Mhmm. But how the hell are all these mobile apps getting away with it, disabling it all? And and their apps feel so much better than the browser app, so come on. You you gotta be able to disable pointer events or disable selecting text on case by case. Don't just blanket do that because that's annoying on websites. ESLint a lot of cases, you wanna be able to do that. But think about There are some things that, yeah, you certainly don't need to select. I I was designing,

little chips, UI chips, and there's never a situation where your users are gonna wanna select that text and copy it. There it doesn't doesn't make sense. Right? It's not body text. It's it's nothing that, like, would be useful to get, like, a list of all that stuff. So, yeah, you can throw a user select none on that, and then that then you avoid that situation where that becomes selectable.

Mhmm. If it has a link in it, I think that that's probably the case that drives me the most nuts JS when you can't select a link and copy that link from an app. And I think a lot of that is intentional because they want you to click it and you open it in your in app browser.

Yeah. It's all a lot of these things, like you've mentioned, can absolutely be, accessibility Tolinski, like this one, allowing Zoom on everything. When you put this in here, I was like, let me go through my native apps list and see if I can pinch to Zoom the UI on any of them, and not a single one of them. Not a single one. And you know what? Nobody's crying about accessibility on those.

So, like, why? Because you have the ability to size up the UI from within the OS. Yes. That sizes up the UI. And guess what you could do on the web? You can do that on the web. People knew it. Yeah. For the longest time,

I probably have said this many times in my career JS don't disable zooming. There's, like, a little meta tag that you can put user you can set the min and max zoom size on the thing. In in a lot of cases, yeah, you wanna be able to zoom in on a website, especially, like, there's, like, a photo and you wanna zoom it up. However, there are like, if you're trying to give somebody an app like interface and you zoom that up and you have, like, a fixed header and now everything is weird and you have a map, and and you can't zoom out because now you're scrolling the map out.

Pain in the butt. So Yeah. The one thing we don't have in CSS is, like, wouldn't it be nice to simply just say, like, image zoom true or something like that? Or you could just allow zooming on things. Like, oh, yeah. Somebody would probably wanna be able to zoom this image, or somebody would like to do to zoom something here.

And that would be be really nice. We don't really have that. If you wanna, like, reimplement if you disable zooming and you wanna reimplement it, like, oh, just on on images, you know, someone can pinch and zoom in, you get then you're in JavaScript and and touch events and touch end, and that's a whole JavaScript heart world.

I'm sure there's there's utilities out there for it. But Maybe that's not that bad. Maybe that's not a maybe that time maybe maybe that's not something you gotta worry about. I'd like, I this is not one that I I had on my radar as being a a problem. It's not a problem in native land, so why are we so concerned about it? And then I went to every native app, and I was like Yeah. And and you know what? It doesn't bug me. I've never tried to zoom in on a native app ever.

The ones that you you might, like

that's, like, baked into the dang app. So Yeah. Like like on images, I guess, you you click on an image, and it it it opens it up in a Node, and then you can Skyboxer. Yeah. You can you can zoom that. Right? It's true. I'm trying to look at all of my apps now.

Lightbox.

None of them.

None of them have been built in. And I've never tried. The only time wrong. So, man, I, yeah, I I I think that that is such a thing when you zoom in on a website and then now the UI, you're you're zooming out. You pinch in, then it goes to the tab view. Especially, like, I, yeah, I can I can handle it? But, like, I I I've learned so much about UI

by simply just giving phones to my kids and to, like, like, older parents and and things like that. Here? How do I get zoomed in? Now I'm all zoomed in. Yeah. Oh Wes, what did I do? Oh. Oh. Yeah. You know? Just doing stuff. Yeah. Oh, man. It drives me like, I was building that sticker printer where the kids would press the button, speak into it, and then let go, and my kids could not do it. They were just, like, double tapping it, and then and then when they double tapped it, it it sent a request off. So then I had to, like, add a check to see if they if it was shorter than two seconds.

And, like, I was just like, oh my gosh. It's so painful.

I've never been a, I don't know if you've been a part of you, like, a focus group or anything like that. We ran user testing, and I've talked about this on the show before, at Ford. And maybe it would have been better to give the UI to a bunch of kids because the adults were not helpful at all. They were like, this UI doesn't have the Mustang. I would expect it to have the Mustang. And you're like, that's not what we're asking about. Like, we're we want you to use it and tell us how it feels. But there's no Mustang. And this guy was, like, so hung up on it. He he would, like, bogarted the entire conversation just to to talk about the stupid Mustang not being in the demo. Yeah. Sorry, sir. We would have liked to know if you could click the buttons better. I'll often do that. When I'm I learned this from Ben as well. When he is checking out a new app, somebody's like, hey. Can you check out my app? I get DMs all the time. I'll often throw on my screen recorder

and, like, show myself interfacing with the app for the first time and just, like, talking through it. Like, oh. Yeah. What do I do now? Where do I click? Because, like, that info is so key to somebody who's building a product and actually knows where all the pieces are.

Yeah. I I think that's super helpful. And sometimes people can get really dismissive about that. Like, okay. You're just not using it right. But, like, that's holding it wrong. Yeah. Yeah. That's that's where all the the stuff that there's there's friction there for a reason. I consider myself to be the type of person who, prides themselves on being able to identify those types of things Sanity, like those, like, pain points. Because I I mister Magoo through life just, like, stumbling over every pain point and then getting through it and then being like, oh, okay. That's how you do do it. Yeah. So I would if there are sharp edges, physical or digital, I will run into them. That is for dang certain.

Next one here is jank, and jank can feel like it's usually just a frame rate issue. You're scrolling, and the thing just doesn't feel smooth. The number one comment you get about web apps is that they don't feel as smooth as native apps. Buttery. Yeah. And there's nothing in the web platform that's making your app not smooth. It's it's usually a number of things. It's, sometimes bad CSS. Sometimes it's JavaScript. Sometimes you got watchers. You got memory that's that's doing stuff. Mhmm. The browser has a built in FPS meter. You can see

the FPS. You you you go to inspect element. Yeah. If you open up dev tools and you hit command shift p, that will open up your command palette. I never use the command palette. Oh, man. And then just type FPS, show the frames per second meter. But then there's also, like like, highlight rendering, like, divs that render. And if you've got, like, a, like, a animation in the background of a layer, you you'll see it. It's flashing red because it's it's updating often.

And sometimes you can figure out how to put those in separate layers so that you're not getting like, you're not rerendering absolutely everything. You're just rerendering what needs to be done. And, honestly, some yeah. There's a number of things there that could be an issue. Sometimes it's a use effect that, you didn't notice that was,

firing. Silently bankrupting you? Yeah. I mean, there's all kinds of things. For me, I had a I had a a transition on a man, what did I have a transition on? I had a transition on a background color, but I had enough of the elements that it was tanking my FPS. And that's like a technique that if you had it on one button, a transition on a background color, that's no big deal. You got a thousand buttons on the screen. A transition on the background color just tanks your FPS. And it took me a long time to figure that out. I shouldn't have it shouldn't take me that long, and I just changed it to be an opacity thing. I did the color with, after pseudo element and did an opacity. That fixed the performance issue. But, like, a lot of the times, it's just not the care taken to dive into, alright, what is the FPS? And I I have 60 FPS here as the target. You don't have to have 60 FPS on everything, but, like, you should be striving to get that number as high as possible. We have high refresh screens these days, and they feel nice.

So One thing I learned from Matthew Pnpm, he's the dev behind motion.dev Yeah.

For what we call Framer Motion. And one thing he said that really stuck with me is that it's not about having a high frames per second. It's about having consistent Mhmm. Frames per second. Meaning that, like, it's fine if it's if it's 20 frames a second. Just make sure that it's always 20 set because because what happens Wes if we've got 60 frames a second video and then we drop two or three frames, people notice it right away because it's it's jarring to the eye to go up from one to another. But if we released it at 24 frames a second, Hollywood movies are released at that, and it's it's fine. Nobody's like, this is very low frame rate. You know?

Movies on the, vaulted silver screen of Hollywood are at 24 frames per second.

Full page refresh. This is is such a simple one. There are so many, I don't know, frameworks. There's nothing wrong with fast HTML. But if you've got pretty heavy pages, you're going from one to another, most frameworks will allow you. It's it in fact, it's very hard using a framework now like SvelteKit or any React framework

that when you click a link, it doesn't actually change the page. It's usually just a push state. Yeah. And and you know what? Even, like, web purists who wanna do everything on the server side and don't want any client side rendering and stuff like that. The the one of the big issues too is not having, like, the proper color scheme set up. And then so if you have, like, a dark screen and you change pages and it does a full page refresh, you would get, like, a white screen for, like, half a second if the color mode color scheme JS incorrect and things like that. Like, those things are just gonna make it feel ugly. And that and, you know, I I think for some reason, I think client side rendering gets, I don't know, poo pooed for some reason, but client side rendering rules, and it is one of the things that's going to make your app feel more native. And, like, I don't that's not necessarily, like, a client versus server thing as well. Like, my my personal website, westboss.com,

fast as heck. It's a 100% server server rendered, but it's still using Node client side. Hydrate. Yeah. Yeah. Go check it out. Changes?

There's there's no client side rendering on page changes?

No. That's what happens is that you click a Tolinski. It goes to the server for that markup.

Markup comes back, and then the the client side JavaScript simply just replaces the content that has changed on the page.

It's not getting a full new HTML page.

It's not. No. It's just it's getting the React Vercel components knows which pieces of that page need to need to be updated. Yeah. Well, I'm talking about, like, a full HTML page coming in. Yeah. Yeah. Like like, if you're going from one page to another, likely, your header, your nav, and your footer are going to stay the same. Right? Yeah. And you go to the next page. And even if even if it did have a full, HTML page change, you can still get that nice experience. You just wait for the HTML to be returned from the server, and then you transition that thing over. So you don't have that, like, weird blank screen in between while you're waiting for the request to come back.

Yeah. Well, then your your server response has to be very fast, which network dependent and all kinds of stuff. Yeah. Well, like, what? You're you're either sending your data back,

right, like, via JSON, or you're sending rendered HTML back. Or pre yeah. You're preloading. You're you're doing those types of things to to ease that pain. I don't think it necessarily matters which format it's coming back in, whether it's coming back in JSON and you're Mhmm. You're throwing that in in client side rendering it, or you're just getting HTML from the server and replacing it. Weren't you, like, mister HTMLX for the longest time? You're you're

head over heels for it. I was mister HTMLX for, I would say, about Three days? About about three days. Yes. The reason why, I I because I I got at the same time and even before then, I was getting really into local data caching.

And it's just like, they're that they're so incompatible, those two approaches.

But, also, you you could do in HTMLOS client side routing with it, and it's not client side routing, but you're hitting it, and it's only replacing it's like AppShell. Right? It's only replacing the talking about here. That's exactly what I'm saying is a problem is replacing the entire HTML document and not doing the AppShell stuff. That stuff's fine. Even whether that data JS coming from the server or the client, doesn't matter. Yeah. Yeah. Oh, good. Good. Well, we're on the same page then.

Wes, did you see that comment? Someone was like, these two better resolve their differences, or or else I feel like they might split up in 2026.

This is like, we've never disagreed on anything ever. We have, one little spat about

what was it even about? Forms? Forms. TandStack forms. Scott couldn't understand the use for TandStack form, and then SpellKit comes out with the same thing.

And he's thinking, no. It's the best thing ever. I guess so. Podcast is over. I'm done because you you're misrepresenting my point so severely.

It's not even the same point. And, yeah, and you did a voice for me. That's not even what I sound like. I have a lower voice. I have a boomy voice. Let's talk about slow loading times. That's a big one. Loading screens. That that is like man, there's apps that are native apps that you can tell are so

clearly, like, web apps wrapped just based on the loading screens and the way way you feel with that. And the fact that they, like, arrest the entire UI. They'll throw a the you can't do anything while you're waiting. You know? Just sit here and let me show you this little plane that that flies across while we load in your data. That's

so frustrating. Who is it? OptumRx.

I feel like OptumRx.

Man, they OptumRx is like a medication company. They had a fine app. It was just like a totally fine app. Whatever the hell they did. Holy cow, man. The AppNow JS, like, takes each Wes, like, takes seconds. And if you go from one page back to the same page back to the same page, it does that full request with, like, no cache. I just clicked the link. So Dude.

Go to optumrx.com and just click on any link, and it does the, like it does, like, two or three redirects.

Air Canada does this as Wes. And then the loader restarts every time, so it, like, jitters.

Who whoever they and this app used to be totally fine.

And the native app is the exact same way. And what's crazy is that they also screwed up their data platform because they, like, they started, like, sending out medications incorrectly and stuff or or, like, certain medications weren't showing up. So I went on their customer support. They're like, yeah. Our new system is having some issues where it's, like, unsubscribing you from your medications and changing the dates. And it's like, I had an issue the other day with it where it Wes, like it was in it was currently December, and it was like, you have one refill. Next refill available November 2025 or whatever, but it wouldn't let you do it because it was saying, your refill is not available, like, to be filled yet.

It it's not available to be filled until and it was a time in the past. I'm just like, oh, their engineering team is cooked. I I don't, like, don't know what something must have happened where they're on the powered or It's some sort of online. CRM all the way down. You know, it's running on some Java

barracuda server in someone's basement, and, like, there's no possible way they can build a Yeah. A modern web app in that experience.

It it was a redesign redesigned so badly that I'm like, I would rather go to CVS, drive to the store, and pick up my medication than keep any of my stuff on this any longer. It's infuriating.

But either way, slow loading times, loading screens, all that stuff. One of the reasons why native apps feel really fast with some of this stuff is, a lot of these, local first, but not necessarily local first as a term, strategies, whether that is local data caching, having data stored. Like, a lot of native apps use SQLite databases stored on your device to do a lot of the stuff, and then they do processing in the background. So either they're downloading data in the background to populate that database so when you click things, things load fast.

So local data caching is a big one. Tansack DB is a good option for that if you're if you're in that ecosystem or even even not or any sort of local data or even just, like, hard caching stuff in general. If if the stuff is cached on your device, it's gonna be so much faster. Like like that OptumRx thing where it's, like, fetching the same data and it's still doing a full hit, like, that that's awful. Another one of these two is, like, non instant data mutations.

Like, when I click something, I I don't care.

Like, it should feel like something happened. Your app should respond to it. So optimistic UI is a strategy for that Wes your UI is responding as if it was successful, and then you can backtrack if it wasn't. But, like, having the thing happen when you click the button is one of the reasons why so many native apps feel so Node. Because, typically, they're just storing things in a SQLite database or doing a sync offline. Even if you don't like the offline

stuff, I I tweeted something about how offline first and and optimistic is so good. And a lot of people are like like, local first is not it. And I was like, even if you don't like the local first stuff, at least understand that you should optimistically render out some of your UI or at least show me a spinner, something that's happening. I'm just going through this OptumRx website, see what it's built in. It's, it's the funny thing is it's using the latest React.

It's using React Router. It's using the suspense.

Bro, I could have told you that it was React. So much. And this is not me being a hater on React. I just know that whenever they launched the redesign, it had it had React written all over it. You could just feel it. Sometimes, you can feel what a Wes I can feel an Angular website. When an when a website

you start typing in it and it validates immediately, like, what like, you're typing your email address and you type w, and it's like, that's not a valid email address. And I'm like, I'm not done yet. I I can smell that for a 100 miles away. That's an Angular website.

Oh, yeah. Yeah. It's it's crazy. Yeah. I have dude, I'm on a I'm on a page right now. This JS, like, this is almost comical how bad this site is now. I just logged in in the normal login, and it took me to a page that has no navigation.

And it says zero claims, no claims found. You have zero claims this Yarn, and then it has no other navigation on this page. This is the main app login. And then the, the the page title is, I kid you not, forward slash secure forward slash,

turn claim history. Like, they didn't have a a proper page title on this page. I just logged in to the app. Proper they don't even have a page title. What's going on here, Optum? Alright. This Scott, this website that you've you've gifted to us has provided so many examples. I'm gonna share my screen right now because the next one we have here is what's called CLS, cumulative layout shift. And and this is when a page loads and then something loads and and causes the page to to move in some account. And and very, very commonly, this is like an image loads and pushes your content down, or the page loads and you realize this person hasn't bought something. Let's throw a banner over the top, and it pushes it down. You know? Like, those are Oh, yeah. Those are common things where the page loads and then something else happens or some CSS Node. Something is caused to cause a a a repaint that causes the the the content to be pushed down or whatever. In this website, because it is client side rendered entirely as Scott's favorite way No. It's not. There's no way. There's something oh my god. This is doing double CLS.

So hydration is what it is. It's the We have this hydration.

When I click on a link, there's this home breadcrumb, and then it says member resources.

So what's happening is there's nothing there initially. Oh, yeah. And then the home pops up probably because they check client side what page they're on, and then the member resources pops up at at some other ESLint. And you get this just little dance, And this makes websites feel like crap.

Oh. Oh, mad. This this episode is making me mad. This episode is making me mad. Let me tell you. Yeah. OptumRx, I'm glad I get to share this with you because I've I've been so angry at this app and the website for so long now. Look at this. Boom. Boom.

Oh, the further login page further login page. What do you need on the login page that, like, needs you to oh, do you Brianna? Click it.

One, two, three, four renders.

And and let me tell you, the native app the the native app is clearly just the same thing, but put into a native app. And it didn't used to be bad. It used to be fine. It used to be, like, totally usable.

Like and it's it's all this stuff is fixable.

Right?

This this site might not be fixable. You might need to, you know, burn this.

You might need to burn it to the ground.

Another little another little treat I just saw is that the font of the the word loading changes after a second.

I don't know if you can see it or not, but those are the things that, like, I'm if if I can notice it, then it's really bad. But a lot of stuff, you just don't know why. There's a little and why do these websites Yeah. Yeah. Feel so good,

and you might not even realize why it is. I feel the worst for the people the customer service people who work there who have to deal with all these people being like, what the hell Bos going on with your website? It sucks. Alright. Off of Optimax because I'm gonna I'm gonna lose my mind if I keep talking about this site. The address bar on mobile, especially on, like, Safari, address bars have been, like, pushed to the bottom.

There's, like, a weird, like, touch area where you can't click too close to it. You have to be cognizant of things towards the bottom of your site. We got viewport units a while ago, and viewport units were, like, the the ish. Everybody should be using viewport units. But we needed new ones because of how mobile browsers actually end up end up being. Because if you use 100 VH and the URL bar is visible, then that 100 VH isn't actually 100 VH. It actually pushes down. It doesn't actually fill the entire viewport.

So that's why we have the, DVH, which is, I believe, dynamic. Is that what it stands for? Yeah. In the d There's Yeah. There's

LVH, SVH, so large and small, meaning that, like, When it's available and when it's not. Yeah. When it's available and and when these these address bars and, like, buttons pop up. And then DVH is is just a a fluid value that will adjust given how much space is available if the address bar and things are are visible. And, honestly, this is probably one of the biggest contributors to jank, not deviate viewport Sanity, but the fact that this address bar and the buttons pop in and out of the app as you're scrolling all the time, that doesn't happen on on native apps, and it's so frustrating that it does happen. If you add an app to your home screen JS, like, a PWA,

it feels a 100 times better. Yeah. This is definitely one that, like, and I I'll put this same thing in the category of if you have, like, a mobile navigation and it's too close to the bottom Wes you have that bottom view the bottom toolbar, you won't be able to click on it. So you might get, like, people trying to click on it. So you need a little bit of padding there. So not necessarily tightly related, but, like, another thing that I've encountered where there's a button visible, you go to click it, and nothing happens, so you have to scroll down and then click it. So just something to be cognizant about that, again, could be solved just by using your thing. Scott, I'm pleased to report that OptumRx

disabled zooming on their website, and it Oh, thank goodness. They don't have the horizontal scroll issues, and they don't have the accidental zooming in, which is good because there's probably a lot of elderly people using this app, and they will accidentally zoom in with when they put oh, I didn't realize I had two fingers on the screen. So we'll give them points for that.

Points points issued.

I'll take it. Yes. I'll take anything.

I although I am stoked that I I've moved all of my medications off of it, so I never have to open that app Oh, good. Ever again. Yes. Last one we have here is is full width scroll traps. And

probably one of the most frustrating things on the mobile web is using an embedded map. If you've ever tried to use a Google Map that has been embedded into a website, it's extremely frustrating because you try to scroll down, and then your your finger this used to be where your finger would catch the map, and now all of a sudden you're scrolling the map and you're not scrolling the website. So they changed that now to you have to use two fingers to pan around a map on the web, which is not what anything else uses, and it's it's really frustrating to use that as well.

And then you try to zoom in the map, but if you do it too far, then you accidentally zoom in the page, and it's just you end up with this, like, weird space where you're zoomed into the map too much, but you're also zoomed into Mhmm. The the website, and it's just very, very frustrating. So if you are embedding something that could possibly be a scroll trap, maps being the biggest one, certainly give a little bit more attention to whether or not if it works. You know? Try it. Mhmm. I think the the biggest thing we can say from this entire episode JS, like, try your websites, folks. I think some of you are not trying your websites.

Yeah.

I know. Yeah. That is such a a thing. I I remember this JS this is not a problem that you see as much anymore. But back in the day, we used to get, like, PSD comps.

Especially like me, I was working at agencies, so I'd get a lot of, like, PSD comps before we had Sketch, and people weren't really using Illustrator for some reason, because you didn't have vector based websites anyways. But you'd get a PSD comp, and one developer would implement it exactly. And another developer, you'd look at their work, and you'd be like, did you even open this thing up in a browser? Did you even compare the two? They used to call it, like, pixel perfect design. And, like, I just never understood how you couldn't see the difference there. And, likewise, I don't understand how you're not using your stuff. I dog food everything that I'm making all the time. Now that doesn't mean there aren't bugs.

I'm sure people could find all kinds of stuff on the Syntax site that are just bugs I haven't gotten to yet. But, like, if I'm building something that I want to feel like an app, man, I I'm I'm using it twenty four seven. Like, my my Habit Path app is my habit tracker that I built for myself, and I'm using it all the time. And there's things about the UI that I hate, that I wanna change, but I am still understanding, like, what its pitfalls are and just from using it. Use your stuff.

And use Sentry to help you fix some of these bugs and and stuff that, people might be encountering. You might learn something.

Let us know your frustrations. Leave them down in the comments below. I'd love to hear them. Please.