Live data from Hacker News

Migrating 300k LOC from Flow to TypeScript

medium.com

81–87 of 87 posts

Re: Migrating 300k LOC from Flow to TypeScript

#81

Earlier quoted context omitted.

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

Stop being dismissive. You know that’s not the point. I have a few applications that use the same API, and it’s consumed using a shared library in Typescript. There’s a little bit of code that takes raw messages, parses and validates them, then returns typed objects. This means we can use those typed objects confidently throughout the rest of the codebase, making some useful guarantees about the content of them and d…

> Stop being dismissive. You know that’s not the point.

Please edit such swipes out of your comments here, regardless of how wrong or annoying you find someone else's comment. Your post would be much better without those bits and the swipe at the end.

https://news.ycombinator.com/newsguidelines.html

Re: Migrating 300k LOC from Flow to TypeScript

#82

I've been reading the comments, and sorry, I can't help it. Every time I read about (or try) some trendy thing in JS/Front-end world, I feel irritated and sad. Every single "big promise" hype that supposed to help us to "fix" issues with front-end development adds more complexity and frustration. jQuery was awesome, then "okay", then become bad, then later really, really bad. Same with Backbone. Same with Angular and…

So you have seen the JS world progressing and feel sad about that they haven't just found out the "best way" from the beginning? I think it's marvelous how fast JS moves and outdated solutions are phased out in new projects for better and more reliable methods (although I admit some JS developers pick the wrong tools for wrong reasons). The act of having to constantly learn and think about a better way of doing things has at least kept me sharp and meticulously pondering the pros and cons of each way of doing things.

Sure the churn can be discouraging and if you wanted to be able to write the same way with same tools to retirement I wonder why you'd even consider doing frontend development. I am quite happy with the tools I use (Typescript, React, Mobx, StyledComponents) and have felt no need to change for something else. They are tools I am very productive with, and all the developers I've worked with have been able to get quickly on track with using them. No huge mental leap from JS to TS as with functional languages like Clojure or Elm.

Although it's my opinion that, JS itself should be eventually be phased out for something better for majority of frontend software. It just has too much old baggage so it would be best to just switch for something new completely. However, there's something mysteriously intriguing about JS in that allows so great flexibility, in good and bad, that not just any language can replace it. But nowadays I don't do much complaining about JS stuff anymore. I have found my sweet spot and I'm mostly just busy getting stuff done and there's things far worse in programming than how "bad JS is".

Re: Migrating 300k LOC from Flow to TypeScript

#83
post #46

Earlier quoted context omitted.

Well, as a someone who had the same initial feelings with TypeScript when it came "oh it slows me down, these types are just a waste of time", I get where you're coming from but think that you have some other issues than TypeScript with your team and project. First of I'd want to say that most of your complaints about "no runtime type validation" in the context of TypeScript/JavaScript is just how unreliable JS is as…

Also I think part of the problem is that TypeScript encourages developers to write interfaces that have complex parameters (e.g. accept instances of specific classes) whereas JavaScript encourages simpler parameters like strings, numbers or plain JSON. In OOP, passing complex instances to functions across different files is dangerous because the different files may all end up affecting the same instance's internal st…

TypeScript doesn't encourage returning classes. Writing classes just as data handlers is still verbose and clumsy. You can have a team that's writing Java in TypeScript and see that, but that's not conventional at all.

Instead, TypeScript encourages returning structurally typed interfaces. Which are just data.

Re: Migrating 300k LOC from Flow to TypeScript

#84

Earlier quoted context omitted.

That's the general consensus and how I mostly feel too. But I'm starting to feel like the drawbacks might possibly be outweighing the benefits.

If we were talking about Ruby or Python, you'd have a stronger point. However Typescript's benefits far outweigh its drawbacks in light of Javascript's excessive lenience. Since, you're complaining about types, have you made good use of Typescript's interfaces and class inheritance? They're pretty powerful and even more flexible than something like Java.

Yes, I use TypeScript types very idiomatically and have received very positive feedback on my TypeScript code. But just running `tsc` takes >10 seconds on a relatively small project, and IDE support is becoming proportionately slow, e.g. hovering over anything to show its type often takes 5-10 seconds before VS Code will actually have something to show me. It's becoming painful, and that feature which I once heavily relied on has become nearly useless to me.

Re: Migrating 300k LOC from Flow to TypeScript

#85

Earlier quoted context omitted.

If we were talking about Ruby or Python, you'd have a stronger point. However Typescript's benefits far outweigh its drawbacks in light of Javascript's excessive lenience. Since, you're complaining about types, have you made good use of Typescript's interfaces and class inheritance? They're pretty powerful and even more flexible than something like Java.

Yes, I use TypeScript types very idiomatically and have received very positive feedback on my TypeScript code. But just running `tsc` takes >10 seconds on a relatively small project, and IDE support is becoming proportionately slow, e.g. hovering over anything to show its type often takes 5-10 seconds before VS Code will actually have something to show me. It's becoming painful, and that feature which I once heavily…

Is the time spent compiling drastically more than the time spent debugging code because of the lack of types? A few seconds of compiling is because than the potential hours wasted on debugging. Besides, you can mitigate compile times by getting a faster computer. Silicon time is still way cheaper than carbon time.

Re: Migrating 300k LOC from Flow to TypeScript

#86

Earlier quoted context omitted.

Yes, I use TypeScript types very idiomatically and have received very positive feedback on my TypeScript code. But just running `tsc` takes >10 seconds on a relatively small project, and IDE support is becoming proportionately slow, e.g. hovering over anything to show its type often takes 5-10 seconds before VS Code will actually have something to show me. It's becoming painful, and that feature which I once heavily…

Is the time spent compiling drastically more than the time spent debugging code because of the lack of types? A few seconds of compiling is because than the potential hours wasted on debugging. Besides, you can mitigate compile times by getting a faster computer. Silicon time is still way cheaper than carbon time.

It's not just "seconds wasted in compiling". It's having my IDE say "thinking..." for 3-10 seconds every time I want to see what type something is. Or having create-react-app load for 5-15 seconds, every time I save any file before letting my browser update (even if I press refresh manually), because it's compiling. And when this happens on a minute-by-minute basis, it drastically slows down development time.

Re: Migrating 300k LOC from Flow to TypeScript

#87

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.

Protobufs is an antipattern. You can't expect external systems to agree with your system's type definitions. It just gives other people extra work when integrating with your system.

JSON is better because it allows external services to interpret the data in their own way regardless of their type system.

Post reply on HN