Hacker News Reader

Comment by vultour | Hacker News Reader

It's hilarious listening to my friends who do frontend rave about the the incredible framework of the month, every month there's a new one that's supposed to be the last, ultimate, final stop for developing frontends.

Lately it's all about server-side rendering... they managed to reinvent PHP 25 years later with 100x the complexity.

View on HN

I don't really understand these sorts of low-effort comments. You're probably referencing the React Server Components that were recently proposed. React has supported server side rendering basically since its inception. The problem with most existing SSR implementations in any language is that it's a one-shot synchronous process which doesn't allow for out of order streaming. For example, you might want to render a loading state and replace it with content once some network call returns. This used to take multiple requests; you get the initial page, some JS makes the network call, then you might need to download even more JS to render the result. Now you can do it all in one shot with (almost) no JS; the server can stream this entire sequence of HTML chunks in one response.

That's pretty useful and it's not "PHP 25 years later with 100x the complexity"

This gets repeated in every thread about front-end tech, and every time people have to repeat the same explanation. SSR is not PHP. SSR allows you to run the same code on client and server. You get to use client-side frameworks, but the page is rendered before it even reaches the client.

If people could try to understand SSR before diminishing it, we could have much more productive discussions. But as of now the frequency of these uninformed comments makes me feel like people who are ignorant about front-end, are somehow proud of their ignorance.

> but the page is rendered before it even reaches the client

Which is what PHP was built for.

> If people could try to understand SSR before diminishing it, we could have much more productive discussions.

If new generation of frontend people could try to understand PHP before diminishing it, we could have much more productive discussions.

You can't just crop out half the sentence and make an equivalency. The full sentence was

> You get to use client-side frameworks, but the page is rendered before it even reaches the client

Does PHP run in the client? No? Then it's not the same as SSR. You have it completely backwards. I understand PHP but you clearly don't understand SSR

It's not PHP. It's not even close to being PHP... SSR frameworks are truly impressive pieces of technology that might impress you too if you weren't raging uncontrollably.

This is really untrue. The complexity of large PHP projects could get insanely high. The advantage of using SSR in JavaScript is that your entire application speaks the same language as the browser does, so sharing code between server and client becomes incredibly easy.

To clear up some confusion, I believe people are using the terms SSR and hydration interchangeably. Hydration is a new technology that uses SSR and then adds reactivity: https://en.wikipedia.org/wiki/Hydration_(web_development)

The server code will use the framework to handle SSR and hydration. Meaning that all you have to do is write the frontend and you get SSR for free.

If I'm not mistaken, GWT did hydration way back in 2010.

Reply on news.ycombinator.com