Extreme Server Side Rendering
46 points by hmac
46 points by hmac
IIRC this is actually not a new technique, and was used in the past for live updates in some places, all the way back in early IE days.
I thought "surely they're just misremembering document.write()", but no, I forgot about the "forever frame", which even got a dedicated nginx module https://github.com/wandenberg/nginx-push-stream-module/blob/master/docs/examples/forever_iframe.textile
If I'm understanding right, this is also the same method as described here previously for live-updating content on a page without any javascript
I thought I remembered some other article posted to Lobsters within the last year or so, describing a similar approach for allowing a responsive form using only HTML, but I'm failing to find that...
It upsets me that contemporary Web developers misuse the term "rendering" to mean "HTML generation". Browsers have rendering engines that convert HTML, CSS, and other features into an interactive document. Both server-side and client-side applications can generate HTML to incorporate into the rendering process.
Using specific terms to mean specific things makes this process easier to understand. I have been developing Web applications for thirty years, but I imagine some newcomers will find the word "rendering" in Mozilla's documentation for Client-side rendering and Rendering engine. I don't blame Mozilla for this and won't shoot them as the messenger.
This sloppy use of language reminds me of when "responsive" stopped meaning that Web pages rendered quickly following a request and instead that they coped better with different screen sizes.
I think the first time I heard "server side rendering" was in the context of early-ish mobile frameworks where resources were limited on the client so the server was asked to do the rendering. And for a very, very long time, I believed this meant that the server was doing the work of the browser (positioning elements, applying styles, etc.) and basically returning a "bitmap" to the client.
Big surprise when I later learned that rendering just meant HTML generation as in the older days. So yeah, this term is weird.
I know what you mean, but using "rendering" to describe templating or any kind of general compilation is a normal and common practice.
I agree it has become common and I dislike that. When I gave a conference talk in 2003 about Web templating using Perl I covered three different templating engines: Template::Toolkit, HTML::Template and XML::LibXSLT which wraps Gnome's libxslt. None of them use the term render: they use process, output, and output respectively. PHP, from around the same era, uses output.
Why do you think an abstract, generally applicable concept like "rendering" should be restricted to a narrow sense that's relevant to a single community?
Rendering is a great term to use whenever a representation gets transformed into something more concrete. A User object becomes a nested group of HTML tags representing the user. Then those HTML tags become rectangles and fonts. Then those rectangles and fonts become texture buffers and shaders. Then those buffers and shaders become bits in the display buffers.
It is perfectly reasonable to call any one of these steps "rendering".
To my ear, "rendering" is a useful opposite of "parsing". Parsing turns unstructured soup into a nice traversable structure; rendering melts it back down. :)
Welcome to linguistics. Are you familiar with what a polyseme is? Words get appropriated all the time by being applied to similar concepts. All language is "sloppy" in the way you're talking about. This is how humans communicate.
Are you familiar with what a polyseme is?
No, that's a new word to me.
Before I chose computer programming as a career, I studied Economics as a degree. Early on, I learnt that that economists use the word "scarcity" in a different way to how the general public use that word in common language. I have since encountered other words that have different meaning for practitioners in a specialism and the general public.
Yes, language happens, and I can't change that.
But I can suggest that Web development would benefit from using "render" more specifically, knowing that Web developers will mostly ignore that suggestion. And now I know a useful word to describe this happening. :)
As a fan of Moby Dick, it upsets me that this word is used for anything other than the process of slowly cooking blubber until the fat melts out of it.
It's not whale-specific tho. I can't easily buy schmaltz where I live, so I get cheap-as-chips offcut chicken skins from my butcher and render them at home.
My fellow bridge architect hated when I would use the word architecture applying to the invisible electrons in my computer. Neither he liked flying high, hot people and of course smashing good music.
On the front-end side, there's no JavaScript or other logic required to render the page. As a result, once the page is loaded, there's no ability for it to be dynamic.
Are front-end developers suffering from some kind of collective amnesia of the distant past of, like, 15 years ago?
Some frontend developers weren't alive 15 years ago. I don't know about you, but I started playing around with plain HTML sites when I was like 9 years old via geocities.
Nevertheless, if that's your specialization then the DOM is your wheelhouse. I can't take the article seriously when it proceeds from such obviously false premises.
I wonder if the author had been exposed to Phoenix LiveView. I can imagine that LiveView was born from similar tinkering
Unlike server side events, I suppose the browser needs to keep in memory everything from the start. Maybe both unparsed and parsed.
Nice! You can actually reset the client state/connection every now and then by sending a tag with
<meta http-equiv="refresh" content="1">
Where 1 means in 1 second (see docs). I normally send it down with a 30 second timer. That way the connection will restart every 30 seconds, this also handles clients getting disconnected (as it's effectively a retry).
A lot of these tricks (early flush with chunked encoding) were actually used by google to speed up search results back in the day.
If you're happy to add a little client side JS you can use something Datastar which has a morph algorithm on the client (helps keep focus states etc) and SSE.
If these don't render for you it's because I only support zstd compression (and some older versions of safari don't support it).
Speaking of compression another pro tips is to use either brotli (if you want to support old safari) or zstd compression on the stream/chunked response. This will help a lot with the latency as streaming compression is crazy good (and will keep even large responses under the ethernet 1kb MTU).