4 ms·

Am I missing something or is this fundamentally not that interesting of an idea? The tl;dr of it is just that they slowly migrated a smaller subset of the inter

Am I missing something or is this fundamentally not that interesting of an idea? The tl;dr of it is just that they slowly migrated a smaller subset of the internal tooling to use TypeScript, and probably in the last 3 years have migrated even more. Is that...notable? I'm sure lots of big companies use TypeScript now. My company has roughly the same # of engineers as Google and has had some teams that adopted TypeScript while others didn't. We even own a product that uses Flowjs, for some reason. It didn't require a huge rigamarole to do so, just a hook into the internal build system (which, looking at it now, is significantly smaller in surface area than the rules_typescript Bazel rule).

wffurr 5y ago
The post covers this in detail. JavaScript at Google was almost completely different from JavaScript elsewhere. The tools were different, the libraries are different, and even the language itself is different (jscompiler’s ES4-inspired type system). It’s also a huge company with a gigantic monorepo (there’s papers about it elsewhere) and a lot of inertia. It’s amazing what Evan and his team were able to do for front-end development at Google by building tools to bridge between Google JS and TypeScript.
- rejectedandsad 5y ago
  Lots of companies have turned JS into effectively another language with a subset of its features with internal libraries. Perhaps they aren't as academically interesting as Closure, but it's not that notable. The monorepo aspect of the story just seems to just make doing this significantly more difficult for no discernible benefit. Isn't this the same team that made that 5 page issue on the TypeScript Github page complaining about a version bump?
  - Orphis 5y ago
    A monorepo surely makes that kind of change difficult. But when it's in, you know every team has access to it. Not just 2 or 3 teams out of hundreds. It has many other benefits as well that have been outlined in lots of other posts.
  - xmprt 5y ago
    This is one such change that is much harder with a monorepo because it introduces many breaking changes. However, in a lot of cases monorepos allow for upgrades and code sharing without much if any effort from individual teams. So a lot of people can get the benefits without doing anything.
emmelaich 5y ago
It's interesting because it's a problem that crops up in every software shop to some degree. Tech debt is a wicked problem and certainly not exclusive to Javascript. It's well written too; a good model for design / discussion papers.

wffurr 5y ago

The post covers this in detail. JavaScript at Google was almost completely different from JavaScript elsewhere. The tools were different, the libraries are different, and even the language itself is different (jscompiler’s ES4-inspired type system). It’s also a huge company with a gigantic monorepo (there’s papers about it elsewhere) and a lot of inertia. It’s amazing what Evan and his team were able to do for front-end development at Google by building tools to bridge between Google JS and TypeScript.

rejectedandsad 5y ago
Lots of companies have turned JS into effectively another language with a subset of its features with internal libraries. Perhaps they aren't as academically interesting as Closure, but it's not that notable. The monorepo aspect of the story just seems to just make doing this significantly more difficult for no discernible benefit. Isn't this the same team that made that 5 page issue on the TypeScript Github page complaining about a version bump?
- Orphis 5y ago
  A monorepo surely makes that kind of change difficult. But when it's in, you know every team has access to it. Not just 2 or 3 teams out of hundreds. It has many other benefits as well that have been outlined in lots of other posts.
- xmprt 5y ago
  This is one such change that is much harder with a monorepo because it introduces many breaking changes. However, in a lot of cases monorepos allow for upgrades and code sharing without much if any effort from individual teams. So a lot of people can get the benefits without doing anything.

emmelaich 5y ago

It's interesting because it's a problem that crops up in every software shop to some degree. Tech debt is a wicked problem and certainly not exclusive to Javascript. It's well written too; a good model for design / discussion papers.