Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TypeScript at Google

neugierig.org

Post reply on HN
Print view View original

91–100 of 201 posts

Re: TypeScript at Google

#91

Post by williamdclt »

a_humean wrote: post #88
conover wrote: post #21

Earlier quoted context omitted.

The codebase powering www.twitch.tv utilizes TypeScript and I can’t imagine working on a project of any significant size without leveraging it going forward.

So I know you also use React extensively at twitch, so how are you finding react and typescript working together? I've been using the two together recently and its been great. Like you I don't think I could ever go back to not using typescript for anything but the smallest projects. However, often times I've found some common react patterns to be difficult to express in typescript. Namely default props and high order…

Maybe use the defaultProps HOC from recompose? Or take example from it!

Re: TypeScript at Google

#92

Post by wwwigham »

bcherny wrote: post #48
evmar wrote: post #31

Earlier quoted context omitted.

This idea is probably worth a post of its own. I believe that because TypeScript's type system is effectively advisory rather than guaranteed ('unsound'), you cannot rely on it for optimization unless you're willing to unpredictably break programs.

Hey, that’s an interesting thought! If you go all the way and make it sound with variance annotations, banning asserts & under specified types, etc. then you end up with a language that sucks to use in practice. If you go to the other extreme, you don’t have static types at all. If different parts of your code are typed to varying degrees, or you use a lot of unsound types/inferences, maybe there’s a way to assign a…

> If you go all the way and make it sound with variance annotations

Variance annotations aren't quite what would make the language (in strict mode) sound. Specifically, what makes it unsound is the `any` type (generally) and the lack of enforced variance on methods, non-function properties, and index signatures. It doesn't need annotations to determine variance - type parameter variance can be inferred from where in a type a type parameter is used. It already does so for functions (that's the strict flag's strictFunctionTypes subflag). The real issue is that far, far too many people rely on, eg, unsound array assignments (array aughta be invariant over what it contains but it's often treated covariantly), for it to be reasonable to be a default. However it could always be changed (or added) in the future - that's what the strictness flags are for, ideally; providing ways to ratchet up the safety such that it won't permanently break longtime users of the language.

Re: TypeScript at Google

#93

Post by wwwigham »

s4vi0r wrote: post #52

As somebody migrating a React codebase from JS to TS, I can't believe how popular TS is. It seems like something that only exists due to the popularity of Angular, where I can only assume the experience is significantly better than with React. The type system is frankly disappointing, and the errors the compiler spits out at you (besides the most obvious ones) are almost always useless or gibberish and at times even…

> The type system is frankly disappointing, and the errors the compiler spits out at you (besides the most obvious ones) are almost always useless or gibberish and at times even more harmful than helpful.

I'd love to see examples of such errors. (And, ideally, accompanying code example)

Re: TypeScript at Google

#94

Post by moogly »

helixten wrote: post #11
mattferderer wrote: post #5

I'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.

I hope the work they did with the Babel team with help with this. https://blogs.msdn.microsoft.com/typescript/2018/08/27/types...

Until this showstopper is fixed (it's been almost 9 months now), some of us can't move forward with Babel 7: https://github.com/babel/babel/issues/7074

Re: TypeScript at Google

#95

Post by boubiyeah »

eksemplar wrote: post #40

I always wonder why people think typescript is a fix for bad code. We primarily do JavaScript, and I see no issues with it when you set up governance in how to use it. I don’t think building your own libraries is really a bad thing either, in fact I think you should do so often instead of relying on 3rd party packages of quality you typically judge on how many times they’ve been downloaded if you’re being honest. I t…

How is dart superior to TS? This is so uninformed. Just like your view of what a type system does.

Dart is very poorly designed, and they managed that even without the constraint of being 100% compatible with good old broken javascript.

It doesn't have null safety. This right here, is enough said and yet we could continue for hours, like how its standard library made the same 20 years old mistakes as java with things like "immutable collections are just mutable collections that throw exceptions", etc, etc.

Flutter might increase the demand and pressure on Dart quality but it's not a good language by any stretch of the imagination.

Re: TypeScript at Google

#96

Post by realusername »

markn951 wrote: post #7

We’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 s…

You can do it step by step when you need it, we had about 5% Typescript in the biggest project in my company when I started, now it's about 70%.

Re: TypeScript at Google

#97

Post by realusername »

eksemplar wrote: post #40

I always wonder why people think typescript is a fix for bad code. We primarily do JavaScript, and I see no issues with it when you set up governance in how to use it. I don’t think building your own libraries is really a bad thing either, in fact I think you should do so often instead of relying on 3rd party packages of quality you typically judge on how many times they’ve been downloaded if you’re being honest. I t…

> Want a number? Then call your argument numWhatever and check your input.

Oh no, please not the ugly Microsoft naming syntax again... I thought that died a long time ago.

Re: TypeScript at Google

#98

Post by sandGorgon »

nojvek wrote: post #51
eksemplar wrote: post #45

Earlier quoted context omitted.

How? I think it’s inferior because it allows you to rewrite only parts, and unless you convert your entire code base, then you’ll not have type safety. Because the bits that aren’t typescript won’t warn you when you compile.

Typescript will happily check your JavaScript code with “allowJs” compiler flag. We write all our new code in good ol ES6 flavor of JavaScript and typehint in jsdoc. Typescript as a typechecker serves as very well. It’s a great incremental adoption strategy.

can you explain how this works ? this is very interesting to us. We have a large react app (created using create-react-app) in ES6 and have been considering adopting TS gradually.

This seems a great first step.

Re: TypeScript at Google

#99

Post by realusername »

eksemplar wrote: post #45
machiaweliczny wrote: post #42

Earlier quoted context omitted.

Typescript is superior for refactoring.

How? I think it’s inferior because it allows you to rewrite only parts, and unless you convert your entire code base, then you’ll not have type safety. Because the bits that aren’t typescript won’t warn you when you compile.

> I think it’s inferior because it allows you to rewrite only parts

That's exactly why it's superior, your project just becomes better step by step without an expensive and complicated full rewrite.

Re: TypeScript at Google

#100

Post by Alexendoo »

a_humean wrote: post #88
conover wrote: post #21

Earlier quoted context omitted.

The codebase powering www.twitch.tv utilizes TypeScript and I can’t imagine working on a project of any significant size without leveraging it going forward.

So I know you also use React extensively at twitch, so how are you finding react and typescript working together? I've been using the two together recently and its been great. Like you I don't think I could ever go back to not using typescript for anything but the smallest projects. However, often times I've found some common react patterns to be difficult to express in typescript. Namely default props and high order…

For the default props side of things, as of typescript 3 and the latest @types/react it should work as you would expect:

https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in...

Post reply on HN