[oefrha]

They did acknowledge that, albeit subtly,

> After a string of production incidents in early 2021, we realized our existing SSR system was failing to scale as we migrated more pages from Python-based templates to React.

Apparently their old server-rendered Python app (not called SSR though for obvious reasons) was scaling just fine before the migration.

[anentropic]

Yeah... and then this:

> We evaluated several languages when it came time to implement the SSR Service (SSRS), including Python and Rust. It would have been ideal from an internal ecosystem perspective to use Python, however, we found that the state of V8 bindings for Python were not production ready

Wow, that is some convoluted architecture

It seems like the problem here is React

[andrewingram]

Yeah, you have to do a lot to offset the problem that, out of the box, rendering React on the server is slow.

[whazor]

I see a lot of React hate which I can understand, but don't forget that React allows you to release faster as a big company.

React is a defacto standard that product people know and understand. They can ship complicated features faster across platforms (for example React Native), while the more technical engineers get to solve these more generic problems (dependency hells, integrations, CI/CD, performance).

Alternative solutions would potentially require more technical engineers to build features and thus slow down product development for a big company.

[manigandham]

> "I see a lot of React hate"

Pointing out badly constructed solutions using the wrong tech is valid criticism. It's not "hate" to say that React and this SSR setup is used being used unnecessarily for a site that doesn't need it.

> "React allows you to release faster as a big company."

This is absolutely not a rule in any way. Again, using the proper tech for the situation is what matters. Large teams with complex frontends can sometimes move faster with React, but there are million other factors that go into this.