I'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]
The future (and the past) of the web is server side rendering
151–160 of 371 posts
Re: The future (and the past) of the web is server side rendering
#152“Server side rendering” is such a terrible term. The server isn’t doing rendering, the browser is. The server is sending a complete well-formed DOM for the client to render. Well done, modern devs! A plain .html file does that. I really hope some of the heavy front-end frameworks die a death, some common sense prevails, and we get a lighter, faster loading, more responsive web. I can dream.
How can a plain html file pull content from a database?
Re: The future (and the past) of the web is server side rendering
#153Much 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/
Completely agree. For me the biggest advantage is eliminating the need to learn, debug, and maintain components on an additional frontend framework (Angular/React/Vue). I just built a rough toy project [0] that was my first time with FastAPI and HTMX and it was fun and fast. [0] https://www.truebuy.com/ (like rotten tomatoes for product reviews but just for TVs right now)
It's consumer reports but faster :)
Re: The future (and the past) of the web is server side rendering
#154Much 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?
Re: The future (and the past) of the web is server side rendering
#155“Server side rendering” is such a terrible term. The server isn’t doing rendering, the browser is. The server is sending a complete well-formed DOM for the client to render. Well done, modern devs! A plain .html file does that. I really hope some of the heavy front-end frameworks die a death, some common sense prevails, and we get a lighter, faster loading, more responsive web. I can dream.
> Well done, modern devs! A plain .html file does that And then if you want to take that rendered data and do anything interactive with it you have some js soup of parseInt(document.getQuerySelector(".item > .item__quantity") all over the place. HN has some weird hate for this new server side rendering, when it's really the smart thing to do and equivalent to what any app is doing: the "frame" of the app is downloade…
> And then if you want to take that rendered data and do anything interactive with it you have some js soup of parseInt(document.getQuerySelector(".item > .item__quantity") all over the place.
Nothing stops a dev from providing both a server-side render and an API endpoint, for those that don't want the JS soup. In fact, such a design is not uncommon, and it's fairly straightforward to write a backend interface that both the server-side rendered endpoint handler and the API endpoint handler can use.
> HN has some weird hate for this new server side rendering, when it's really the smart thing to do and equivalent to what any app is doing: the "frame" of the app is downloaded once (and we can send the initial data with it), and then it can become interactive from there. e.g. if the data needs to be reloaded we can make a small JSON request instead of reloading the whole page and re-rendering it.
The "smart" thing to do depends on what your requirements are. For minimal latency, server-side rendering tends to fare much better, as it requires only one round trip to fetch all the necessary information to render the page contents.
Re: The future (and the past) of the web is server side rendering
#156The future of the web is most web developers losing their jobs for failing to be good stewards of their platform.
Re: The future (and the past) of the web is server side rendering
#157Does anyone know the stats about what's being served?
For things like blogs, server-side HTML with a sprinkle of client-side Javascript (or WASM) makes a lot of sense.
But for applications, where you're doing, you know, work and stuff, in-browser HTML makes a lot more sense.
The thing is, as a developer, most of the work is in applications. (It's not like we need to keep writing new blog engines all the time.) Thus, even though most actual usage of a browser might be server-side HTML, most of our development time will be spent in in-browser HTML.
Re: The future (and the past) of the web is server side rendering
#158This is why I'm really excited about htmx [1]. No need to write isomorphic javascript at all. You can still use server side templates but have interactive web pages. [1] https://htmx.org/
It really is so terrific. After using it for over a year, I agree with the creator's of htmx when they say that this is how web development would have been if HTML as hypermedia was continually improved all these years.
When you start using htmx, you raise your eyebrows and think - hmmm this could be something interesting. When you use it for many months, you then open your eyes very wide and think - this is something special! In hindsight is so damn obvious, why didn't it happen much earlier?!?!
Re: The future (and the past) of the web is server side rendering
#159The 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?…
[deleted]
Re: The future (and the past) of the web is server side rendering
#160Earlier quoted context omitted.
Well, I wouldn't use such a website anyway (especially a document converter -- that is better done using a real application), regardless of where the processing was done, unless I was very certain that the website was trustworthy. For one thing, even if the website purports to not move my data to their servers, how do I know they're being truthful without going to extremes such as sniffing traffic? There have been pl…
You can swap out my examples for anything really. The point is the more work the server does, the more data you have to send them to do that work. As far as trusting it's client-side only, opening the network tab in devtools would suffice. If you think they broke the sandbox (Google would pay millions for that!), yes sniffing would be the next step. At least you have a sandbox on web, you usually don't have that for…
With a couple of necessary exceptions, I don't use websites to store or process personal data, so that's not really the use case I have in mind.
What I have for native applications that I don't for the web is the ability to firewall off the native applications.