5 ms·
I never really got the appeal of SSR, and I've implemented it a cuouple times with Next.JS and things like htmx. Can anyone come up with the ideal use case whe
by moralestapia 2y ago
I never really got the appeal of SSR, and I've implemented it a cuouple times with Next.JS and things like htmx.
Can anyone come up with the ideal use case where SSR shines? I'm willing to buy it if I see it.
- recursivedoubts 2y agowhen your app is mostly text-and-images https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/when-to-use-hypermedia/
- grey-area 2y agoWebsites. Most websites are significantly simpler to build and maintain with SSR and traditional tools. An entire generation has forgotten this it seems and still thinks in terms of JS frameworks even when trying SSR. As one example take this website, which serves the page your wrote your comment on using an obscure lisp dialect and SSR.
- moralestapia 2y ago>Websites. Wait, is SSR a thing outside the context of websites?
- grey-area 2y agoNo, that's the primary use case. Works pretty well and has done since 1991. The majority of websites use SSR.
- moralestapia 2y agoWeird.
- int_19h 2y agoThere was a time when SSR was the only option. All early web apps were SSR. It gets rather painful though, which is why we don't do that anymore.
- ezekiel68 2y agoWhat is the specific pain? Are you just referring to dynamic content on the client in general or different issues?
- int_19h 2y agoThe oldest web apps - web email clients being probably the canonical and most familiar example - didn't do dynamic refresh at all, because there was no way to fetch data from the server, so you couldn't do it even with JS. Any user action that required any part of the page to be updated involved a (very visible) whole page refresh. You could limit the scope of refresh with frames to some extent, but it was still very noticeable. Microsoft introduced XMLHttpRequest in 2000 for this exact reason - its original purpose was to allow the newly introduced Outlook web UI to fetch data from the server and use that to update the DOM as needed. This was then enthusiastically adopted by other web app authors (most notably Google, with GMail, Google Maps, and Google Talk), and other browsers jumped onto the bandwagon by providing their own largely compatible implementations. By 2006 it was a de facto standard, and by 2008 it was standardized by W3C. The pattern was then known as AJAX, for "asynchronous JS and XML". At first web apps would use the browser API directly, but jQuery appeared right around that time to provide a consistent API across various browsers, and the first SPA frameworks showed up shortly after (I'm not sure if I remember correctly, but I think GWT was the first in 2006).
- ezekiel68 2y agoOh, I'm familiar with the history. I was thinking maybe you had similar concerns (lack of dynamic content) with something modern like HTMX which is a modern take on Server Side Rendering -- but it does in fact include mechanisms for AJAX-like calls.
- 2y ago
- littlecranky67 2y agoI use nextjs with static exporting (so technically no SSR). You get SEO and quick first page loads. Once the user is logged in, I use CSR only and the data loads via REST.
- nop_slide 2y agoSEO. I run skatevideosite.com and accidentally did the first rewrite when I took it over in react because that’s all I knew. I absolutely tanked the seo. Rewrote it in rails and got everything back in shape and it’s been a fun experience!