Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Migrating 300k LOC from Flow to TypeScript

medium.com

Post reply on HN
Print view View original

21–30 of 87 posts

Re: Migrating 300k LOC from Flow to TypeScript

#21

Post by z1mm32m4n »

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…

Ironically, one of the easier ways TypeScript has been able to work quickly is by skipping the type inference Flow does. It’s a trade off. The Flow team was advised that this approach would have performance problems early on in the project, and opted to focus on type system features first and perf second.

Re: Migrating 300k LOC from Flow to TypeScript

#22

Post by cryptica »

paulbrittain wrote: post #16
cryptica wrote: post #12

Earlier quoted context omitted.

So you're saying that on your planet TypeScript has runtime type validation?

I'm saying our experiences are totally opposite and that I find your opinion bizarre.

ActionScript 3 was one of my first programming languages and I used it for many years; it's also based on the ECMAScript standard and very similar to TypeScript so I should be biased to like TypeScript, but I really don't.

I was a big fan of static types for many years (I also did Java and C++) so I understand your point of view perfectly but I also understand that it is incorrect. The fact that my POV seems so bizzare suggests that you haven't considered it thoroughly before.

Re: Migrating 300k LOC from Flow to TypeScript

#23

Post by phpnode »

cryptica wrote: post #12
paulbrittain wrote: post #11

Earlier quoted context omitted.

Our experiences are totally opposite. I find your opinion bizarre...

So you're saying that on your planet TypeScript has runtime type validation?

On this planet it is possible to do runtime type validation with typescript. It's not an out of the box feature but a number of libraries allow it, e.g. https://github.com/gcanti/io-ts

Re: Migrating 300k LOC from Flow to TypeScript

#24

Post by vimslayer »

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, but man I'm going to be sad if we end up making the change and I have to convert all those nice and clean `foo?.bar?.baz` chains into some unreadable multiline monstrosity or calls to some random getter library.

Flow's exact object types [1] are really useful and have prevented actual bugs when used with optional properties. TypeScript's concept of "freshness" [2] does prevent many if not most of these bugs though.

[1]: https://flow.org/en/docs/types/objects/#toc-exact-object-typ...

[2]: https://basarat.gitbooks.io/typescript/docs/types/freshness....

Re: Migrating 300k LOC from Flow to TypeScript

#25

Post by Sahhaese »

stickfigure wrote: post #20
cryptica wrote: post #17

Earlier quoted context omitted.

This is incorrect, merely declaring a type for all your API inputs does not prevent clients (especially a bad actor) from actually sending objects of different types at runtime; and when they do, your code will crash catastrophically. Try it. You need to do manual schema validation, just like you did with JavaScript. TypeScript adds 0 value. The type only gives you an illusion of safety, which is worse than no safety…

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

Re: Migrating 300k LOC from Flow to TypeScript

#26

Post by dragonwriter »

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, even moreso, multi-team projects.

Re: Migrating 300k LOC from Flow to TypeScript

#27

Post by torben-friis »

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…

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 paragraph, we follow some degree of functional programming precepts, which implies we avoid mutability as much as possible, so I can't comment much on the problems of mutating TS. I enthusiastically recommend pursuing immutability though, TS or not.

Re: Migrating 300k LOC from Flow to TypeScript

#28

Post by skybrian »

cryptica wrote: post #17
harunurhan wrote: post #15

Earlier quoted context omitted.

It doesn't sound to me that you really took it seriously and try. For example for what you said about "JSON objects received from the API" has no type validation, it doesn't unless you define the types for it. You can write interfaces that defines the API responses and use it across whole code base.

This is incorrect, merely declaring a type for all your API inputs does not prevent clients (especially a bad actor) from actually sending objects of different types at runtime; and when they do, your code will crash catastrophically. Try it. You need to do manual schema validation, just like you did with JavaScript. TypeScript adds 0 value. The type only gives you an illusion of safety, which is worse than no safety…

Used properly, runtime checking and types go well together. Types help you remember whether incoming data has been validated. You can use them to make sure your code does runtime checking exactly once, rather than multiple times or not at all due to changes in different packages that can introduce security bugs. This can make security reviews a lot easier.

I don't know if that's commonly done in Typescript, though? It seems more common in web apps to trust your own server to send you good data.

Re: Migrating 300k LOC from Flow to TypeScript

#29

Post by jmull »

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…

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 together. But obviously, you're seriously limiting the scalability of your product and agility of your releases when you do this (you need a command-and-control dev communication structure). If you want static type checking to make guarantees beyond the local component, this is a major architectural commitment. To maximize the "guarantees" of static type-checking, it will affect the topology of your entire product, including the release process. (How much downtime is acceptable per release? What limitations are you willing to accept in terms of distributed scalability? Is it acceptable that user sessions become invalid for a release and how will you handle the UX for this?)

Not saying you shouldn't do it, but go in with your eyes open.

Now, static tools certainly have their uses. But:

(1) type-checking is just one limited case. e.g., go get eslint, turn on almost all the rules, and work with that for a few weeks. After you get over the initial shock, you'll get a lot of benefit from from it and it will last for years.

(2) it doesn't help you with anything external to the source file that's not tightly coupled through some additional control mechanism. (Note that you pay a price for control mechanisms.) So, it's a small solution to small problems. Quite nice. But limited without paying an additional price, which may be quite expensive depending on the other goals of your system.

I don't agree with the previous poster's assertion that it's a useless hack. But I understand why one might feel that way. The utility of static type-checking seems to be greatly oversold.

Re: Migrating 300k LOC from Flow to TypeScript

#30

Post by Dirlewanger »

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…

All those examples in your last paragraph should be accounted for in data modeling and in the domain logic. Saying a type checking tool somehow prevents this from happening is asinine.
Post reply on HN