Good reasons not to use TypeScript(medium.com) |
Good reasons not to use TypeScript(medium.com) |
End result: checks don't work, because all our data is run-time. Most of our parameters are still of type `any`. We need to explicitly specify types everywhere that are either `any`, or they're not actually checked. I discovered recently that someone had accidentally created a type that was conceptually the duplicate of an existing type. One of those should never ever get used, but the code doesn't complain, because it's only encountering this in runtime.
So I'm inclined to agree: Typescript doesn't really add what it's supposed to add. It adds a lot of work, without providing the security we expect from it.
Or even without that, your data should be entering the system as type 'unknown'. There's then a validator function that takes in unknown and outputs the intended type.
From there onwards, integrity is guaranteed by typescript, but only if you have the discipline to use it consistently. Otherwise, yeah, don't bother.
Anyway, we're going back to simple JSON objects. Typescript is clearly not helping in our case, and the whole process with parsing all incoming objects is fairly cumbersome without adding much value.
I think it is well-known fact among programmers that a prototyping phase of 10kloc+ project requires types. Not for a formal proof, but to help programmers to understand their code better and faster at monday morning through a type error feedback. There is no reason to not use ts the same way there is no reason to not have a ruler and yesterday’s sketches in your toolbox.
Everyone may have their opinion, but this modern “media presence in software development” nonsense goes beyond all limits.
When I first started using TypeScript, I was surprised to find that it wouldn't compile code I absolutely knew was correct, or that it would allow "risky" code in some cases as the author says. The talk formalized the issues I faced using TypeScript by teaching me about soundness, completeness, and the trade-offs that are often taken between the two.
Generally, TypeScript has made my life a lot easier than the occasional trouble it's brought me.
Validation of this data was essential, the crunching was complicated, and we wanted to be able to make assumptions about the data through the type system to make the code simpler.
We found JSONSchema validation was a perfect fit for this purpose (via ajv). In all the overhead of maintaining JSONSchema files was much lower than we thought it would be, and it even exposed some bugs in our internal APIs that we patched up at the same time.
I do wish there was a nice way to generate that sort of validation code directly from a TypeScript interface though.
It is not a platform language. Thus just like any guest language brings its own tooling, idiomatic library wrappers around platform libraries, an additional code generation layer to debug, having to write FFI (or type declarations to platform libs).
Having said this, I do use TypeScript in the context of Angular or BabylonJS, but that is because those frameworks are the "platform".
Server side? Gimme Java, most of the time.
Anyways, it doesn't really matter that much given source line annotations. I wish TypeScript went with some more aggressive sugar so we could have nice things like operator overloading.
“io-ts introduces the concept of a runtime type (an instance of the Type class) which represents a runtime validator for a typescript (static) type. [2]”
See:
[1] https://gcanti.github.io/io-ts/
[2] https://lorefnon.tech/u2018/03/25/typescript-and-validations...
In your code, if someone throws a bad class into the mix, it will blow up both in Typescript and in Java/C# and in any other programming language. But, somehow, blowing up in Typescript is way worse that blowing up in Java/C#. Go and tell me that when I'm not allowed to put `nulls` anywhere neither in Java nor in C#, because that's something I can do in Typescript today.
Even if it's only a compile time check, and can therefore still be circumvented at runtime, this check for null values has still helped me out a lot. At least within a class it ensures my assumptions are consistent, which is not nothing.
The problem with receiving a wrong class is not intrinsic to any particular type system:
A *a = reinterpret_cast<A*> &a;
// have a nice gdb day
>Typescript doesn't really add what it's supposed to add.
Underspecified/force-casted types couldn’t help with these promises. It is like programming in C with a heavy preference to void pointers and va_lists.