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

41–50 of 201 posts

Re: TypeScript at Google

#41

Post by bcherny »

smt88 wrote: post #22
Karupan wrote: post #12

I love typescript as a JavaScript developer, but having used go for personal projects, I find the type system complex (maybe necessarily so). Having said that, I cannot thank TS enough for how it’s made life easier when working on and refactoring large codebases.

I don't know what you find complex about the type system, but I actually find it slightly limiting. They keep improving it, so it can express about 95% of what I want, but I still hit situations where I can't tell the compiler everything.

What sorts of things do you have trouble expressing with the type system?

Re: TypeScript at Google

#42

Post by machiaweliczny »

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…

Typescript is superior for refactoring.

Re: TypeScript at Google

#43

Post by machiaweliczny »

MBCook wrote: post #24
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.

Have you spent any real time with Flow? As I’m starting to get into the modern front end world… I do want the safety of a stronger type system but it doesn’t look like the React ecosystem has really decided which way to go. TypeScript is popular. But flow was developed by Facebook and so it’s obviously heavily used by some of the top people. I’ve only been reading about them, I haven’t chosen to use one yet. But I’ve…

I worked with both. Without going into details - I recommend TS as it's better documented and easier to work with. With 3.0 they also improved error messages.

EDIT: one thing I miss from flow is https://github.com/gcanti/babel-plugin-tcomb - it's quite handy to spot data errors (before you have big static coverage)

Re: TypeScript at Google

#44

Post by ketralnis »

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…

> fix your shitty code with code that’s only less shitty because your compiler protects you

I mean... Yes? That's exactly what it's for. That's all it's for. That's all I want out of it, and that's what it does. I'm not really sure what you're railing against here.

Re: TypeScript at Google

#45

Post by eksemplar »

machiaweliczny wrote: post #42
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…

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.

Re: TypeScript at Google

#46

Post by eksemplar »

ketralnis wrote: post #44
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…

> fix your shitty code with code that’s only less shitty because your compiler protects you I mean... Yes? That's exactly what it's for. That's all it's for. That's all I want out of it, and that's what it does. I'm not really sure what you're railing against here.

My point is that I don’t think it fixes your shitty code.

Especially not if you’re not converting your entire project to typescript, and if you’re converting the entirety of it, then why not use a better language?

I think typescript is popular because it’s very java/c# like and I think it’s dangerous because it allows you to write bits of your program with the safety it provides and other bits without it.

So you’ll have programmers thinking they are safe, when they are really not.

Re: TypeScript at Google

#47

Post by whatever_dude »

lugg wrote: post #18
shadowmint wrote: post #15

I feel like this sort of organic growth (for typescript) is a very healthy sign for a project. ES6 (or whatever we’re supposed to refer to it as now) is good enough for many things, but when you see it used heavily with, for example, proptype hints... you get the feeling that there really is a trend these days towards flavoring static type checking and the error checking that offers. I think its an interesting shift,…

I feel like for production I would want a clean upgrade path to whatever JavaScript implements in the future. Can typescript and code converters provide this? (The article sort of touched on it.) Sadly, standards seem to be sitting on their thumbs with weak excuses - people doing it different ways therefore we do nothing. Just take the larger market share compiler, add a few handy features from others and call it a d…

One of the goals of Typescript is to be closer to what JavaScript _will be_, rather than create something new. You won't see chunks of code that need to be rewritten.

That said, yes, you can compile TS to JS with no ecmascript compatibility constructs to just remove types and essentially "eject" TS into JS.

Re: TypeScript at Google

#48

Post by bcherny »

evmar wrote: post #31
chrisco255 wrote: post #9

Earlier quoted context omitted.

Nice! Didn't realize this was a thing. I suspect they could make even more aggressive optimizations if they made a TS version.

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 confidence score to every type to indicate how accurate you think it is. Maybe there’s a clever way to statically compute that score, or you can instrument some % of prod traffic at runtime to observe types with lower confidence (Node has this, or see MonkeyType or Reticulated Python). Then take that info and feed it into Closure compiler.

Re: TypeScript at Google

#49

Post by nojvek »

MBCook wrote: post #37
_frog wrote: post #27

Earlier quoted context omitted.

From my personal experience, Flow prioritises soundness in its type system, and thus can catch some bugs that TS won’t, but the TS tooling and editor support is drastically better than Flow’s. Edit: oh and it’s worth noting that I’ve had much more luck finding TS definitions for third party packages than I have with Flow.

Could you expand some more on the tooling/editor support? I’ve only done a cursory look. My editor (IntelliJ) supports both to some level. Webpack/Babel do too. I’m very new to writing React and modern front end JS so it’s quite possible there are things that I should be looking out for that I don’t even know about.

Typescript compiler architecture is quite different to flows. Typescript was written from the get go to provide really fast and accurate intellisense to IDEs. The newer refactoring powers are super nice too. Most ides just ask typescripts language service “hey, my user’s cursor is here, what should I show for code completion?”

I think that’s what differentiates TS from flow. Typescript thought about the whole developers workflow while flow is just a compile time typechecker.

Re: TypeScript at Google

#50

Post by nojvek »

murukesh_s wrote: post #39
MBCook wrote: post #36

Earlier quoted context omitted.

I know, and that’s a definite plus. I don’t have to worry that it will go away or lose all the main contributors. But is not developed by the same developers/company as React. I will say given what TS is competing against the fact that it so well used is rather compelling. I know all of Angular is also written in TS. It’s clearly very heavily used.

React can fade but JavaScript won't..(it could only evolve). outside react Typescript is the clear winner and even most of the react projects I am seeing is using Typescript. I would say Typescript is the clear winner. Also VSCode is now far popular than other editors which is developed by Microsoft as well..

Also typescript and React go really really well because typescript can do tsx which is a strongly typed flavor of jsx.

Being able to use good code completion when using other people’s components is a huge boon.

Post reply on HN