What does HackerNews think of tsickle?
Tsickle — TypeScript to Closure Translator
[1] https://github.com/angular/tsickle
[2] 'gents', in this repo https://github.com/angular/clutz
We used it at Lucid when we converted our codebase from Closure annotated JavaScript to TypeScript. https://www.lucidchart.com/techblog/2017/11/16/converting-60...
Google has support for using TypeScript in Closure annotated JavaScript via Clutz: https://github.com/angular/tsickle
It also has support converting TypeScript to Closure annotated JavaScript via tsickle: https://github.com/angular/clutz
Before we converted all of our codebase to TypeScript we used both Clutz and tsickle. It was complicated to setup, but it worked. Now we just use tsickle. It's great to get the optimization of the Closure Compiler while using TypeScript.
(1) The angular compiler doesn't have the same JS or CLI interface as the TypeScript compiler. I have to know very specifically which I am using when; my build tooling must always know whether it's compiling TS the Angular way, or the vanilla way, and there isn't much commonality.
(2) What if I want to use an alternative TS compiler? Or someone writes a faster one in Go? Or I want to use tsickle [1], which is Closure Compiler-compatible?
Now it turns out there isn't a TS compiler in Go, and the Angular team are the authors of tsickle, and so ngc happens to work with it. But it's an architectural smell to couple that closely for my MVC framework (and IMO with little necessity).
I'd be interested in seeing what a large typescript project would look like run through https://github.com/angular/tsickle.
I don't have a direct comparison to Uglify, but as of last fall advanced optimizations does save us about 2.5 MB over simple optimizations.
We're also using Tsickle (https://github.com/angular/tsickle) and Clutz (https://github.com/angular/clutz) to be able to use TypeScript with our Closure Compiler compatible codebase. Closure Code can be depended upon in TypeScript code and vice versa. It's been awesome to use the type system of TypeScript in combination with the minification power of the Closure Compiler. The build process is definitely a bit crazy at the moment, though.
Disclaimer: I work at Lucid Software.
It wraps the TypeScript Compiler and outputs CC compatible type annotation comments.
The downside to its age is that it likes to do things its own way; it's had a static module system since long before ES2015 modules or even CommonJS modules existed. It does have support for other module systems now, though. And as the article mentions, it performs optimizations far beyond what other JS tools do.
One of the big things people disliked about the compiler is that to get maximum optimizations out of it, you had to write your JS in a relatively static way, preferably with JSDoc type annotations.
This is less of a barrier now, I think; TypeScript has become quite popular in the front end community, and the Angular team has created TSickle[1], which allows the TypeScript compiler to output Closure annotated JS.
Webpack is a lot more capable, but also results in shipping a much larger code bundle to your users. This might not matter so much for desktop clients, but in many parts of the world, mobile users still have pretty restrictive data caps, and overages are very expensive.
https://github.com/angular/tsickle
It's already used within Google to effectively optimize TypeScript apps. However, someone still needs to write the integrations between tsickle and the multitude of public JS build systems and there's not a lot of pressure on me to do it (I have lots of other work to do).
[0]: https://github.com/angular/tsickle
[1]: https://github.com/google/closure-compiler/wiki/Type-Based-P...