Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scaling React Server Side Rendering

arkwright.github.io

Post reply on HN
Print view View original

111–120 of 137 posts

Re: Scaling React Server Side Rendering

#111

Post by rimliu »

a13n wrote: post #27
superkuh wrote: post #5

The easiest way to do this is to not use javascript for everything in the first place and to actually generate html instead of expecting people to run your code, then having to do it yourself in a convoluted workaround when they won't or can't.

This is probably the worst possible takeaway from this article. > not use javascript for everything Using JS for frontend + backend has significant advantages. Your developers only need to know one language/codebase. You don't need to hire/maintain separate frontend/backend teams who need to figure out how to coordinate with each other. > actually generate html That's what server-side rendering does. > expecting peop…

   > Your developers only need to know one language/codebase
As one wise man said: make it easier for the users, harder for a database. The same applies to developers. We tend to forget who we make products for.

Re: Scaling React Server Side Rendering

#112

Post by rimliu »

dwaltrip wrote: post #29
superkuh wrote: post #5

The easiest way to do this is to not use javascript for everything in the first place and to actually generate html instead of expecting people to run your code, then having to do it yourself in a convoluted workaround when they won't or can't.

Interactive applications? Ever heard of them?

Sluggish webpages. Ever heard of them?

Re: Scaling React Server Side Rendering

#113

Post by loh »

dvt wrote: post #39
a13n wrote: post #27

Earlier quoted context omitted.

This is probably the worst possible takeaway from this article. > not use javascript for everything Using JS for frontend + backend has significant advantages. Your developers only need to know one language/codebase. You don't need to hire/maintain separate frontend/backend teams who need to figure out how to coordinate with each other. > actually generate html That's what server-side rendering does. > expecting peop…

> Running your frontend code on the backend to generate HTML is an elegant solution and extremely easy to implement. These days it works out of the box. Not sure where you got the idea it was a "convoluted workaround". Oh boy, this must be the overstatement of the decade. I've done SSR with a few frameworks now, including Meteor, Nest, and Next. Saying that "it works out of the box" is so disingenuous, it borders on…

From my experience, this is not the case, not for a long time now, at least.

With proper architecture, all you need is plain React (no frameworks) with `styled-components` for everything - i.e., server rendering, client rendering, and hydration.

The architecture I'm describing is a fully top down approach, with concerns separated into API, UI, and App components, where the route dictates the data to be fetched, which is passed as a `store` to the layout to be rendered, with each layout being a composition of the UI components, App components, and occasional API components. I've had a lot of success with this approach and it is, in my opinion, the simplest way, incredibly easy to follow and maintain, and extremely minimal for what is actually being achieved.

With this architecture, switching between server-only rendering and client-only rendering and/or some combination of both becomes a matter of minutes, or even just seconds if you have some env var switches in place.

Re: Scaling React Server Side Rendering

#114

Post by sim_card_map »

lewisjoe wrote: post #94

This looks like a great piece of article. Kudos to the people who wrote it because the most sure-shot problem in SSR is running to scaling issues and this is a much needed one. But here's an unpopular opinion: Server side rendering shouldn't even be a thing. Running a language as dynamic as Javascript on servers, is at best - a problem that can be dealt with, but not necessarily the solution. I'm saying this as a ful…

> SPA, Components and functional programming is the best thing that happened to web development in the recent past.

Citation needed.

Re: Scaling React Server Side Rendering

#115

Post by chrismmay »

hnbreak wrote: post #110

People debate SPA vs SSR without any context. Both have their use case: Everything before a login => SSR, everything after => SPA. Why? SSR is proven to be much better at SEO. But SPAs offer best UIs. Nobody wants to click through stuttery SSR dashboards in 2019, wait for page loads, submits, etc. People prefer slick UIs, that was one of the reasons DigitalOcean got big (because of their then stunning dashboard or af…

Thank you for this very practical advice. The thought of trying to dynamically decide whether to render on the client or server side, as the author of this article did, seems so over-the-top complicated to me. Taking your advice is something doable for us mere mortals.

Re: Scaling React Server Side Rendering

#116

Post by rejschaap »

chrshawkes wrote: post #34
adossi wrote: post #17

Earlier quoted context omitted.

One of the main reasons I never bothered to learn React was that using Razor syntax in .cshtml on my ASP .NET projects has all the convenience of react with no client-side overhead. However I understand there is some benefit to delegating some of the work to clients considering the power of modern devices.

Whether Razor or Server Side React, it's the same thing. Both are compiled and produced on the server and sent to the client. No difference except that react is a much better template engine.

React is component based, this allows for a level of encapsulation and reusability that cannot be achieved with Razor. You might not truly appreciate this until you try out React.

If you don't want to dig too deep though, compare how to add a datepicker to a view in both systems. With React it is just another component, with Razor it is a bit more finicky.

Re: Scaling React Server Side Rendering

#117

Post by simion314 »

dwaltrip wrote: post #29
superkuh wrote: post #5

The easiest way to do this is to not use javascript for everything in the first place and to actually generate html instead of expecting people to run your code, then having to do it yourself in a convoluted workaround when they won't or can't.

Interactive applications? Ever heard of them?

How many such web pages to you hit daily? I think the only one I seen in the last month was some solar system thing, and some work related stuff that are actually apps.

Most news sites are not apps and recently I am starting to turn off JavaScript on this websites and I am considering instead of blacklisting pages I maybe whitelist stuff if things get even worse, we ended up like in Flash days where you had an extension or a setting to Allow flash on this page.

Re: Scaling React Server Side Rendering

#118

Post by mhd »

hnbreak wrote: post #110

People debate SPA vs SSR without any context. Both have their use case: Everything before a login => SSR, everything after => SPA. Why? SSR is proven to be much better at SEO. But SPAs offer best UIs. Nobody wants to click through stuttery SSR dashboards in 2019, wait for page loads, submits, etc. People prefer slick UIs, that was one of the reasons DigitalOcean got big (because of their then stunning dashboard or af…

> But SPAs offer best UIs

I don't consider this a settled conclusion. Mostly because it's a false dichotomy. There are alternatives to both SSR of component sites and SPAs, and every solution has its inherent advantages and disadvantages.

UI isn't even the primary feature of an SPA, that would be offline usage.

Having more interactive elements without page loads is a feature of "DHTML", and that can be had from anything between small embedded snippets of vanilla JS to full-fledged SPA frameworks. Intermediate solutions like StimulusJS or AlpineJS seem to be getting a bit more popular, too.

But in this Fallen World, it seems we're usually getting the worst of either extreme usually. Either a long rendering time for a whole page, then delivered in one "flash" (assuming you've got a fast connection), or multiple elements popping in and out while several JSON-RPC requests are made.

You can optimize both cases, of course. Proper caching/DB views etc., or things like HTTP2/GraphQl/React Suspense etc.

But it's definitely not an either/or answer. Few things in fiddling around with computers are.

Re: Scaling React Server Side Rendering

#119

Post by buboard »

dwaltrip wrote: post #29
superkuh wrote: post #5

The easiest way to do this is to not use javascript for everything in the first place and to actually generate html instead of expecting people to run your code, then having to do it yourself in a convoluted workaround when they won't or can't.

Interactive applications? Ever heard of them?

tbh they are very hard to miss, and the reason is the loading spinners on every box.

Re: Scaling React Server Side Rendering

#120

Post by buboard »

unlinked_dll wrote: post #28
simonw wrote: post #10

Earlier quoted context omitted.

Try using client-side rendered website on a cheap Android phone on a 3G connection sometime - or even a cheap Android phone on LTE. That's how most of the world's population will experience your site. I'm baffled that so many sites have invested in multiple megabytes of JavaScript to render their pages. It's like our entire industry has forgotten how to build sites that can be used by anyone who's not on an LTE iPhon…

>That's how most of the world's population will experience your site. Unless you're FAANG you probably don't care about most of the world's population, but the tiny slice that is most likely to see your site and generate revenue for you. It's not baffling that most developers don't make things for most people. That's just a waste of time and money.

it's not, because phone coverage can be spotty when in a car using the train, busy wifi connections etc. aren't we supposed to be optimizing for mobile? SPAs should only be used for things like gmail. Newspapers offering megabytes of javascript , when they know that a lot of their reading happens in trains is obscene.

On the one hand google promotes SPA frameworks. on the other hand , google makes AMP because they are too slow. It's not stated often enough, but modern web is schizophrenic

Post reply on HN