If It Ain't TypeScript It Ain't Sexy

If It Ain't TypeScript It Ain't Sexy(developer.okta.com)

50 points by aaronpk 7 years ago | 45 comments

mohsen1 7 years ago |

> Naively, someone might think you’d write fewer tests with TypeScript. That someone would be wrong.

Have you seen unit tests that check "what if I don't send the right number/type of arguments"? Yeah those unit tests are not necessary if you use TypeScript.

shados 7 years ago | |

They're not necessary in JS either.

You'd presumably have at least some tests in the form of "Give these input, get that output". By checking that output, you pretty much confirm its the right type at the same time.

I've seen a lot of test suites that have stuff like:

"given input A, test that result is defined. Given input A again, test that result is 1234". It's like, yo, if result is 1234, its obviously defined.

There are edge cases, so yeah, the amount of tests you don't write in TS is > 0, but it's far and few in between.

nicoburns 7 years ago | | |

It was pretty common to write runtime type assertions at the top of functions in JS before TS was invented...

futureastronaut 7 years ago | | |

Those assertions are invariants so that the test fails with a meaningful error message rather than raising IndexError or what have you.

captainbenises 7 years ago | |

They are though. What if the API you're relying on doesn't have types and it returns something you didn't expect.

I think this is the biggest gotcha for developers who are using typescript. Typescript doesn't do runtime type checks, so if you're calling out to something third party that isn't written in typescript, you can't trust it'll return what you think it returns.

poink 7 years ago |

If you maintain a popular public project, you help the entire JavaScript community if you use TypeScript, because then you can ship perfectly accurate type definitions along with your code. Even if the user is using plain JavaScript, their editor can probably use those type definitions to provide coding assistance.

Also, it's hard to call something a "leaky abstraction" when it's a superset of the thing it sits atop.

reverentgeek 7 years ago | |

True, it's not the same kind of leaky abstraction you find with other technologies. I'm thinking more about the newcomer to JavaScript/TypeScript, who has only focused on the latest language features, trying to get a grasp of what is going on in the ES5-compatible code that gets generated.

Same is true with relying on Babel, of course.

WorldMaker 7 years ago | | |

More so than any random Babel preset someone might hand a new developer, though, Typescript has been pretty strict at this point towards staying strictly to ES Stage 3+ proposals. (And the few exceptions [enums, namespaces] are all common JS patterns that just about anyone should recognize the generated code, and are easy enough to avoid if you want to be more strictly ES Twenty Xteen+Types.)

(Also, the current Babel wisdom of "last two browser versions" suggests that ES2015 or ES2016 is the compatible downlevel of choice in 2019, rather than ES5.)

ng12 7 years ago | |

Absolutely. It's by far the easiest way to ship an easily consumable API reference with your library.

shados 7 years ago | |

It's leaky in the sense that you can bypass it. If I flag something as private in TS, there's nothing stopping a "any" somewhere from making it writable, for example.

BoorishBears 7 years ago | | |

That's not what a leaky abstraction is.

hodgesrm 7 years ago |

I love TypeScript. It's like the good parts of Java (classes, type-checking, good support for service-based programming models) with Javascript goodness like handy functional programming tricks, concise code, reactive programming, and not having to worry about concurrency.

The biggest problem is that it lacks document that rolls up TypeScript and Javascript underpinnings in one place. As it is you can't just read the TypeScript docs at https://www.typescriptlang.org/docs/home.html and get started. Or rather you can but you'll promptly run into many cases where you can't reason effectively about behavior because you don't understand how Javascript works. (E.g., iterating over collections of Javascript entities.)

There have been a bunch of projects to create a better Java. TypeScript looks like one of the best attempts so far, in part because it broke free of trying to remain compatible at the VM level. It does not deal with every use case for that reason but looks like an excellent language for microservices. Interestingly the origin as a client-side language is not that different from how Java was first marketed...

Edit: Moved reactive programming to the javascript side of the fence (what was I thinking?)

rickette 7 years ago | |

> I love TypeScript. It's like the good parts of Java (classes, type-checking, good support for service-based programming models) with Javascript goodness like handy functional programming tricks, concise code, reactive programming, and not having to worry about concurrency.

This, 100%. And I'm saying that as a guy who's been writing Java for the better part of 10 years.

ng12 7 years ago |

> TypeScript doesn’t absolve you from learning JavaScript. When things go awry, you’ve still got to be able to spelunk the JavaScript code it produces.

TypeScript code is still 90% regular ES6 JavaScript, of course. That said I very rarely need to go grepping through the transpiled code.

arcticfox 7 years ago | |

> TypeScript doesn’t absolve you from learning JavaScript. When things go awry, you’ve still got to be able to spelunk the JavaScript code it produces.

I've written several projects in Typescript and I don't think I've ever had to analyze the transpiled code. I'm curious how esoteric the situations are where this is still necessary.

GiorgioG 7 years ago |

The problem I have with TypeScript isn't the language itself, but the illusion of type safety that it gives you. It gives you a better developer experience at compile-time, there's no doubt there. My problem is once TS is transpiled, all type-related bets are off. You can easily find yourself in situations at runtime where a string is passed into to a function that's expecting a number. You may not get an actual runtime error, instead you might just see unexpected behavior. I've had to fix bugs due to this situation more times than I can count (I didn't write the original code) in our Angular app.

wvenable 7 years ago | |

That's the problem with JavaScript, not TypeScript. TypeScript doesn't eliminate that problem but it doesn't cause it either.

TypeScript does heavily mitigate that problem by verifying all the types that it can at compile time.

stunt 7 years ago |

> Type-checking only helps with one class of bugs that can occur in a codebase

TypeScript is not only about eliminating bugs, for instance maintaining a large project is much easier comparing to Javascript.

However, A lot of teams would still use Javascript for small backend applications, and the best example is Lambda functions! With rising popularity of Serverless architecture JS is here to stay for backend.

While TS will remain a good alternative for many things of course.

lstamour 7 years ago | |

You’d be surprised the number of places you can use TypeScript where only JS is supported. Most recently, TypeScript allowed me to easily use modules and ES2018 syntax with the legacy, somewhat terrible Google Apps Script JS engine, thanks to Clasp: https://github.com/google/clasp/blob/master/docs/typescript....

I often find merely searching for a typescript-compatible solution helps me discover some of the safest and bug-free options quickly, avoiding legacy jQuery-era projects.

mcphage 7 years ago |

I generally like Typescript, but I find it frustrating that it doesn't include a useful standard library. Instead, we're stuck with Javascript's bare bones of a library, which means a lot of thing that can be done in other languages just using their library, need to either code from scratch, or import from a 3rd party library.

lstamour 7 years ago | |

Don’t overlook the number of options available out of the box with the —lib parameter: https://www.typescriptlang.org/docs/handbook/compiler-option...

In many ways, I prefer this approach—it means TypeScript as a language will stay compatible with JavaScript, and keeps options like Babel 7’s outright removal of TS types easily done. If you need a feature JS doesn’t have, import it, or pick a browser or runtime API. Seems simple enough to me. :)

mcphage 7 years ago | | |

> Don’t overlook the number of options available out of the box with the —lib parameter

Thanks! I honestly wasn't aware of that at all!

> it means TypeScript as a language will stay compatible with JavaScript

If Typescript's library was written in JS, then the elements that were needed can be compiled down and included with your code.

> If you need a feature JS doesn’t have, import it, or pick a browser or runtime API

I really appreciate standardization—that way everyone is on the same page with basic methods. I don't have to worry about learning multiple versions, or worry that code I'm reading is doing the same thing in a slightly incompatible way. Or listen to people arguing about those same minor differences :-)

Justsignedup 7 years ago |

The ugly: It is still javascript....

I heard this argument against CoffeeScript. At the time CS was still fucking amazing. And I loved it. Sure now people roll their eyes because JS has all the features coffeescript had, but not the indentation-based logic flow... Whatever. CoffeeScript 4 lyfe!

In any case, I see it as a positive. This is just like saying at the end you still gotta know Assembly to write in C...

Also they forgot to mention. Interfaces. Fuck I love interfaces. Self documenting code? Yes please. Awesome auto-completion from tools? Yes please. Sure if you develop in the caves like cavemen and use VIM only without anything to help you, sure, TS is slower. But the point is that amazing dev tools are amazing.

The problem with languages is when the type system isn't strong enough in some cases, but too strong in others. It would be nice for prototyping to use `var` and let the compiler figure the type out. However it would be awesome to write a method that says position 1 is a number between 1 and 100.

saghm 7 years ago | |

> The problem with languages is when the type system isn't strong enough in some cases, but too strong in others. It would be nice for prototyping to use `var` and let the compiler figure the type out. However it would be awesome to write a method that says position 1 is a number between 1 and 100.

Out of curiosity, which of those two cases do you think of as having too strong a type system? To me, both of them (type inference and numeric bounds at the type level) seem like they require a stronger type system to fix, not a weaker one.

sebazzz 7 years ago |

> TypeScript requires a build step. That might be enough reason for a JavaScript developer to say, “No, thank you.”

In my experience most JS developers have other considerations. Tests are also a build step, so good chance a codebase already has those.

madmaniak 7 years ago |

Never got the answer: https://news.ycombinator.com/item?id=18978404

_hardwaregeek 7 years ago | |

VS Code and TypeScript itself

seattle_spring 7 years ago | |

All of Airbnb? All of Facebook (in Flow)? All of Palantir, Coinbase, and Stripe?

No one answered that post because your history proves that you are not asking in good faith.

madmaniak 7 years ago | | |

Interesting claim about Airbnb or Facebook. Thanks for an answer didn't knew it and I was seriously interested. I always ask to get answers - in good faith for me and others. No idea why you stalk my history and make false assumptions.