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!
@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
Alex Russell
Aaron M
Nick Chomey
yumaikas/sakiamu