I have easy solution: don't use React!
Scaling React Server Side Rendering
91–100 of 137 posts
Re: Scaling React Server Side Rendering
#92I developed the JS architecture of https://www.productreview.com.au and we have faced tons of issues getting SSR right, but it was worth it. We're getting more than 10M pageviews a month and I'd like to share our experience: * Upgrading NodeJS indeed gives us massive performance boosts, but apply with caution. Ideally have a set of visual regression tests just to be safe * Profile your NodeJS code just like you do wi…
> * Properly serialize your JSON strings. That's what we use: https://gist.github.com/eliseumds/6192135660267e2c64180a8a9c... . That doesn’t look like “properly”. The double escaping is overcomplicated and no safer compared to a direct window.__productreview_data = ${escapedReduxStateJsonString}; (and forgets about \v, maybe others), the transformation doesn’t preserve “ Closer to correct: JSON.stringify(data) .repla…
Thanks for pointing out the `https://v8.dev/blog/cost-of-javascript-2019. From what I remember, we had some issues with IE11, thus the replacement for the other characters.
We'll consider "application/json", makes sense.
Re: Scaling React Server Side Rendering
#93Earlier quoted context omitted.
On a bad connection, I'd pick a react SPA with a slow upstart over a classic server-side rendered one any day all things being equal. With the react app there's a chance I'll have the js already cached and I'm only fetching the data. With the SSR I'll probably be fetching data and view continuously.
Nonsense. You haven’t experienced a slow connection recently, or you’re just loading the same sites over and over again. I love the JS experts on HN, telling everyone it’s impossible to do all of the stuff we were doing on a daily basis in 2012, without the magic of megabytes of client-side code.
Please don't be a jerk in comments here. I'm sure you can make your substantive points without that.
Re: Scaling React Server Side Rendering
#94This 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 full-time Javascript developer. We can do better than mandating JS on the servers.
#1. SPA, Components and functional programming is the best thing that happened to web development in the recent past. So, let's stick with it.
#2. But we are stuck with Javascript to embrace these otherwise abstract engineering methods, because browsers are stuck with JS.
#3. Webassembly is here. So why not a UI-framework, that embraces components, SPAs and functional programming but with a better language (something like Elm). A language that compiles to webassembly for browsers to run logic & build UI and runs natively on servers? This hypothetical system should compile to HTML on the servers and support smooth progressive hydration.
Running a bunch of JS on the servers, on a piece so critical like rendering HTML will always be a suboptimal solution. Imagine saving all that server-scaling costs with a much server-cost-friendly language like Rust or Swift?
Re: Scaling React Server Side Rendering
#95Earlier 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…
On a bad connection, I'd pick a react SPA with a slow upstart over a classic server-side rendered one any day all things being equal. With the react app there's a chance I'll have the js already cached and I'm only fetching the data. With the SSR I'll probably be fetching data and view continuously.
Nonsense. You haven’t experienced a slow connection recently, or you’re just loading the same sites over and over again.
People keep asserting it’s impossible to do all of the stuff we were doing on a daily basis in 2012, without the magic of megabytes of client-side code.
Re: Scaling React Server Side Rendering
#96This 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…
Wasm isn't capable of manipulating the DOM yet.
Re: Scaling React Server Side Rendering
#97This 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…
Wasm isn't capable of manipulating the DOM yet.
Yes, but it can send commands to construct and manipulate DOM. See - https://github.com/yewstack/yew
Re: Scaling React Server Side Rendering
#98Earlier 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.
What people fail to consider is even with the high end smartphones, how do we know you are guranteed full speed 4G all the time?
The network speed varies greatly in various places (in the subway, through the tunnels etc) and more often that not, we have sucky network speeds even though we are on "4G"
Re: Scaling React Server Side Rendering
#99I think it would be a good idea to see this setup in a larger comparison like https://www.techempower.com/benchmarks. It is not my impression that node based apps did particulary well here in these tests. So if performance is important why not use something that has proven to be fast.
Re: Scaling React Server Side Rendering
#100This 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…
Rather than running JS on the server, one way I found things to be effective is using any server side templating capability to basically "bootstrap" what the JS might typically do on start-up. So the server renders you a page that looks well formed and then the JS hooks into it for client interactions.
The issue that can be runned into here is possibly duplicating efforts on the server and JS side. You can keep them separate enough but it's tough if you're used to creating everything either through the server or through JS on the client.
The last web app I worked on like this is unfortunately not public but performed rather well and wasn't all that difficult to maintain either.