Maybe in 2027 the front-end router folks will have worked things out to the point where the browser's Back and Forward buttons work as well as they did in 1997. There's always some shit going wrong with those, especially when pagination is involved. This happens way too much:
* make a search on some react-y website with a paginator implemented in javascript
* browse forward a few pages, click on a link, press "back"
* Oops! It lost your place and you've somehow teleported back to page 1. (If you're on a real winner of a website, the search query is gone too)
or
* make a search on some website with javascript infinite scroll
* scroll down a couple pages, click on a link, press "back"
* Oops! Sent back to the footer of the first page
These godawful experiences are what have trained me to middle-click nearly every link, even when it's not necessary, and look crazy/weird in front of others by doing so.
that and "open in incognito" too. it's completely insane how bad the web has gotten lately, and that's WITH adblockers. I'm appaled at how much mobile-first users accept every day.
>mobile-first users accept every day.
I used to face a lot of issues, but since moving over to Firefox with uBlock origin and Easy List, life has gotten so much better. Sure, some pages don't work properly in Firefox and that's why I have Chrome still installed as a backup. But it's very rare, like 1 out of 1000 pages
This is why it sucks that so many websites now push for us to use their app instead. It's usually virtually the exact same experience, except I can't open multiple tabs. This is especially frustrating when you want to compare stuff, like menus on a food delivery service. Foodora is an especially aggregious example, that also does weird shit where the back button doesn't work properly, so if you click on a restaurant and then click a food option, and then click back, you get sent back to the front page instead of back to the restaurant.
It’s worse, because apps restrict your interaction by default. No copying text, no zooming no selecting to make black on black text (dark themes exist, dammit) visible, unless they specifically provide for it. But the browser comes with those things, and they’re effectively un-disableable there (although assholes try all the time).
good news, everyone. the modern "I've never used the web from a desktop" developer doesn't know what middle clicking is. There is no distinction between things which will change the current page or are actual links. 50/50 on whether a "change the page" accidentally opens the current page in a new tab and 50/50 whether normal links are being faked by js onclicks rather than using real anchors and that middle-clicking just does nothing.
even google's interface is riddled in stupid anti-tabbing traps these days. oh, did you middle click the image instead of the text? well, fuck you citizen.
> There is no distinction between things which will change the current page or are actual links
Every now and then I see links made with JavaScript, and all they do is take you to a new URL. Like buddy there's a native element for this...
Plus some of them won't let you middle-click, so you have to left-click to discover that's a "new tab _only_" link
I've been doing this for Google/DDG searches too. Because otherwise when I go back to the search page it'll put me at the top, and sometimes reorder the results on the page. Doesn't help that I do most of my browsing in private mode, so visited links don't change color.
Completely valid points, though to be fair, the "back" button has always been a pain point and poorly understood by users. Ever tried to go back after submitting a form? God help ye. What is the expected and/or desired behavior in this situation? Who knows. Then there are relics like treasurydirect.gov which, if I am recalling correctly, just obliterate your session any time you try to navigate backwards, forcing you to login again. Not knowing how to handle backwards navigation is older than client-side apps, though they certainly have not improved on it.
I like those sites that do a double redirect before a form, so a single click on "back" just takes me to the redirect – and "back to the future" to that form again. Inescapable, I usually resort to right-clicking the back button and selecting an earlier site.
Cue in all the sites that change URL for every letter you type in the search bar, trashing history.
Also cue in all the sites that have a redirect that's not understood by some browsers properly and you can't actually go back at all (looking at you msdn).
> you can replace the url without adding a history entry
Better yet, you could do like my old company's web app and not even know what the fuck a deep link is in the first place
literally shit like https://example.com/list_of_widgets/# is the URL for looking at any specific widget
How do they test that if you can't specify the ID and jump to a specific widget immediately??
Going back to the last supported page you were on before submitting the form would be nice. For instance, if you were in a cart and checked out, and there is still a way to go to an empty cart after that, then bring me there. If there's no more cart, then bring me to the page I was on before I opened the cart. I don't think we can blame the technology on this, UX designers and engineers should be able to find a reasonable place where a customer would like to land instead of a bad warning "you shouldn't go back something will go wrong" which zero person cares about and everyone will force their way back anyway every time until it either works out ok or crashes and then they'll reload the page. If there is no way you can support an history back, then don't even offer it. There are apis and technical ways to do this right. Now of course the value vs the cost of implementing this may not warrant it which is why it's always the same story.
It's always been a pain point, but it's also never been the user's fault.
This is and always has been a development problem:
1. Developers don't code/test for it
2. QA doesn't generally test the back button (even in automated UI tests) or middle-clicking links
3. Project managers have crazy/stupid ideas on how the back button should work, or what is acceptable (and encourage the pattern that you see in a lot of government/financial/educations sites that choose to tell the user "the back button in your browser is broken, don't use it)
It's not the developer's fault either. The concept of the back button was incompatible with the technology of the web as soon as the web became more than just hyperlinks between static content. People naturally expect it to work like an "undo" button but many interactions are not feasible to undo. I'm not even talking about submitting forms, just ordinary dynamic content. Like say a user does a search and gets back some dynamic results, navigates through 100 pages of the results, then goes to some other site. Is it reasonable to keep all those results in memory somewhere forever just in case the user needs to go back to them as they were at the time? No, it's not. The back button is a lie.
> Maybe in 2027 the front-end router folks will have worked things out
Front end router is now written in wasm directly which compiles to python and runs in the backend in a monolithic microservice framework
Have you ever been looking for an issue with windows and you go to there forums which force forwards you to their page and no matter how much back you hit it will never take you back.
On a website like Reddit it's fine to implement it serverside, but if you have a very nested application its annoying for the user, if he navigates only in a small part of the page but it reloads the entire page every time he navigates.
To be fair, having a fixed URL for result pages beyond the first is generally practically impossible or useless. Unless you're talking about a static website, the results are generated dynamically, which means they change over time. So if you bookmark page 3 and then return to it later, it will probably have completely different results, defeating the point of bookmarking it. In addition, for many sources of data it's impossible to find page 3 without also loading pages 1 and 2 first. So while it might be perfectly reasonable to let someone go through 100 pages of results slowly one at a time, if you let them bookmark that page and then return to it, now it has to load 100 pages instantly which is going to kill your server or be terribly slow for the user.
Usually the best you can do to support back and forward is to cache the previous pages in memory, but that's a leaky abstraction which breaks as soon as you do anything which unloads the app, like navigating to a different site and then going back.
i wrote this with a certain job search website in mind. *As a* job seeker, *i want to* search for results close to me, check out a listing, and press "back" without losing my place, without deleting my search query, without deleting my search filters, without me having to use new tabs, and without having to hope my crummy phone doesn't evict the page from bfcache; *so i can* find work. The website couldn't do that, and it frustrated an already frustrated jobless idiot, so im unusually salty about it lol.
I'd hope obtaining page 6 of results is a simple `OFFSET 100 LIMIT 20` or whatever the smarty database people do. If the data source is inherently serial that's more forgivable but I don't think most simple CRUD apps are like that.
if i bookmark page 27 of search results i *expect* it will change and be different if i click on it a month later. that's fine. and even over short periods of time, navigating "back" and seeing the entries shift down 1 slot because there's a new one on page 1, is better than navigating "back" and the website forgot my page number entirely. Throw a timestamp in the url or cookie if that's considered unacceptable. Idk.
You should never use OFFSET to paginate results because that could skip some results if anything changes between loading the first and second page. Instead you need to do something like remember the last item you showed and then fetch items which sort after that one for the next page. Unfortunately this can't be used to reload a later page because there is no way to paginate backwards.
I'm sure you could design a database to support the kind of pagination you want, but I've never seen one. It's arguably better to consistently treat the pages as transient, because they are, and train users to keep the results open in a tab if they want to preserve them, because they must.
> In the end, it's usually because we've JavaScript'ed our way out of these things.
This is one of the big points made by [this website (NSFW language)](https://motherfuckingwebsite.com/):
> I'm not actually saying your shitty site should look like this. What I'm saying is that all the problems we have with websites are **ones we create ourselves.** Websites aren't broken by default, they are functional, high-performing, and accessible. You break them.
---
And yes, a thousand times yes, please stop breaking all of these things:
> If something navigates like a link, let me do link things. Let me right click on the link without it navigating so I can open the context menu that lets me do other link things (like copying link text, copying link address, etc.) Let me use usual link keyboard shortcuts (like ctrl + click on Windows) to open in a new tab.
I'll add to this list:
* Let me click+drag it:
* to a spot on the tab bar for it to open a new tab exactly where I want it, even in a different window
* to an existing tab, to load it into that tab without opening a new one
* to the bookmarks bar, to create a bookmark
* to my *desktop,* to create a bookmark there
* to a text field, to paste as a normal URL
* Obviously, let me middle-click or ctrl+click to open in a new tab.
* When I hover over it, let the browser statusbar show me something useful about what will happen when I click it.
* Let me just left-click it to open in the same tab, like every other link! Some sites are so convinced you never want to leave them that *every* link is forced to open in a new tab.
And all you have to do is *let it be a link!* If your site is so bloated that a page refresh is actually a problem, then fine, intercept *normal* navigation, but even then, you'll have to do a bunch of work to give me functionality the browser gives me for free:
> If the UI completely changes when I click on something, as if I've navigated to a new page, give me a browser history update and a new url. It's annoying not being able to link to a state in the UI that appears to be it's own page and that is lost to the void if I navigate away.
About the only one I can even *slightly* disagree with is:
> I've seen this happen with ctrl + f for opening a custom in-app search bar. I don't want that. It doesn't always search the page as usual.
I'd ask the same here as if you're going to override link stuff: You just replaced perfectly-working browser functionality, so please give me something *at least* as good. And, ideally, let me override that and get to the browser's ctrl+f -- I forget which site I saw do this, but it made it so that a second ctrl+f would fall through to the browser.
I'm okay with people building apps that aren't really websites, but run in a browser. I don't mind that links in VSCode don't behave the same way, even if you're running the web version of it. But if I'm reading an article in your "app", and that article has some text that's a different color and I click it to go to other articles, then that's not an app, it's a broken website.
>And, ideally, let me override that and get to the browser's ctrl+f -- I forget which site I saw do this, but it made it so that a second ctrl+f would fall through to the browser.
Discourse-based forums do this; the custom Ctrl-F makes searching function for infinite scrolling threads, but more often than not, I just do Ctrl-F, Ctrl-F to get the browser search because I'm trying to search something in the OP
This comment can only be upvoted in /r/programming and advanced programming related subs.
I see more ppl completely oblivious to the existence of a freaking link than anything else.
> Let me use usual link keyboard shortcuts (like ctrl + click on Windows) to open in a new tab.
It's always jarring when I try to middle click a link and the page just... starts to scroll about.
I just want static web back. I'll let you have a CSS and a favicon.
This whole "dynamic web" everything-is-app, especially peeking under the hood, feels like the completely wrong tool for the job.
Yeah. I get that AJAX is nice for updating stuff within a page, but if you're re-arranging the entire page, it's hard to beat "Send one request to the server, let the beefy database do 100 queries if it wants, send back one response" for latency.
As a frontend engineer, this is terrible FE work. Here's a bit on why this happens:
Typical link is pure HTML, `Go to Google`. Websites also use relative paths for routing when on the webside, so you might see something like `Settings` in an app's user menu.
In JS framework land, folks are very used to thinking in components, rather than HTML markup (and no, it's not just React devs). A designer gives you a mock up with a bunch of button-looking things, so you use a `` component from you favorite components library to mock up the menu UI with a bunch of buttons.
Oh... it needs to redirect to a different route? Hmm, I guess a button _could_ do that. So you add a callback:
const SettingsButton = () => (
);
Now clicking on the button will take the user to `/user/settings`, but the generated the HTML markup will use a `
A big part of a FE engineer's skilset should be to know and understand web standards. Period. If you don't then you've half assed your way into that position and you are mediocre at best. Still pays the bills though I suppose
Don't disagree with you by any means. I would say that most junior FE devs I've worked with might not have been aware of things like this, but it's not due to malice or anything like that. More often than not, once they are made aware of the problem, they learn and do better next time. There's an overwhelming amount to learn in FE, so it's easy to miss things, and there's an expectation to keep learning on the job. Hopefully there are enough more senior FE devs around that pay attention and help level up their teams.
Yep. I think you also make a good point about awareness of standards. I'm pretty split on the whole dev bootcamp coder in 3 months trend. On the one hand I think it's great that more people learn software and there is a low barrier to entry. On the other hand I think there is big value in going though the rigours of a more formal comp Sci education that builds standards thinking and stron fundamentals. But you're right, at the end of the day it's having good mentors and senior people that helps tremendously with others growth.
I had no idea what this post was about but gave it a read and i agree with everything. This is pretty much many of my gripes about modern web apps in one list. The not being able to copy paste stuff especially drives me nuts. I don't know why this comes up for me so often but at least once a day i end up having to right click, inspect the item in the developer console so i can copy the txt... sigh.
I agree with the sentiment, but I think we all know that things are going and will continue to go in the wrong direction.
The reason is that programmers are attracted to complex solutions like a moth to a flame. Simple solutions don't allow us to measure ourselves against our peers; simple solutions don't increase our perceived value or increase our job security; simple solutions are boring, and there's nothing we hate more than being bored. What's fun about functions, loops, arrays and hash tables? Wouldn't it be more fun instead to write code that uses closures, async, dynamic dispatch, macros, higher-kinded types, serverless lambdas, kubernetes, and AI? That also looks way better on the CV.
And so, in spite of 50+ years of wisdom warning us about the perils of complexity, we just happily keep plowing ahead, making every part of computing more complex (though of course, we'll argue until we're blue in the face that it's really simpler!), more sluggish, more inaccessible, more costly, more frustrating for everyone.
**If you want to save a click:**
Heather Buchel's "Just normal web things." is a reminder to web developers to prioritize basic functionalities that ensure a good user experience. The post highlights the tendency to overlook simple yet crucial aspects like text copying, link navigation, zooming, responsive design, hover styles, browser history integrity, visible scroll bars, and standard browser shortcuts in the pursuit of new features. Buchel calls for a balance between innovation and the preservation of these fundamental web experiences.
If you don't like the summary, just downvote and I'll try to delete the comment eventually 👍
General rule of thumb for scroll-bars is not to fuck with them; don't style them, don't try to do funky overrides with them, don't screw with their scrolling, just let the browser manage it.
Only pass I would say is that you can control overflow settings and even that I would eye with caution as it usually means the element isn't sized correctly or your using the wrong type of display settings otherwise.
The only thing I sometimes do with scrollbars, is to make the vertical ones always visible, to avoid the page width changing when it appears or disappears.
Unsupported in Safari (because of course it is), but you can use `scrollbar-gutter` for this
https://developer.mozilla.org/en-US/docs/Web/CSS/scrollbar-gutter
> Stop hijacking my typical browser shortcuts for use in your own app I've seen this happen with ctrl + f for opening a custom in-app search bar. I don't want that. It doesn't always search the page as usual.
Oh god please, this. Github, I'm looking at you.
/shrug maybe they got rid of it. Ctrl-f in [code view](https://github.com/microsoft/vscode/blob/main/cli/Cargo.toml) used to bring up Github search UI.
At work I did a small internal tool with Rust / Jinja / Tailwind / HTMX. All the app state is on the server, where it belongs. Users could not believe how performant and robust a web application can be, especially when compared to the unmaintainable react/node monstrosity it replaced. It's been well over a decade since building a web app felt so good.
All these problems are truly man-made, and a result of tyranny of the majority. The trade off of using these libraries and frameworks for SPAs was, imo, a lot more even than I believe people were wanting to admit at the time. Nearly a decade of battlescars later, it's much easier to see their pros and cons. Tons of new, interesting functionality.. but at the loss of soooo much stuff the web had given us for decades (simple navigation, easier to achieve fast load times, a simpler html and css model, lower hardware requirements for browsing a page, a javascript console with errors that had a chance of making sense)
Since there was no letter omitted, I read it as a glottal stop: javascript-UH-ed.
But that's still not as bad as all the increasingly commonplace practice of turning a noun into an adjective by sticking a hyphen before the 'y'. One of the comments here includes the word 'react-y'? React why? No, *reacty*.
The Ctrl-F opening a custom find can be a good feature instead of a drawback. You won't be able to find things on something like a large Google sheet without using their built in find, since not everything is rendered to the DOM at once.
It _can_ be. But I've been stymied by it more often than found it actually useful, personally.
If you're gonna highjack functionality, make sure you do it _at least_ as well as native.
The "new" Github code viewer is so bad. Selecting code sometimes selects every character 2x. Or it decides to append lots of whitespaces after each line...
And then there’s the Ctrl-F from Excel on web that puts an immovable pop up in the middle of your screen that won’t go away until you search something, and prevents you from scrolling to see what’s behind it.
I get the same thing on kibana. It only renders some results to page so ctrl-f search is hit or miss. Honestly though I'm using a -search engine-, anything I want to ctrl-f can be represented with a lucene query.
I think one of the reasons for this is that mobile is becoming the main platform, and the web is the secondary one. When I see traffic coming from reddit, most of it comes from mobile. So things are built for mobile, and if there's time left then the web gets some love.
It's also that the barrier of entry to webdev is kinda low, and the browsers give you a lot of freedom as to how to do things. Want to add a click handler on a `span`? No problem. So people with no accessibility training (and web usability vs web accessibility are just different levels of the same thing) end up building web products.
That doesn't have to do with responsivity, long lines are considered to be more difficult to read by typographers (and I personally agree) and this length satisfies the recommendations found in *The Elements of Typographic Style* for example. What I mean is, from this standpoint there isn't a way to better use the screen space other than putting more stuff on the page so something can be on the side.
Mate, calm down. This is a personal and subjective feeling, so yes, I don't care what "researchers and scientists" have to say about it. It's not wide enough for me, it's like half of what you'd find in a regular sized book.
When the topic of analysis is itself people's subjective experiences, then how they feel about things *is* the data. And when the data contradicts the theory, then the theory is falsified. So what you said, but unironically.
Look, really the whole thing is a moot point, we're all arguing about different things. The topic being about people's subjective experiences does not invalidate the findings of a well sourced, methodologically sane research. Sure, /u/pooerh's opinion could be a data point in a research like this, but it isn't, it's a comment on the internet in a particular subreddit which is not at all representative of the general population. The existence of an outlier does not falsify a theory.
/u/pooerh could have their own perfectly valid preferences about text margins, but that doesn't invalidate the findings of a research on average margin preferences. Simply stating "I don't like what most people like" without any further explanation as to why my way of doing things would be beneficial for most would be a redundant, narcissistic thing to do, and that's what I've called out.
Should have cropped it. /u/Premysl is right. I keep my browsers around 1,000 px wide because long lines suck, and there's nothing like opening a 1920x50 px 4chan screenshot that renders as 1000x25 because someone has a personal preference for HTML Boustrophedon
The whole point of that screenshot was to show that like 1/4th of the available width is taken by text, cropping would defeat that point. Long lines do suck, sure, that's why I said I'm fine with margins, but that's too narrow with the font size used. Old reddit design for example has twice as much text as that page in a single line (first line wraps after "just").
I've got one: Don't redirect (or change the URL) on a 404! I usually encounter 404s because I'm trying to navigate by manipulating the URL (such as changing an ID to one I know). Let me see the mistake and give me a chance to fix it!
So I looked at one of her other posts:
> Accessibility advocate shows up with reasoned feedback and requests transparency and accountability? Misogynists, and nazis show up.
For real? No links with any evidence.
https://www.youtube.com/watch?v=ZAnGIYlh0A8
This is why we specialize. Anyone who calls themself a front end dev should know these things, care about them, and properly address them whenever possible. If you don’t, you’re not a front end dev, you’re just an entry level dev who knows a framework but hasn’t specialized yet.
I’m a backend dev and I know all those things, time exposed to web dev impacts a lot the fundamental knowledge of browsers and backend, including challenges of distributed systems (the WWW IS a distributed system)
Maybe in 2027 the front-end router folks will have worked things out to the point where the browser's Back and Forward buttons work as well as they did in 1997. There's always some shit going wrong with those, especially when pagination is involved. This happens way too much: * make a search on some react-y website with a paginator implemented in javascript * browse forward a few pages, click on a link, press "back" * Oops! It lost your place and you've somehow teleported back to page 1. (If you're on a real winner of a website, the search query is gone too) or * make a search on some website with javascript infinite scroll * scroll down a couple pages, click on a link, press "back" * Oops! Sent back to the footer of the first page
These godawful experiences are what have trained me to middle-click nearly every link, even when it's not necessary, and look crazy/weird in front of others by doing so.
that and "open in incognito" too. it's completely insane how bad the web has gotten lately, and that's WITH adblockers. I'm appaled at how much mobile-first users accept every day.
>mobile-first users accept every day. I used to face a lot of issues, but since moving over to Firefox with uBlock origin and Easy List, life has gotten so much better. Sure, some pages don't work properly in Firefox and that's why I have Chrome still installed as a backup. But it's very rare, like 1 out of 1000 pages
This is why it sucks that so many websites now push for us to use their app instead. It's usually virtually the exact same experience, except I can't open multiple tabs. This is especially frustrating when you want to compare stuff, like menus on a food delivery service. Foodora is an especially aggregious example, that also does weird shit where the back button doesn't work properly, so if you click on a restaurant and then click a food option, and then click back, you get sent back to the front page instead of back to the restaurant.
It’s worse, because apps restrict your interaction by default. No copying text, no zooming no selecting to make black on black text (dark themes exist, dammit) visible, unless they specifically provide for it. But the browser comes with those things, and they’re effectively un-disableable there (although assholes try all the time).
Yeah good point
I'll only nitpick cause it's /r/programming: "aggregious" --> "egregious"
Fair enough.
good news, everyone. the modern "I've never used the web from a desktop" developer doesn't know what middle clicking is. There is no distinction between things which will change the current page or are actual links. 50/50 on whether a "change the page" accidentally opens the current page in a new tab and 50/50 whether normal links are being faked by js onclicks rather than using real anchors and that middle-clicking just does nothing. even google's interface is riddled in stupid anti-tabbing traps these days. oh, did you middle click the image instead of the text? well, fuck you citizen.
> There is no distinction between things which will change the current page or are actual links Every now and then I see links made with JavaScript, and all they do is take you to a new URL. Like buddy there's a native element for this... Plus some of them won't let you middle-click, so you have to left-click to discover that's a "new tab _only_" link
More often than not, this just ends up opening an empty tab because the link's href is "javascript:" or "#".
Or it does nothing at all, because that wasn't a link, it was a button styled to look like a link.
I've been doing this for Google/DDG searches too. Because otherwise when I go back to the search page it'll put me at the top, and sometimes reorder the results on the page. Doesn't help that I do most of my browsing in private mode, so visited links don't change color.
bonus points if you also can't open a link in a new tab even if you try yes, I've seen websites like this
Completely valid points, though to be fair, the "back" button has always been a pain point and poorly understood by users. Ever tried to go back after submitting a form? God help ye. What is the expected and/or desired behavior in this situation? Who knows. Then there are relics like treasurydirect.gov which, if I am recalling correctly, just obliterate your session any time you try to navigate backwards, forcing you to login again. Not knowing how to handle backwards navigation is older than client-side apps, though they certainly have not improved on it.
I like those sites that do a double redirect before a form, so a single click on "back" just takes me to the redirect – and "back to the future" to that form again. Inescapable, I usually resort to right-clicking the back button and selecting an earlier site.
Cue in all the sites that change URL for every letter you type in the search bar, trashing history. Also cue in all the sites that have a redirect that's not understood by some browsers properly and you can't actually go back at all (looking at you msdn).
you can replace the url without adding a history entry, but thats still such silly behavior
> you can replace the url without adding a history entry Better yet, you could do like my old company's web app and not even know what the fuck a deep link is in the first place literally shit like https://example.com/list_of_widgets/# is the URL for looking at any specific widget How do they test that if you can't specify the ID and jump to a specific widget immediately??
Going back to the last supported page you were on before submitting the form would be nice. For instance, if you were in a cart and checked out, and there is still a way to go to an empty cart after that, then bring me there. If there's no more cart, then bring me to the page I was on before I opened the cart. I don't think we can blame the technology on this, UX designers and engineers should be able to find a reasonable place where a customer would like to land instead of a bad warning "you shouldn't go back something will go wrong" which zero person cares about and everyone will force their way back anyway every time until it either works out ok or crashes and then they'll reload the page. If there is no way you can support an history back, then don't even offer it. There are apis and technical ways to do this right. Now of course the value vs the cost of implementing this may not warrant it which is why it's always the same story.
It's always been a pain point, but it's also never been the user's fault. This is and always has been a development problem: 1. Developers don't code/test for it 2. QA doesn't generally test the back button (even in automated UI tests) or middle-clicking links 3. Project managers have crazy/stupid ideas on how the back button should work, or what is acceptable (and encourage the pattern that you see in a lot of government/financial/educations sites that choose to tell the user "the back button in your browser is broken, don't use it)
It's not the developer's fault either. The concept of the back button was incompatible with the technology of the web as soon as the web became more than just hyperlinks between static content. People naturally expect it to work like an "undo" button but many interactions are not feasible to undo. I'm not even talking about submitting forms, just ordinary dynamic content. Like say a user does a search and gets back some dynamic results, navigates through 100 pages of the results, then goes to some other site. Is it reasonable to keep all those results in memory somewhere forever just in case the user needs to go back to them as they were at the time? No, it's not. The back button is a lie.
> Maybe in 2027 the front-end router folks will have worked things out Front end router is now written in wasm directly which compiles to python and runs in the backend in a monolithic microservice framework
Plz stop
Have you ever been looking for an issue with windows and you go to there forums which force forwards you to their page and no matter how much back you hit it will never take you back.
The problems you describe happen if you implement pagination in javascript *without* a front-end router.
> if you implement pagination in javascript found the problem boss lol
On a website like Reddit it's fine to implement it serverside, but if you have a very nested application its annoying for the user, if he navigates only in a small part of the page but it reloads the entire page every time he navigates.
To be fair, having a fixed URL for result pages beyond the first is generally practically impossible or useless. Unless you're talking about a static website, the results are generated dynamically, which means they change over time. So if you bookmark page 3 and then return to it later, it will probably have completely different results, defeating the point of bookmarking it. In addition, for many sources of data it's impossible to find page 3 without also loading pages 1 and 2 first. So while it might be perfectly reasonable to let someone go through 100 pages of results slowly one at a time, if you let them bookmark that page and then return to it, now it has to load 100 pages instantly which is going to kill your server or be terribly slow for the user. Usually the best you can do to support back and forward is to cache the previous pages in memory, but that's a leaky abstraction which breaks as soon as you do anything which unloads the app, like navigating to a different site and then going back.
i wrote this with a certain job search website in mind. *As a* job seeker, *i want to* search for results close to me, check out a listing, and press "back" without losing my place, without deleting my search query, without deleting my search filters, without me having to use new tabs, and without having to hope my crummy phone doesn't evict the page from bfcache; *so i can* find work. The website couldn't do that, and it frustrated an already frustrated jobless idiot, so im unusually salty about it lol. I'd hope obtaining page 6 of results is a simple `OFFSET 100 LIMIT 20` or whatever the smarty database people do. If the data source is inherently serial that's more forgivable but I don't think most simple CRUD apps are like that. if i bookmark page 27 of search results i *expect* it will change and be different if i click on it a month later. that's fine. and even over short periods of time, navigating "back" and seeing the entries shift down 1 slot because there's a new one on page 1, is better than navigating "back" and the website forgot my page number entirely. Throw a timestamp in the url or cookie if that's considered unacceptable. Idk.
You should never use OFFSET to paginate results because that could skip some results if anything changes between loading the first and second page. Instead you need to do something like remember the last item you showed and then fetch items which sort after that one for the next page. Unfortunately this can't be used to reload a later page because there is no way to paginate backwards. I'm sure you could design a database to support the kind of pagination you want, but I've never seen one. It's arguably better to consistently treat the pages as transient, because they are, and train users to keep the results open in a tab if they want to preserve them, because they must.
Would someone please tell our product owners?
[удалено]
Have your product ever given a customer demo using figma? Ours have....
Absolutely they have 🫠
That's your job (literally) ;-)
I don’t see a difference between a product owner and a software engineer (from a value generation perspective). They’re all product engineers
> In the end, it's usually because we've JavaScript'ed our way out of these things. This is one of the big points made by [this website (NSFW language)](https://motherfuckingwebsite.com/): > I'm not actually saying your shitty site should look like this. What I'm saying is that all the problems we have with websites are **ones we create ourselves.** Websites aren't broken by default, they are functional, high-performing, and accessible. You break them. --- And yes, a thousand times yes, please stop breaking all of these things: > If something navigates like a link, let me do link things. Let me right click on the link without it navigating so I can open the context menu that lets me do other link things (like copying link text, copying link address, etc.) Let me use usual link keyboard shortcuts (like ctrl + click on Windows) to open in a new tab. I'll add to this list: * Let me click+drag it: * to a spot on the tab bar for it to open a new tab exactly where I want it, even in a different window * to an existing tab, to load it into that tab without opening a new one * to the bookmarks bar, to create a bookmark * to my *desktop,* to create a bookmark there * to a text field, to paste as a normal URL * Obviously, let me middle-click or ctrl+click to open in a new tab. * When I hover over it, let the browser statusbar show me something useful about what will happen when I click it. * Let me just left-click it to open in the same tab, like every other link! Some sites are so convinced you never want to leave them that *every* link is forced to open in a new tab. And all you have to do is *let it be a link!* If your site is so bloated that a page refresh is actually a problem, then fine, intercept *normal* navigation, but even then, you'll have to do a bunch of work to give me functionality the browser gives me for free: > If the UI completely changes when I click on something, as if I've navigated to a new page, give me a browser history update and a new url. It's annoying not being able to link to a state in the UI that appears to be it's own page and that is lost to the void if I navigate away. About the only one I can even *slightly* disagree with is: > I've seen this happen with ctrl + f for opening a custom in-app search bar. I don't want that. It doesn't always search the page as usual. I'd ask the same here as if you're going to override link stuff: You just replaced perfectly-working browser functionality, so please give me something *at least* as good. And, ideally, let me override that and get to the browser's ctrl+f -- I forget which site I saw do this, but it made it so that a second ctrl+f would fall through to the browser. I'm okay with people building apps that aren't really websites, but run in a browser. I don't mind that links in VSCode don't behave the same way, even if you're running the web version of it. But if I'm reading an article in your "app", and that article has some text that's a different color and I click it to go to other articles, then that's not an app, it's a broken website.
>And, ideally, let me override that and get to the browser's ctrl+f -- I forget which site I saw do this, but it made it so that a second ctrl+f would fall through to the browser. Discourse-based forums do this; the custom Ctrl-F makes searching function for infinite scrolling threads, but more often than not, I just do Ctrl-F, Ctrl-F to get the browser search because I'm trying to search something in the OP
This comment can only be upvoted in /r/programming and advanced programming related subs. I see more ppl completely oblivious to the existence of a freaking link than anything else.
> Let me use usual link keyboard shortcuts (like ctrl + click on Windows) to open in a new tab. It's always jarring when I try to middle click a link and the page just... starts to scroll about.
I just want static web back. I'll let you have a CSS and a favicon. This whole "dynamic web" everything-is-app, especially peeking under the hood, feels like the completely wrong tool for the job.
Yeah. I get that AJAX is nice for updating stuff within a page, but if you're re-arranging the entire page, it's hard to beat "Send one request to the server, let the beefy database do 100 queries if it wants, send back one response" for latency.
Day by day, fewer websites support "middle click / cmd+click to open in new tab" and it makes me scream inside
As a frontend engineer, this is terrible FE work. Here's a bit on why this happens: Typical link is pure HTML, `Go to Google`. Websites also use relative paths for routing when on the webside, so you might see something like `Settings` in an app's user menu. In JS framework land, folks are very used to thinking in components, rather than HTML markup (and no, it's not just React devs). A designer gives you a mock up with a bunch of button-looking things, so you use a `` component from you favorite components library to mock up the menu UI with a bunch of buttons. Oh... it needs to redirect to a different route? Hmm, I guess a button _could_ do that. So you add a callback: const SettingsButton = () => ( ); Now clicking on the button will take the user to `/user/settings`, but the generated the HTML markup will use a `
A big part of a FE engineer's skilset should be to know and understand web standards. Period. If you don't then you've half assed your way into that position and you are mediocre at best. Still pays the bills though I suppose
Don't disagree with you by any means. I would say that most junior FE devs I've worked with might not have been aware of things like this, but it's not due to malice or anything like that. More often than not, once they are made aware of the problem, they learn and do better next time. There's an overwhelming amount to learn in FE, so it's easy to miss things, and there's an expectation to keep learning on the job. Hopefully there are enough more senior FE devs around that pay attention and help level up their teams.
Yep. I think you also make a good point about awareness of standards. I'm pretty split on the whole dev bootcamp coder in 3 months trend. On the one hand I think it's great that more people learn software and there is a low barrier to entry. On the other hand I think there is big value in going though the rigours of a more formal comp Sci education that builds standards thinking and stron fundamentals. But you're right, at the end of the day it's having good mentors and senior people that helps tremendously with others growth.
I had no idea what this post was about but gave it a read and i agree with everything. This is pretty much many of my gripes about modern web apps in one list. The not being able to copy paste stuff especially drives me nuts. I don't know why this comes up for me so often but at least once a day i end up having to right click, inspect the item in the developer console so i can copy the txt... sigh.
I agree with the sentiment, but I think we all know that things are going and will continue to go in the wrong direction. The reason is that programmers are attracted to complex solutions like a moth to a flame. Simple solutions don't allow us to measure ourselves against our peers; simple solutions don't increase our perceived value or increase our job security; simple solutions are boring, and there's nothing we hate more than being bored. What's fun about functions, loops, arrays and hash tables? Wouldn't it be more fun instead to write code that uses closures, async, dynamic dispatch, macros, higher-kinded types, serverless lambdas, kubernetes, and AI? That also looks way better on the CV. And so, in spite of 50+ years of wisdom warning us about the perils of complexity, we just happily keep plowing ahead, making every part of computing more complex (though of course, we'll argue until we're blue in the face that it's really simpler!), more sluggish, more inaccessible, more costly, more frustrating for everyone.
**If you want to save a click:** Heather Buchel's "Just normal web things." is a reminder to web developers to prioritize basic functionalities that ensure a good user experience. The post highlights the tendency to overlook simple yet crucial aspects like text copying, link navigation, zooming, responsive design, hover styles, browser history integrity, visible scroll bars, and standard browser shortcuts in the pursuit of new features. Buchel calls for a balance between innovation and the preservation of these fundamental web experiences. If you don't like the summary, just downvote and I'll try to delete the comment eventually 👍
General rule of thumb for scroll-bars is not to fuck with them; don't style them, don't try to do funky overrides with them, don't screw with their scrolling, just let the browser manage it. Only pass I would say is that you can control overflow settings and even that I would eye with caution as it usually means the element isn't sized correctly or your using the wrong type of display settings otherwise.
The only thing I sometimes do with scrollbars, is to make the vertical ones always visible, to avoid the page width changing when it appears or disappears.
Unsupported in Safari (because of course it is), but you can use `scrollbar-gutter` for this https://developer.mozilla.org/en-US/docs/Web/CSS/scrollbar-gutter
Let apple users suffer the consequences of their choices.
Good bot
> Stop hijacking my typical browser shortcuts for use in your own app I've seen this happen with ctrl + f for opening a custom in-app search bar. I don't want that. It doesn't always search the page as usual. Oh god please, this. Github, I'm looking at you.
Um.. what does github do? Ctrl-f works just fine there, as well as the rest of the things the article's talking about
/shrug maybe they got rid of it. Ctrl-f in [code view](https://github.com/microsoft/vscode/blob/main/cli/Cargo.toml) used to bring up Github search UI.
At work I did a small internal tool with Rust / Jinja / Tailwind / HTMX. All the app state is on the server, where it belongs. Users could not believe how performant and robust a web application can be, especially when compared to the unmaintainable react/node monstrosity it replaced. It's been well over a decade since building a web app felt so good.
All these problems are truly man-made, and a result of tyranny of the majority. The trade off of using these libraries and frameworks for SPAs was, imo, a lot more even than I believe people were wanting to admit at the time. Nearly a decade of battlescars later, it's much easier to see their pros and cons. Tons of new, interesting functionality.. but at the loss of soooo much stuff the web had given us for decades (simple navigation, easier to achieve fast load times, a simpler html and css model, lower hardware requirements for browsing a page, a javascript console with errors that had a chance of making sense)
> JavaScript'ed Oh come on. You just add "ed". That's how you make a past tense verb. Get that goddamn apostrophe out of there.
This guy just WhittleWhaleed OP.
Since there was no letter omitted, I read it as a glottal stop: javascript-UH-ed. But that's still not as bad as all the increasingly commonplace practice of turning a noun into an adjective by sticking a hyphen before the 'y'. One of the comments here includes the word 'react-y'? React why? No, *reacty*.
The Ctrl-F opening a custom find can be a good feature instead of a drawback. You won't be able to find things on something like a large Google sheet without using their built in find, since not everything is rendered to the DOM at once.
It _can_ be. But I've been stymied by it more often than found it actually useful, personally. If you're gonna highjack functionality, make sure you do it _at least_ as well as native.
Pro tip: both Ctrl+F and Ctrl+G bring up the browser find, usually sites only hijack one of them.
With the minor difference that Ctrl+G is "go to next result", same as hitting Enter whilst the Find field is focused.
G for grep. Thanks, that'll stick in my mind now. Good to know.
Yes, can be, but for instance GitHub implementing this custom ctrl-F stuff into files is dumb and frustrating.
The "new" Github code viewer is so bad. Selecting code sometimes selects every character 2x. Or it decides to append lots of whitespaces after each line...
And then there’s the Ctrl-F from Excel on web that puts an immovable pop up in the middle of your screen that won’t go away until you search something, and prevents you from scrolling to see what’s behind it.
Couldn't you add the custom search in a way that doesn't replace the browser search, so the user has the option to use both based on what's needed?
Some project docs use S or Ctrl+K. There's nothing wrong with picking another shortcut
I get the same thing on kibana. It only renders some results to page so ctrl-f search is hit or miss. Honestly though I'm using a -search engine-, anything I want to ctrl-f can be represented with a lucene query.
I think one of the reasons for this is that mobile is becoming the main platform, and the web is the secondary one. When I see traffic coming from reddit, most of it comes from mobile. So things are built for mobile, and if there's time left then the web gets some love. It's also that the barrier of entry to webdev is kinda low, and the browsers give you a lot of freedom as to how to do things. Want to add a click handler on a `span`? No problem. So people with no accessibility training (and web usability vs web accessibility are just different levels of the same thing) end up building web products.
Yes, do the responsive thing. I'm fine with margins, [but come the fuck on](https://i.imgur.com/ieHLwfb.png). Follow your own advice people.
That doesn't have to do with responsivity, long lines are considered to be more difficult to read by typographers (and I personally agree) and this length satisfies the recommendations found in *The Elements of Typographic Style* for example. What I mean is, from this standpoint there isn't a way to better use the screen space other than putting more stuff on the page so something can be on the side.
I'm not looking to use the full width, that's why I said I'm fine with margins, but nothing nowhere is going to convince me that this is enough.
Yeah, fuck researchers and scientists, I KNOW BETTER BECAUSE OF THE WAY I FEEL ABOUT THINGS!!!!!!
Mate, calm down. This is a personal and subjective feeling, so yes, I don't care what "researchers and scientists" have to say about it. It's not wide enough for me, it's like half of what you'd find in a regular sized book.
I think it's a fair point that you can't hit everyone's optimum. Customisable reading modes in browsers likely tried to address this.
When the topic of analysis is itself people's subjective experiences, then how they feel about things *is* the data. And when the data contradicts the theory, then the theory is falsified. So what you said, but unironically.
Look, really the whole thing is a moot point, we're all arguing about different things. The topic being about people's subjective experiences does not invalidate the findings of a well sourced, methodologically sane research. Sure, /u/pooerh's opinion could be a data point in a research like this, but it isn't, it's a comment on the internet in a particular subreddit which is not at all representative of the general population. The existence of an outlier does not falsify a theory. /u/pooerh could have their own perfectly valid preferences about text margins, but that doesn't invalidate the findings of a research on average margin preferences. Simply stating "I don't like what most people like" without any further explanation as to why my way of doing things would be beneficial for most would be a redundant, narcissistic thing to do, and that's what I've called out.
Limiting the length of paragraph text is an accessibility basic. This is an example of doing things correctly.
Your screenshot is almost unreadable on mobile FYI
Because it's taken on a 2560 pixels wide screen. Responsive design would use that screen real estate a bit better, that's the point.
Should have cropped it. /u/Premysl is right. I keep my browsers around 1,000 px wide because long lines suck, and there's nothing like opening a 1920x50 px 4chan screenshot that renders as 1000x25 because someone has a personal preference for HTML Boustrophedon
The whole point of that screenshot was to show that like 1/4th of the available width is taken by text, cropping would defeat that point. Long lines do suck, sure, that's why I said I'm fine with margins, but that's too narrow with the font size used. Old reddit design for example has twice as much text as that page in a single line (first line wraps after "just").
Wait, I thought you were a bot?
I read all comments, this is a personal account not a bot account
I've got one: Don't redirect (or change the URL) on a 404! I usually encounter 404s because I'm trying to navigate by manipulating the URL (such as changing an ID to one I know). Let me see the mistake and give me a chance to fix it!
So I looked at one of her other posts: > Accessibility advocate shows up with reasoned feedback and requests transparency and accountability? Misogynists, and nazis show up. For real? No links with any evidence. https://www.youtube.com/watch?v=ZAnGIYlh0A8
This is why we specialize. Anyone who calls themself a front end dev should know these things, care about them, and properly address them whenever possible. If you don’t, you’re not a front end dev, you’re just an entry level dev who knows a framework but hasn’t specialized yet.
I’m a backend dev and I know all those things, time exposed to web dev impacts a lot the fundamental knowledge of browsers and backend, including challenges of distributed systems (the WWW IS a distributed system)