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

31–40 of 87 posts

Re: Migrating 300k LOC from Flow to TypeScript

#31

Post by cryptica »

torben-friis wrote: post #27
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 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.

Re: Migrating 300k LOC from Flow to TypeScript

#32

Post by peteretep »

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's disturbing that so few people can see how useless it is. To me, it's extremely obvious.

I think this is probably the wrong kind of hubris.

Re: Migrating 300k LOC from Flow to TypeScript

#33

Post by JohnDotAwesome »

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…

As someone who has also been using TypeScript for over a year and JavaScript for over 10 years, I've had a different take on it.

Disclaimer, I freaking love JavaScript and TypeScript.

> TypeScript is a hack of epic proportions and every so often the reality rears its ugly head in the form of failed source mapping, version compatibility issues, unexpected types during runtime, poor architectural decisions aimed at pleasing the compiler instead of fulfilling project goals.

This just sounds like JavaScript to me. Maybe TypeScript has helped elucidate those problems for you. TypeScript adds some syntax to help formalize solutions to these problems that existed in JavaScript already.

> TypeScript is a very poor way to model real-world systems because it incorrectly assumes that real-world entities have a fixed type schema

This sounds to me like programmer error. TypeScript provides facilities for unknown structures, or structures that have multiple possible definitions. There is the union type for which we can tell the compiler that a value can be of type `A[ or B[ or C[ or... ]]]`. Perhaps even more powerful is optional types. In interface you'd describe an optional field with a question mark, like `{ foo?: string }`. Alternatively, you could use the union type described above, unioned with `undefined`. These structures help you create types that actually do model the uncertainty of data coming into your program. If you're not using these techniques, then you're missing out! Having the type-checker yell at me because I didn't check for the undefined case is a really really cool thing.

> Why not force the developers to account for as many cases and schemas as possible, it's our job!

I would argue that TypeScript provides the vocabulary for doing just that and that JavaScript provides no such niceties. Sure, you provide run-time checks on a piece of datas validity, but there's no system to check that run-time behavior before code gets merged to master.

If you're not running `"strict": true` and annotating your TS code with optional values when data is coming into your program, you might have a bad time.

Re: Migrating 300k LOC from Flow to TypeScript

#34

Post by torben-friis »

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.

Perhaps I didn't explain it well - my point was not that you need TS to validate your inputs, it was that you can use TS to guarantee internal consistency of data, and that said internal consistency will work well as long as you ensure that the input is safe -which you do need to implement through other means like json schema. What TS offers in this context is to ensure that you didn't call a function with arguments present in the wrong order, that you didn't assign one variable instead of another, that you didn't forget to include one last argument...

All things that come up relatively frequently in vanilla JS during refactoring processes.

Re: Migrating 300k LOC from Flow to TypeScript

#35

Post by untog »

jillesvangurp wrote: post #10
untog wrote: post #8

Earlier quoted context omitted.

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…

All these issues are being worked on. If you use kotlin-js, the output is javascript. There are no GC issues, you use the javascript GC. WASM is currently indeed bottlenecked on the lack of GC. This is being worked on. I expect a lot of progress over the next two years that will gradually remove most of the obstacles on this and other fronts. None of these are fundamental issues; it's just a matter of things not bein…

I'd recommend taking a look at Svelte as well, it compiles down to "raw" JavaScript with very little client-side bloat.

Re: Migrating 300k LOC from Flow to TypeScript

#36

Post by orta »

truth_seeker wrote: post #6

I really like the way TypeScript approaches Dynamic world of JS ecosystem with various advance types. https://www.typescriptlang.org/docs/handbook/advanced-types.... Intersection Types - An intersection type combines multiple types into one. Union Types - A union type describes a value that can be one of several types Type Guards - A type guard is some expression that performs a runtime check that guarantees the type…

Nice overview! I plan on building a larger version of this into the docs eventually

https://github.com/microsoft/TypeScript/issues/31983#issueco...

Re: Migrating 300k LOC from Flow to TypeScript

#37

Post by finchisko »

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.

what do you mean by type validation of JSON objects? If you mean, that you can for exammple pass string to object property defined as number, then I must warn you, that this is problem in all languages (eg. most java json serializers, will throw exception). Anyway if you need to ensure all object properties have correct type, you should write validator/transformer (there are already libraries that can do it for you).

Re: Migrating 300k LOC from Flow to TypeScript

#38

Post by eropple »

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.

And that's what `runtypes` provides.

Re: Migrating 300k LOC from Flow to TypeScript

#40

Post by shados »

z1mm32m4n wrote: post #21
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.

Flow's perf issues has more to do with bugs than anything. Its usually pretty near instant even on big projects, but do one little thing wrong somewhere that hits an edge case and everything goes to hell and you'll never find where it came from.
Post reply on HN