re: TypeScript is a waste of time. Change my mind. VIEW POST

TOP OF THREAD FULL DISCUSSION
re: UPD: I turned this thread into article dev.to/stereobooster/type-system-f... Ok let's start constructive conversation by fixing some terminology: ...
 

Thank you for your input! Allow me to respond and clarify:

JS is typed language, it is dynamically-type-checked language (or some people short it down to dynamically typed).

Yes, I know. However, I wanted to differentiate between TypeScript / Flow-based JavaScript and JavaScript code that doesn't have TypeScript / Flow. I was first going with "plain", but then again, technically you can have JSX and other non-JS features without static types, so that's why I settled with "untyped".

And there is a trade of: you need to write a bit more code (type annotations) in order to make static type checker work. It's up to you to decide if it worth it or not.

Yes, I agree completely. However, I also believe that it is not worth it in the majority of cases, and that many people are misguidedly using TypeScript believing that it will save them time when in fact it only slows down development in both the short and long-term.

TS is not sound (any type), but you can bulletproof it with tsconfig, by setting all strict checks to true. And by prohibiting usage of explicit any.

This is true; however, in my experience this only leads to lots of red squiggly lines. It's impossible to do completely strict types in TypeScript / JavaScript, and there's always going to be that one case that cannot be fixed with this. Before you know it, you've got half-types and hacked code all over the place, and that's something that's not satisfying at all, especially when you've spent an extra 20-40% of development time writing up types, downloading type libraries and exporting interfaces.

You can make a bridge between static type system and dynamic type system. Check that type are valid dynamically on the input (which is unknown and uncontrolled) and rely on the static type checker through the rest of the programm

You sure can, but I would argue that if you want true type safety and security you should look at a statically compiled, more lower-level language. For example, in many large companies the API that interacts with the database is almost always written in a statically typed language such as C++, C#, Java, etc. - I don't think that TypeScript is the solution here. Plus, importing a function makeSureItIsAString seems like overkill just to make TypeScript support complete.

Once again, thank you for your detailed response, and I hope my response has been appropriate!

 

It's impossible to do completely strict types in TypeScript / JavaScript, and there's always going to be that one case that cannot be fixed with this.

You have to understand where it is impossible: at the I/O boundary where your typed system talks with the outside world. Types help to make sure statically that the typed part of the program does not contain type errors. If the I/O boundaries are clearly delineated, and the data is cleanly marshalled from the untyped world into the typed world, you will clearly see the benefit if the typed world is large. If the only thing you do in your programs is manipulate the untyped data, it is easier without types.

 

JSX is typed as well - it's just React.createElement() and you can attach dynamic type checking with PropTypes. Or in typescript

Or you can use them both like described here.

Let's stick to correct usage. Untyped means there are no types or what is the same, there is only one type. For example, assembly is untyped language it has only one type - bit strings, Lambda calculus is untyped language it has only lambdas.

It's impossible to do completely strict types in TypeScript / JavaScript, and there's always going to be that one case that cannot be fixed with this

In general it should be possible. The other question if you want or not. Don't mix up two argument.

typed language such as C++, C#, Java, etc.

You realise that all those languages are not type safe?

Java unsound, C unsound

Haskell has a sound type system. The type system of C (and thus C++) is unsound.

-- cs.uaf.edu/~chappell/class/2016_sp...

C# unsound

No, the C# type system is not sound, thanks to array covariance, my least favourite feature:

-- stackoverflow.com/questions/239391...

It means it is totally possible to write program in all of those language which will crash at runtime because of type error.

Don't confuse static types with type system soundness.

Plus, importing a function makeSureItIsAString seems like overkill just to make TypeScript support complete.

You don't need them everywhere you need them only to validate io e.g. user input, server response etc. There are libraries like, io-ts which helps to simplify this process.

In general it should be possible. The other question if you want or not. Don't mix up two argument.

I wouldn't say "in general", I would say "in theory" - however, in practice it is commonly the case that you don't write 100% of the code you use; and as such, you cannot confirm the validity and "typeability" of the code you are given.

You realise that all those languages are not type safe?

That was not my point, and I overstepped when I said "true type safety". Obviously TypeScript does not provide sound type safety and neither do the languages I've listed; however, they do have much stronger, native checks for static typing that are built into the languages, as opposed to TypeScript which still transpiles down before then being interpreted - quite a few layers there where errors can occur.

You don't need them everywhere you need them only to validate io e.g. user input, server response etc. There are libraries like, io-ts which helps to simplify this process.

Could you give an example of when you would need to validate and when you wouldn't? Seems weird to have to validate whether user input is a string, for example.

Could you give an example of when you would need to validate and when you wouldn't?

If you expect string and you read from the html input you will get string. But if you, for example, read state from URL and decode it and expect some arguments to be numbers, things can go wrong here. Or if you, for example, use JSON.decode to get response from the server, you need to make sure that response is in correct format.

I would validate all user input, I meant to say, that reading IO is typically not that big compared to other logic of application.

however, they do have much stronger, native checks for static typing that are built into the languages, as opposed to TypeScript

Why do you think so? Typescript is quite advanced type system it is based on latest research (and written by the same people who wrote C#, Anders Hejlsberg for example). So this claim needs a bit more evidence.

The fact that it compiled to JavaScript doesn't make it unsafer. All checks happen before compilation. The same for native programs, check happens before compilation, one of the compilation steps is type erasure (unless you use something like Reflections or io validation or pattern matching on boxed values). After type erasure you deal with untyped assembly code. Do you think assembly is more safe than JS? (rhetorical question)

 

...in my experience this only leads to lots of red squiggly lines.

I don't know much about TS (and not a fan of JS, but let's leave that out of this), but I do know a lot about both C++ (static typing) and Python (dynamic typing).

If your code is filled with red squiggly lines from any linter or other static analyzer, you can almost certainly depend on your code being the problem, not the analyzer!

The same flawed logic in what I just quoted at the top is the reason C++ developers are afraid to turn on -Werror: "but, but, my code won't compile, it'll just give lots of errors.

I've seen that issue in nearly every language I've worked in, so it simply tells me that if someone is working in TS, and is avoiding strict mode because "too many red squiggly lines," you can bet the house they've been writing bad code. Chances are, in fact, they're using TS as if it were nothing more than JS-with-type-hints-on-top...and utterly eschewing the patterns and logic one must follow when working with types.

All that to say, if someone's gripe is too many red squiggly lines, I wouldn't trust the quality of their code in that language.

 

This article has some misinformed opinions being reported as fact. I don’t mean that as an insult, I am just sad that there is no empiricism involved. Allow me to clarify:

For example, in many large companies the API that interacts with the database is almost always written in a statically typed language such as C++, C#, Java, etc.

All of those languages are weakly-typed when it comes to the MOST important aspect:

// valid C#
String myStr = null;

// invalid TypeScript 
const myStr: string = null;

Do you see how big of a problem it is that C# allows reference types to be implicitly nullable? That means that you can never know if your data is there are not. :( But with TypeScript you can have confidence in your code. The only languages that have strict null are TypeScript, Kotlin, and Swift. Can you see now how your subjective statement above is both incorrect and misleading? I feel like it’s the equivalent of “the cool kids are using C#.”

Plus, importing a function makeSureItIsAString seems like overkill just to make TypeScript support complete.

There’s no reason to write functions like makeSureItIsAString when libraries like io-ts do all of that work for you of ensuring type accuracy at compile time AND runtime. So if you’re looking to build an enterprise-grade app, io-ts or tsoa are wondeful tools to eliminate bad data from even getting through the front doors.

Let's use softer tone. Everybody has holes in their knowledge, it is ok as far as person willing to learn and take part in reasonable conversation. (Conversation was pretty reasonable so far. ❤️@parkroolucas. The title is a bit harsh, but I guess this is meant to be clickbait).

All of those languages are weakly-typed when it comes to the MOST important aspect:

Weakly-typed/strongly-typed is ambiguous terms. See here

The title is a bit harsh

Yes. How many of these anti-TS articles are there? But when you look at the usage rates, most of the developers who try TS are interested in using it again.

I totally get you ❤️. What I'm saying if we all switch to this tone, it would be hard to have constructive conversation ¯\_(ツ)_/¯ (Yes author used the provocative title and text, yet somebody should stay cold-blooded)

 

I’m really disappointed to hear this same subjective phrase again:

when in fact it only slows down development in both the short and long-term.

I was hoping to find some objectivity. At a minimum, can you please try to convince me that TypeScript slows you down more than it speeds you up?

Consider the fact that I wanted to rename a variable yesterday and VSCode let me do it (and it can only do it accurately because of TypeScript). It changed the variable in 78 files. And this is important: it didn’t just do - “find and replace...” it did it intelligently. To refactor a variable name in JS would have taken a very long time and I would have had to regression test the entire codebase to make sure I didn’t break anything. I would estimate that a full regression test of my application would take 1.5 days.

And you also forgot about the fact that TypeScript helps to communicate your meaning to future developers. Isn’t that important?

So if it helps significantly with refactoring and helps you be a better coworker, then why is it a waste of time?

Good point, ease of refactoring is a place where static typing helps.

My experience was the same: I was forced to do numerous refactorings over big codebases, all done by pressing two buttons thanks to TypeScript, refactorings which would otherwise have taken hours with plain JS. TypeScript is a godsend for the JS ecosystem in my opinion.

Vscode refactors plain js just fine. Typescript does not help with that.

I don't think that's true across multiple files and variables. Especially when multiple classes/interfaces have the same variable names

Ah - you're renaming a variable in an interface? In that case, yes, probably vscode can do that thanks to typescript, and wouldn't be able to do it without it.

OTOH, all the times I did this, I did a global search&replace, eyeballing to make sure, and having the tests for extra verification.

Uh, wait why are you using a single variable across 78 files? If I have to understand 78 files to understand a feature it sounds like you have bigger problems.

That’s a lot of judgement Jordan. You seem to be making some assumptions.

“uh, wait why are you using a single variable across 78 files? If I have to understand 78 files to understand a feature it sounds like you have bigger problems.”

For a moment, suspend your assumptions and consider the fact that we had a valid reason for updating the the name of a property on some data. The reason the variable change effected 78 files is because we renamed a property on a data object that we use throughout the entire system. And since we have many api tests, end-to-end tests, unit tests, and more it caused a large change. But that’s the beauty of TypeScript... I can make a change that effects the entire system without causing any quality concerns.

So while your assumptions involve a change to one feature, in reality this change effected all features. When you take a functional / data-oriented approach it’s not uncommon to have many transformation functions that manipulate the data. And since I currently work on a data visualization UI, there are a great many ways that the users want the data to be transformed.

Does that clarify how one variable name can ripple out? Hopefully it communicates how TypeScript allows my team to continuously refactor with safety and without having to spend a bunch of time updating tests just because we learned that we originally misspelled a property on the data an API returns.

Yeah, you're right I did judge. Sorry. I don't know your codebase, I just find it odd that a single variable would exist across 78 files. Feels wrong to me. Something like KISS or maybe SRP come to mind. But again I don't know your codebase.

I think what they were doing is renaming a key in an interface, like going from data.online to data.isOnline

Or adding data.timestamp. With TS you automatically get notified of all the places where this data has to be set and also you now automatically know everywhere you use data that it also has a timestamp property. Also, TS ecosystem goes further than that, you could have Protobuf definitions that might be updated because data is serialized and sent over the network to multiple other services, and with the updated TS typings everyone just knows about this change and can update their code accordingly. And yes, this data interface could be used by hundreds of files across multiple services and git repos.

code of conduct - report abuse