TypeScript at Google • Hacker News Board

Re: TypeScript at Google

#81

Post by rounce » Sun, Sep 02, 2018, 9:13 AM UTC

shadowmint wrote: post #69

EE84M3i wrote: post #23

Earlier quoted context omitted.

Sorry if this is a well known term but what is a "proptype hint" in this context? I can't seem to find any references for '"proptype hint" "javascript"' or any variations that come to mind on Google. Edit - changed previous sentence to "proptype hint". I originally erroneously read the parent as saying "prototype hint" which I couldn't find results for, but even after correcting my reading error my question still sta…

github.com/facebook/prop-types is the 2nd google search result for this term, and is what I was referring to, although the first result (devhints.io/react#property-validation) is arguably a better summary. Ie. ‘lite’ type checking, used in react. (did you perhaps see the results for ‘javascript prop type hint’ as a google autocorrect suggestion or something? This is a well known term, but I’m pretty amazed two second…

I read it and thought you were referring to something related to some proptype based code completion. The use of 'hinting' threw me off completely, especially when you're talking about checking & validating.

Re: TypeScript at Google

#82

Post by int_19h » Sun, Sep 02, 2018, 9:15 AM UTC

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. It’s really as easy as that.

It sounds like you have reinvented the Hungarian notation - 15 years after it was phased out?

Re: TypeScript at Google

#83

Post by bazza451 » Sun, Sep 02, 2018, 9:16 AM UTC

TheAceOfHearts wrote: post #20

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…

http://www.syntaxsuccess.com/viewarticle/closure-compiler-vs... - interesting article about how closure enables smaller bundle sizes.

I agree, it would be cool for someone to do the same thing for Typescript, I seem to remember a repo a while back on Github that said someone was experimenting with it - cant for the life of me remember where though!

Re: TypeScript at Google

#84

Post by stefano » Sun, Sep 02, 2018, 9:20 AM UTC

adwhit wrote: post #78

bazza451 wrote: post #76

Real big fan of TS, like anything though you just have to be disciplined when using it. Type absolutely everything and set the transpiler to the most aggressive checks possible... If you’re being lazy and putting : any everywhere and then complaining about how good it is...you’re doing it wrong In our project I’ve found we make a lot less mistakes than with pure JS and there’s a lot less pointless type check unit tes…

I always use it with > "compilerOptions": { "strict": true } But given the huge number of other options I worry that like GCC's '-Wall', that doesn't actually give you the strongest possible type checking. Anyone know about that? My aim with Typescript is to turn JS into OCaml.

> My aim with Typescript is to turn JS into OCaml

If that's the goal, why not use the real thing http://ocsigen.org/js_of_ocaml/ ?

Re: TypeScript at Google

#85

Post by Raphael » Sun, Sep 02, 2018, 9:23 AM UTC

Vinnl wrote: post #72

MBCook wrote: post #24

Earlier quoted context omitted.

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…

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…

Create React App is the first link that TS gives you in "getting started". Is there something wrong with it?

https://github.com/Microsoft/TypeScript-React-Starter#typesc...

Re: TypeScript at Google

#86

Post by michaelmcmillan » Sun, Sep 02, 2018, 9:23 AM UTC

bazza451 wrote: post #76

Real big fan of TS, like anything though you just have to be disciplined when using it. Type absolutely everything and set the transpiler to the most aggressive checks possible... If you’re being lazy and putting : any everywhere and then complaining about how good it is...you’re doing it wrong In our project I’ve found we make a lot less mistakes than with pure JS and there’s a lot less pointless type check unit tes…

I share your view! Unfortunately, getting devs to write proper unit tests is – for whatever reason – difficult.

Types just smuggle themselves in with the rest of the program (granted they only cover a subset of the bugs tests do).

Re: TypeScript at Google

#87

Post by bazza451 » Sun, Sep 02, 2018, 9:25 AM UTC

bazza451 wrote: post #83

TheAceOfHearts wrote: post #20

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…

http://www.syntaxsuccess.com/viewarticle/closure-compiler-vs... - interesting article about how closure enables smaller bundle sizes. I agree, it would be cool for someone to do the same thing for Typescript, I seem to remember a repo a while back on Github that said someone was experimenting with it - cant for the life of me remember where though!

didn't read the other comment on this - https://github.com/angular/tsickle was the repo

Re: TypeScript at Google

#88

Post by a_humean » Sun, Sep 02, 2018, 9:28 AM UTC

conover wrote: post #21

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.

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 components. The type signatures I'v ended up with for my HoCs aren't as simple as I'd like, but I guess there is no way getting around that.

I've actually started to prefer render props over HoCs simply because the type signatures are simpler. Still no idea how to handle default props correctly.

Re: TypeScript at Google

#89

Post by wwwigham » Sun, Sep 02, 2018, 9:30 AM UTC

mcny wrote: post #77

Tade0 wrote: post #71

After a few years with both TS and JS my verdict is that TypeScript definitely helps , but mostly with type-related bugs - with proper testing you don't get many of those. What I would like to have in TS is a more expressive type system - the current is somewhat basic(e.g. you can't have a Symbol as a dictionary key - interesting given that it's possible in JS. Also you can't mix dictionary fields with regular ones i…

I don't understand language design or expressiveness but I'm ok with going slow and being restrictive. I think what we need is a subset of JavaScript, not a superset. There are things we should not be able to do in JavaScript in a web browser because to me that's where JavaScript belongs. I think the whole idea of js on the server or in other kind of projects is very silly. But that's besides the point. But I agree w…

> But I agree with your example of symbol in dict. I would be surprised if it isn't already on the roadmap. Have you tried reaching out to the typescript people?

It's not just on the roadmap, it's in code review/iteration as of last week: https://github.com/Microsoft/TypeScript/pull/26797

Re: TypeScript at Google

#90

Post by underwater » Sun, Sep 02, 2018, 9:30 AM UTC

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…

Have you looked into Flow? This is the type of project it’s suited for (gradual typing). Facebook were in a very similar position when they created it. You can add a Flow pragma to a file and immediately get useful feedback based on Flow’s type inference.