This post includes recommendations for teams that are procuring websites, and I think they can be summed up as: *buy simpler problems*.
-
@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.
-
Guillaume Rossolinireplied to Alex Russell on last edited by
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.
-
@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
-
dmitriidreplied to Guillaume Rossolini on last edited by
@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/
-
@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 Russellreplied to Alex Russell on last edited by
@caseyleask The set of organisations that have the operational discipline to program somebody else's slow computer through a straw in JS with high confidence can be counted on two hands without resorting to binary.