This post includes recommendations for teams that are procuring websites, and I think they can be summed up as: *buy simpler problems*.
Every feature that gets added via JavaScript is more complex, more expensive, and harder to improve. That means that when things go wrong, they're treble costly to fix because JS is *"f-it! we'll do it live!"* for web development. JS disables or routes around all the ways the browsers try to help.
Let browsers help!
In this sense, progressive enhancement can be understood as *"let browsers help as much as they can, and only add what they fail to provide"*
This leads to simpler, cheaper solutions to common problems. First, because many of the problems you'll end up with are about letting the browser help *more*, and if you haven't YOLO'd your site off a bridge, that's easier to do.
Second, because you've minimized the amount of JS that might be defeating browser attempts to help in the first place.
@slightlyoff "JS is 'F*k it, we'll do it live!' for web development'"
Love this so much.
@slightlyoff Read all four parts, I liked it. Where i have my own mental block is thinking about applications i've worked on, and if it would've been practical to not use an SPA framework. I think this is definitely true for some apps or some parts of all of them. I do need to give these things more of a try. My main worry is about dynamic updates in complex screens, or multi step forms.
I've written the latter in server apps, but found state management more manageable in client side
@agmcleod Check your values.
"more manageable" is a developer-centered claim, not a user-centered approach.
Who do we do this for?
@slightlyoff that's fair. I can see a version of this where we choose a tech much like how people buy a car. They get something to handle that edge case that they maybe drive in once every two years, rather than something that answers the problem better for the other 98%.
Where we could build complex & dynamic submission forms like that in its own contained thing using more robust tools. While the rest of the app sits server rendered as it's much simpler.
@agmcleod Yeah, I try to explain to teams that this diagram might have different implications for different parts of a site; e.g., WordPress is two different apps:
1.) a post viewer with a huge number of page views but very shallow sessions and different data on each page.
2.) an editing and admin interface used by a relatively small number of people, but very intensely.
These differences justify different stacks in each area, and many sites/apps have a similar bi-modal or tri-modal structure
There's also a large and growing subset of WordPress that's genuinely dynamic on the front end - e-commerce, learning management systems, social networks etc.. They're a mess and require an ungodly amount of compute power to provide any form of scale (because nothing can really be cached), but you can still get a Facebook-like site with an activity feed and comments, instant messaging etc..., to load in under 2 seconds with a good server setup because it is ssr html
Expressing deep apprehension about how such a thing could ever come to pass, the U.S. populace confirmed Thursday that it was deeply wary of a suddenly usable website. https://theonion.com/nation-wary-of-suddenly-usable-website/ #satire #ux
Everyone in a site's production chain has agency to prevent disaster
The number of times I tried advocating for this at my previous job 🤷♀️ I didn’t always succeed but talking about it, repeatedly, is useful. “Isn’t that your job?” was always on the tip of their tongue, understandibly (to a degree).
The best argument I found was in the studies that show x% longer page load leads to y% loss of conversion (ie. direct correlation to campaign success, hence revenue).
And the best example for that was the home page, specifically the hero images in a carousel that was under the responsibility of the marketing team. They had tools to upload the images, set the links and alt text in the various languages the site was available in, set a schedule etc so there was no technical involvement at all. Sometimes there would be 6 or 7 images in that carousel, noticeably slowing down page loads on that most important page.
@GuillaumeRossolini @slightlyoff
What's frustrating is that sometimes the bad performance isn't really the result that of a framework used, or true incompetence.
We're now investigating and refactoring an app of ours. There's nothing really too odious... but a death by a thousand cuts: features brought in under impossible deadlines, invalid device assumptions, original architecture not evolving for new requirements etc.
1/
@GuillaumeRossolini @slightlyoff
To the point that our assumptions about perf bottlenecks end up being wrong and appear in a different place from what we originally assumed :)
2/2
@dmitriid @GuillaumeRossolini This is why teams should always prefer simpler problems; when you don't have good operational control and observability, the complexity of the architecture multiplies your costs to remediate.
See also: https://infrequently.org/2022/05/performance-management-maturity/
Despite advances in browser tooling, automated evaluation, lab tools, guidance, and runtimes, modern teams struggle to deliver even decent performance with today's popular frameworks. This is not a technical problem per se. It's a management issue, and one that teams can conquer with the right frame of mind and support.
@slightlyoff @GuillaumeRossolini
Also, as additional data point to "get the team and managers to use cheap phones", I cannot stress the importance of "bad" devices enough.
In our case we develop for smart TVs and gaming consoles. A five-year-old TV on the lower performance spectrum? Well, millions use it, and you have to support and test on it. And that's on top of constraints (CPU and RAM) thar partners impose.
Sadly, people forget about it on the web proper.
@slightlyoff procurement processes, performance budgets, accessibility standards.
You pointed these things out in part 4, and I agree with them.
Frontend frameworks and code bloat are a symptom. I saw the same behaviour in Classic ASP as you're complaining about now in frontend frameworks.
Even without JavaScript, poorly run organisations will just make horrific sites on the server, fixing none of the issues you care about.
@caseyleask There's a noteworthy difference: ASP-era, server-side badness taxes the site owner's resources, and slow DB/service calls perform poorly for users regardless of client device, which is to say, it's a more egalitarian sort of slow.
JS bloat scales in impact with client device properties. That is, it makes an unequal situation worse for those with the least.
Alex Russell
Kristen Grote
Aaron M
Nick Chomey
yumaikas/sakiamu
Sarah E Bourne
Guillaume Rossolini
Stuart 
dmitriid
ygg