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

101–110 of 201 posts

Re: TypeScript at Google

#101

Post by untog »

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.

100% agreed. It was incredibly liberating to move from Babel with its byzantine level of configuration and plugins to "just run tsc". So much easier to reckon with - Typescript is Typescript is Typescript.

Re: TypeScript at Google

#102

Post by h1d »

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

At this point I feel JS won't have to evolve much unless some useful feature needs JS itself to be extended but let AltJS take care of usability and just concentrate on rock solidness, performance and portability between runtimes and developers can just use whatever shiny new version they want to use that runs on old but battled tested runtime without waiting for the whole internet to upgrade.

Re: TypeScript at Google

#103

Post by TulliusCicero »

TheAceOfHearts wrote: post #8
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.

TypeScript was released in 2012, I wouldn't call a 4 year old tool an early release. And if you were already using Webpack picking it up was as easy as adding a loader. IMO, using such early proposals isn't worth the risk in production. Especially for proposals that are so young that they haven't even settled on a clear spec as to its behavior, like the pipeline operator.

> TypeScript was released in 2012, I wouldn't call a 4 year old tool an early release.

Goddamn time travelers, stop messing with chronology!

Re: TypeScript at Google

#104

Post by h1d »

jpswade wrote: post #68

I think the most fascinating thing here is that Google are turning to a language developed and maintained by Microsoft.

It's come to a time that discriminating MS was an old thing.

Re: TypeScript at Google

#105

Post by h1d »

FlorianRappl wrote: post #70
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 can believe how popular TS is and it is super useful. I would not write a React application of any noticeable size without TS (and just FYI I would never willingly write an Angular app). The reason that I get far superior code completion and meaningful warnings / errors is sufficient to add a few annotations here and there. Many people are doing TS wrong. They add types everywhere. Honestly, you should write as man…

At least add them on function return types and annotate types on common objects so that you don't have objects lingering with wrong property name/type or redundant properties that would be confusing to review.

It helps to create a type reference for your database schema, so you don't try to insert something weird or insert with missing columns.

Re: TypeScript at Google

#106

Post by nathan_f77 »

I wonder if it's worth migrating from Flow to TypeScript?

Flow has been great, but I've just tried to update to the latest version and I'm dealing with a flood of indecipherable errors, especially from the react-dnd library. Looks like no-one is really maintaining the flow types so I'm on my own, and I don't even know where to start.

I also haven't been able to track down some errors, like "Cannot read property 'foo' of undefined". Flow thinks that this variable can never be undefined, and I have no idea how it's happening. It might even be a bug in Immutable.js, but I have no idea.

So if TypeScript is more popular and has a bigger community, then maybe it's worth migrating just so I can get more help with these issues. And maybe TypeScript will catch more cases as well.

Re: TypeScript at Google

#107

Post by jeremyjh »

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…

The point of type checking isn't so much to prevent bugs in production, but to speed up your development loop by catching many errors before you've even saved your file. Its much faster to see a red squiggly right after you've written a line of code, and fix it, rather than figure out whats gone wrong 10 minutes later looking at a stack trace in your test suite.

Re: TypeScript at Google

#108

Post by jeremyjh »

h1d wrote: post #102
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,…

At this point I feel JS won't have to evolve much unless some useful feature needs JS itself to be extended but let AltJS take care of usability and just concentrate on rock solidness, performance and portability between runtimes and developers can just use whatever shiny new version they want to use that runs on old but battled tested runtime without waiting for the whole internet to upgrade.

That isn't going to happen with Typescript. Aside from the type system, Typescript won't be implementing new features until they are in the ECMAScript standard.

Re: TypeScript at Google

#109

Post by cribbles »

> Gmail engineers had to worry so much about Internet Explorer's poor garbage collection algorithm that they'd need to manually hoist string literals out of for loops to avoid GC pauses.

What does this mean in practice? I know about variable hoisting and function scoping, but not about old JS GC algos.

Re: TypeScript at Google

#110

Post by styfle »

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…

I agree, the TypeScript team loves React and one of the reasons I started using React was because JSX/TSX is one of the few ways to type check views.

I have been maintaining some boilerplate to demonstrate TypeScript + React SSR that should point the reader in the right direction https://github.com/styfle/react-server-example-tsx

Post reply on HN