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

31–40 of 137 posts

Re: Scaling React Server Side Rendering

#31

Post by qwerty1234599 »

Vesuvium wrote: post #20
t0astbread wrote: post #11

Earlier quoted context omitted.

Aren't you back to the scaling problem when you generate the HTML on your server? As in, you now have frontend code to run on your server, which is more or less the same as SSR. Addendum: That is, if your loads are large enough of course. Small projects will not have scaling problems either way.

That's exactly the point he's making. If you use a frontend js framework and you have to do SSR, then there's no longer any reason to use a JS frontend framework, because the reason they were made was to offload to clients the rendering, at the price of more complexity. Back then, the cloud was not a thing yet, there was no Docker, no Kubernetes, no nice APIs to start instances, so it made sense to offload some compu…

What... the reason for JS frontend frameworks is to be able to dynamically update data visible without a full page refresh/refetch

Re: Scaling React Server Side Rendering

#32

Post by sandov »

ng12 wrote: post #25
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.

Are you advocating for avoiding dynamically generated pages altogether? I agree that would be simpler but try winning that argument with the bizdev folks :)

I think he/she advocates for websites to be generated on the server (if they're dynamic) and not passing on that burden to the browser. Specially if the browser language was created to add drop-down menus and cool snow effects, not to generate a complete html website.

Re: Scaling React Server Side Rendering

#33

Post by thrower123 »

t0astbread wrote: post #11
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.

Aren't you back to the scaling problem when you generate the HTML on your server? As in, you now have frontend code to run on your server, which is more or less the same as SSR. Addendum: That is, if your loads are large enough of course. Small projects will not have scaling problems either way.

One of the bigger problems these days is that people don't bother assessing whether their use case is actually complicated enough to actually need any of this stuff, they just want to use it for the sake of using it.

People are allergic to actually profiling anything. I think, some days, that it is intentional, because if they had real data, the stories they tell themselves to justify what they are doing would fall apart.

Re: Scaling React Server Side Rendering

#34

Post by chrshawkes »

adossi wrote: post #17
pjmlp wrote: post #12

Earlier quoted context omitted.

Thankfully most of our Web projects keep being SSR in Java and .NET stacks, with minimal JavaScript.

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.

Re: Scaling React Server Side Rendering

#35

Post by arkwright »

yoz wrote: post #4

This is a fantastic article. I was daunted when I saw the length, but everything about it - the prose style, the mixture of drawings, the pace - led me through and out with a whole load of valuable lessons about load balancing, caching, isomorphic rendering and more. Thank you! One question for the author, if they're reading: how did you prep for writing this piece and gather the story details? It's quite a journey,…

Thanks for the kind words! You made my day.

I didn't really do any preparation. I had recently been thinking that pretty much every website I had ever built was sadly no longer in existence, and so I wanted to start producing real, "tangible" artifacts from my work; something that might have a shelf life of more than a couple of years. I had those recent SSR adventures in mind, and wanted to write them down before they faded from memory.

I usually begin with a bulleted todo list of insights or topics I want to cover. Then I dive in, and write in a more or less stream of consciousness fashion, which causes me to think of more topics to add to that list. I comb over the article and the list iteratively, reordering stories, editing, and and adding context as I go, until the result feels right. In this case I didn't have any notes, the content was rebuilt from memory.

Re: Scaling React Server Side Rendering

#36

Post by scarmig »

qwerty1234599 wrote: post #31
Vesuvium wrote: post #20

Earlier quoted context omitted.

That's exactly the point he's making. If you use a frontend js framework and you have to do SSR, then there's no longer any reason to use a JS frontend framework, because the reason they were made was to offload to clients the rendering, at the price of more complexity. Back then, the cloud was not a thing yet, there was no Docker, no Kubernetes, no nice APIs to start instances, so it made sense to offload some compu…

What... the reason for JS frontend frameworks is to be able to dynamically update data visible without a full page refresh/refetch

JS does add some capabilities around avoiding full page refresh/refetches. See e.g. Turbolinks or PJAX for libraries that help with that.

Frontend frameworks do a hell of a lot more than that, though. Much of the time, they're doing things that are either the result of shortcomings in browser standards and implementations or things that are just stupid.

Re: Scaling React Server Side Rendering

#37

Post by aplummer »

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…

> You don't need to hire/maintain separate frontend/backend teams who need to figure out how to coordinate with each other.

In my experience the language is very little of what makes a frontend / backend developer, and you still need separate teams.

Re: Scaling React Server Side Rendering

#38

Post by arkwright »

zyngaro wrote: post #23

Great read ! What did you use to draw the diagrams ?

Diagrams are drawn with a Pilot Fineliner (greatest pen ever) in an artist's sketchbook. I then take a photo with my phone, crop to size, and run the image through a two stage conversion process. First ImageMagick converts the image to grayscale and cranks up the contrast. Second, Potrace converts the grayscale bitmap to an SVG. This was my hack way of avoiding the purchase of a tablet.

One interesting consequence of this process is that every drawing needs to be perfect the first time. I didn't realize how much I lean on undo/redo until it wasn't there any more!

Re: Scaling React Server Side Rendering

#39

Post by dvt »

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…

> 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 fake news. Even ignoring the trillion edge cases involving authentication, cookies, localstorage, dynamic components, promises/futures, async components, and so on, it will take dozens of man-hours to get properly-rendered server output that works with server-side routing, hydration and looks good on Google's SEO crawlers.

Post reply on HN