The saga of the Closure compiler, and why TypeScript won

Interesting read. I wrote the original compiler back in 2002&#x2F;2003, but a lot changed by the time it was open sourced (including the confusing name -- I just called it a javascript compiler).<p>One detail this story gets wrong though is the claim that, &quot;The Gmail team found that runtime JavaScript performance was almost irrelevant compared to download times.&quot; Runtime performance was actually way more important than download size and we put a lot of effort into making the JS fast (keep in mind that IE6 was the _best_ browser at the time). One of the key functions of the js compiler was inlining and dead-code removal so that we could keep the code readable without introducing any extra overhead.

A few things held closure compiler back in my mind from general adoption:<p>- First and foremost a Google tool, not a tool <i>meant</i> for the masses, per se[0]. It could do great things, but it had the dependency on closure tools, which were not the easiest to use outside of Google (did anyone outside google actually use the `goog.*` stuff?) and writing annotation files (externs) of libraries and such never caught on and weren&#x27;t shared in some meaningful way.<p>- Lacked evangelism. I imagine this had to do with the above. There weren&#x27;t people from Google singing the benefits loud and proud everywhere about using the Closure Compiler<p>- Docs weren&#x27;t the best. Some parts are still broken (links and such).<p>- It didn&#x27;t evolve. Closure <i>could have</i> been a pretty great bundler too, actually, but it didn&#x27;t support ESM for a long time and it was never clear how to get it bundle things even when it did, I think you mostly had to declare each dependency file for it to work correctly, but I never myself got it to work 100%<p>These are some of the things that I think ended up holding it back. It could have been a cool little ecosystem too. There was a sister project called Closure Stylesheets that was for CSS that was supposedly very good as well, though I think thats no longer maintained. I believe it was very similar to how people use PostCSS in terms of what it did<p>[0]: Lots of projects use it to minify their JS but never really took advantage of the advanced functionality it can provide on top.

Closure compiler was actually one of the biggest influences on the design of TypeScript, and even the early motivation for the approach that TypeScript took.<p>From <a href="https:&#x2F;&#x2F;medium.com&#x2F;hackernoon&#x2F;the-first-typescript-demo-905ea095a70f" rel="nofollow noreferrer">https:&#x2F;&#x2F;medium.com&#x2F;hackernoon&#x2F;the-first-typescript-demo-905e...</a>:<p>&gt; There were many options already available, but none seemed to be resonating well with a broad enough section of the market. Internally at Microsoft, Script# was being used by some large teams. It let them use C# directly instead of JavaScript, but as a result, suffered from the kind of impedance mismatch you get when trying to stand at arms length from the runtime model you are really programming against. And there was Google’s Closure Compiler, which offered a rich type system embedded in comments inside JavaScript code to guide some advanced minification processes (and along the way, caught and reported type-related errors). And finally, this was the timeframe of a rapid ascendancy of CoffeeScript within the JavaScript ecosystem — becoming the first heavily used transpiled-to-JavaScript language and paving the way for transpilers in the JavaScript development workflow. (Aside — I often explained TypeScript in the early days using an analogy “CoffeeScript : TypeScript :: Ruby : C#&#x2F;Java&#x2F;C++”, often adding — “and there are 50x more C#&#x2F;Java&#x2F;C++ developers than Ruby developers :-)”)<p>&gt; What we quickly discovered we wanted to offer was a “best of all worlds” at the intersection of these three — a language as close as possible to JavaScript semantics (like CoffeeScript) and syntax (like Closure Compiler) but able to offer typechecking and rich tooling (like Script#).

I&#x27;ve been using the Google Closure compiler for the last 8 years or so, in production. My SaaS depends on it, so you could say I make a living based on that tool. It&#x27;s been working great, providing a significant performance increase to my ClojureScript code, along with a bunch of other benefits. I use advanced compilation mode.<p>I&#x27;m not sure why the author believes that &quot;minification was a design goal&quot;. Minification is a side effect.<p>&gt; &quot;In the context of npm in 2023, this would be impossible. In most projects, at least 90+% of the lines of code are third-party. &quot;<p>Well I guess that&#x27;s why I avoid using npm and why I can maintain code for 8 years and still keep my sanity. I keep the use of third-party code to a minimum, carefully considering each addition, its cost over time, and the probability that it will be maintained.<p>As a side note, I think it&#x27;s immature to use terms like &quot;X won&quot; or &quot;Y is dead&quot; in tech discussions.

Closure Compiler was an amazing tool, and still is.<p>When I was at Lucidchart, I helped convert the 600k line Closure codebase to TypeScript. [1] In fact, Lucidchart still uses Closure (for minification+library, not typechecking).<p>There are better approaches available in 2023, but Closure Compiler will always have special place in my heart.<p>[1] <a href="https:&#x2F;&#x2F;www.lucidchart.com&#x2F;techblog&#x2F;2017&#x2F;11&#x2F;16&#x2F;converting-600k-lines-to-typescript-in-72-hours&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.lucidchart.com&#x2F;techblog&#x2F;2017&#x2F;11&#x2F;16&#x2F;converting-60...</a>

&gt; Unless you&#x27;ve worked on frontend at Google at some point in the past 20 years, it&#x27;s unlikely that you&#x27;ve ever encountered the Closure Compiler<p>Unless, of course you were at the forefront of frontend stuff like a decade ago and Closure Compiler was the absolute best for a long time at dead-tree elimination and compressing JS artifacts. Or, you&#x27;re a developer using ClojureScript. Or...<p>&gt; It occupied a similar niche to TypeScript, but TypeScript has absolutely, definitively won.<p>Huh? The Closure Compiler is so much more than just &quot;JavaScript but with types&quot;. It also provides minification, provided a namespacing system, additional standard library and such.

Outside Google, ClojureScript (with a &quot;j&quot;) used to depend on the Closure compiler (with an &quot;s&quot;) - partly because the library that came with the compiler provided a Java-like API which was convenient as the Clojure language was originally written targeting Java, and partly because the language had quite a large runtime and tree shaking was necessary for performance. You also had to write extern declarations if you used outside code, much like you have to manually declare types for untyped dependencies in when using Typescript.<p>Edit: ClojureScript still depends on Google Closure.

I absolutely hate property renaming in the Closure compiler.<p>If you’re not acutely aware of it and you do a `myObj[‘someProp’]`, you’re not going to get any in code warnings, everything will work as you expect in development, and you’re tests and presubmit checks will pass. On multiple occasions for me, the problem surfaced in production, and there was no one around to tell me that property renaming was even a thing. I had to try to debug compiled code.<p>Worse still is that you don’t even have to try to do a `myObj[‘someProp’]` to get into trouble. There is very commonly used library code that will cause the same problem—you’re just calling a method that tries to access a property on an object. But since it’s abstracted, it’s even harder to catch during a code review or to debug the problem.

From what I recall, the Closure type system wasn&#x27;t well suited to Javascript. I recall it as being quite Java-ish (nominal rather than structural). It&#x27;s been a loooong time since I looked at it, though, so I might be misremembering.

This bring back happy memories of the Closure Compiler and using Clojurescript. I built a product back in the day using these technologies. There was definitely a lot of innovation in the Clojure ecosystem. Also I remmeber how confusing if was to talk about the difference between Closure and Clojure since they sound the same :)

Part of Closure Tools was also an early CSS transpiler called &quot;Closure Stylesheets&quot; that behaves very much like the CSS &#x27;preprocessor&#x27; languages that followed it <a href="https:&#x2F;&#x2F;github.com&#x2F;google&#x2F;closure-stylesheets">https:&#x2F;&#x2F;github.com&#x2F;google&#x2F;closure-stylesheets</a><p>It&#x27;s easy to see this set of JavaScript and CSS tools as ahead of their time, and the first of the particular kind of toolset that followed in the years after it.

Typescript won because Microsoft shipped vscode with out of the box TS integration that just worked. This is touched on in the article but understated.<p>They used the exact same approach as visual studio and .NET, and managed to eat up the entire fragmented ecosystem in a matter of years.

I&#x27;ve never worked for Google, but have written a lot of Closure code.<p>Unfortunately, my opinions about Closure are colored by how it was used within my org -- which was far from ideal. We should have taken the best of Closure (the compiler, type checking, and maybe a few utility libraries) and ignored most of the rest.<p>When we switched all greenfield JS development from Closure to React around 2016, it resulted in a 2-3x speed-up in the development process. Not because the compiler stage added any significant time to our process, but because of poor design patterns that were implemented because Google was using them -- but perhaps not with the correct level of understanding about how to use them effectively.

Great article, I had forgotten that Closure existed.<p>Weird have been interesting to include Facebook&#x27;s Flow. That one seems pretty similar to TypeScript but more oriented towards Facebook&#x27;s specific needs than a genuinely open source tool.

Interesting note: React itself uses the Closure Compiler <a href="https:&#x2F;&#x2F;legacy.reactjs.org&#x2F;blog&#x2F;2017&#x2F;12&#x2F;15&#x2F;improving-the-repository-infrastructure.html" rel="nofollow noreferrer">https:&#x2F;&#x2F;legacy.reactjs.org&#x2F;blog&#x2F;2017&#x2F;12&#x2F;15&#x2F;improving-the-rep...</a>

To confuse matters further, CloJurescript uses the CloSure compiler.

A footnote to this is that ClojureScript bet heavily on the Closure compiler, at a time when, IIRC, it wasn&#x27;t even open sourced. In particularly, it was not just a bet on the technology, but the underlying methodology, so ClojureScript was designed to produce a lot of JS that the Closure compiler would find easy to optimise. A solid and clever design, but a bet on the wrong ecosystem.

google has the curse that they can scale any problem across hundreds of machines. This isn&#x27;t an environment that creates tools that a single developer wants to run on their machine. closure was always slower then alternatives and not fun to use on your 6 year old laptop to check your side project.

We still use the Closure compiler on one of our projects that originated about 10 years ago. It’s difficult (but not impossible) to debug with, but there’s no compelling reason to replace it yet. The code base has been completely rewritten over time with modern JS and amazingly the compiler works just fine.

I&#x27;ve never seen these as competitors. Closure is for minifying code and typescript is for type checking.

Maybe in the not so distant future, TypeScript versus Closure Compiler won&#x27;t matter and everyone will be compiling their favorite language to WebAssembly instead.<p><a href="https:&#x2F;&#x2F;caniuse.com&#x2F;wasm" rel="nofollow noreferrer">https:&#x2F;&#x2F;caniuse.com&#x2F;wasm</a>

Google has a history of killing its own products and services. It is not wise to build on top of depending on their tools. It&#x27;s likely that you&#x27;ll get rugged next quarter.

Under &quot;Why TypeScript won&quot;, the article says:<p>&gt; It&#x27;s self-hosted (tsc is written in TypeScript)<p>Why would that matter? What if TypeScript was written in Rust? I would assume the better performance would have increased its adoption even more.

How does a programming language &quot;win&quot; against a code minifier? Typescript and Closure compiler solve entirely different problems, they are not in any way alternatives to each other.<p>It&#x27;s not like Typescipt somehow solved code minification in a way that made Closure compiler redundant. It&#x27;s still used where it makes sense (e.g. to compile Scala.js output, although other solutions like terser.js work too).

I still use it (indirectly) every day.

It&#x27;s still used in TS apps

Closure Compiler was way ahead of its time. I used it extensively at my first job. It was the only way to stay sane pre-ES5. It&#x27;s still great for people who want to write JavaScript applications as if they were Java applications. But it lost because people hate writing Java applications.