5 ms·

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 nooooooo

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

lawwantsin17 5y ago
alserio 5y ago
As a developer I like doing CSR apps. As an user I like when my sites are SSRed. There are people who are trying to bridge the gap. https://dev.to/ryansolid/server-rendering-in-javascript-why-ssr-3i94 https://dev.to/ryansolid/server-rendering-in-javascript-why-... https://dev.to/this-is-learning/conquering-javascript-hydration-a9f https://dev.to/this-is-learning/conquering-javascript-hydrat...
- deleted 5y ago
  [deleted]
adamzochowski 5y ago
because scraping and indexing the site is hard. because getting first response on super slow speeds doesn't accomplish anything because many js devs write buggy code that renders in their browser etc
DangitBobby 5y ago
It's a nice architecture when the API devs get to throw stuff over the fence to the frontend devs. It's less nice when you are the guy throwing stuff over the fence and then running around the fence to catch the stuff you just threw over it. It makes you start to wonder if there's anything you can do about the fence. The answer is "yes."
- langsoul-com 5y ago
- midrus 5y ago
  What an awesome metaphor, 100% agree with this. That's why I've always said that the SPA architecture with a separate backend is a way to increase the amount of work so that it can be distributed to more people/teams. It baffles me when I see single developer or small team projects going for this.
hardee 5y ago
Fantastic if you ever could anticipate having multiple different consuming clients. Otherwise it's fantastically over-engineered IMO.
- etchalon 5y ago
  I don't see it as anymore over-engineered than SSR. In traditional SSR, using a template language, you craft a query and expose your variables to your template. In SPA, you craft a query and expose your variables through an API.
inopinatus 5y ago
Now that the end-user is essentially using their browser as a thick client for that RIA/SPA, and the client-server interaction primarily supplies certification and replication services, we can congratulate ourselves on having more-or-less reinvented Lotus Notes.
- GiorgioG 5y ago
  And a poorly implemented reinvention at that.
- xvello 5y ago
  Ouch, that hit too close to home :/ It's too early for whiskey where I live.
quickthrower2 5y ago
SSR would make HN better under load when logged in, for example. When logged in you would get the cached versions like a logged out person, and then wait for user-specific content (and if it never renders, you can always just read).
- etchalon 5y ago
  As far as I can tell, HN is rendered on the server.
  - quickthrower2 5y ago
    I meant SSR as in what nextjs does. Render on the server using front end tech, cache for performance and then rehydrate in the front end for up to date data. They should have called it Server Side React Initial Rendering maybe :-)
jefftk 5y ago
SSR (2012ish, debatable) long predates Lighthouse (2018). If you mean that SSR is only a thing because people want pages to load quickly, however, then I'll completely agree with you.
midrus 5y ago
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.
dbbk 5y ago
Let's say you're a mobile user on a 3G network, which a lot of our users are. With a SSR app (that's cached behind Cloudflare), they can see a document in about 100ms max. With a fully client-side rendered app, you're talking multiple, multiple seconds while they're staring at a blank white screen. Try it in real life and you'd quickly see your idea would be a terrible user experience.
- 5560675260 5y ago
  Why would it take multiple, multiple seconds to download JS bundle (cached behind Cloudflare) and then make a request for initial data (probably also cached behind Cloudflare)? Overhead of downloading most of the app is likely less than that of loading a single hero image from said website.
  - dbbk 5y ago
    On 3G and even low 4G it absolutely would. I've seen it. Also, a lot of mobile devices do not have as strong processing power as you think. Parsing and executing that much JavaScript also adds time.

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

lawwantsin17 5y ago

alserio 5y ago

As a developer I like doing CSR apps. As an user I like when my sites are SSRed. There are people who are trying to bridge the gap. https://dev.to/ryansolid/server-rendering-in-javascript-why-ssr-3i94 https://dev.to/ryansolid/server-rendering-in-javascript-why-... https://dev.to/this-is-learning/conquering-javascript-hydration-a9f https://dev.to/this-is-learning/conquering-javascript-hydrat...

deleted 5y ago
[deleted]

adamzochowski 5y ago

because scraping and indexing the site is hard. because getting first response on super slow speeds doesn't accomplish anything because many js devs write buggy code that renders in their browser etc

DangitBobby 5y ago

It's a nice architecture when the API devs get to throw stuff over the fence to the frontend devs. It's less nice when you are the guy throwing stuff over the fence and then running around the fence to catch the stuff you just threw over it. It makes you start to wonder if there's anything you can do about the fence. The answer is "yes."

langsoul-com 5y ago
midrus 5y ago
What an awesome metaphor, 100% agree with this. That's why I've always said that the SPA architecture with a separate backend is a way to increase the amount of work so that it can be distributed to more people/teams. It baffles me when I see single developer or small team projects going for this.

hardee 5y ago

Fantastic if you ever could anticipate having multiple different consuming clients. Otherwise it's fantastically over-engineered IMO.

etchalon 5y ago
I don't see it as anymore over-engineered than SSR. In traditional SSR, using a template language, you craft a query and expose your variables to your template. In SPA, you craft a query and expose your variables through an API.

inopinatus 5y ago

Now that the end-user is essentially using their browser as a thick client for that RIA/SPA, and the client-server interaction primarily supplies certification and replication services, we can congratulate ourselves on having more-or-less reinvented Lotus Notes.

GiorgioG 5y ago
And a poorly implemented reinvention at that.
xvello 5y ago
Ouch, that hit too close to home :/ It's too early for whiskey where I live.

quickthrower2 5y ago

SSR would make HN better under load when logged in, for example. When logged in you would get the cached versions like a logged out person, and then wait for user-specific content (and if it never renders, you can always just read).

etchalon 5y ago
As far as I can tell, HN is rendered on the server.
- quickthrower2 5y ago
  I meant SSR as in what nextjs does. Render on the server using front end tech, cache for performance and then rehydrate in the front end for up to date data. They should have called it Server Side React Initial Rendering maybe :-)

jefftk 5y ago

SSR (2012ish, debatable) long predates Lighthouse (2018). If you mean that SSR is only a thing because people want pages to load quickly, however, then I'll completely agree with you.

midrus 5y ago

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.

dbbk 5y ago

Let's say you're a mobile user on a 3G network, which a lot of our users are. With a SSR app (that's cached behind Cloudflare), they can see a document in about 100ms max. With a fully client-side rendered app, you're talking multiple, multiple seconds while they're staring at a blank white screen. Try it in real life and you'd quickly see your idea would be a terrible user experience.

5560675260 5y ago
Why would it take multiple, multiple seconds to download JS bundle (cached behind Cloudflare) and then make a request for initial data (probably also cached behind Cloudflare)? Overhead of downloading most of the app is likely less than that of loading a single hero image from said website.
- dbbk 5y ago
  On 3G and even low 4G it absolutely would. I've seen it. Also, a lot of mobile devices do not have as strong processing power as you think. Parsing and executing that much JavaScript also adds time.