Hacker News Reader

Comment by drenvuk | Hacker News Reader

I think using it would be the first one.

I don't think I'll ever be able to convert to using typescript, I'd rather have validators running in the code checking external inputs for the proper fields at runtime before the rest of the system blithely processes whatever it gets due to safe assumptions. Add integration test for specific modules and everything works fine.

I don't want to compile languages that don't need compilation and I don't like the fact that I need to create all of these fake feeling types which are actually just objects rather than javascript classes. It's just feels like boilerplate when you could instead include the 'type' that it's supposed to be in the name and look up a validator for that 'type'.

I'm probably wrong, but it really doesn't feel like it.

View on HN

Static typing check is a huge boost for code refactoring. It allows you to quickly make changes and be reasonably confident that you haven’t horrendously broken something.

It doesn’t obviate the need for dynamic validation nor is it meant to do that. But it does give you a clear point of where to perform those validations rather than littering it everywhere throughout your application.

It doesn’t obviate the need for testing either. But it does eliminate an entire class of dumb programming errors such as incoming a function with the wrong arguments.

Yeah, I mean I don't want to just say "you're wrong", but you kind of are here.

TypeScript alone doesn't make any assertions and doesn't offer any checking at system boundaries ("external inputs"). That's not what it is for, and the types you specify with it aren't objects. All that stuff gets compiled out before the code is even run. The point of TypeScript is so that you don't have to run your code to know whether the way it handles data internally is the way you intend it to.

Validation at system boundaries is a separate concern, and handled separately. I like to do it with a package called "runtypes", which both supports arbitrarily complex shapes in its validators, and expresses them in a way that's very close to TS and can be trivially converted into compile-time TS types so that you don't have to write the same types twice.

I wasn't sure what to make of TypeScript for a while, too. But having once tried it, and since become very conversant with it, I'll go back only for trivial tasks or under significant duress. Sure, writing types is a fair bit more work up front and a little more ongoing, but it really does make a huge difference in maintainability; in my experience, it's a little work now to save a lot of work later, as the resulting code is both less likely to exhibit an entire class of often quite subtle bugs, and easier to reason about and modify.

There's a heavy push towards Typescript lately and I agree with your counter. I'll add to it: Type checking gets you somewhere, but are you better off there? It depends on where you want to be.

As you've mentioned, integration tests are important, and cover your assumptions on a closer-to-the-user level.

I suspect that there's a flock that prefers working with the testing pyramid remaining standing. Put another way, are uncomfortable if the lower bases are unstable.

There is another flock that prefers the agility and flexibility that comes without logical gymnastics of type checking, relying on inverting the pyramid to prove they're done. Not right or wrong, but another way of making.

"I don't want to compile languages that don't need compilation"

Well it's a transpilation, not a compilation, and you are able to run .ts files in dev mode without transpilation.

"fact that I need to create all of these fake feeling types"

I feel the contrary to you. I want everything to be well defined in my application, especially if it's a server :)

Reply on news.ycombinator.com