Live data from Hacker News

TypeScript at Google

neugierig.org

51–60 of 201 posts

Re: TypeScript at Google

#51

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.

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.

Re: TypeScript at Google

#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 more harmful than helpful.

It's better than nothing I guess, but I can't help but feel extremely underwhelmed with it given how many people use it. Are all of the people in this thread Angular developers or something?

Re: TypeScript at Google

#53

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.

> Because the bits that aren’t typescript won’t warn you when you compile.

You just wrote exactly why static types are great: you get warnings when you forget to refactor your shitty (sic) JS code.

Re: TypeScript at Google

#54

Google has enough resources for someone to write a transpiler that can take annotated JS and convert most of it to TypeScript. It's certainly much more pleasant than having to type random comments everywhere, which kinda makes syntax highlighting way less useful. Oh, and last I checked there were no editor plugins for linting Closure Compiler annotated code. Another option would be to add TypeScript support to Closur…

Google did a bit of work on converting Closure annotated JavaScript to TypeScript. It's called Gents and it's part of the Clutz project https://github.com/angular/clutz/tree/master/src/main/java/c...

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.

Re: TypeScript at Google

#55
post #37
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.

At this point, I think Flow clearly has a minority mindshare & is looked at more skeptically all around the JS ecosystem, and maybe even the React ecosystem based on what I see talked around. TS does a much better job integrating with existing JS and is much more practical about incremental updates whereas Flow bleeds all too easily into needing to add typing to a significant amount of code in order to add a type.

That's not to say that either TypeScript or Flow are perfect - they both are constraining with typing when it comes to composing functions last I checked.

Re: TypeScript at Google

#56

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…

Seconded. I don’t see anything bad with typescript itself, but naive but passionate usage of perceived silver bullets tends to create terrible things. there are many terrible coffeescript/backbone codebases, overwrought usage of redux, etc...

Many of such overcomicated systems come from trying to use the latest coolest thing without thinking about if it improved anything. the tools were never used correctly and the person just moved on, marking JS as a shitty language with a shitty ecosystem.

When there’s always something new on the horizon it’s too easy to assume the previous difficulty was because of the old tool vs taking the time to just learn the tool.

There are many developers who don’t really understand MVC for example and so much pain comes from trying to ham fist a jquery mentality into one.

Re: TypeScript at Google

#57
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…

What TS version are you on? The error messages are definitely one of the weak points, but they've been massively improved for many cases in 3.0.

FWIW I use Typescript with React, have had very few bad experiences(but not zero) and I'm never going back.

Re: TypeScript at Google

#58

Earlier quoted context omitted.

> 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 h…

TypeScript has structural (not nominal) typing, which makes it very different from Java/C# in practice.

Also, it doesn't fix shitty code. It just lets the compiler warn you when you're either making a mistake or misunderstanding some other part of your code base.

You should really try it before you say it doesn't help.

Re: TypeScript at Google

#59
post #49
post #37

Earlier quoted context omitted.

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 develop…

To Flow's credit, their language server does provide IDE features:

https://github.com/flowtype/flow-language-server#supported-f...

I still have found TypeScript to be an overall more pleasant developer experience, though.

Re: TypeScript at Google

#60

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.

That's the main reason I use Flow almost exclusively. I don't like sacrificing really useful features for the sake of a cleaner code base.

[deleted]
Post reply on HN