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.
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.
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.
Also, it's hard to call something a "leaky abstraction" when it's a superset of the thing it sits atop.
Same is true with relying on Babel, of course.
(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.)
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?)
This, 100%. And I'm saying that as a guy who's been writing Java for the better part of 10 years.
TypeScript code is still 90% regular ES6 JavaScript, of course. That said I very rarely need to go grepping through the transpiled code.
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.
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.
Typescript vs Javascript is less problematic today than modern JavaScript vs browser compatible JavaScript.
The amount of green boxes in this specific feature blows my mind:
--sourceMapThat's it.
TypeScript does heavily mitigate that problem by verifying all the types that it can at compile time.
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.
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.
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. :)
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 :-)
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.
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.
In my experience most JS developers have other considerations. Tests are also a build step, so good chance a codebase already has those.
No one answered that post because your history proves that you are not asking in good faith.