I think it's a bit ridiculous to call it "server side rendering". It is called HTTP
It's called sending HTML from server.
aka a protocol for transferring hypertext from server
The future (and the past) of the web is server side rendering
221–230 of 371 posts
Re: The future (and the past) of the web is server side rendering
#222Earlier quoted context omitted.
Yes indeed! The core aspect, however, is that your server is returning fragments of html that htmx places in the DOM extremely quickly. They have pretty good examples on their site illustrating some "modern" UI patterns. As an example, you may have an HTML table on your page that you want to insert a new row for some reason on let's say a button click. You place some attributes that htmx understands on your button th…
Sounds pretty slow. At least a second before the UI responds to any action?
You for sure wouldn't want to build a spreadsheet type app with htmx because of that aspect. Many other types of web apps can benefit from the simplification of the architecture, however. And like my paging example, many times you need to go to the server anyway. But sure, like anything, I wouldn't use htmx for every situation.
Re: The future (and the past) of the web is server side rendering
#223Earlier quoted context omitted.
Yes indeed! The core aspect, however, is that your server is returning fragments of html that htmx places in the DOM extremely quickly. They have pretty good examples on their site illustrating some "modern" UI patterns. As an example, you may have an HTML table on your page that you want to insert a new row for some reason on let's say a button click. You place some attributes that htmx understands on your button th…
Sounds pretty slow. At least a second before the UI responds to any action?
True BizarreByte. I love how htmx let's you easily add animation indicators on actions, because many times it's too fast due to the small chunks coming back and getting placed so quickly in the DOM
Re: The future (and the past) of the web is server side rendering
#224Idk Im not so much into web development but isn't ssr rendering much more expesive? I just move all the processing/calculation to my/server side instead of the clients. This means for a business with many clients I have to pay for the stuff that the clients themselves could have done instead...
Compute power is absurdly cheap these days, especially for something as simple as SSR of web pages
Re: The future (and the past) of the web is server side rendering
#225Much more prefer the htmx way of SSR parts of the page dynamically. Also, totally server-side agnostic, so we can use what we prefer. Clojure in our case. https://htmx.org/
HTMX has to be my favourite thing web related. I never really got React and always found it a bear to setup and use, but HTMX and server ride rendering? Easy and extremely productive for a non-frontend guy like me.
I really hope it or something like it becomes popular long term.
Re: The future (and the past) of the web is server side rendering
#226Earlier quoted context omitted.
As with SSR vs CSR in general, I think which is best depends on how much interactivity there is on the page. And also how much can be done entirely on the client side (it is possible to cache data client side too and make the app work entirely offline). As an extreme example, something like https://www.photopea.com/ would be a nightmare to use if it was server-side rendered. Or consider something like Google Maps. Fo…
> how much interactivity there is on the page Yes, and also how much interactivity is better served by a thick browser-based client than by a round-trip to the datacenter. In practice, many Web applications we encounter daily have relatively low interactivity (where something like Google Maps or the Spotify Web player score as "high"). And then they are implemented using thick frameworks that are frequently slower th…
> However, most Web applications that we encounter frequently are more like e-commerce, blogs, recipe websites, brochureware sites, landing pages and the like that absolutely are primarily about presenting information. Using thick browser clients is a sub-optimization for most of those Web uses.
I mean sure (although I'd probably make a distinction in the terminology and call those websites as opposed to web applications). I don't see many of those kind of websites using client side rendering though. I think the grey area is sites like Gmail which do have quite a bit of interactivity but would also be workable with SSR. Personally I think they're generally better using CSR. If done badly as the current gmail is then it makes things slow, but if done well (like the older gmail!) then it's faster.
Re: The future (and the past) of the web is server side rendering
#227IME the big gains nearly always come from how data is surfaced and cached from the storage layer.
You may get some nominal gains from sending less JS or having the server render the html, but IME the vast majority of apps have much bigger wins to be had further down the stack.
Re: The future (and the past) of the web is server side rendering
#228Re: The future (and the past) of the web is server side rendering
#229I've been using svelte for years and love it.
I've been using sveltekit for years and still struggle with it.
With sveltekit, I'm never really sure when to use prerender. I'm never sure how and where my code will run if I switch to another adapter.
With pure svelte, my most ergonomic way of working is using a database like pocketbase or hasura 100% client side with my JavaScript, so the server is a static web server. It's got real time subscriptions, graphql so my client code resembles the shape of my server side data, and a great authentication story that isn't confusing middleware.
I'm sure SSR is better for performance, but it always seems to require the use of tricky code that never works like I expect it to.
Am I missing something?
Re: The future (and the past) of the web is server side rendering
#230I've been using svelte for years and love it. I've been using sveltekit for years and still struggle with it. With sveltekit, I'm never really sure when to use prerender. I'm never sure how and where my code will run if I switch to another adapter. With pure svelte, my most ergonomic way of working is using a database like pocketbase or hasura 100% client side with my JavaScript, so the server is a static web server.…
In Sveltekit it's SSR on first load and then client following as the components in that page change, as far as I know. How SSR is done, not where it's done, depends on the adapter. It's always server first unless you specially opt out.