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

61–70 of 87 posts

Re: Migrating 300k LOC from Flow to TypeScript

#61

Post by fulafel »

chillacy wrote: post #14
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…

Is this a joke? If your real world data doesn’t have a fixed schema representable in a type system how do you machine parse it?

Check out Rich Hickey on this, eg in the 10 years of Clojure talk (or the transcript).

Static typing requires you to express things in a way that is easily formally provable by the type system. It's much easier to write correct code (=working parer) than the correctness proof in a limited type system. This goes for higher order operations on schemas / types too, eg schemas are easier to make composeable than types.

Re: Migrating 300k LOC from Flow to TypeScript

#62

Post by sdegutis »

chaostheory wrote: post #56
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 Typescrip…

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.

Re: Migrating 300k LOC from Flow to TypeScript

#63

Post by deckard1 »

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…

The problem with JavaScript is that it's a terrible example of a dynamically typed language.

> The benefits are a vastly improved safety net at a very minimal cost, smarter tools

That's entirely subjective. As far as tooling, I get the impression from my coworkers and what I've seen online that people that love TypeScript love big bloated IDEs. They love having their IDE tell them what to do. And, personally, I find their usage of IDEs to be a crutch that prevents them from transitioning from a plateau of mediocrity to being a great developer. They don't understand the code. They merely throw things together that match the types that their IDE tells them, like LEGOs. Then they spend hours trying to figure out why their code doesn't work.

As far as the cost goes, my experience has been vastly different than yours. TypeScript is killing my organization. For no real benefit. The warnings it produces are for theoretic bugs rather than actual bugs. The warnings TypeScript produces are incomprehensible to most developers. And when they finally quiet TypeScript down, they don't realize they have the wrong types! No one seems to fully realize how easy it is to get TypeScript wrong. Your code gets littered with ts-ignore and "any" types and suddenly you have a mountain of tech debt. Code becomes ugly and difficult to read with type annotations. It's hard to imagine anyone actually winning in this war of attrition between clean, simple, readable code and TypeScript.

If you're doing TypeScript and having an easy time of it, you're most likely doing it wrong. TypeScript is incredibly nuanced.

Management loves TypeScript though. It's a shield for responsibility. When bugs happen (and they still will with TypeScript), they can point to TypeScript as something they tried. They didn't fail the organization, their technology failed them.

Re: Migrating 300k LOC from Flow to TypeScript

#65

Post by chenglou »

eropple wrote: post #58
icxa wrote: post #43

Earlier quoted context omitted.

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

I see what you’re trying to say here, but Reason (and its compiler BuckleScript) aren’t the kind of puristic language folks might think they are. BuckleScript has one of the most comprehensive way to bind to whatever piece of JS you have: https://bucklescript.github.io/ and you can also just include raw JS code as a last resort, all type checked still, while keeping type soundness (in this case, almost like `any` but not really).

HN’s too short to describe the extent of it; if you’d like some language that shares a similar spirit as TypeScript (with extra features such as native compilation), please do check out Reason and BuckleScript. Our main goals are great JS interop, fast build, robust type system and a familiar syntax for JS users.

Re: Migrating 300k LOC from Flow to TypeScript

#66

Post by jmull »

stickfigure wrote: post #50
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…

I don't get this argument at all. If you look at a typical call stack - in any language - going from the frontend all the way to the database, there will be hundreds of lines. Two, maybe three of those will be remote jumps. Every one of those calls is an opportunity for a contract mismatch. Even if static type checking misses a half-percent of your calls, it's still working to enforce 99.5% of your contracts. The val…

There’s nothing wrong with static type checking, It’s generally good and will prevent certain kinds of problems with out the cost of unit tests. I’m all for static checking generally, not just for types.

My point was to point out the limitations. I might be wrong, but people seem to often ignore these limitations. This oversells the benefits and leads to frustrated people like the one whose comment I originally responded to.

99.5% is not nothing, but not something you can live with in most systems so you are probably going to need something more. Also, you are going to be a lot happier if the vast majority of those hundreds of lines in your cross-system call stack are completely agnostic to the types of your problem domain and you want to be careful to minimize the coupling between components living on different sides of the jumps you mention. You can do that, of course, with static types, but it takes more care and intentional design and you really need to acknowledge the issues before you can get it reasonably right.

Re: Migrating 300k LOC from Flow to TypeScript

#67

Post by icxa »

eropple wrote: post #58
icxa wrote: post #43

Earlier quoted context omitted.

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

> TypeScript does not take out dynamic typing or prototypical object orientation

Hence my wording, leads you down the path not forces you to. More often than not, your TypeScript codebase (at least the part you have written yourself or by your team) will be Classical OO style and fully typed, and your code reviews will consist of copious amounts of "we should add a type here"

Re: Migrating 300k LOC from Flow to TypeScript

#68

Post by robmcm »

WorldMaker wrote: post #59
vimslayer wrote: post #24

Earlier quoted context omitted.

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…

Can’t wait for the, “Elvis operator” to land. Going to remove so much code!

Re: Migrating 300k LOC from Flow to TypeScript

#69

Post by icxa »

chenglou wrote: post #65
eropple wrote: post #58

Earlier quoted context omitted.

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

I see what you’re trying to say here, but Reason (and its compiler BuckleScript) aren’t the kind of puristic language folks might think they are. BuckleScript has one of the most comprehensive way to bind to whatever piece of JS you have: https://bucklescript.github.io/ and you can also just include raw JS code as a last resort, all type checked still, while keeping type soundness (in this case, almost like `any` but…

Thank you for all the work you do btw -- Reason is awesome and I am having a lot of fun learning. Interop seemed daunting at first but after I tried it, it was a great experience.

Re: Migrating 300k LOC from Flow to TypeScript

#70

Post by untog »

battletested wrote: post #54
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…

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

> A Typescript codebase is about 2x bigger than a Coffeescript codebase, that means about 2 times more chance for bugs

That's pretty obviously not true. If that extra code is adding type annotations then it is removing potential bugs because the code won't compile if you accidentally combine incompatible types.

Post reply on HN