These skills seem to heavily prefer JS when plain HTML would do, in some cases just because it "looks less clobbered". Like really, if you are on a js front end heavy shop, this probably matches your mental model. If you prefer rendering on server and only use js for actually interactable elements, look elsewhere
> If you prefer rendering on server and only use js for actually interactable elements, look elsewhere
Server-side rendered HTML is not plain HTML. Static HTML is always an option (the right one).
Failing that, I would strongly prefer a JS-heavy SPA instead of anything rendered on a server. It's unquestionably the lesser evil.
I would have been just as right about this a decade ago, but anyone writing an SSR project today in 2026 tends to be naive about the realities and pitfalls of web dev.
My agent briefs tell them to not trust memory/knowledge of frameworks and to actually read the installed versions. It works well so far. At one point, there was a framework (Next.js) behavior that differed from what was written in documentation, so I pinned a failing test as a known defect so that I could detect when it went back to "working as intended."
How do you keep your guidance tied to versions of your frameworks/dependencies?
9 comments
[ 4.1 ms ] story [ 33.2 ms ] threadServer-side rendered HTML is not plain HTML. Static HTML is always an option (the right one).
Failing that, I would strongly prefer a JS-heavy SPA instead of anything rendered on a server. It's unquestionably the lesser evil.
I would have been just as right about this a decade ago, but anyone writing an SSR project today in 2026 tends to be naive about the realities and pitfalls of web dev.
How do you keep your guidance tied to versions of your frameworks/dependencies?