TypeScript at Google
neugierig.org
TypeScript at Google
1–10 of 201 posts
Re: TypeScript at Google
#2I wish they would make a JS/TS-based version of the Closure compiler. I suspect a lot of apps would benefit from the compilation and we'd see much smaller bundle sizes. But the Java dependency is a burden to bear.
Re: TypeScript at Google
#3I wish they would make a JS/TS-based version of the Closure compiler. I suspect a lot of apps would benefit from the compilation and we'd see much smaller bundle sizes. But the Java dependency is a burden to bear.
Isn't there already one? I seem to recall that it mostly works, just much more slowly than the java version
Edit: here you go: https://www.npmjs.com/package/google-closure-compiler
Re: TypeScript at Google
#4Google Maps definitely made JavaScript cool at a time when it was not much in favor - people still thought Java Applets or Flash were going to rule the web.
Re: TypeScript at Google
#5I'm hesitant to work in any JavaScript code base that isn't using TypeScript at this point. Two years ago, it was painful to use as any early release is but the benefits were obvious.
My biggest wish for TypeScript is that it was easier to use experimental flavors that supported JS features currently being considered, such as the pipeline operator proposal.
Re: TypeScript at Google
#6I'm hesitant to work in any JavaScript code base that isn't using TypeScript at this point. Two years ago, it was painful to use as any early release is but the benefits were obvious. My biggest wish for TypeScript is that it was easier to use experimental flavors that supported JS features currently being considered, such as the pipeline operator proposal.
Yeah, agreed.
If I were looking for a regular job, I would probably filter employers based on whether they use TypeScript or not at this point (assuming it was some JavaScript-adjacent project). I'm not sure if there's really a good way of doing this sort of filtering.
Re: TypeScript at Google
#7We’re going through a similar process at my company - how do we refactor the decade old startup-style JS without 1) spending a year rewriting everything from scratch generating little business value and potentially introducing regressions in the process 2) continuing to build stuff on that shaky house of cards. It looks like the solution we’ve kind of settled on has also been TypeScript. At this point it’s probably sub-5% of our prod code that’s TS source, and it’s daunting given how much we have to change and how many years it will take at our current pace, but it is the middle ground moderate way and probably the right way to approach things like this.
Re: TypeScript at Google
#8I'm hesitant to work in any JavaScript code base that isn't using TypeScript at this point. Two years ago, it was painful to use as any early release is but the benefits were obvious. My biggest wish for TypeScript is that it was easier to use experimental flavors that supported JS features currently being considered, such as the pipeline operator proposal.
TypeScript was released in 2012, I wouldn't call a 4 year old tool an early release. And if you were already using Webpack picking it up was as easy as adding a loader.
IMO, using such early proposals isn't worth the risk in production. Especially for proposals that are so young that they haven't even settled on a clear spec as to its behavior, like the pipeline operator.
Re: TypeScript at Google
#9I wish they would make a JS/TS-based version of the Closure compiler. I suspect a lot of apps would benefit from the compilation and we'd see much smaller bundle sizes. But the Java dependency is a burden to bear.
Isn't there already one? I seem to recall that it mostly works, just much more slowly than the java version Edit: here you go: https://www.npmjs.com/package/google-closure-compiler
Nice! Didn't realize this was a thing. I suspect they could make even more aggressive optimizations if they made a TS version.
Re: TypeScript at Google
#10I wish they would make a JS/TS-based version of the Closure compiler. I suspect a lot of apps would benefit from the compilation and we'd see much smaller bundle sizes. But the Java dependency is a burden to bear.
There's a JS version of the Closure compiler [0].
And the version shipped on NPM [1] has options for either native, Java, or JS.