Great post on #ClosureCompiler, it's history at #Google and how it evolved compared to #TypeScript.
https://effectivetypescript.com/2023/09/27/closure-compiler/
I can help with one of the last points:
> True to form, this tool [tsickle] is open source but pretty inscrutable to an outsider. It may be used by Angular but I couldn't tell.
I can confirm that Angular does *not* run `tsickle` or Closure in user projects with `ng build`. There was an experiment some years ago where we tried this to see if we could improve bundle sizes, but found that asking users to write Closure-optimizable code was too difficult and hard to justify outside Google. As a result, we never ran this in prod.
I believe we do technically run `tsickle` in Angular GitHub repositories, as we have a unique build system setup with #Bazel and #rules_nodejs. If you've ever contributed to Angular, you probably ran `tsickle`. We've been trying to remove this dependency, but I don't think it's happened yet.
@develwithoutacause Good post! One thing that stuck out to me was the assertion that in most projects & companies, >90% of the code is third-party; but at Google the ratio is flipped and almost everything is written in-house, which is why Closure worked so well there.
I do wonder at what point that starts to be realized - I'm at a large org (Fortune 200) that's steadily marched towards more and more of the codebase coming from OSS. Is it just at FAANG-scale that it flips?
@mattdsteele Hard to say, we'd probably need a more comprehensive survey.
Google is likely unique in that we've kind of developed are own independent "tech island" (as coined by Urs I think?) where we've developed our own internal tools and constraints such that you really _can't_ just plug in an external OSS tool.
The historical point about #Gmail as the first big Google #SPA and how it's timeline aligns with #Node is relevant, most #web #OSS tooling didn't exist like it does today.
Hypothetically you could replace Closure compiler with #Webpack, #Rollup, or any other bundler, but Google workloads are so large that these tools just fall over in comparison.
Even if we had switched to Webpack, migrating the internal codebase makes things move much slower than the external ecosystem. Moving to Rollup or #ESBuild would be a major task in itself, so that tooling can easily become technical debt just as expensive as maintaining our own.
Most companies don't have this scale and history.