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.
Yes, what I'm saying is that you can have the backend return e.g. "{ "response": 301, "redirectUrl": "https://example.com" }", and then have the frontend handle that properly, and you get the functional equivalent.
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.
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.
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
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
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.
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.
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).
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.
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.
You should be able to click at 75% on the scroll bar and immediately jump there, no grab and drag needed. MacOS still offers this option, but apps that reinvent the scroll bar never respect this system-wide setting.
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.
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.
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?
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?
> 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
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.
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.
> 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.
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.
Most vanishing scrollbars only show up if you mouse over them or use some other means to start scrolling; simply moving the cursor when it's over the content doesn't make them show up.
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).
> 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.
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.
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.
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.
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.
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.
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'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
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.
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.
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.
The demo being such a bad example of smooth scroll made me feel ambivalent toward the entire article. On the one hand, perhaps the author is so bad at designing UX that this was their best attempt at a demo and not just a bad faith attempt at proving their point. On the other hand, if someone so clearly informed about the UX issues is inept at implementing it well then perhaps it really is too much power to wield over web standards.
This is mentioned in the first sentence of the article: "Momentum (aka. smooth or interia) scrolling plugins (example here), while marketed as enhancements, are a plague upon the internet."
reply