Live data from Hacker News

The absurd complexity of server-side rendering

gist.github.com

321–330 of 395 posts

Re: The absurd complexity of server-side rendering

#321
post #5

Call me old fashioned, but PHP still gets the job done better than just about anything else.

Already mentioned in other replies, but as a long time node/react developer, for the last year or so I've been working on a project built with Laravel (blade components) + Unpoly (for server interactions) + Alpine (client side only interactions) and it feels like a real "cheat code". Everything is super easy, although some people think the way we do it is pretty "uncool" so they look down at you.

Re: The absurd complexity of server-side rendering

#322

Earlier quoted context omitted.

This was my PHP experience with CodeIgniter 15 years ago. Nothing new under the sun.

That's good, I think? I'm not claiming that Laravel was the first or the best PHP framework, just that they were using it. (Admittedly I assume it's a reason their code is so well organized.)

Laravel inherits its organisation from the underlying Symfony 2 framework, just like Drupal nowadays.

Re: The absurd complexity of server-side rendering

#323
post #7
post #5

Call me old fashioned, but PHP still gets the job done better than just about anything else.

And usually leads to a BBOM architecture

Not my experience. Most Laravel projects I've seen are in a much much better shape than even the most minimal "microservices" I've seen around. You get so much done for you with Laravel that it makes it a bit more difficult to mess up.

I've seen microservices that had absolutely no guardrais going off the hill too many times. At my previous job "migrations" where bash scripts with SQL in them because they "didn't like ORMs and they were slow". LOL. They were handling signup form POSTs and profile updates.

Re: The absurd complexity of server-side rendering

#324

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

In my opinion (and experience, this architecture is great as a way to scale teams, having a clear interface between them.

As soon as you have to work on both sides of the API, it is not and advantage anymore.

I think separating the backend from the frontend is a way to increase the amount of work required in order to gain a saner way to split it into chunks for different teams.

As a single person, or a small team, doing an SPA and an API only backend, if not done for learning purposes then it is just either madness or CV padding, or something else....makes no sense at all to me.

Re: The absurd complexity of server-side rendering

#326

The original server side rendering (HTML rendered on the server by your choice of language) is simple, efficient and most sites on the internet still use it, including this one. The article is talking about ‘modern’ js style server side rendering combined with client side rendering, which is of course a huge dumpster fire and encourages absurd complexity on both sides of the equation, starting with the fact the app i…

It's mind boggling some people don't know you can render plain html on the server, or even submit forms without javascript.

Such a basic building block seems to be fading away nowadays, even some times presented as a "novel" thing or a "feature" (eg: remix)

Re: The absurd complexity of server-side rendering

#327

Earlier quoted context omitted.

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

Pardon me while I load up reddit on my 4 year old $1000 Costco Special laptop. Yup, that was fast. OK let me disable ad block. Under 3 seconds to first render. Comments appear in under 2 seconds. Reddit performs very well. The new UI is legit faster. There is a bit of stupid here and there with it, and if you aren't logged in the experience is horrible, but speed is, IMHO, not one of the site's problems.

16 core Ryzen Threadripper 2950X on a 40Mbps link with ublock origin: 4-5 seconds for first render.

Re: The absurd complexity of server-side rendering

#328

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…

I have a marketing site and a dashboard SaaS app. For the marketing site I decided to keep it in React for consistency, but I just kept the server rendering and removed the JS tags from the output. Now it's a fully server-rendered site with no client-side JavaScript, and it's super fast cause it's cached on the CDN.

I feel like not many people realise this is an option but it can work really nicely.

Re: The absurd complexity of server-side rendering

#329

The complaint in the article is technical, but my issue with the SSR + hydration approach is that it doesn't actually work for the users. Mainly because if you need a page that is indexed by Google, there is a high chance your users will browse it and open pages in new tabs. So the approach of "there is a small initial penalty, but everything is faster later" no longer applies -- you get that initial hit quite often.

What initial hit are you referring to? If it's the origin request, just chuck it behind a CDN with some Cache-Control headers and call it a day.

Re: The absurd complexity of server-side rendering

#330

Earlier quoted context omitted.

Hiya, I wrote this gist. I do actually think Monads or similarly expressive type constructs would allow us to eliminate this class of issue for good. Hopefully the rise of Wasm makes this problem irrelevant for functional programmers, but that’s a whole other can of worms. That said, it’s probably impractical to try and achieve that sort of type safety in JS via the Monad route, but maybe a clever TypeScript extensio…

Monads are just type constructors with two operations: bind and pure. I fail to see the connection and why do you need a type constructor with a bind and pure operation at all to solve SSR.

I was thinking you could use them to specialize the IO types to prevent accidentally calling the wrong type of function in the wrong place.

Say you have a `ServerIO a` and `ClientIO a` type. Browser APIs, like addEventListener, would use the ClientIO type. Server specific APIs like fs would use the ServerIO type. That would prevent the entire issue I've described, and allowing users to confidently make changes to their shared code.

Post reply on HN