I feel old when an article explains that a server can generate HTML and the browser renders the HTML and that this can be done quite efficiently for every interaction with a user.
It’s strange to me that one can be a webdev without understanding that you do not need JS for a web app, although it does improve the UI in some areas.
It feels even stranger that the term server-side rendering became a thing, since the server doesn’t render anything, but just generates HTML and sends it over the wire.
No it is not. Same as videogames generate scenes and videocards render those scenes.
Render is the final step presented to user. Users do not see HTML, they see text, boxes with background colors, buttons, those are html elements rendered for visual consuption.
In the whole React ecosystem render is used as a keyword to produce HTML/DOM abstractions though. For example class based components having the render function.
The rendering you mention never happened anywhere in the React JS code. Browser did the rendering internally.
In React, 'rendering' means creating the DOM nodes and 'painting' refers to browser rendering [1]. So with server-side rendering the DOM nodes are 'rendered' by the server and the browser 'paints' it.
Same here. I remember the days I was new and hip fondly.
I work with frontends among other things so I am semi-aware of the current state of insanity.
I try to not talk too much and go with the flow. The older I get the more software (and business) in general seems like it’s built out of raw insanity.
I feel old too, reading this same argument today. I joined this industry in early 2010 and people were saying the same things about frontend stacks.
Back then, I believed that the people making this argument were onto something, as it felt overly complicated to me as a beginner.
At this point it feels more likely that the people making this argument don't have any kind of experience in frontend development that span multiple teams collaborating on the same UI.
In the backend this was "solved" through mocroservices.
In the frontend you're gonna be in a world of pain unless you're using one of the popular spa frameworks. Well, you're probably still gonna be in pain. It'd just be worse if you didn't use the framework.
I remember using ColdFusion to dynamically render HTML on the server, and still support client side rendering in the client via standard JS if needed.
Times were simpler then, I feel the abstraction was a lot simpler.
I'd like to see the simpler ColdFusion / ASP style model grow with support from smarter back end tech.
The crazy levels of abstraction in the client/server model are just confusing for someone like me, who was quite happy with the older way of doing things.
Web delivery should be about simplicity and maintainability, not seemingly academic exercises in purity, speed, or abstractions.
Well, that's the catch. If you are building marketing web _sites_, then maybe. I made my first website in 1999. But sites never entertained me much, I preferred building apps.
I've even built my first web _app_ using plain JS. It was quite painful. When jQuery came around, it was a miracle. But still, building dynamic forms with dependent fields, multi-step forms etc was quickly becoming chaotic. I was basically doing my own version of htmx, this was sth around 2006.
You could theoretically keep some semi-sane architecture with jQuery and server-generated snippets but it rarely happened in reality.
Enter Backbone. Finally some good code organization for frontend code. A bit of boilerplate, some pandemonium of events in large apps. Still fond memories and pretty solid apps.
When I first saw React I was appalled. What is this ugly XML thing with code inside? That's like php at the turn of the century. But then I've never really liked any templating language so I gave it a try and never looked back. React is going through some weird identity crisis, but I would still pick it up for any serious enterprise dynamic web app. I have high hopes for Solid, which should be React but cleaned from some historical mistakes. But for sure I am not going back to stitching some server generated snippets and quickly hitting it's limits.
I didn't forgot about server generated html. It's fine for a _lot_ of web pages. But let's not pretend that this is some universal goodness. It sucks for dynamic experiences. Htmx is not our lord saviour, it will again quickly become a mess with stringly connected bits and pieces. Just a simple form where sometimes you need to return the forms with errors or successfully update some elements elsewhere: you need to use ugly out-of-band updates. They tout Htmx being the true REST but handling 400s is shit, now you're adding some events and lo and behold, you are back where I was in 2006 with tangled ball of strings.
Django has the function render (it used to be render_to_response) that takes a template and converts it to HTML. So it isn't just the JS people who are using the idea of rendering in this sense. More generally, rendering doesn't necessarily mean something visual; for instance, one may talk about how a phrase in one language is rendered in another language.
(I'm also 39. You and I may see each other at the shuffleboard court soon.)
> It feels even stranger that the term server-side rendering became a thing, since the server doesn’t render anything, but just generates HTML and sends it over the wire.
Meanwhile, someone somewhere is working on a backend framework that streams raw display frames to a lone <canvas> element.
It’s strange to me that one can be a webdev without understanding that you do not need JS for a web app, although it does improve the UI in some areas.
It feels even stranger that the term server-side rendering became a thing, since the server doesn’t render anything, but just generates HTML and sends it over the wire.
And I’m only 39.
reply