Migrating 300k LOC from Flow to TypeScript • Hacker News Board

Re: Migrating 300k LOC from Flow to TypeScript

#51

Post by [deleted] » Thu, Jun 20, 2019, 4:42 PM UTC

dragonwriter wrote: post #26

cryptica wrote: post #9

I've been using TypeScript for over 1 year after 10 years of JavaScript and I really don't like it. It slows me and the team down and creates more problems than it solves. It doesn't even ensure type safety because there is no runtime type validation for JSON objects received from the API. It's disturbing that so few people can see how useless it is. To me, it's extremely obvious. TypeScript is a hack of epic proport…

> It doesn't even ensure type safety because there is no runtime type validation for JSON objects received from the API. It ensures internal type safety. If you don't have a lot of complexity on your side (e.g., a large client-side app) that may not be worthwhile to you, but it's certainly a thing it does, and a reason static typing is generally considered to be of value, particularly in large, multiprogrammer and, e…

[deleted]

Re: Migrating 300k LOC from Flow to TypeScript

#52

Post by vicapow » Thu, Jun 20, 2019, 4:50 PM UTC

munchor wrote: post #41

I recently underwent a very similar experience at MemSQL[1] but for only 30K LOC. The pain points that led us away from Flow to TypeScript seem to be the same as the ones as Quizlet's . Overall, I'm very happy to see more and more teams move to TypeScript as a direct consequence of its Babel 7 support. TypeScript makes more sense as a pure type checker and not as a full blown transpiler. It's also interesting to see…

There is not a 1-1 metric for "coverage" across these two systems. For exmaple, TS believes this code is "covered" but Flow knows it's not safe:

type A = { readonly prop: number }; type B = { prop: number };

function func(f: B) { f.prop = 20; return f; }

const a: A = { prop: 10 }; func(a); // no error?

Re: Migrating 300k LOC from Flow to TypeScript

#53

Post by [deleted] » Thu, Jun 20, 2019, 4:53 PM UTC

z1mm32m4n wrote: post #3

The important parts here are (1) that they remained metrics driven and (2) that they focused on repeatability. 1. Both TypeScript and Flow are gradual type systems. They both explicitly allow escaping the safety and coverage of a type system, either to allow easier interop with existing JavaScript packages or to allow existing JavaScript codebases to incrementally adopt types. So there are always holes in which error…

[deleted]

Re: Migrating 300k LOC from Flow to TypeScript

#54

Post by battletested » Thu, Jun 20, 2019, 5:00 PM UTC

untog wrote: post #8

jillesvangurp wrote: post #7

I recently spent some time introducing typescript to a javascript code base. My background is mostly backend/JVM, so I wasn't the perfect person to be doing this obviously. But as there was nobody else and I needed to own this stuff, I put in the work and got things done. My impressions are mostly positive in the sense that if you are doing JS, you are better off doing TS. The tooling is great and you can start with…

I absolutely agree on TypeScript, I love that it's opinionated and simply versioned. Every time I have to step back into a codebase that uses Babel and X number of different plugins it just tires me. Typescript is just Typescript, and the compiler works fantastically well. > Better still, a lot of these languages are coming to the browser (via WASM or transpilation) I think this has always been a concern - CoffeeScri…

> CoffeeScript had its moment in the sun, then the good parts got merged into JS

No. Some good parts have been merged, but so many good parts will never get to ESxx or Typescript. Most dev's just don't see it because they do not know Coffeescript well enough. Compared to Coffeescript, Babel is a total mess with all it's options/plugs config etc..

I rarely have type issues in JS, Python or Coffescript. I do have type issues in Typescript though. I fix that with 'any', just like my collegues. A Typescript codebase is about 2x bigger than a Coffeescript codebase, that means about 2 times more chance for bugs. But it's totally amazing to see the Typescript proponents considering the language to be a godsend. I moved from C/C++ to Javascript to get rid of static typing, it's part of my love for JS, but now that joy is being destroyed by static type enthusiasts.

I've never worked in a pretty Typescript codebase ever, same with JS, so many bad constructs, bad naming, bad architecture, etc, etc.. IMAO the real problems with codebases cannot be fixed with Typescript, the problems are way too big and complex for that.

I still don't understand why JS dev's that crave for types don't do Elm or Purescript instead of Typescript.

Re: Migrating 300k LOC from Flow to TypeScript

#55

Post by chaostheory » Thu, Jun 20, 2019, 5:04 PM UTC

cryptica wrote: post #31

torben-friis wrote: post #27

Earlier quoted context omitted.

Typescript has been useful for my team to reduce the number of unit tests and constant checking of number and order of parameters in functions, presence of null/undefined values, etc - when compared to JS obviously. It works particularly well when coupled with JSON schema validation that checks that the contract of your api is not ignored (TS types map very easily to and from JSON schemas). As for your third paragrap…

I still don't get it. You can also add rigorous schema validation to your API endpoints with plain JS so you don't need to worry about strange inputs in your tests either. This is not unique to TS.

Yes, but it feels like more work and it's more verbose. In Typescript, it's also more or less convention, where as in JS it's just nice to have. I have less guesswork to do with Typescript. There's value in that.

Re: Migrating 300k LOC from Flow to TypeScript

#56

Post by chaostheory » Thu, Jun 20, 2019, 5:14 PM UTC

sdegutis wrote: post #47

I've been a big fan of TypeScript for a few years, but lately I've been Considering Removing Typescript[1] from my project, because it seems to have just as many drawbacks as benefits, and the freshness of pure JavaScript is starting to look appealing again. But I haven't heard anyone take this perspective and I'd be really curious to hear people's thoughts on this idea. [1] https://sdegutis.com/2019-06-20-considerin…

> Browsers don’t support it, so it adds an extra build step. Type-completion has gotten slower the bigger our project gets.

This is something a faster computer can mitigate. Also I would compare the time you spend guessing what parameters actually are in vanilla JS vs the seconds you lose waiting for a Typescript build. Silicon time is much cheaper than carbon time.

I don't understand how anyone doesn't use Typescript for large projects. Javascript is just too lenient. It doesn't even complain when you're not matching a method signature that you call; you can't even catch these ninja errors let alone explicitly know they dropped on you. There's a lot of value when you have a system that adds more checks and validation before runtime.

Re: Migrating 300k LOC from Flow to TypeScript

#57

Post by lacker » Thu, Jun 20, 2019, 5:27 PM UTC

My only real pain point with TypeScript so far is with a codebase where some parts run in Node, some parts run in the browser, and some parts are libraries that can be imported by either. The best solution I have found is to separate out all TS code into three directories and have multiple tsconfig, but it often doesn't work nicely with the rest of the ecosystem.

Re: Migrating 300k LOC from Flow to TypeScript

#58

Post by eropple » Thu, Jun 20, 2019, 5:37 PM UTC

icxa wrote: post #43

jmull wrote: post #29

Earlier quoted context omitted.

People should not be downvoting this. There's a weird impulse out there to try to pretend the limitations of static type-checking don't exist... namely, that it's static . That is, it's build-time checking and doesn't provide guarantees at runtime. For tightly coupled systems were you control all tiers, you can stretch the value of static type checking by ensuring that changes to back, middle, and front all roll out…

Tangentially, but in a similar vein, this is my gripe with TypeScript: It leads you down a path that takes the best part of JavaScript out: namely it's dynamicity, and prototypical object orientation, and leaves you with a hamstrung, not-so-good statically typed OO language. When you view it in that light, it hardly stands up to other options out there, IMO of course. That's why I was lead to something like ReasonML…

TypeScript does not take out dynamic typing or prototypical object orientation. If you can more cleanly communicate something dynamically, do it. `any` is right there. (And I do this sometimes! Of course, code where I do this is invariably where most of my unit testing has to be, but I have the choice, and I'm making it.)

And, not to be pointy, but I always get a real weird vibe about people who come rolling in professing that TypeScript isn't a backhoe when it professes to be a shovel. TypeScript is not about a "world class type system" and that's never been the claim. It's about reducing the ways in which normal developers can shoot themselves in the foot. If ReasonML or whatever equally bloggable thing scratches your itch, sure, but you're never getting the 95th percentile of developers, to say nothing of the 50th, to write it--and that 50th, and that 95th, percentile can benefit from better tools, too.

Re: Migrating 300k LOC from Flow to TypeScript

#59

Post by WorldMaker » Thu, Jun 20, 2019, 5:42 PM UTC

vimslayer wrote: post #24

vimslayer wrote: post #13

There have been a few posts like this, and the discussion always seems to focus on plain JavaScript vs TypeScript. I'd like to see some talk about Flow vs TypeScript instead. We have what I'd call a medium-sized project (~30k loc) written with Flow and TypeScript's superior tooling is indeed attractive enough that we too have been thinking about making the switch. Having used both, there are a few features in Flow th…

A few more random thoughts that popped into my head: Flow's Windows support is pretty buggy. We have some team members who prefer Windows as their dev machine and it looks... painful. Flow supports the upcoming `?.` operator and overall they seem more open to introducing features that are in a development phase and might be changed/deprecated in the future. I guess it's a matter of perspective if that's good or bad,…

> Flow supports the upcoming `?.` operator and overall they seem more open to introducing features that are in a development phase

It's funny because Typescript started out by trying to get ahead of a lot of features and "settling down" to trying to stick to (mostly) only TC39 Stage 3+ features has been a maturation that has been good for the language. It's interesting that Flow seems to be moving the other direction.

A benefit to making it easier to pipeline Typescript inside Babel is that it is no longer entirely on Typescript to transpile every possible wishlist language proposal. This is also why a lot of people preferred Flow because you could just slot Flow checking before or after certain transforms. Typescript is getting better about fitting into the middle of a Babel transform stack so that you might have some basic preprocessing steps of Stage 2 or earlier or non-standards track things that Babel supports before type checking.

(The Optional Chaining proposal for `?.` is currently in Stage 2 in TC39. Indications seem to be that at least some of the Typescript devs are ready to champion that feature in the very minute it hits Stage 3.)

Re: Migrating 300k LOC from Flow to TypeScript

#60

Post by WorldMaker » Thu, Jun 20, 2019, 5:53 PM UTC

Sahhaese wrote: post #25

stickfigure wrote: post #20

Earlier quoted context omitted.

"Types are useless because they don't version my wire protocol!" is a wholly specious argument. There are a variety of RPC protocols that address versioning in a variety of ways; this isn't a typechecker responsibility. You can generate Typescript interfaces from protobufs if you fancy. Typescript makes sure that all your code agrees with the protocol definition you have chosen. That alone is immensely valuable.

Typescript only checks all that at compile time though. The complaint here is that even a typed json.Parse :(json:string)=>T will not actually give any type checking when you pass it a string containing any schema.

When you type json.Parse you are taking on the responsibility that what is returned is actually T. If you want the type checker's help that you are sure it might not be T, then ask for it: json.Parse or json.Parse> is maybe more accurate, and would force you to write runtime checks. Partial in particular is a great helper type that is often exactly what a lot of want in a json.Parse situation: gives you the field autocomplete you want, but reminds you that they may be undefined.