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

11–20 of 201 posts

Re: TypeScript at Google

#11

Post by helixten »

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

Re: TypeScript at Google

#12

Post by Karupan »

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.

Re: TypeScript at Google

#14

Post by kylecordes »

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

I'm really eager to see availability of some extra features via this new pathway.

But I am less excited about projects containing TypeScript plus the large number of transitive dependencies from a typical Babel set up; I've been greatly enjoying TypeScript instead of that.

Re: TypeScript at Google

#15

Post by shadowmint »

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, with python and javascript both being poster child dynamic languages, but people who use them seriously going... ‘yeah, type checking is actually pretty handy...’.

Re: TypeScript at Google

#18

Post by lugg »

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 day.

https://ecmascript-daily.github.io/pages/status-of-static-ty...

Re: TypeScript at Google

#19

Post by crooked-v »

kylecordes wrote: post #14
helixten wrote: post #11

Earlier quoted context omitted.

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

I'm really eager to see availability of some extra features via this new pathway. But I am less excited about projects containing TypeScript plus the large number of transitive dependencies from a typical Babel set up; I've been greatly enjoying TypeScript instead of that.

For my part, my web projects have generally ended up with both Typescript and Babel because of old-browser-support reasons, so integrated parsing simplifies things for me.

Re: TypeScript at Google

#20

Post by TheAceOfHearts »

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 Closure Compiler, although it doesn't seem likely since there's no spec to guarantee compatibility.

I'd love to see Facebook, Google, and Microsoft team up in this space, instead of creating 3 separate but very highly similar tools.

Also, while we're talking about Closure, let's take a moment to appreciate its amazing UI toolkit [0]. I'd still consider many of their widgets to be the gold standard. It's written with desktop clients in mind and is incredibly feature-complete. I believe it also has pretty good accessibility, although I haven't personally tried that out. Oh, and don't forget the i18n as well! The closure library definitely has a lot of quirky aspects to it, but it's still quite amazing if you consider its age and how much stuff it supports. It's worth taking a few minutes to browse through their docs [1].

[0] https://google.github.io/closure-library/source/closure/goog...

[1] https://google.github.io/closure-library/api/

Post reply on HN