Scaling React Server Side Rendering

Post by true_religion » Tue, Dec 31, 2019, 11:51 PM UTC

kalyantm wrote: post #98

unlinked_dll wrote: post #28

Earlier quoted context omitted.

>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"

Post by mhd » Wed, Jan 01, 2020, 2:28 PM UTC

hnbreak wrote: post #133

mhd wrote: post #130

Earlier quoted context omitted.

Yeah, I never quite liked the currenly en vogue mixed approaches, where it's harder to draw a line, you often have to serve two masters and you feel it's mostly done that way because React developers don't want to learn anything else, despite cases where a complete server-side approach with an old-school template language might be a better fit, despite how hip functional reactive component based development is. But a…

Re your second point: How is the SSR scene in Go land? Are there thriving ecosystems? Besides, it took me a long to leave pug/stylus, I'am still not sure if a pug-based SSR is still the best way to get stuff out of the door. But again, opting for an 10 years old stack let you miss lot of things (eg maintainability of react code is top-notch).

Post by minitech » Thu, Jan 02, 2020, 10:08 PM UTC

eliseumds wrote: post #92

minitech wrote: post #90

Earlier quoted context omitted.

> * 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.

  const inlineJSON = data =>
    JSON.stringify(data)
      .replace(/\u2028/g, '\\u2028')
      .replace(/\u2029/g, '\\u2029')
      .replace(/

  const escapedReduxStateJsonString = inlineJSON(JSON.stringify(data));