In case anyone's curious, this is how I would summarize Facebook's code style in JS (after auditing/reviewing a lot of their 'open-source' libraries):

- The code is reasonably readable. Names are generally sensible, and there's no three-letter-abbreviation nonsense.

- There is not a lot of 'magic' in the code (unlike, say, in Google code); the structure is pretty straightforward and consistent to follow.

- ... However. It is very clearly corporate code. It tends to avoid using anything not written by Facebook, so there are lots of reinvented wheels that *should* have just been dependencies on something else.

- Those reinvented wheels often take shortcuts. Sometimes those shortcuts have security implications, sometimes they "only" make the code unreliable or buggy.

- There are a lot of claims of implementations being especially performant or scalable, as a seeming justification for having a reinvented wheel. Sometimes these seem true, most of the time they're very debatable.

- Their build systems are absurd. Ridiculous levels of complexity, bespoke build tooling with strange architectural choices that doesn't actually do anything the common tools don't already do. Just use what everybody else uses already, ffs.

- Lots of inlined workarounds for Facebook-specific usecases/situations. These are usually clearly marked, but it's clear that anyone who isn't Facebook is a second-class citizen in library design choices.

- Overall, the total complexity of their code is high. Use of abstractions is poor; there often seems to be three times as much code as is needed to do the job, because they keep reimplementing the same structures for different purposes even within the same library.

- Occasional inline vendoring. This is usually because they need some internals change in a library they're using, but that vendored fork then never gets updated again, and I often question whether it couldn't have been upstreamed.

I'm posting this review for two reasons:

1. To demystify 'big tech' developers and show that they're not some sort of infallible superheroes with exclusive tools that nobody else could reproduce. Their work is slightly above average, at best. I have seen random libraries from unknown developers with much better work.

2. To show how the environment in which software is developed, affects *how* it is developed. The shortcuts and reinvented wheels above make total sense for a corporate environment; because they are focused on internal demands and meeting deadlines in any way possible, not on collaboration with others in the public commons or the broader public interest.