I’d add don’t fcuk with with urls and browser navigation and the back button but it’s a long lost battle, SPAs broke the web and made it much worse.
But SPAs don't need to, they chose to. The history API is fine and can be used to have SPAs and their navigators work with the browser and user, instead of against it. But a lot of developers broke it because they ignored bookmarkability and navigation and the like because they didn't care.
A good SPA works just like a regular website and other than it being fast and responsive, you shouldn't even notice it is one. But alas.
It's because when you build a SPA you give up a bunch of stuff that comes with the traditional web page model, and it's stuff that most teams overlook until it's too late. They are usually fixated on a certain set of performance issues that drove them to do an SPA in the first place, their energy goes into that, and then they kind of look around at all the other stuff and go, oh, we don't have time for those things.
This is why I typically fight SPAs every step of the way with our clients, if any other architecture will work I see if there is a good case to be made for it, because I know that SPAs are usually going to end up shipping broken in some way.
What kind of stuff do you give up with an SPA?
You give up server redirects and cookie auth. (well you don't lose cookie auth, but you need extra steps for it to prevent CSRF)
You can just have the server return a json object instructing the frontend to navigate, accomplishing server redirects.
This didn't come through pwas. We've had ajax for ages before they became a thing and mpa also had opaque state for modals/detail views etc.
Blaming SPAs for such things is like blaming the ocean for a hurricane... Sure, you'd have less hurricanes without the ocean, but it's ultimately not the reason for them
> fast and responsive
I'm sorry but I have to disagree. I've never seen a fast or responsive SPA, not to mention the absurd amounts of resources they require. A tab taking up 400 mb of memory is pure insanity and this is the de facto standard these days. Look at HN: this is the definition of fast and responsive. It will work equally well on my dual-xeon workstation and a first gen raspberry pi zero. This is fast and responsive. Most people who use a computer to navigate the internet would not care if the browser blinks when you navigate a page. Mobile users don't really use the web beyond social media and chats so it makes no difference to them either. SPAs solved a problem no one had by creating 1000 other problems. Just take us back to server side html rendering and I guarantee most ordinary people as well as most developers will love it.
> I've never seen a fast or responsive SPA
Here, let me blow your mind. It's in Czech, but you can click the orange buttons to try the activites: https://gramazing.com/features .
Made with NextJS (client side only), Django, hosted in Germany on a cheap VPS.
> SPAs solved a problem no one had
The problem was: can we make the same data APIs to serve the web and mobile apps?
Current gen frameworks can totally consume the api on server and spit out perfectly normal html to browser just like normal mpa. However this depends on whether you have a competent ops team that is capable to deploy something other than static html. And not having that is the reason you choose spa at first place in a lot of times.
Why did we let them be able to do so?
if done properly, this allows the url to represent where you are in the app, and makes back/forward work - like in typical web pages, just without a reload.
Most often though, I see it done inconsistently, and it's a painful mess
Because some sites need to change those things. So they can't just deny it for everybody.
Who is "we" and how could "we" stop them exactly?
Because when implemented properly it is a better user experience.
Browser navigation (especially "open in new tab") and the back button were broken by global (server-side) session state long before SPAs were a thing. If anything, SPAs improved on that, because very few server-side web frameworks ever handled state well (Wicket being by favorite exception).
You know what I don't like? Having to hit the back button far too many times while I was interacting with an element on the page. It makes sense that I should be able to bookmark or send a particular state but I much prefer if the URL is changed in-place (without creating a navigation step) to achieve this.
Yah agreed - updating params when filtering / sorting / paginating should replace instead of push to the history stack. Easy enough to do.
there are very easy ways to make SPAs which don't fuck with URLs (since, I don't know, ten years?). People who don't care about the web fundamentals/urls/back button/scroll UX/etc have broken the web, not SPAs
I have a single SPA deployed in my life. About 5-6 years ago. I did nothing to preserve the history, it was just working back then. Imagine how more polished are things now. I am thinking that people who are breaking the history should take special steps to do so, otherwise it will just work out of the box with most frameworks/libs.
Sometimes the requirements are shit and so are the results. Like asking a instant redirect on invalid page and thus break the back button completely after submit any form. And yet you still get requirements like this.
The US Treasury website logs you out when you hit the back button, and is very much a traditional website, not an SPA.
Or the escape button, Squarespace!
> the back button
Especially Microsoft TechNet articles and the like. Microsoft should be ashamed breaking back functionality on people searching for solutions to windows problems. Just adds one more complaint to the list.
Also don't mess with scroll bars. Seems to be a more recent trend to make them about 1px wide on everything
Indeed, tiny scroll bars make it impossible to use a touch screen.
If you really want your app to be ergonomic, make sure it works with one and two finger gestures, such as dragging a finger to scroll.
Touch screens should support two-finger drag scrolling which is a much bigger hit-target than any scrollbar.
Sure, but I can grab the scroll handle and yank it down to 75% instantly. How much superfluous motion do I have to endure on a long page to even find 75%? Can I see how far along I am on the page with the invisible scroll bar that barely renders anything? Is the rendering of its overall progress consistent between applications, if not completely broken?
The boring, "ugly" built-in OS widget works extremely well. Every attempt to replace it with something better for one use case inevitably throws out a dozen others that the designer didn't think about.
I'm OK with them popping up on mouse-over, many web sites have taken the easy route and disabled them completely on one or both axes.
Then the only way to scroll on desktop is to highlight text across the frame's edge.
Middle click your mouse button then move mouse to the right, thats the best way to do it.
shift + mouse scroll for horizontal scroll works too, at least on Firefox.
Nah, I hate that. Frequently it gets in my way when I have my screen split with two browsers side by side. I'll try to hover over the scrollbar on the right hand side of the left page, try to click, and end up clicking the right window. Give me the whole damn scrollbar please.
Exactly. I have a 5120-pixel-wide monitor. I can afford the space needed to display a scroll bar.
I usually hide them. I try to not use overflowing content, but when it has to overflow I hide the scrollbar because scrollbars disrupt the design and the standard ones are extremely ugly.
How can you make an assertion like "they are extremely ugly" when they're different or absent entirely depending on device and browser? Don't make decisions for your users, this breaks expectations and accessibility.
I dont want users that need handholding anyway. I want my app to look good. Almost all scrollbars on all of my devices and browsers look ugly. Users that need handholding usually also are the more problematic users.
What a horrible, anti-social attitude. I hope you aren’t working on anything important.
Shocker, apps do not have to be for everyone.
You don't know who you are excluding by working against accessibility. It's very naive and small-minded of you to think that you are only inconveniencing some caricature in your head.
I am inconveniencing my time which is important to me. I dont have to build my apps accessible to everyone as they are clearly not purposed for everyone. Whats so hard to understand with that?
Way to spit in the faces of disabled people!
So if i am building my own house i should also spend thousands of dollars more to make it accessible? If my house isnt accessible do i also spit disabled people in the face?
That's a poor analogy - a house is private property which only you and invited guests may enter. A website you publish on the Internet can be viewed by anyone who discovers it. Not including accessibility features excludes disabled users from reaping the benefits of your site. So a better analogy would be "if I build a public space do I have to make it accessible?" You betcha!
I guess this is a philosophical discourse. I simply build my own apps not for everyone and its not my problem if someone has a problem with that. If I build something thats meant for the public I try to build it accessible, but only if I feel like its needed. Seems like there is a market for accessibility software, why not jump on it? Why isn't the accessibility software good enough to not make the devs go extra steps on projects that are clearly not meant for everyone? The internet is for everyone, sure. My apps aren't. Simple as that.
Sooner or later, you will be less able than you are now. Everyone faces disability, it's just a matter of when, or how rapidly it happens.
I already face disability as i have to wear glasses to see properly. Still wont change the fact that I wont put the burden of making my apps accessible onto myself as they clearly aren't meant for disabled people and/or people that I don't want to use my app.
> Why isn't the accessibility software good enough to not make the devs go extra steps on projects that are clearly not meant for everyone?
Is it not an extra step to intentionally hide the scroll bar? And thus, simply no extra work to just... not? Scrolls bars are a convenient feature for all users, nobody is judging the appearance of your website around how it looks with a scroll bar.
Try building a modern looking website only for scrollbars to look like they are from 1990. They break immersion. Especially on artsy websites that try to immerse people.
This is like people who use synonyms prolifically, replacing all of their words so that lexical units do not repeat. It appears jarring and somewhat pretentious, past a certain point: readers will rarely notice the common UI paradigms which they have come to expect, but viewers assuredly become aware upon contradictory circumstances such as absence. Some feel these pseudo-minimalistic phenomena are grating. You intend greatness alongside immersion, however an effect most contrary may occur.
Art? Nah. (Maybe once.) Dead horse gimmick, now.
> So if i am building my own house i should also spend thousands of dollars more to make it accessible? If my house isnt accessible do i also spit disabled people in the face?
not hiding the scrollbars on your website doesn't cost you thousands of dollars so I don't really see the equivalence
Yea but theres a difference in showing scrollbars and making the whole website accessible.
> So if i am building my own house i should also spend thousands of dollars more to make it accessible?
Well, you don't know what tomorrow you will need. I remember my grandmother needing to make the house accessible after my grandfather lost control of half his body after a stroke.
And those accessibility enhancements are not a problem even if they're not directly needed anymore: no steps between rooms, big sliding doors, lot of space for the shower etc. Even able people can appreciate those.
Whats the issue with getting them once they are needed?
It may be harder to had them or more expensive. And the fact you suddenly need them also mean there are low chances you'll be able to do the work yourself.
Like: build a house on only one floor so no stairs => no need for elevators later on. But it requires more floor space.
I would've agreed with you if I didn't start with Firefox on my web design journey. I never found scroll bars to that problematic because FF has pretty sleek ones. So I always ensured scrolling worked on overflow, when I started to more seriously test and use chrome I was absolutely disgusted by those vile thick scroll bars that would ruin my amateur design. But by that time I had understood that scroll bars are a need not a want.
They are a want. You can keep scrolling functionality without having scrollbars. If you write apps that serve the biggest demographic possible I get your sentiment. I dont want to serve to the biggest demographic possible, I want to serve specific people.
I love vanishing scrollbars. The moment I move my mouse, they're there. When I stop, they're gone. Want to see progress? Nudge the mouse.
I'm glad at least one person likes that "feature".
I guess folks who rotate their monitors to portrait mode would appreciate not wasting the entire height on a permanent scroll bar, but I like knowing how far I am into the page (not that that's really a true indication of where the page will end due to how large the modern header and footer regions tend to be nowadays).
Don't forget lazy-loaded content as a further perversion of the scrollbar :'( Discourse is my mortal enemy.
> you're essentially telling users: "We know better than you." That arrogance doesn't go unnoticed. Respect your users' autonomy
IMHO, that assessment and corresponding answer applies perfectly not only to Momentum scrolling but also to most of the current trends in UX design. I wonder how we got into this worship of aesthetics to the detriment of everything else.
I don’t think it’s fair to blame the problems on “trends in UX design.” It’s more the lack of UX design.
Theoretically, I agree. UX shouldn't be about making systems look good. In practice, though, this appears to be the main concern (maybe because it's the easiest one to grasp?), leaving all the other ones subordinated to it. Hence I would blame the "excess" of UX design.
Yeah, that part reminds me of the flatteringly named "Call to Action" buttons. There was a nice blog article named something like "Button presses You" which i can't seem to find. Essentially, it goes on the trajectory of the purpose of any application telling you what and how to do instead of you, the user, deciding what the programm should do.
Indeed. CTA buttons and everything. Instead of simple, readable text-based menus, icons everywhere because they are "more intuitive". Navigation aids because, otherwise, "users get lost". Useless animated pictures together with apologetic error messages whenever the system (frequently) crashes. Everything facilitated by tools like Figma, enabling designers to be creative by pointing and clicking and leaving the multiple implementation and maintenance details as an exercise to developers who have now to "specialize" on front-end. What a hell. Yesterday I had to use a government web app and got lost. They even bothered to create some video tutorials but unfortunately the software went recently through a redesign to "improve UX" and now the icons don't match the ones in the tutorial anymore. The amount of damage they create with their cutesy interfaces and their condescending attitude is astonishing.
> Instead of simple, readable text-based menus, icons everywhere because they are "more intuitive". Navigation aids because, otherwise, "users get lost".
I'm not especially dumb but after they dropped "hamburger button" I think it took me about 10 years to ever look for the "hamburger button" for basic functionality, especially on non-touch devices.
What horrors lie beneath the hamburger? What void of regular function could there be?
Amen! I've been on the internet since the dang Gopher days (so, pre-HTML), and I appreciate the bare HTML aesthetic's minimalism.
As well, their link at the bottom to the website that inspired this opinion piece page is chef's kiss.
Viewing the page source on these kinds of pages gives me warn fuzzies, not in a nostalgic way, but in a "these folks get it" kind of way. It's like in the Helvetica documentary where the guy explains what it must have felt like for designers to newly be able to choose Helvetica instead of those 1950s crap script fonts.
Bravo.
While we're at it, my hatred for the < > symbols on rows of things on previously explicitly only scroll up/down pages is just as intense today as when I first experienced it.
Streaming media platforms are probably the most notorious offenders in this space, but are definitely not alone.
Hijacking Ctrl+F or Ctrl+K are my two top peeves lately.
I'll add hijacking selection and Ctrl-C too.
Outlook for web hijacks ctrl+r.
Don't fuck with the standard key combos.
Stop surprising users by taking away functionality from other applications.
Come to think of google docs spreadsheet thing does this too, and also F5. It also often fails to render correctly so I need to refresh the page.
This is why applications shouldn’t live on top of a browser on top of an OS GUI. That’s just restricting the workable UI conventions too much and makes for a confusing mess.
Ctrl+F hijacking, even if it provides a useful app search feature is something I despise. Browsers should have an alternate Shift+Ctrl+F or something that can be used in those cases. I just discovered Shift+Cmd+F that does something on Firefox.
That doesn't really help if the website removes the parts of the page that are outside the current screen from the DOM.
A prime example: JIRA's backlog view. In the self-hosted version, you could easily find the issue you were looking for in the backlog view by just using the browser's search, press Ctrl+F, write some words, you have the issue you were looking for. The cloud version Atlassian forced their users into, OTOH, features their own implementation hijacking Ctrl+F combined with dynamically removing the issues not currently visible from the DOM, to ensure that no-one can have the convenience of the browser's built-in search.
Honestly, this is one that I think can go both ways.
In Google Sheets on the Mac recently, Cmd-F for searching within the spreadsheet has stopped working—and while it's true that the way it worked was by hijacking that system shortcut, it didn't actually replace it with anything. So the only way to search was to go to the Sheets menu bar and find it in the menu.
Only a few applications behave like that because of defective coding hamster browser is a good scroller .Tilt scrolls are available in iPad and this helps old people like me to scroll quickly read me there is an automatic scroll also which is very good
Also don't fuck with that thing where scrolling down progresses an animation, moves things sideways, gets you past the scrollgate until you can continue scrolling down the page. Terrible, jarring, disruptive, user-hostile design.
The best part is that the "Back to the normal version" link is only clickable if you smooth-scroll all the way back to the top. You really got me with that.
Whoever would implement something like this on their site?
To my recollection, I have never come across this on a website since the Flash days, however.
Even the scroll bar is broken on the (other) demo page. Ouch!
Intentionally broken scroll on mobile?
It's like Poe's Law but for insipid web UX.
really really really well done
The example uses the plugin luxy.js: https://min30327.github.io/luxy.js/
It appears that the plugin basically does two things:
1. Repeatedly calls window.requestAnimationFrame with a callback
2. Set a custom style on a specified element (position:fixed, width:100%, transform:translate3d)
You'd have to stop both to override the plugin.
Why is it even possible to fuck with scroll.
If you try hard enough, it's possible to fuck with almost any aspect of normal web UI. Trying to prevent existing ways of doing it will lead to worse ways being used by people who think they know better.
because this is web and nothing makes sense.
The inner platform effect is unavoidable. At the extreme end, there will always be someone reimplementing a browser on top of webgl/wasm/whatever.
My most annoying scroll-experience is Grafana, too easy for people to make dashboards with a bunch of scrollbars and I always fail pick the correct one to scroll down.
I enabled a smooth scrolling behavior in my logitech mouse settings and it created a bug where bootstrap dropdowns would appear and disappear immediately.
It was far from obvious that this was the cause. In fact I completely forgot about this setting. I thought the problem came from the website or an extension or the browser or bootstrap, damn.
I'm fine if sites make creative choices for things, if they are a creative site. Homestar runner would be a classic example of this done extremely well. The time he "broke out" of the frame was amazing.
But, if you are making something with plenty of precedent, please follow it. There is a reason we wind up with mandated nutrition labels and such. It is good to be similar to things. Especially if you are, in fact, similar
Can we also talk about fucking with zoom?
That's my personal pet peeve.
When I zoom on an image, it should zoom with the rest of the page, not resize itself to shrink to the same size. That behavior is infuriating.
<glares at github PDF view>
Yeah. Don't fuck with scroll, don't fuck with crtl/cmd-click, don't fuck with copy/paste (specially in password fields), don't fuck with the back button, etc.
I really don't face this issue ever, but I tried the demo page and the experience is garbage.
I use vimium to navigate on the web and made scrolling through that website unusable.
Just don't
Are there any examples of sites using this for real? I assume the example is made especially bad to make a point.
I hadn't even considered this existing. From the title, I assumed it was about those pages set up to stay fixed on one page and then change entirely to the next one when you've scrolled down far enough.
Now that I think about it, I haven’t seen this in years.
There was a period of time where this was popular for over-designed product landing pages, but that fad faded out as quickly as it appeared.
If a page with this behavior ever gets linked on HN you’ll know immediately by the 100s of comments raging about it. :)
Speaking of which, does Firefox offer the ability to turn this off in about:settings ? Or will that break the event detection ?
I'm also curious if this functionality is possible to achieve through browser configuration.
Alternatively, a browser extension could potentially provide a helpful solution.
I suspect the implementation may vary on a case-by-case basis. The example [1] on the page utilizes the luxy.js [2] library.
For this specific page [1], I found that I can disable the smooth scrolling behavior by running the following command in the developer tools console:
luxy.init({ wrapperSpeed: 1.0});
1. https://dontfuckwithscroll.com/smooth.html
2. https://min30327.github.io/luxy.js/
Oh the irony, the scrollbars on this pages covers the last letters of each line.
That's your browser (and lack of margin on the page).
I have never encountered a website that did something like that. Are there any examples?
I'm a bit confused. Smartphone operating systems do momentum scroll since the first iOS. Everywhere, not just in the browser. Is this website specifically talking about websites which try to emulate Android & iOS inertia scrolling on desktop browsers? (I guess momentum scrolling doesn't work well with mouse wheels, where the mouse wheel doesn't have inertia.)
They are talking about adding that kind of scrolling using JS as demonstrated in the alternate version of the page that they link to. I don't understand why anyone would think it's needed though when scrolling already works like that at the OS or browser level. Doing it in JS just doubles up on the effect, leading to a very strange feel.
At least on my iPad here, when the screen is scrolling, and you touch the screen, it stops. On the demo page, it doesn’t. Who would want that, or think that was better? If I encountered that, I’d go away from that website and never go back.
My god, please boost this.