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

241–250 of 395 posts

Re: The absurd complexity of server-side rendering

#241

Post by tored »

astrange wrote: post #80
gmfawcett wrote: post #13

Earlier quoted context omitted.

I have colleagues using Laravel, and there's nothing muddy-ball about their apps at all. Their code is tidy, modern, readable, and clearly maintainable. In terms of practical effect, frameworks influence developers more than languages do.

The idea of using a "framework" in a language that gets completely reloaded on every new request doesn't make sense - at least I thought a framework was something that wrapped your own code and presented an event loop, etc. You'd want a "library" if you just wanted to improve on the original low quality PHP database connectors and such. But PHP developers always did seem to have inappropriate jealousy over unrelated…

It has somewhat become better in PHP with preloading and better caches like the inheritance cache.

Re: The absurd complexity of server-side rendering

#242

Post by ryanbrunner »

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. It may be janky at times, but navigating between comments on stories is under a second, loading more comments is, well, not fast, but quick.

Reddit is an example that clearly shows that the user experience of "old-style" code where interactions are primarily with the server beats out SPA.

old.reddit.com is clearly superior in pretty much every way save some pretty old CSS styling (which could easily be fixed without changing the underlying technology). The rewrite still feels buggy and slow, and the added interactivity doesn't really make a meaningful difference.

Re: The absurd complexity of server-side rendering

#243

Post by LASR »

vecinu wrote: post #202
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…

> So I think that SSR (running JS on server) is rarely useful. I would disagree for a couple of reasons. The team I work with at a large SV company built a very complex SSR framework for our mostly static app for 2 reasons: - Isomorphic codebase, you can share the majority of your code with the client/server since it's Node on the backend and ES2015 on the frontend - SEO. Google penalizes your site for slowness and m…

> mostly static

> SSR is justified because isomorphism

> SSR is justified because SEO

I think the fundamental problem is that you have a mostly static site and yet chose to write it like a non-static SPA.

SSR now bridges the downsides of this mismatch.

But the point is that SSR is a solution to a problem introduced by some sub-optimal decision-making.

If you had a use case that necessitated a SPA, then it is understandable.

If you just built a static site, then you don’t need isomorphism and your SEO would also be straightforward.

Re: The absurd complexity of server-side rendering

#244

Post by ryanbrunner »

recursivedoubts wrote: post #122

Hello. I'm here from 1999 and I'd like to help: https://htmx.org

Probably more like ~2005. I was a web developer in 2001 and XMLHttpRequest still felt like secret knowledge that you only found out about by digging deep into Microsoft documentation (and wasn't well supported if you weren't using IE). Most people I knew were making pages interactive by targeting forms to iframes.

Re: The absurd complexity of server-side rendering

#245

Post by fuzzy2 »

dinkleberg wrote: post #165
diego_sandoval wrote: post #151

> After a fashion, it was decided that sometimes our HTML is best rendered by JavaScript, running in a user's browser. While some would decry this new-found intimacy, the age of interactivity had begun. I didn't get the memo when this was decided, and I'm still unconvinced. Let me see if I get this straight: The main reason for client-side rendering is that some web applications don't want to do a full page reload ev…

I can’t speak to the decisions on the parts of whoever is building the frameworks. But I will say the dev experience working on a frontend app using React, Vue, etc. is substantially greater than using something like Django templates. And I say that as someone who has written a great deal of both. I really wish I could be as productive in Django templates as I am with React, but alas. Once you go to component based U…

But then maybe Django templates are not so great? You can also have UI components in the backend. Interactivity can be a little tricky though.

Re: The absurd complexity of server-side rendering

#246

Post by jsemrau »

Nextgrid wrote: post #232
giantrobot wrote: post #220

Earlier quoted context omitted.

Most online content is too small/short to be worth paying an amount of money that would be worth the transaction.

A lot of content such as clickbait/etc actually has negative value and only works because ad impressions pay before the content has been seen and can't be clawed back even if the content ends up being garbage.

If there would only be a way to reward people for good content.

Re: The absurd complexity of server-side rendering

#247

Post by saint-loup »

Come on, Trisomorphic rendering or Distributed Persistent Rendering are pretty simple, basically these are just [insert joke about monoid in the category of endofunctors].

https://en.wikipedia.org/wiki/Hydration_(web_development)#Tr...

https://www.smashingmagazine.com/2022/04/jamstack-rendering-...

Re: The absurd complexity of server-side rendering

#248

Post by ryanbrunner »

robertoandred wrote: post #12
Daishiman wrote: post #2

The 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 take it you haven't taken a look at backend lately. Vagrant? Or Docker? Composer? Maybe Drush. Will this plugin break? Is it even still actively maintained? Which database? Are we still on the NoSQL fad? Maria, or postgres or mysql? And does my production host support my language version, and oh god another php vulnerability

I dunno man, my "backend architecture" is a bunch of Rails servers (some web servers, some queue servers, but they run on the same codebase with different entrypoints), a PostgreSQL server, and a Redis server.

Re: The absurd complexity of server-side rendering

#249

Post by realityking »

iforgotpassword wrote: post #223
matt_kantor wrote: post #176

Earlier quoted context omitted.

I don't think I understand your point. Weird markup vs WYSIWYG authoring is orthogonal to static vs dynamic serving.

Static serving usually means you don't have anything running on the server but an actual web server, and you upload the static files to its webroot. So it's not technically possible to have any fancy editor in your browser. You have all the brains in some tool you run on your machine that processes your markup files and spits out html files. Sure, you could throw PHP or whatnot on your server, have a nice editor and…

There’s a whole category of headless content management systems, either API or git based, to give a friendly editorial experience (also for non technical editors) while maintaining the advantages of static sites.

Here’s a good starting point (not my post): https://pagepro.co/blog/jamstack-headless-cms-which-one-to-u...

Disclaimer: I work for a vendor in this space

Re: The absurd complexity of server-side rendering

#250

Post by ryanbrunner »

robertoandred wrote: post #192
Daishiman wrote: post #167

Earlier quoted context omitted.

I have done nothing but backend for a decade. Docker's been around for the past 6 years and still going strong. Database? Postgres, always. You have to bend it so far until it breaks it's not even funny. If you need something else, you'll now. Backend lang? Python. Framework? Django. Need data munging? NumPy/SciPy/Pandas/PySpark. Need a really high speed component? C will do, Rust if you feel fancy. OS? Ubuntu, or De…

So React has been around longer than Docker? Good to know that frontend is on a slower treadmill than backend, which according to this thread has moved on to alpine or htmx or something else.

React is for sure a relatively stable part of frontend, but the ecosystem around it seems to be building mountains of complexity on top of React.
Post reply on HN