[jamra]

I've been looking into TypeScript recently, but after having clicked on this article, I'm thinking that I'll stick with ES6.

Being able to have code completion in javascript is nice, but it's also something that you can work around by developing a good work regiment using browser-based debugging tools. The benefit of typescript is substantial, but circumventable. The drawback, one that I haven't seen anyone mention yet, is now having to deal with generics inside javascript. Trying to reason about this code and spending most of my cognitive focus on how the author is dealing with generics adds an entirely different complexity to reading and understanding javascript.

On one hand, it's helpful to have types. On the other, adding a very Microsofty overhead to programming using meta-data on your data and generics inside javascript makes me want to pass on this.

[smt88]

Reasoning about generics in TypeScript isn't bad. I'm not totally sure what you meant by that. I just rewrote an API in TypeScript for Node, and I didn't spend most of my time reasoning about meta-anything. TypeScript mostly added amazing, insightful static analysis, and when I ran my code, it almost always worked perfectly at runtime. The debugger in VSCode is great, too!

[spion]

I think its a common meme that started because of the complexity of C++ templates and continues to be perpetuated by the creators (and moreso, users) of Go as an excuse to not implement generics.

Unlike C++ templates, generics in TypeScript are really simple - I'd estimate it would only take a week to get used to them.

[jamra]

I have some experience with C++'s templates, but I'm more comfortable with Generics in C# which I believe are done correctly. I view the code I saw as closer to C#'s approach to generics so I'm not sure your assumption is correct in my case.

I just don't want the extra mental overhead of writing and reading generic parameters whereas I never had to do that with javascript. I really enjoyed the concept of having types for my javascript objects, but am getting frightened at the concept of decreased readability due to generics.

[spion]

I honestly dont see the overhead.

Its impossible to have any sort of typed functional programming without generics. Even the most basic of functions, map, has a type:

  declare function map<T,U>(a:Array<T>, f: (T) => U):Array<U>

Just like functions are parameterised by their arguments, generics are types parameterised by (type) variables. They don't have to be any more complex than that. Whats the mental overhead there?

[mreiland]

C# generics are not the same creature as C++ templates. It isn't a matter of done correctly or incorrectly, it's apples and oranges.

[jamra]

Yes I know. I've done both. Typescript's syntax appears more like C#'s generics.

My issue is that I would like types for when I get data from the server, but I don't really want to deal with casting window to "any".

I personally went through the pains of learning javascript and have come out on the other side comfortable with its dynamic types. I really like the idea of compile time error checking, but I'm not sure I would stand for adding the complexity of generics.

The change in my workflow is not very difficult. For example, when I'm using plain old javascript, I use documentation to find out how to use third party libraries and DOM manipulations. Though it works out for all of my needs, I wouldn't mind adding types. Adding types on top of that would reduce casting and spelling mistakes, but it's not like I can't open up the browser and test my code with a step through debugger. I would personally prefer opening the browser and maintaining readability in my code versus having type safety in my code and giving up readability.

[spion]

I almost forgot: generic type variables are used very little outside of generic libraries. We have a 20KLOC codebase which doesn't use type variables at all and has only a single in-house written dependency [1] that declares functions with type variables.

note: This is about declaring generics, not using them. You'll still have to write Array<string> and Promise<MyType>, thats true. But its hardly any different from ArrayOfString or PromiseOfMyType in terms of readability.

If I may be so bold, I'd really encourage you to give it a spin. You just might find that your fears about readability are exaggerated.

[1]: https://github.com/doxout/promise-observer

[kuschku]

It depends – if you write a library, using typescript is extremely helpful.

If you just want to write a site while using a bunch of libraries, it might be useful to use VSCode, which provides autocomplete for normal JS code, as long as at least parts of the code have typescript bindings.