3 ms·

> I don’t think libraries like React could get developed at Google given how hard it would be to evolve the API surface. That's more of a feature and not a bug

> I don’t think libraries like React could get developed at Google given how hard it would be to evolve the API surface. That's more of a feature and not a bug to me. Users of a library would appreciate it if the API surface doesn't change dramatically over time.

compiler-guy 3y ago
That's the strange thing about the GP comment: Teams can and do change their API surface dramatically over time. They use the LSC process that the GP doesn't like to do it, and it is 99% invisible to the API users. It works, if not exactly flawlessly every time, very consistently well, and there are dozens of such changes in flight all the time that API users barely even realize exist. Don't know what the alternative would be.
tallowen 3y ago
I don't think the burden of the changing API surface was place on the callers of that API. With core library developers updating their callsites, it meant that people calling into early versions of React, never had to deal with upgrading the react version in their package. As a caller of these libraries, it was much nicer to have the React team take care of upgrades where possible rather than having to deal with it myself. Furthermore, there were tons of changes that could happen across the board at facebook that didn't happen at google due to owners files. Lots of people were empowered to make broad changes to the entire codebase which in aggregate made the codebase better. Coming from Facebook, all the systems around owners and readability represented a huge amount of time to be able to make changes that should have been easy. It also left the codebase with many warts that would have been relatively quick to fix locally but a pain to land. Facebook went in the other direction - there were better and better tools for making broad updates
CalChris 3y ago
Dramatically, no. But then a couple of releases of deprecated and then hasta la vista is fine with me if it means progress.

compiler-guy 3y ago

That's the strange thing about the GP comment: Teams can and do change their API surface dramatically over time. They use the LSC process that the GP doesn't like to do it, and it is 99% invisible to the API users. It works, if not exactly flawlessly every time, very consistently well, and there are dozens of such changes in flight all the time that API users barely even realize exist. Don't know what the alternative would be.

tallowen 3y ago

I don't think the burden of the changing API surface was place on the callers of that API. With core library developers updating their callsites, it meant that people calling into early versions of React, never had to deal with upgrading the react version in their package. As a caller of these libraries, it was much nicer to have the React team take care of upgrades where possible rather than having to deal with it myself. Furthermore, there were tons of changes that could happen across the board at facebook that didn't happen at google due to owners files. Lots of people were empowered to make broad changes to the entire codebase which in aggregate made the codebase better. Coming from Facebook, all the systems around owners and readability represented a huge amount of time to be able to make changes that should have been easy. It also left the codebase with many warts that would have been relatively quick to fix locally but a pain to land. Facebook went in the other direction - there were better and better tools for making broad updates

CalChris 3y ago

Dramatically, no. But then a couple of releases of deprecated and then hasta la vista is fine with me if it means progress.