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

141–150 of 395 posts

Re: The absurd complexity of server-side rendering

#141

Post by PaulDavisThe1st »

thaumasiotes wrote: post #131
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"

sign seen in Seattle on a housing project in the 90s:

  ALL ILLEGAL ACTIVITIES ARE PROHIBITED

Re: The absurd complexity of server-side rendering

#142

Post by KorematsuFredt »

JJMcJ wrote: post #73
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…

> 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.

I had a website which I was rendering statically using Jekyll. Overtime I had millions of pages, rendering was getting too time consuming and was taking up far too much of space.

I then moved on to PHP. Worked like a charm with $15/mo server on Google cloud. Excellent search performance as well.

Re: The absurd complexity of server-side rendering

#145

Post by eli »

cyber_kinetist wrote: post #115
eli wrote: post #77

Earlier quoted context omitted.

Heavily cached server-side rendering and statically generated sites kinda converge at some point to the same thing

Yes, but the latter can do the same thing without the complexity of the former.

App server + Cache server == Static deployment pipeline + Simple file hosting. I don't think the latter is necessarily simpler.

Re: The absurd complexity of server-side rendering

#146

Post by lmc »

Widdershin wrote: post #134
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.

I was never really a fan of the original 'Colors' article but I think the analogy works really well for this client-side vs server-side stuff.

Red = client

Blue = server

Purple = either

I think I will use this if I ever have to teach it.

Re: The absurd complexity of server-side rendering

#147

Post by ryan_lane »

jiggawatts wrote: post #136
dymk wrote: post #75

Earlier quoted context omitted.

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 esp…

Have you worked on one of these products before? I worked for Wikimedia Foundation, and it's not trivial to generate the pages statically. The content itself is wikitext, not html. It'd derived from content, templates, and meta-templates. Quite a bit of the data comes from other sources, like wikidata, or commons. You need to display things differently based on logged-in vs logged-out status.

Through lots of layers of caching, the fact that the backend is dynamic doesn't really make things that taxing. Serving mostly static content is a pretty well-known problem-set at this point.

Wordpress is perfectly fine, btw. If you use memcache/redis, and some form of a reverse-proxy caching layer (like cloudflare/fastly), you can very easily be #1 on hackernews for the entire day, from a single t2 instance in AWS (I say this from experience, multiple times).

Yes, if you can static-generate your site, it's probably better to do so, but it's a more difficult approach, and is also limiting in terms of managing the content.

Re: The absurd complexity of server-side rendering

#148

Post by canyonero »

> If you're considering using one of these frameworks, I would recommend you carefully consider if the complexity is worth it, especially for less-experienced members of your team.

Far too many folks seem to believe that complexity is a binary choice or that it can be avoided wholesale by choosing frameworks (or lack-thereof) to solve their problems.

Truth is, when you're building software on the web, you're gonna have gonna have to make a series of decisions on where the complexity that you'll inevitably encounter should live.

We're all simply making tradeoffs on where that complexity lives: the browser runtime, the build system, the type system, the server, the platform, their framework, your framework.

Re: The absurd complexity of server-side rendering

#149

Post by petrocrat »

jamal-kumar wrote: post #16
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…

Even in smaller applications this is incredibly relevant. I've recently written something that's meant to interface on a local area network, just controlling something on another computer, literally just one or two users at a time -- thing is the precision of floating points are a big thing here, and we have to consider that. So all of the bignum stuff had to stay server-side in C++ after much messing around doing ma…

Did you try to use javascript's BigInt data type?

Re: The absurd complexity of server-side rendering

#150

Post by lmc »

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.

How well does it work for complex projects/component libraries? React is a pain in the ass but there's at least some established patterns for large projects.
Post reply on HN