TypeScript at Google • Hacker News Board

Re: TypeScript at Google

#181

Post by mwcampbell » Sun, Sep 02, 2018, 8:31 PM UTC

mwcampbell wrote: post #151

Nitramp wrote: post #124

> The first tempting option is to just abandon this ruined planet and settle a new one that doesn't even involve JavaScript. If only we invested more in GWT (a Google project that compiles Java to JavaScript) or Dart (a Google project that compiles a new language to JavaScript) or WASM or [insert your favorite language here — Clojure? Haxe? Elm?] we wouldn't need to worry about JavaScript at all! I thought about this…

Kotlin looks promising. Sure, you can use the whole JVM ecosystem with Kotlin/JS or Kotlin Native. But it looks like JetBrains is trying to bootstrap a JVM-independent Kotlin ecosystem. So why Kotlin instead of TypeScript? 1. Potentially more static optimization, because Kotlin is designed from the start for static typing. 2. Ability to target other platforms (Android, iOS, desktop) without adding the overhead of a J…

Oops, meant can't use the whole JVM ecosystem with JS or Native.

Re: TypeScript at Google

#182

Post by Vinnl » Sun, Sep 02, 2018, 8:31 PM UTC

acemarke wrote: post #142

Vinnl wrote: post #72

Earlier quoted context omitted.

Although it's clear that Facebook's libraries, among which React, favour Flow, there's strong community demand for TypeScript even around React. Thus, the type definitions that are available for React are excellent, Redux even includes its type definitions natively, and most of the large tools in the React ecosystem work pretty well with TypeScript. The main large project you're likely to use that does not really pla…

We're actually looking at removing the type definitions from the Redux core and punting them over to DefinitelyTyped, because neither of us primary maintainers use TS ourselves and we don't have the experience to maintain the type definitions. Also, the CRA-TS fork runs, but the one time I played with it was when I tried to help another team set up their project, and that's when I found out it has _ridiculously_ rest…

Haha right, it's still the case that the type definitions for Redux are very much usable though :)

Re: TypeScript at Google

#183

Post by mpawelski » Sun, Sep 02, 2018, 9:26 PM UTC

steadicat wrote: post #155

leppr wrote: post #154

Earlier quoted context omitted.

The "official" Typescript solution to variadic type parameters is to write a bunch of overloads covering the most frequent cases, e.g. from 1 to 5 parameters.

TypeScript 3.0 fixed this: https://blogs.msdn.microsoft.com/typescript/2018/07/30/annou...

no yet really. But it's good first step to have "true" variadic types support. Right now I think you still can't represent stuff like `Promise.all` without many numbers of overloads.

Re: TypeScript at Google

#184

Post by uvtc » Sun, Sep 02, 2018, 9:44 PM UTC

munificent wrote: post #167

> If only we invested more in GWT (a Google project that compiles Java to JavaScript) or Dart (a Google project that compiles a new language to JavaScript) or WASM or [insert your favorite language here — Clojure? Haxe? Elm?] we wouldn't need to worry about JavaScript at all! I'm on the Dart team. I don't know if the author intended this, but you could read this as saying that Google isn't investing much in Dart, whi…

> If you're looking to rewrite a lot of code and pay off technical debt anyway, {snip}

Also if you're writing something from scratch.

I see four of these statically-typed better-than-JS languages with familiar syntax that, while having their own VM (or compiler, or both), can also compile to JS:

* Dart

* Haxe

* Kotlin

* Reason

Re: TypeScript at Google

#185

Post by mpawelski » Sun, Sep 02, 2018, 10:08 PM UTC

eksemplar wrote: post #46

ketralnis wrote: post #44

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…

>I think typescript is popular because it’s very java/c# like

I think at beginning it was mostly used by developers familiar with Microsoft stack (.NET world mostly). But TS was not designed for C# developers, it was designed for JS ones! And I'm super happy it's becoming more and more popular in more "mainstream" frontend community.

I'll just copy my old response to some very old thread that talk about why it not just "a language for C# developers":

" Once sometimes asked me "Isn't Typescript a language for C# developers that don't know JavaScript" It's unfortunate that people think that TS is similar to C# just because it came from Microsoft. Flow language is like 80% similar to TS, but no one says it's similar to C#.

TS is just JS + new features from future JS specification + optional type system. And optional type system is fundamentally different than the one in C#, and it was designed to fit well with JS patterns and idioms (structural vs nominal type system)

If you look at TS code that looks like C#, it's because JS looks like that (classes syntax, classical inheritance, lambda syntax - it's all ES7 (or ES2016/ES2017, or whatever it's called now) "

Re: TypeScript at Google

#186

Post by joshtynjala » Sun, Sep 02, 2018, 10:14 PM UTC

acemarke wrote: post #142

Vinnl wrote: post #72

Earlier quoted context omitted.

Although it's clear that Facebook's libraries, among which React, favour Flow, there's strong community demand for TypeScript even around React. Thus, the type definitions that are available for React are excellent, Redux even includes its type definitions natively, and most of the large tools in the React ecosystem work pretty well with TypeScript. The main large project you're likely to use that does not really pla…

We're actually looking at removing the type definitions from the Redux core and punting them over to DefinitelyTyped, because neither of us primary maintainers use TS ourselves and we don't have the experience to maintain the type definitions. Also, the CRA-TS fork runs, but the one time I played with it was when I tried to help another team set up their project, and that's when I found out it has _ridiculously_ rest…

The first thing I do in a new CRA-TS project is make the tslint.json rules default to warnings instead. Or just disable them completely. After that, it's great! I'm actually surprised that they still haven't loosened the rules after Dan called it out a month or two ago. Seems like an easy enough fix to at least make them warnings until they choose better defaults.

Re: TypeScript at Google

#187

Post by SiVal » Mon, Sep 03, 2018, 12:53 AM UTC

sanderjd wrote: post #136

Nitramp wrote: post #124

> The first tempting option is to just abandon this ruined planet and settle a new one that doesn't even involve JavaScript. If only we invested more in GWT (a Google project that compiles Java to JavaScript) or Dart (a Google project that compiles a new language to JavaScript) or WASM or [insert your favorite language here — Clojure? Haxe? Elm?] we wouldn't need to worry about JavaScript at all! I thought about this…

This is a super interesting perspective. It seems to me that another way to strike this very tricky balance is to design a language with it in mind - so that you can choose semantics with the emulation trade-off explicitly taken into account - and invest very heavily in its ecosystem - so that you can catch up on the library, framework, and IDE front. Arguably both Dart and TypeScript (among others) are doing the fir…

This isn't like using Kotlin or Scala in order to use an alternative to the "original" language. The power of TypeScript is that it is designed to be less an alternative programming language per se than a dev tool for JavaScript. Instead of choosing different semantics, you're being somewhat more explicit in specifying your JS semantics. And you aren't switching to a different ecosystem, you're making your tools more powerful when working with the JS ecosystem.

Since the nature of this "tool" is an extension to the syntax, there is a bit of risk that there will be an conflict with some future JS, but other than that, the 2-factor (same but more explicit semantics, same but fortified ecosystem) analysis seems to show why TypeScript is popular.

Re: TypeScript at Google

#188

Post by s4vi0r » Mon, Sep 03, 2018, 1:44 AM UTC

geewee wrote: post #57

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…

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.

The most recent, 3.0.1 I believe? Or 3.1.0 - whatever it is.

As far as going back goes - it's preferable to plain JS I guess? But that's not saying all that much. I don't know - I'm sure I'll appreciate it more after this migration period is finished and things start to stabilize, but as of right now I'm definitely not enjoying it.

Re: TypeScript at Google

#189

Post by s4vi0r » Mon, Sep 03, 2018, 1:50 AM UTC

rukenshia wrote: post #66

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…

I feel you and I think it is more of a "React + TypeScript" problem than a TypeScript problem. We have started using Angular 2 (now.. 6?) with TypeScript for a project last year and I never had big issues with TypeScript. Last month, one of our teams started a React project and given the success of using TypeScript before, they opted to do the same with their project. I've walked them through a few things but found m…

Using TS3 with ours and the problems are definitely still there.

I think the most immediate and obvious pain point for me is typing HOCs. It's basically a matter of rearranging how you apply them until TS can automatically infer a type for you. At the same time, using `compose` instead of applying them individually solves that problem but results in strange types (that are different from the type TS infers if you apply the HOCs manually yourself in an order that makes it happy) that I suspect will cause type errors down the road when we convert the files that make use of it to TS as well.

Re: TypeScript at Google

#190

Post by s4vi0r » Mon, Sep 03, 2018, 1:57 AM UTC

wwwigham wrote: post #93

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)

I'm not at a desktop or laptop where I could provide you with a proper example, but the most obvious pain point is HOCs.

I was receiving an error complaining about a missing prop on a component I was wrapping with `injectIntl` from `react-intl` and could not for the life of me figure out what was wrong. Searching the type error wasn't helpful, and it wasn't until I really dug down and spent about a half hour of my time that I realized it was because we had something like `injectIntl(connect(foo, bar)(SomeComponent))` instead of `connect(foo, bar)(injectIntl(SomeComponent))`

The type error did not in any way make that clear or obvious. If I had to compare it to anything, it would probably be the type of error messages you see if you play around with type level programming/dependent types in Haskell. Or the types of error messages you see when writing Clojure.