It's not so much a disconnect as more of a reluctance to specialize in what is an increasingly legacy/archaic way to build applications. I studied in the nineties and I've seen it all. Server side model view controller style UIs where each click results in a completely new page being fetched that is completely static slowly died over the last two decades plus (ever since MS pioneered XmlHttpRequest and AJAX became a thing in 2001).
Not doing requests via javascript still works. And for quick and dirty stuff where you don't care about how things look and feel it's a perfectly valid way of doing things. A lot of developer tools fall in that bucket. And a lot of developers are in any case a bit challenged on the UX front anyway so there's a good argument for not using too many ways to shoot at your feet. But having every request wiping the current page, scrolling to the top, etc. can be a bit jarring as a UX as well. And there's the whole round trip latency for fetching pages too, which can be noticeable.
In other words, if paying customers are involved you probably should not go there. Mostly people expect things to look and feel nice and have some designers involved with the whole thing.
End users don't care about any of this of course. They also don't care if the app is native, a webapp, or something you could have hosted on geocities 25 years ago. But they do notice if things look dated, crap, or otherwise a bit meh.
They especially don't care how things look under the hood. The whole notion of semantically pure HTML, vue vs. react, and all the other nonsense web developers obsess about. It does not matter to them at all. You could use divs for every freaking HTML element and they couldn't care less. Or render the whole thing with some native UI toolkit to a canvas (which is an option these days). As long as it does the job.
You don't have to do a SPA. But you kind of do have to deliver something that works and looks and feels nice. With WASM, we are kind of getting a lot more ways to do things. The whole game of working around browser quirks and limitations with dom trees, CSS, and what not is not necessarily the way of the future.
My personal issue with SPAs is that the experience is often not really better than the old school way, it's just the the issues and failure modes are different. SPAs tend to be slower to load, break platform conventions by re-implementing browser behavior and they're are more stateful, making invalid states harder to recover from.
Personally, unless the interactivity is needed (i.e. web apps, not web pages), I prefer a more basic site where I can be reasonably sure that UI will work the same way as everywhere else, even if it's not as fluid.
I think that's very subjective. SPAs load pretty quickly on a modern network. It's pretty much a non issue unless you are a bit OCD about such things. And I've seen some nice examples of SPAs that are actually quite nice to use. Mostly we're talking about the content of 2 or 3 floppy disks from way back (I'm old enough to have used those). Even back then that wasn't a lot. Many interesting things required multiple floppy disks.
My observation is that people vote with their feet. Including developers. The developers who complain the most about this stuff aren't actually building a whole lot worth talking about.
Anyway, it's hard to break conventions when the convention has actually been SPAs for quite some time now. Most major websites are simply not very old school at this point, to put it mildly. That stopped being good enough a long time ago.
My issue with SPAs is that I very often end up in an incorrect state. I don't know, maybe I'm using a browser wrong? I'm clicking on things, pressing back and forward, and almost daily in some SPA app I get to either a blank screen or some error. I then refresh, and inevitably lose the state, as the URL would likely not match the latest correct state of the app.
> The whole notion of semantically pure HTML, vue vs. react, and all the other nonsense web developers obsess about. It does not matter to them at all. You could use divs for every freaking HTML element and they couldn't care less. Or render the whole thing with some native UI toolkit to a canvas (which is an option these days). As long as it does the job.
Only if your definition of “does the job” does not include “is accessible to every potential user” or you put in much more effort than you would otherwise have to if you used the web standards as intended.
Not doing requests via javascript still works. And for quick and dirty stuff where you don't care about how things look and feel it's a perfectly valid way of doing things. A lot of developer tools fall in that bucket. And a lot of developers are in any case a bit challenged on the UX front anyway so there's a good argument for not using too many ways to shoot at your feet. But having every request wiping the current page, scrolling to the top, etc. can be a bit jarring as a UX as well. And there's the whole round trip latency for fetching pages too, which can be noticeable.
In other words, if paying customers are involved you probably should not go there. Mostly people expect things to look and feel nice and have some designers involved with the whole thing.
End users don't care about any of this of course. They also don't care if the app is native, a webapp, or something you could have hosted on geocities 25 years ago. But they do notice if things look dated, crap, or otherwise a bit meh.
They especially don't care how things look under the hood. The whole notion of semantically pure HTML, vue vs. react, and all the other nonsense web developers obsess about. It does not matter to them at all. You could use divs for every freaking HTML element and they couldn't care less. Or render the whole thing with some native UI toolkit to a canvas (which is an option these days). As long as it does the job.
You don't have to do a SPA. But you kind of do have to deliver something that works and looks and feels nice. With WASM, we are kind of getting a lot more ways to do things. The whole game of working around browser quirks and limitations with dom trees, CSS, and what not is not necessarily the way of the future.