[HN Gopher] The saga of the Closure compiler, and why TypeScript...
___________________________________________________________________
The saga of the Closure compiler, and why TypeScript won
Author : Fudgel
Score : 58 points
Date : 2023-09-28 07:55 UTC (15 hours ago)
(HTM) web link (effectivetypescript.com)
(TXT) w3m dump (effectivetypescript.com)
| ramesh31 wrote:
| 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'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.
| aidenn0 wrote:
| Are you thinking of GWT rather than Closure?
| ramesh31 wrote:
| >Are you thinking of GWT rather than Closure?
|
| Yeah, fair enough. Though at the time their usage was almost
| always as a pair.
|
| Closure itself was still written in Java though, and had a
| bunch of support for Java-y things as well like namespaces,
| generics, inheritance, etc.
| noelwelsh wrote:
| From what I recall, the Closure type system wasn't well suited to
| Javascript. I recall it as being quite Java-ish (nominal rather
| than structural). It's been a loooong time since I looked at it,
| though, so I might be misremembering.
| com2kid wrote:
| TypeScript aims to make a type system that can model anything
| you can do in JS. Of course JS can modify its objects, at
| runtime, in literally any way imaginable, so the TS type system
| has to be Turing complete. Anything less powerful and you
| aren't going to be able to model what arbitrary JS code is
| doing.
|
| My go to example being a function that takes in an object with
| a bunch of camel case parameterFields and makes them into snake
| case parameter_fields.
|
| Easy peasy in TypeScript, You can say, in a generic fashion,
| "pass an object with camelCase field names, and return the same
| object but the field names are snake_case".
|
| This is incredibly useful when adapting between different
| systems!
|
| Traditional OO systems fall flat on their face attempting such
| feats.
| stevage wrote:
| Funny, I actually wrote and maintain a library which, amongst
| other things, does almost the same thing as your contrived
| example, except it's camelCase to kebab-case. It's written in
| Flow though, because that was what I knew at the time.
| com2kid wrote:
| > does almost the same thing as your contrived example
|
| Sadly, not contrived!
|
| Anyone using protocol buffers is actually familiar with
| this exact scenario. Not sure how the JS PB compiler
| handles things though, I never bothered to look under the
| covers.
| bananapub wrote:
| you're confusing Closure with Clojure
| ramesh31 wrote:
| >You're confusing Closure with Clojure
|
| No. Idiomatic Closure code was extremely Java-like. That was
| the whole point. Google built it to abstract away the nasties
| of early JS for their huge stable of Java programmers at the
| time. Dedicated JS engineers weren't really a thing yet.
| krackers wrote:
| It's just JSDoc though?
| noelwelsh wrote:
| Right, but if you can't give precise types to common coding
| patterns the type system isn't very useful. A lot of work in
| Typescript is about being able to type the kind of things
| people do in JS.
| paulddraper wrote:
| That is correct. It was heavily Java inspired. (And the
| compiler itself is written in Java).
|
| But the same is true of JSDoc.
|
| There weren't any popular type systems that weren't like Java.
|
| ---
|
| Also, there are some notable departures, e.g. union types.
| stevage wrote:
| Great article, I had forgotten that Closure existed.
|
| Weird have been interesting to include Facebook's Flow. That one
| seems pretty similar to TypeScript but more oriented towards
| Facebook's specific needs than a genuinely open source tool.
| paulddraper wrote:
| Closure Compiler was an amazing tool, and still is.
|
| 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).
|
| There are better approaches available in 2023, but Closure
| Compiler will always have special place in my heart.
|
| [1]
| https://www.lucidchart.com/techblog/2017/11/16/converting-60...
| sangnoir wrote:
| Closure was/is a technological marvel - years ahead of the
| competition in some aspects. Closure had dead-code removal
| years before "tree-shaking" became popular in the Javascript
| world - both the buzzword and the implementations.
|
| The public-facing documentation was terrible, and it got very
| little evangelism.
| paulddraper wrote:
| > The public-facing documentation was terrible, and it got
| very little evangelism.
|
| Like a lot of Google OSS projects, honestly.
|
| Cool tech, but awkward for everyone not-Google to use.
| jawns wrote:
| I've never worked for Google, but have written a lot of Closure
| code.
|
| 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.
|
| 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.
| pard68 wrote:
| I still use it (indirectly) every day.
| latte wrote:
| Outside Google, ClojureScript (with a "j") used to depend on the
| Closure compiler (with an "s") - 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.
|
| Edit: ClojureScript still depends on Google Closure.
| [deleted]
| err4nt wrote:
| Part of Closure Tools was also an early CSS transpiler called
| "Closure Stylesheets" that behaves very much like the CSS
| 'preprocessor' languages that followed it
| https://github.com/google/closure-stylesheets
|
| It'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.
| no_wizard wrote:
| A few things held closure compiler back in my mind from general
| adoption:
|
| - First and foremost a Google tool, not a tool _meant_ 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 't shared in some
| meaningful way.
|
| - Lacked evangelism. I imagine this had to do with the above.
| There weren't people from Google singing the benefits loud and
| proud everywhere about using the Closure Compiler
|
| - Docs weren't the best. Some parts are still broken (links and
| such).
|
| - It didn't evolve. Closure _could have_ been a pretty great
| bundler too, actually, but it didn '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%
|
| 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
|
| [0]: Lots of projects use it to minify their JS but never really
| took advantage of the advanced functionality it can provide on
| top.
| troupo wrote:
| > Docs weren't the best. Some parts are still broken (links and
| such).
|
| Quite an understatement :) It was something like two pages of
| "install like this" (one page) and "you should use Closure
| library" (one page).
|
| Errors? Troubleshooting? Integrating with anything outside
| Closure? Hah.
| capableweb wrote:
| > Unless you've worked on frontend at Google at some point in the
| past 20 years, it's unlikely that you've ever encountered the
| Closure Compiler
|
| 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're a developer using ClojureScript. Or...
|
| > It occupied a similar niche to TypeScript, but TypeScript has
| absolutely, definitively won.
|
| Huh? The Closure Compiler is so much more than just "JavaScript
| but with types". It also provides minification, provided a
| namespacing system, additional standard library and such.
| paulddraper wrote:
| There is a 100% chance you know about the Closure Compiler if
| you did any research on minification pre-2012.
| holoduke wrote:
| Exactly. We build a large SPA back in 2008. Used closure
| compiler just for modulizing the code base and minification for
| production. It had some linting as well. The software still
| running today only last year moved to parceljs.
| yankput wrote:
| > The Closure Compiler is so much more than just "JavaScript
| but with types". It also provides minification, provided a
| namespacing system, additional standard library and such.
|
| That's literally what the article is about if you read a few
| sentences more
| capableweb wrote:
| Ok, maybe take that up with the article author that they're
| being inconsistent then?
| Waterluvian wrote:
| I think it's surprising to some who live and breathe a domain
| just how niche many parts of it really are.
| arthurbrown wrote:
| 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.
|
| 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.
| marksomnian wrote:
| Interesting note: React itself uses the Closure Compiler
| https://legacy.reactjs.org/blog/2017/12/15/improving-the-rep...
| danvk wrote:
| That is an interesting note (and news to me as the article
| author). Note that they used Closure in its "simple" mode,
| rather than "advanced", which is what the post is mainly
| talking about. I wonder if React still uses CC?
___________________________________________________________________
(page generated 2023-09-28 23:00 UTC)