If It Ain't TypeScript It Ain't Sexy | Hacker News Reader

If It Ain't TypeScript It Ain't Sexy

developer.okta.com

50 pointsaaronpk45 comments

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

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.

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

Different topic than unit tests, but also if its in the public interface of your code and you don't control all callers, you might need those assertions anyway (since they could be invoked from non-TS code, or they could have been cast to a any type, especially in non-strict mode TS)

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

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.

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.

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

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.

That's not what a leaky abstraction is.

An abstraction that doesn't properly hide what's under the hood and requires people to still be aware of it. That's exactly what TS is.

Ts doesn’t abstract away Js.

It’s a superset of Js, almost the “opposite” of an abstraction (at least in the common intent of an abstraction)

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.

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.)

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?)

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

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

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

Concur. I'm always checking underneath the hood 'because' ... but I have not actually come across a case wherein I've had to.

That said - I think the comment is valid. Transpiling is not compiling and we have not choice but to remain vigilant on the JS, of course, it's not that hard, especially with ES6.

Code has bugs. I don’t even write that much typescript and I’ve looked trough the transpiled code just so that when I encounter a bug I’ll be familiar enough to debug through that layer.

I've been using Typescript for three years, both in the browser and in NodeJS. The only time I've seen JS in my debugger is when source maps weren't configured/found. I've never had to fall back to JS for debugging.

Definitely way less than I used to with CoffeeScript in 2011.

Typescript vs Javascript is less problematic today than modern JavaScript vs browser compatible JavaScript.

Even browser compat JS is slowly going to be almost identical.

The amount of green boxes in this specific feature blows my mind:

https://caniuse.com/#feat=async-functions

It's cutting edge ES type annotations.

That's it.

Do you debug TypeScript code? If I get the code on the browser to place a breakpoint, it's JavaScript there, is there some way to transpile it so it carries the extra information?

Source maps do this

That's what source maps are for (same situation as if you use ES6 and/or a framework and end up transpiling via Webpack etc)

sourcemaps are buggy as hell though (browser's devtools, and just generally the specification's problem, not TS's), and a lot of devtool features don't work with them. Debugging non-trivial problems with sourcemaps on is infuriating. It's really rare (though it happens every now and then in complex software) to have to go down to bytecode or native in something like C#, but in JS/TS/whatever, it happens all the time.

Enabling source maps will have the source including type annotations show up in the web inspector, but the information isn't usable by the JavaScript VM to validate types at runtime. This is also necessary to preserve line and column information when debugging.

    --sourceMap

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.

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.

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

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.

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.

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. :)

> 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 :-)

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.

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

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

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

VS Code and TypeScript itself

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.

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.

Haha Jesus. I originally saw this post because you linked to it from another crazy uninformed rant on ts, not because I "stalked your profile." Get a grip.

Reply on news.ycombinator.com