In this thread: people confusing server rendering (like your old PHP) with SSR (same Javascript codepath for client and server, i.e. Next.js) One is easy, the other is the definition of leaky and crappy abstraction. This article is about the latter technology.
Confusion is by whoever wrote the headline. Server side render is easy. Isomorphic is hard.
The absurd complexity of server-side rendering
111–120 of 395 posts
Re: The absurd complexity of server-side rendering
#112Laravel livewire / Phoenix liveview and a lot of new frameworks are now focusing on bridging this gap between ssr and clientside - almost trying to make it seamless. Though only time will tell, what can of worms that will open later.
Re: The absurd complexity of server-side rendering
#113If so then I think the term "server-side rendering" is somewhat confusing. Your server is "generating HTML", not 'rendering" it.
Rendering in my view means turning code (like HTML) into visual output.. So whether the server serves always the same HTML, or regenerates it for every request, or something in between, the client/browser still has to "render" that HTML into visual output.
True server-side rendering I would think should mean the server renders HTML into a gif or jpg which then gets shown in the browser.
Re: The absurd complexity of server-side rendering
#114I'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
The answer is "yes."
Re: The absurd complexity of server-side rendering
#115Earlier 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.
Heavily cached server-side rendering and statically generated sites kinda converge at some point to the same thing
Re: The absurd complexity of server-side rendering
#116I'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…
Re: The absurd complexity of server-side rendering
#117is it the overabundance of programmers? the fact that it makes them look busy? people liking wasting time recompiling most of the day? overengineering making people feel superior? it certainly doesnt feel healthy and makes one question whether the whole SV startup ecosystem is a cargo cult built on shaky grounds by people who are just apeing each other on everything, from design to backend.
Re: The absurd complexity of server-side rendering
#118See https://remix.run for a modern, sane, progressive approach to server-based rendering w/ as-needed hydration.
Remix has the exact same issue unfortunately: https://remix.run/docs/en/v1/guides/constraints
Re: The absurd complexity of server-side rendering
#119The complexity of web development frontend itself is just absurd. The mess of dependencies, the mess of language transpiling, opaque abstract functions with unreadable call stacks, asset management, sync vs async, the random best practice of the week, etc. I look at the state of web pages and apps and it's not even for the betterment of user experience! Hacker News and old.reddit.com still provide the smoothest, fast…
I wouldn't exactly call clicking on the 'reply' button, and loading a brand new webpage, typing this comment, pressing the 'reply' button again, and then getting sent back to the original webpage 'smooth'.
OTOH, making a reply button that drops-down a textarea with "save"/"cancel" buttons requires about 30 lines of Javascript.
And yet, almost all "modern" sites that have only this functionality has megabytes of dependencies.
Maybe both extremes are bad, and Javascript is like adding salt to food - too little and you'll be able to eat it, but won't enjoy it. Too much and you won't even be able to eat it.
Re: The absurd complexity of server-side rendering
#120Having 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.