"But all that code is necessary to make our sites work the way we want."
Yes, but, on the other hand, is it?
The future (and the past) of the web is server side rendering
161–170 of 371 posts
Re: The future (and the past) of the web is server side rendering
#162I'm always amused to hear web types speak of grinding HTML, CSS, and JavaScript down to somewhat simpler HTML, CSS, and JavaScript as "rendering". Rendering, to graphics people, is when you make pixels.
It's consistent with the use of 'render' or 'paint' to describe what a UI component does to, well, render itself. For most UI systems this has involved higher level APIs than directly pushing pixels for a long time.
Re: The future (and the past) of the web is server side rendering
#163I'm always amused to hear web types speak of grinding HTML, CSS, and JavaScript down to somewhat simpler HTML, CSS, and JavaScript as "rendering". Rendering, to graphics people, is when you make pixels.
[deleted]
Re: The future (and the past) of the web is server side rendering
#164If you don't do server side rendering, you don't (almost) automatically get a set of nice REST endpoints that return JSON/XML/ETC?
I get that the abstraction might be nice for security, but at least for corporate intranet applications, a nicely structured, secured (e.g ODATA) webapi you query for client side rendering has the added benefit that it can be invoked programmatically with REST by other authorized parties.
Obviously, you want the standard DDoS and security protections, but this fact alone, has turned me off server side rendering alone.
Isn't it also nice from a computation cost standpoint to let the client do the rendering? I suppose UX could suffer and for external facing apps, this is likely of the utmost importance.
Happy to be educated if I'm unaware of something else.
Re: The future (and the past) of the web is server side rendering
#165Much 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/
So any change in the UI means sending a request to the server, waiting for it to render, and waiting for that response with the new markup?
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 that will call for the TR HTML chunk from the server. You can imagine replacing all the rows for a paging click etc.
Again check out the example for cool stuff.
Re: The future (and the past) of the web is server side rendering
#166The article seems to contradict itself: The first example shows the server rendering a handlebars template and then sending that as a response to the client -- it's then stated that this "isn't true SSR" Then the same thing is done without a template language, using strings instead, and this is some different kind of SSR altogether and the "true SSR". Which also seems to insinuate that only JS/TS are capable of SSR?…
I'm not sure it's a "contradiction" so much as a weird bending/re-branding of the term "server-side rendering". One of many issues with the article
Re: The future (and the past) of the web is server side rendering
#167Idk 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...
Re: The future (and the past) of the web is server side rendering
#168Much 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/
So any change in the UI means sending a request to the server, waiting for it to render, and waiting for that response with the new markup?
I built a tiny deno+htmx experiment, you can check it out at https://ssr-playground.deno.dev, it's all server-side rendered html with htmx attributes sprinkled around.
Re: The future (and the past) of the web is server side rendering
#169If you don't do server side rendering, you don't (almost) automatically get a set of nice REST endpoints that return JSON/XML/ETC? I get that the abstraction might be nice for security, but at least for corporate intranet applications, a nicely structured, secured (e.g ODATA) webapi you query for client side rendering has the added benefit that it can be invoked programmatically with REST by other authorized parties.…
As an example, Ruby on Rails makes this relatively trivial using respond_to https://apidock.com/rails/ActionController/MimeResponds/resp...
Re: The future (and the past) of the web is server side rendering
#170I may be misunderstanding this, but isomorphic SSR sounds an awful lot like the Java Server Faces concept of a server side DOM that is streamed to the client. JSF was largely dropped by java developers because it ended up scaling poorly, which makes sense since it violates one of the main constraints that Roy Fielding proposed for the webs REST-ful architecture: statelessness. An alternative approach is to retain the…
Slightly off topic, but I found JSF the most productive out of any framework. It has some not so nice edge cases, but when you are “in the green” and you don’t need to scale to infinity (which, let’s be honest, is the case most often than not) it really is insanely fast to develop with. For internal admin pages I would hardly use anything else.