Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The absurd complexity of server-side rendering

gist.github.com

Post reply on HN
Print view View original

131–140 of 395 posts

Re: The absurd complexity of server-side rendering

#131

Post by thaumasiotes »

geenat wrote: post #120

https://htmx.org/ Having spent 36+ years in the computer industry, I consider the advent of htmx to be the first thing in web development to to attempt to pull the industy's head out of it's ass. Don't forget to include a solid remake of css in your project like tailwindcss. It also makes code much more readable.

> Read the docs introduction for a more in-depth... introduction.

Heh. This reminded me of http://itre.cis.upenn.edu/~myl/languagelog/archives/000012.h... .

"PERSONNEL WHO ARE NOT AUTHORIZED TO BE IN THE HANGAR ARE NOT AUTHORIZED TO BE IN THE HANGAR"

Re: The absurd complexity of server-side rendering

#132

Post by mekster »

mst wrote: post #105
gmfawcett wrote: post #92

Earlier quoted context omitted.

You sound like me, but ten years ago. :) I used to have a similarly negative and narrow-minded perspective about PHP, but my colleagues and their outstanding work have enlightened me.

I am entirely unfond of PHP as a language but Laravel - and competently written apps that use it - are damn impressive nonetheless.

If you can't like the current PHP, there's probably no language that will make you feel too well. What exactly is so bad about it?

Re: The absurd complexity of server-side rendering

#133

Post by tiberriver256 »

bob1029 wrote: post #11

I've been saying it for years - the hard part is not "server side" vs "client side", it's making sure the state stays consistent between those 2 buckets. If you want to remove the hell from your life, you need to be all in on one or the other. For us, we've been keeping all state server-side using things like Blazor and hand-rolled js-over-websocket UI frameworks. We never have to worry about more than ~10k users, so…

Blazor Server and other HTML over the wire frameworks (Livewire, Hotwire, HTMX, etc.) are the new sweet spot for a lot of LoB web applications I think.

Re: The absurd complexity of server-side rendering

#134

Post by Widdershin »

AYBABTME wrote: post #51

I find this a very insightful application of the concept of colours to look at the problems of mixing code meant to run on slightly different and subtly incompatible runtimes, within the same code base, without calling out this distinction of "colour" by any particular mean of syntax, or tooling, or explicit documentation. It's a good observation that helps, at least me, shed light and give a name to this problem tha…

Thanks for this comment, this was exactly the point I was trying to get across. I’m glad you found it helpful.

Re: The absurd complexity of server-side rendering

#135

Post by bob1029 »

tiberriver256 wrote: post #133
bob1029 wrote: post #11

I've been saying it for years - the hard part is not "server side" vs "client side", it's making sure the state stays consistent between those 2 buckets. If you want to remove the hell from your life, you need to be all in on one or the other. For us, we've been keeping all state server-side using things like Blazor and hand-rolled js-over-websocket UI frameworks. We never have to worry about more than ~10k users, so…

Blazor Server and other HTML over the wire frameworks (Livewire, Hotwire, HTMX, etc.) are the new sweet spot for a lot of LoB web applications I think.

The amount of leverage you can get out of these paths is pretty incredible. The fundamental idea is really simple too if you boil it down to the absolute minimum essence...

The following 6 lines of javascript is all it takes to connect a hot pipe from server to client and dynamically invoke whatever is required.

  function StartApplication() {
    document.ApplicationSocket = new WebSocket(...);
    document.ApplicationSocket.onmessage = function (e) {
      return new Function('use strict";\n'+e.data)();
    }
  }
Anything that needs to talk back to the server would just send a message on the same socket.

This is pretty similar to how Blazor Server works, except we are able to bootstrap our client off <1kb of javascript+html source.

Re: The absurd complexity of server-side rendering

#136

Post by jiggawatts »

dymk wrote: post #75
JJMcJ wrote: post #73

Earlier quoted context omitted.

> documentation sites, blog-like sites Sites like those can often be fully static sites. Process the docs or the blog posts into HTML. Nothing is generated at runtime. Of course you can cheat a tiny bit, like putting the date in the footer, or cheat a lot. Life's a lot simpler if you don't cheat at all.

Sites like those (e.g. Wikipedia) tend to be driven by a CRM on the backend, with content maintained by a team of people, and so it's not super reasonable for the site to be regenerated and the static HTML file to be reuploaded to the server on every change. Cache the body page, put the timestamped footer on it, and serve it up. Easy peasy, been doing it since 1995.

It's trivial to generate pages statically, irrespective of the update volume. Instead of updating database rows, just save S3 blobs of HTML.

The reason this is not done is an accident of history that is no longer required but has become the norm.

"Back in the day", browser compatibility issues meant that user agent strings had to be inspected and different HTML content served based on the browser. Mobile browsers especially required vastly different content compared to desktop browser. I don't mean two different kinds of content, but dozens.

Similarly, text encoding variations was a huge pain.

With HTML5 and modern browser standards this is a thing of the past. The same static HTML can be served to everyone. Any content that needs to vary based on client-side metrics is best implemented by JavaScript or CSS, which can be responsive to display changes like phone rotation.

There is literally no benefit to dynamic rendering for many sites. It nearly guarantees scalability issues at the hardest part to scale -- the database. It means that every "moving part" must always be moving, or you get a guaranteed outage. It means that any caching tier like a CDN gets you right back to the pros and cons of static rendering: either you don't cache all of the site OR you have to live with the limitations of static/stale content.

CMS products like SiteCore or Wordpress are especially bad, doing everything fully dynamically. I've seen these products struggle to serve 10 requests per second on clusters of VMs that should be able to serve 10 million.

The most crazy thing I saw was a plugin that did image compression optimisation dynamically with a fixed-size cache on a per-server basis. If you had more GB of pictures than the cache size, you'd get cache thrashing and the CPU load on all nodes would spike. Scaling up the farm wouldn't help either because the new server would have an empty cache and hence would overload its CPUs for hours.

Simply pre-optimising everything and dumping the result in something like and S3 bucket would be orders of magnitude more efficient and scalable. We're talking up to 100 Gbps egress to the Internet, no sweat.

Re: The absurd complexity of server-side rendering

#138

Post by temp8964 »

codedokode wrote: post #38

There are cases when server-side rendering (without SPA) is easier and faster. For example: documentation sites, blog-like sites, internet stores, sites like Hacker News. In all these cases, you can save on development time by writing just one application instead of two (server and client), and improve performance (no need to load multimegabyte JS applications and make multiple AJAX requests to display a page). Of co…

LoL. The truth is most sites don’t need tons of js, but we’re in the sad state where normal websites begins with heavy js framework, junky cookies, annoying notifications as a default. Then add more and more junks …

Re: The absurd complexity of server-side rendering

#139

Post by GiorgioG »

inopinatus wrote: post #128
etchalon wrote: post #64

I'm convinced SSR is only a thing because of Lighthouse scores. Client-side rendering with client-agnostic REST APIs is a fantastic architecture. But noooooooooo we can't have nice things

Now that the end-user is essentially using their browser as a thick client for that RIA/SPA, and the client-server interaction primarily supplies certification and replication services, we can congratulate ourselves on having more-or-less reinvented Lotus Notes.

And a poorly implemented reinvention at that.

Re: The absurd complexity of server-side rendering

#140

Post by PaulDavisThe1st »

com2kid wrote: post #55
stevebmark wrote: post #45

Earlier quoted context omitted.

I'm not sure what about two bundles causes a huge level of complexity. Granted, I use Next.js, it does all of this out of the box. SSR is fast, it's provably faster than client side rendering for first load. You can optionally do client side hydration, so the time to meaningful content is fast from SSR, and subsequent page loads are done SPA style (if you want). It's never a fair comparison, but Stackoverflow is enti…

> Also, all forum software, which is SSR, despite being 20-30 years old, is usually faster than a SPA. Only because crap tons of hardware got thrown at the problem. I remember when forums were multi-seconds to load each page. It sucked. People complain about reddit a lot, but even on mobile, the reddit website is fast. It may be janky at times, but navigating between comments on stories is under a second, loading mor…

> People complain about reddit a lot, but even on mobile, the reddit website is fast.

only on mobile is Reddit fast.

Post reply on HN