Or more likely I’m just bitter and old.
Farmville Devs <- Facebook Devs <- Chrome Devs <- OS Devs <- Chip Devs <- Factory Devs
The abstractions are not, however, good enough yet.
Once you start adding conditions and context to the heuristic, it starts to look a lot like a Design Pattern.
What I was describing could maybe be conceptualized as multiple applications that serve one larger site. You have the public facing staticly rendered site, built in whichever way, but that ultimately has accessible rendered content on page load and as fast as possible. Then you also have interfaces to the data that is rendered there, which might be completely separate codebases for different purposes.
These could also take place in things like a reporting portal inside a company, where stakeholders need to regularly see static or filterable reports of pre-rendered data, and then you have other internally available apps that different departments can use to manipulate that data in ways that they can easily receive immediate feedback on whether or not it's valid or how it looks etc..
Maybe we don’t talk about the same thing, but isomorphic code with react is great for websites too: server side render, instant page change on client side. Reuse of exact code. Huge benefits.
As a frontend dev this has always been my stance, but I’ve been consistently shunned for it.
How much of that was naïveté vs. misaligned incentives I’m not sure.
In any case, these thing always leave me with the feeling the industry is getting way too saturated with script kiddies. It just feels immature, and the culture that’s grown around web dev seems to reflect that. Or more likely I’m just bitter and old.