Hacker News Reader

Comment by why-oh-why | Hacker News Reader

Instead of focusing on what TS does not, focus on what it does.

TypeScript is not sound; JavaScript isn’t either. The first one will catch some type errors, the second will catch none.

Syntax highlighting, linting, testing, and now type checking: every step can make you more confident about the code you ship, before it even hits the browser.

You can forgo using any help and probably you’ll code faster, but, again, you lose confidence.

View on HN

FlowType has better soundness than TypeScript. I like to think of TypeScript as a "feelgood" typesystem (especially how it handles predicate functions, type variance in function arguments, and type casts). The only downside is that Flow's typesystem is volatile. You _might_ find it painful to upgrade between versions.

With that being said, I still prefer Flow. Not sure how relevant this is, but at my company we mostly write Flow in the teams. For libraries I tent to provide both (code being written in flow, with with .d.ts provided). I also maintain both 3rdparty ts and flow type defs.

TS tooling blows Flow out of the water, though. But, I've heard flow team at facebook is focusing a bit more on DX and on making the typesystem a bit more ergonomic and expressive. :)

> TS tooling blows Flow out of the water, though

This is the dealbreaker. Building Flow in OCaml was a mistake, full stop.

I'm not convinced the level of soundness we're talking about is important except for the people who like to wax philosophical about PL theory. TypeScript has never been "unsound" in a way I actually care about and I would argue if you get caught up in a soundness issue you're already doing something completely crazy.

It's true that ocaml has different contribution entry profile. The only "issue" here is that flow being a js tool, naturally would attract more js contributions, but that's it. You can't say ocaml itself is not fit for purpose because this kind of tool is pefect use case for ocaml. It would be interesting to see flow rewrite in flow itself thought.

It being written in OCaml is why the tooling is poor. TypeScript integrates perfectly with most build tooling (e.g. Webpack) because it's just JavaScript like every other tool. To run Flow everything has to be shelled out to an external bin which adds a lot of flakiness and manual configuration if you want to integrate it with your build config.

I understand OCaml is great for writing meta languages (ha) but it's bad for the end user.

Maybe, but personally I don't use any tooling at all, just raw js with types in comments and npm test as `eslint . && flow check && jest`.

I use flow as well at the company I'm working for. I found lightweight setup that works surprisingly well for me. It started as experiment to use types in comments. There is no transpilation phase at all, just pure js with types in comments. All my projects use simple npm test "eslint . && flow check && jest" and there are no prepublish hooks, no manglings, no source maps etc. It means you can edit linked modules in place and get instant feedback. The workflow is very fast and non intrusive. It looks like this [0] or this [1] etc.

[0] https://github.com/appliedblockchain/parser-combinators [1] https://github.com/appliedblockchain/helpers

Tests are the only thing that give me confidence about any code I write, Javascript or otherwise.

And compilers are effectively a rudimentary form of test. They are not sufficient, nor necessary but they do validate some basic assumptions about the code.

They also remove redundant testing (you only need to prove something fulfills certain properties once as long as you have a type for it); and the more advanced the type system the fewer tests needed.

friendly tips: runtime type checks are available https://github.com/gcanti/io-ts https://github.com/pelotom/runtypes

I mention io-ts https://github.com/gcanti/io-ts in the post

Thanks for the article It sparked useful discussion around the world

If for no other reason, I would like Typescript for flagging when you typo some property - e.g. foo.FooID vs foo.FooId.

I've lost a stupid amount of time in regular JS because of things like this that make me want to pick up the computer and throw it out the window.

Decent editor does that now. I'm using atom on daily basis and it's helping me with that. VScode and intellij does the same

Doesn't the functionality for that in most editors leverage typescript typings, so that it's not really independent of typescript?

Ah I misread the parent comment. I thought it was more like "I wish typescript has this anti-typo functionality"

You're right that it's not independent from TS.

you can add JSDoc annotations and use a modern IDE like vscode or webstorm, etc.

I would upvote you twice if I can for that compiler is a test thing

It's not just about confidence. It's also about the speed you can use/refactor the code. Suggestions, type information on hover and instant feedback if you forgot, used wrong order or type, misspelled or simply don't remember exactly signatures or auto generated documentation means a lot when writing code. You can move much faster when working on typed code. Nobody ever claimed that types are replacement for tests. It just means that your tests don't require obvious clutter anymore, you can focus on more complex/important test cases to cover.

Tests only help if they are written, and if they cover the code in question. Both of things are unfortunately not always given. If things are not covered by tests type systems are still better than nothing.

Javascript is dynamically typed -- that does not mean it has no types. You are free to add dynamic type checks anywhere you want. I view these as critical for APIs even if you decide to use typescript. I also view them as critical for third-party interfaces where you may not be able to test integrations completely.

Reply on news.ycombinator.com