[userbinator]

It outweighs all the end-user-facing cons by a lot, because companies need us, and our salaries are expensive.

As a user and developer myself, that's the sort of selfish attitude that really really angers your users.

I sometimes wonder if the people claiming to hate client-side technologies or disable JS in their browsers have actually ever had to build a complex website to put food on their table. My bet is the answer is often no, or they are a contrarian in general.

I've worked on "complex"[1] websites in PHP, all static/server-side rendered; zero need of JS, near instant load times, ultra low bandwidth and server CPU utilisation, and don't even need to think about "browser support" because it'll be usable with anything from the past two decades.

[1] complexity in terms of features and usefulness, not in terms of how much code and resources it needs. Unfortunately a lot of developers seem to think complexity as in the latter is a good thing.

[pvg]

zero need of JS

XHR was invented because without it, Microsoft couldn't make a web-based email client that behaved the way users expected an email client to behave. 20 years ago. I'm not sure you can reasonably claim this stuff is not also strongly driven by the expectations of users and and the desire to meet those expectations.

[TeMPOraL]

I'd like to know which users desired a web-based e-mail client 20 years ago. It is my impression that this kind of software is very much push, not pull - i.e. the idea comes from the vendor, not from customers expressing a demand. Which is not a bad thing in itself (a big part of progress is speculative creation); I just don't like the unspoken assumption that companies do things because customers want them to, it's not always true (almost never in B2C).

[pvg]

I'd like to know which users desired a web-based e-mail client 20 years ago.

Millions of them, by then.

https://en.wikipedia.org/wiki/Outlook.com#History

See also Rocketmail.

20 years ago, the market for web-based email was well-established, not some push experiment.

[eitland]

Many of us only used it because it was free/available for everyone and we were students or stuck in another situation were it was the only option. If there was both a webmail interface and imap we chose imap.

Some of us still to this day prefer imap/jmap/exchange if the server support it in a meaningful way.

[mavhc]

those crazy users, not wanting to install, configure and update software, download their emails and make sure their backups work, and just get on with actually reading their emails on whatever computer they wanted

[TeMPOraL]

Those crazy users who then cry, "what do you mean I've lost 10 years of e-mails forever, becuase my daugher commented with an emoji on a YouTube livestream, and Google decided to go nuclear everything associated with that account?".

Cloud services aren't more reliable than owning your data. They're just unreliable in a different way. You need backups anyway.

[mavhc]

That happens less often than people's computers dying.

Which emoji did she use?

[danjac]

Perhaps the SPA pattern, for all the justifications from developers (and yes, of course there are genuine cases where it's a good fit) is really an outcome of Conway's Law[1] in action. In a large enough organization, you corral your dev teams into isolated, specialist "backend" and "frontend" groups which end up communicating largely through decoupled APIs. As with microservices, it's not really about whether this is the most efficient and user-friendly approach to delivering useful apps to the end users, but how much this architecture mirrors your company's org chart.

[1] https://en.wikipedia.org/wiki/Conway's_law

[MattGaiser]

> As a user and developer myself, that's the sort of selfish attitude that really really angers your users.

A user is only unhappy if they withhold some money over it.

[TeMPOraL]

As others said, user != customer. A big chunk of software (perhaps the majority) is bought by someone other than the end-user. Think workplace, or all the OEM garbage that ships with your phone.

On top of that, on the mass market, customers don't have a meanigful choice. They can't signal desires in the entirety of concept space; they choose out of what's available on the market. Which means the choice really lies with the vendors.

[goatinaboat]

A user is only unhappy if they withhold some money over it.

Yes and no. If you are selling to the CFO on the golf course, then you get paid and all the actual users are unhappy. This is the entire ERP industry.

[luckylion]

And they do, even if it's not a conscious decision. Most large scale experiments see bounce rate increase and revenue decrease with page load time. More load time because "it's easier to develop this way and it saves developer time, which is expensive" means more bounces and less sales.

Of course, that only matters at scale. If your site never takes off, optimizing for user experience (instead of developer experience) wouldn't have paid off. On the other hand, maybe putting your users second lowers the chance of it being well received.

[millstone]

Right. If your product is paid for in eyeballs, then by the time users have perceived your low quality, they've already paid.

[TeMPOraL]

This (and related phenomenon with subscriptions) is arguably a big drive for the software becoming increasingly infantilized; shiny toys instead of useful tools.

[djrobstep]

What an absolutely sociopathic attitude

[onion2k]

and don't even need to think about "browser support" because it'll be usable with anything from the past two decades

Not including a patchy or high latency internet connection though, right?

[TeMPOraL]

I'd say especially including these; plain, old, JS-independent, server-rendered sites handle these conditions much better than modern SPAs.

[onion2k]

I don't agree. A classic PHP-as-it-was-used-15-years-ago site either loads or fails for every user request. That isn't good enough any more. An SPA either loads or fails for the first request, but then they do a lot of things that can mitigate a patchy internet connection - prefetching content, offline mode, bundling things to reduce the number requests, etc. A server-side rendered app doesn't take advantage of those optimisations, although things like rel="prefetch" are starting to get used more which helps a lot.

Like the article suggests, there's definitely some middle ground where enough of the site is loaded on the first request for it to work, and then more things can happen in the background to make subsequent interactions faster and more reliable. That isn't a pure SPA and it isn't a pure SSR site either.

[xorcist]

Very few SPAs give proper user feedback. There could be any number of silent errors in the background.

It's even evident for relatively basic things such as infinite scroll. Users on sketchy connections won't even see all the items in a web store if their mobile connection is sketchy enough, and they will never even know it.

There are some real costs here. Had anyone seriously A/B tested these things they wouldn't be so widespread.

[onion2k]

Very few SPAs give proper user feedback. There could be any number of silent errors in the background.

Badly built apps that ignore errors and don't work well for users are certainly not limited to SPAs, and blaming SPA tech for that seems a bit unreasonable.

[TeMPOraL]

For "classical" websites, it was not possible to screw it up. The feeback was always there - clear, unmistakable, universal across sites. Boom, "No Internet", site's gone. Press "back" to get the previous state and click again/resubmit later. And it was nice that you could actually do that - use the "back" button to revert to the last correct state even without an Internet connection. Can't do that with almost any SPA these days.

I suppose it just boils down to the fact that with more freedom comes more freedom to fuck things up. But when you see an industry systematically fucking things up, and being driven by economic incentives that encourage fucking things up, one has to wonder whether some of those freedoms should be taken away.