> That may not work for a lot of sites that depend on client rendering
Products that depend on client-side rendering don't deserve to have regression-free experiences. You are literally doing layout with javascript and wondering why things get funny on edge case clients.
The web is fucked until it becomes truly popular to build vanilla, SSR applications again. I feel like we are almost at the end of the tunnel of client-side hell, but perhaps some aggressive final pushes could help ship the narrative.
The server is fast. Stop doing your layout on the client. Use media queries to address the wide range of viewport dimensions. You can have a responsive website, installable as a PWA on home screen of any mobile device and also as a 4k detailed desktop layout with 0 lines of JS required. All you have to do is stop outsourcing your independence to framework vendors and pick up the MDN bible.
This sounds regressive and the battle has been over for almost a decade now. Server-side rendering is silly and client-side rendering should not be used for the entire page. Even for complex web apps, the majority of the HTML is static.
The best web experiences are static HTML with client-side rendering only used for the dynamic sections of the page. It's not even a choice to do it any other way anymore if you care about a11y and SEO.
> This sounds regressive and the battle has been over for almost a decade now
This sounds like what google would like for everyone on HN to believe.
Using "a11y" and "SEO" to push bad technology abstractions is tantamount to petty bullying in my view.
Genuinely, I don't understand the position that SSR somehow makes accessibility worse. Can you walk me through how adding more javascript on top somehow solves the problem of making a website compatible with a screen reader?
> Can you walk me through how adding more javascript on top somehow solves the problem of making a website compatible with a screen reader?
I didn't say to add javascript to make the page more accessible. I said that a static HTML page is most accessible and should be strongly preferred over any dynamic content regardless of how it's rendered. Screen readers can misannounce dynamic elements and leave the user confused about the state of the page.
But when dynamic elements do need to be reannounced due to an event, refreshing the page would be a terrible experience since the screen reader loses focus and starts back from the top of the page. Aria alerts also require javascript. It makes perfect sense that if you're pushing out an aria alert with js already that all that rendering logic should also go on the client side.
As for SEO, I'm specifically talking about good metadata in the head tag, a static page that's comprehensible, and a sitemap. Static pages are better than SSR for this because SSR doesn't always respond with the same page for the same URL.
Products that depend on client-side rendering don't deserve to have regression-free experiences. You are literally doing layout with javascript and wondering why things get funny on edge case clients.
The web is fucked until it becomes truly popular to build vanilla, SSR applications again. I feel like we are almost at the end of the tunnel of client-side hell, but perhaps some aggressive final pushes could help ship the narrative.
The server is fast. Stop doing your layout on the client. Use media queries to address the wide range of viewport dimensions. You can have a responsive website, installable as a PWA on home screen of any mobile device and also as a 4k detailed desktop layout with 0 lines of JS required. All you have to do is stop outsourcing your independence to framework vendors and pick up the MDN bible.