>So far I haven't met a user who asked for ads

By voting with their feet in favor of free ad-supported services, they are essentially asking for ads.

Perhaps this will change in the future. Twitter is said to be experimenting with offering subscriptions, akin to what Substack or media companies do. But the general arc of the internet up until now has been toward free-with-ads.

IMO, phone apps changed users’ expectations for websites. They want the same interactivity on Facebook.com that they get on the Facebook app. Same with Kayak (or whatever travel site people use these days). Same with Google Maps. However, the vast majority of sites are totally fine as static pages, as long as the user has a fast connection that makes loading between pages imperceptible.

But that does not mean expectations of web users have to be thrown under the bus. Such as, you click on something by mistake and try to fix it by using Back button. With facebook nope, if you forgot to open the link in a new tab, the original view is irretrievably lost. You sometimes can't even scroll back to review something, whole page gets reloaded and it vanishes.

Supposedly one-page apps are meant to improve latency and interactivity, but FB is slow as molasses and frustrating regardless.

FB's terrible back functionality is their own fault since libraries like React Router give you a ton of control over back/forward behavior.

As for FB's slowness, SPAs are hard to do well when you have a lot of live data all over the page. You can get clever with optimistic backend calls and caching, but in the end you still have frequent state changes.

Users want infinite scroll to be fast, so you need over-eager loading _in case_ they scroll. Add over-eager loading all over the page (in case they click on a user profile, in case they click on FB Marketplace, etc.) and you have a recipe for a CPU hog.

Well, this goes even deeper.

Historically, the Web started out as hypertext: static text documents which were interlinked. But right off the bat, there was this drive to create "Rich Web Applications": the browser as an alternate to applications which you don't need to install on a "gatekept" operating system (Windows and OSX).

Flash, Silverlight, Java Web Applets,... All those browser plugins were exactly meant to achieve this. But none of them quite fully lived up to the potential of the idea.

There's a good reason why Microsoft in the 90's wanted to dominate the browser market: because it was a potential threat to lose control over what users could or couldn't do with their computers.

Things changed when mobile devices landed, and Google jumped into the browser market. Suddenly, building a web experience no longer wasn't as "trivial" as making sure your CSS worked on Explorer, Safari and Firefox.

At the same time, the "Application Wars" moved into the mobile realm where there was this battle between "native applications" and "web based applications". The latter was the notion that you could get the same functionality without having to install an app from an app store on your device.

Those dynamics of competition were - and still are - a driving force behind innovation that made browser engines ever more powerful and complex.

"Front-end" as a dedicate discipline didn't truly exist before the 2010's. You were a web master, a web developer, a web designer or something of the sort. But as soon as that complexity did hit, "front end engineering" became a specialization. Where it is really a cottage industry build on top of those complex browser engines, API's and sprawling specifications. For better or worse.

> However, the vast majority of sites are totally fine as static pages, as long as the user has a fast connection that makes loading between pages imperceptible.

Exactly. And that's still a completely valid use case.

The problem is how the industry has shoehorned an entire generation of front-end developers into believing that you need all those gizmo's to write HTML, CSS and JS.

When you're a budding front-end engineer and you land your first job from your internship, you're not even going to question the tools used by your employer. You're just going to use them because all you see is a big black box of complexity and nobody explains the history that has created that box.

I think that's why people will, like the author, ultimately drop out. When writing code for a living turns into this obligatory, rote exercise of juggling this mass of dependencies and complexity, with little to no time or authority to question why they need all this in the first place.

> I think that's why people will, like the author, ultimately drop out. When writing code for a living turns into this obligatory, rote exercise of juggling this mass of dependencies and complexity, with little to no time or authority to question why they need all this in the first place.

This is why I'm optimistic that some small companies or startups will look at this black box, go "nope" and look at simpler alternatives : maybe hotwire or htmx, or some other tech or architecture allows them to build the things they need to build quickly and efficiently and outpace their complexity-bound competition - much like Rails was the alternative back in 2004 to the J2EE behemoths of the day that the industry considered the "right" way to build a web app.

I think it's more likely that faster CPUs will make CPU hog pages less noticeable. Companies keep making bloated pages but users will decreasingly care.

It's not about the cost of the end-user bloat (although that's a problem), but the cost of development and maintenance required by complex front-end frameworks and architectures.

I would say both. User in the sense that people expect the web to behave and be just as rich and fluid as a native app (and will often leave or mistrust you otherwise) and Client in the sense that having a rich web experience drives revenue and whatever other business metrics.

> it is staggering how easy it is to break many of those sites just by resizing the browser window.

I should say that a responsive website does not actually mean a website that responds to resizing the browser window - and that should not be taken to mean it's "broken". Saying that makes you sound like a typical sweatshop PM or stakeholder :) - i won't belabour the actual meaning here.

> I should say that a responsive website does not actually mean a website that responds to resizing the browser window

It does though, at least indirectly. If the point is to handle different screen sizes and resolutions properly that also has the side effect of handling window resizing; and if one doesn't work correctly the other will most likely have issues as well in some situations.

You can pick apart words and meanings as much as you want - a UI that stops fully functioning after the user makes a valid input I consider it broken. Hopefully you wouldn't call it "working as intended" either when a site becomes unscrollable, freezes up or literally moves sideways out of the browser's viewport when you type in a text field.

Resizing a window is not a weird edge case, it's been a basic UI feature for decades, supported even on some smartphones and tablets, and desktop applications have been able to handle it fine.

No what you are talking about is called fluid design not responsive. So whether a website responds fluidly to browser resizing is a design decision and not indicative of something being broken. This is such a common and frustrating misconception.

Sure, you can call not supporting one of the most basic UI features a "design decision", but it's a terrible decision and it won't protect you against valid complaints from users, just like apps like Skype got complaints for mishandling the window's close button.

Intentionally broken is still broken.

> and will often leave or mistrust you otherwise

Oh bullcrap.

This is just a rationalization from people who like the shiny.

> So far I haven't met a user who asked for ads, unmuted autoplaying videos, popups, tracking, loading screens, and UI that's basically broken by design.

What does that have to do with React and others? Tracking and ads are a regulation problem, pop-ups and auto-start videos are user-agent problems, and wait... loading screens? I don't understand, where do you see a loading screen in a normal web page? I mean in an SPA, sure but that's just bringing rendering to the client and people have been doing it since the invention of AJAX.

React and others didn't make the impossible possible, they just increase the development speed and make it much easier to manage complex state.

So, the post is against the complexity in development, you are against the complexity in the average website. I'm suggesting that the first one is neither the reason for the second, nor the enabler, and you can see that kind of user-hostility even in web-sites made with mootools, let alone jQuery or react.

To be honest, I see those even less in modern SPAs. Usual suspects are sites which load every possible js lib in the universe until some integration works and they can display all the ads.

There seems to be a confusion here.