Why I hate your SPA:
- If I click on a link, I receive no indication that I actually clicked a link, then 2-10 seconds later the page abruptly loads. Sometimes the page doesn't load at all.
- I cannot tap and hold a link, wait a second for the pop-up menu, and open the link in a new tab because the link isn't actually a link. It's implemented in JavaScript.
- The back and forward buttons don't work as expected because either history isn't maintained or it's shoddy (scrolling should not be a history event).
- The refresh page button don't work as expected because it resets you to the beginning.
I can't think of any good reason why the browsers can't help out with this UI / UX. Am I crazy?
Clicking on a save button and seeing the page hang is the normal way browsers handle http requests. But a javascript-enhanced experience can tell users about the local perception of the http request (ongoing, timeout, retry, error), or it can inform the user that it's safe to navigate away while their requests retry.
Edit: also agree to it disappear when accidentally hit back or leave page... I don't think you need to ask permission to use cookies so should opt for it... Or some other way to store.
Interesting about the separate window, thought cookies could be set to never expire.
Cookies can certainly be set to never expire, but you don't know which window the cookie was intended for because the cookies are shared.
[1]: https://developer.mozilla.org/en-US/docs/Web/API/Window/loca...
[2]: https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage...
I finally used memcache(d) so that's cool.
Funny that you mention it. Loosing form data on page refresh or clicking "back" button was a problem on the Web until browsers started keeping form state along with page history. Suddenly millions of websites got this new feature without actually doing anything differently. But that was only possible because page transfers were semantic. Frameworks of that time that tried to manage their own form state (like ASP.NET WebForms) didn't have real page transfers, so they didn't get this "upgrade" and currently are significantly worse off in terms of usability.
I think there is a lesson here.
1. Every click is fetched and rendered faster than your javascript code has had a chance to execute, let alone fetch or render.
2. True, minor headache though compared to the vast improvements in usability.
3. Nope.
4. Nope, this is a bug - something javascript pages most certainly are not immune against.
Note that I've of course seen countless slow, bloated static pages - but that's pretty much never because of the tech stack - but because of bloated css, silly large images, and often horrible convoluted html.
Hn is of course a typical example of a web page that on paper would be great as an spa, but works fine as a static page with minor js (broken up/down links notwithstanding..).
D-lang forums is another :
Assuming a 64 kbps connection, and a 50%+ gzip compression, downloading a couple of pages of text is done in about half a second. If the user has such a terrible connection, they've hopefully turned off image loading. I don't think adding 40-400 kbs of gzipped js is going to help with the speed...
It also doesn't work well when opening lots of tabs (which is a popular technique that helps immensely when browsing on a slow connection as pages are loaded in the background).
And if you have a really slow or spotty connection the javascript page would barely load at all.
Also if I have to use 64kb I completly disable js in my browser and whitelist just a couple of websites - best adblock on mobile.
Unfortunately connection are more intermittent now than ever before.
If you turn off images, you get in with 12kb of data. I think 12kb of data should be transferred faster than even the more lighter JS frameworks around...
Even when I was coding web pages in Perl in the 90's I wouldn't do that to a user, that's just mean. You don't need a SPA to provide proper error handling that also rebuilds previous state.
In fact sometimes their web form just forgets things for no reason.
There is no competitor in sight because of the huge huge SEO juice they have built over 15 years.
But it's not THAT inconvenient!
> You forgot to update the styles on that rarely-used page
That's solved with proper css, not SPA.
Anecdotally, every team I've worked with has converted to a SPA, and the main ergonomic upgrade is that updates to the signup page or the "not found" widget quit getting forgotten whenever we change tweak our design. There always seems to be one page that's out-of-date for 2 months before anybody notices, then it quietly gets fixed up because we forgot that the design tweak was a CSS+HTML change, not pure CSS.
Not that that's perfect -- once you have a SPA, nobody remembers the 404 page, because it's a different HTML base...
This was fixed in browsers years ago when they started keeping form state along with page history. I can refresh this page, go back and forth in history, and this text box will keep my comment. Ironically, websites that tried to be clever about form state management and faked page transfers (like ASP.NET WebForms) didn't benefit from the fixes and currently are significantly worse off in terms of usability than websites that used vanilla forms.
I think there is a lesson here.
In about 95% of the SPAs I've tried, each click takes even longer than that.
"you never poll for updates"
Yes, because apparently AJAX/AJAJ is completely nonexistent and there's absolutely zero ground between "pure-HTML like it's 1991" and "VueWangulaReact.js single-page monstrosity".
Hell, even a meta-refresh will fix that if you really do want "pure-HTML like it's 1991", though that's certainly inelegant.
- The author is describing hypertext, which is perfectly fine for textual static content, one of the key goals for which the World Wide Web was conceived.
- Server-side generation of HTML seems totally out of place for other use cases: HTML/JS are now the assembly languages of the web and they belong in the browser. Besides a more distributed architecture is just perfect: server and client focus on what they do best.
- Fixing web-apps with broken history buttons and unlinkable urls is important, but to be honest there are fewer and fewer SPAs that are mono-url these days. And it's perfectly fine to have a unlinkable "Delete this Invoice" app button. If it's not real content it should not be a link.
The first two are fair criticism but they aren't nearly as detrimental to the user experience as the typical single page app antipatterns (no history, no indication of page loading, refresh button is broken, etc).
While it is of course possible to execute any design well or poorly, the observation that a typical single page app is worse than a typical multipage app is certainly valid.
This. I have a very short list of architectural must-haves that I use when evaluating junior dev's code at the start of a project, and not having robust error handling that preserves submitted form information is right up near the top.
It's an annoying design mistake with two input elements, unworkable with five, and just plain cruel beyond that.
Just handing someone an expanded version of "implement good error handling" is not likely to result in a good product. Every project has nuance and subtle trade-offs -- the code review is an opportunity to teach juniors how to map abstract design principles onto concrete implementations without falling back to "cookbook / cargo cult" programming.
I want them to take ownership of their own code, and advance down the path of craftsmanship because I believe this results in long-term value -- both to them personally and to the project at hand.
"Hey, here is your test and here are the answers. You've got one hour" :)
This really shouldn't be a problem for anything other than file inputs. If someone's form is losing submitted information on a validation failure when using an actual HTML submit, then I find it pretty unlikely that they're doing a good job of AJAX submission.
How bad is that really if users are aware of it and they can simply reload the page?
Of course, chat/messenger is something else, but I consider that an exception. (It's easy to build a chat service on top of a static website).
- Every click is a full page load, and you still didn't manage to get caching right, so it takes 2 seconds to load.
- When I have multiple tabs open, your badges and notifications fall out of date, because you never poll for updates.
- If I mis-enter information into a form, your error handling forgets all my information and I have to re-enter it.
- You forgot to update the styles on that rarely-used page, and now it's got half the new CSS and half the old CSS and the point is the header runs halfway down the goddamn content in Times New Roman.
I get it, there are problems with SPAs. But this perfect land of one-page-per-link has real usability problems if it's not implemented properly, and there's a lot of maintenance overhead associated with a sprawling mass of transcluded templates. If we're going to criticize an architecture because it's easy to poorly implement, I don't think "ROCA" or whatever we're calling it has any meaningful benefits over SPAs in the general case.