7 ms·
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.
by onemoresoop 2y ago
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.
- tehwebguy 2y agoOr the escape button, Squarespace!
- deleted 2y ago[deleted]
- Cthulhu_ 2y agoBut 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.
- aredox 2y agoWhy did we let them be able to do so?
- pdimitar 2y agoWho is "we" and how could "we" stop them exactly?
- account42 2y ago"We" is Browser makers and users. We stop them by taking back control of what runs on our computer.
- afavour 2y agoBecause when implemented properly it is a better user experience.
- ikari_pl 2y agoif 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
- marcosdumay 2y agoBecause some sites need to change those things. So they can't just deny it for everybody.
- ffsm8 2y agoThis 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
- axegon_ 2y ago> 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.
- danpad 2y ago> 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 https://gramazing.com/features . Made with NextJS (client side only), Django, hosted in Germany on a cheap VPS.
- justsomehnguy 2y agoAnd you could do all that with a static generated site. Why it needs to be an SPA?
- deleted 2y ago[deleted]
- danpad 2y agoYes, I could do it with server rendered site, it wouldn't be as fast though. Also SPAs were my bread and butter with my previous employer, and I have gotten to a point where I am much more comfy with NextJS+Django than SSR Django, Django+homebrew JS or something like HTMX (as much as I wanted to like that one). Statically generated site is something completely different and I couldn't make Gramazing like that.
- 2y ago
- safety1st 2y agoIt'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.
- ervine 2y agoWhat kind of stuff do you give up with an SPA?
- nurettin 2y agoYou give up server redirects and cookie auth. (well you don't lose cookie auth, but you need extra steps for it to prevent CSRF)
- stackghost 2y agoYou can just have the server return a json object instructing the frontend to navigate, accomplishing server redirects.
- ftmch 2y agoJavascript can do browser redirects, but those are not actual 301 HTTP redirects.
- stackghost 2y agoYes, what I'm saying is that you can have the backend return e.g. "{ "response": 301, "redirectUrl": "https://example.com https://example.com" }", and then have the frontend handle that properly, and you get the functional equivalent. I'm aware that it is different under the hood.
- agos 2y agothere 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
- Habgdnv 2y agoI 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.
- mmis1000 2y agoSometimes 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.
- karmakaze 2y agoYou 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.
- ervine 2y agoYah agreed - updating params when filtering / sorting / paginating should replace instead of push to the history stack. Easy enough to do.
- account42 2y agoStrongly disagree - nothing is worse than hitting back and loosing all intermediate state instead of just undoing the last view change. You can long press the back button to choose an older history entry to go to directly.
- zelon88 2y ago> 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.
- notfed 2y agoThe US Treasury website logs you out when you hit the back button, and is very much a traditional website, not an SPA.
- moring 2y agoBrowser 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).
- vanviegen 2y agoSure that happen(ed|s) sometimes. It's a common mistakes for junior devs, though quite easy to avoid. For SPAs though, you need to do some non-trivial (at least for non-trivial apps) additional work to manage the history. Often teams so this step out butcher it, as they run out of time/budget. Or use a complex bloated framework, creating other challenges.
- ggggggreat 2y agoRedirects broke history long ago, a 2 redirect chain is the worst experience. It's on browsers to fix but that ain't happening, too much inertia.
- slantaclaus 2y agoSPA: single page application. Got it