[Zamicol]

We are (unfortunately) already doing just JSDoc.

Typescript migration was on our road map, but when we dug into it, it didn't solve the biggest issue we had with Javascript, which forces the developer to be aware of various pitfalls. Because of that, we didn't feel that TypeScript solved enough of JavaScript's faults to warrant a migration.

I still think that TypeScript is great and has some of the best tooling I've had the pleasure of working with, but in our case we didn't feel that the added complexity was worth the trade off. JSDoc is "good enough", even though we've run into bugs with it on VS Code.

[rcme]

What kind of pitfalls are you talking about?

[Zamicol]

Digs through some of my Javascript Twitter rants

The latest I ran into, `Object.keys(x).length` appears to recalculate length on every call. There doesn't appear to be a fast (and idiomatic) way to get top level object size in Javascript without using a secondary incrementor.

[hn_throwaway_99]

This seems like a very odd example in many ways:

1. How on Earth would you expect a type validation library to assist with this example?

2. Looking at that example, I would expect that of course it would need to do work on every call. That is, Object.keys(x) is a function call that takes an object and returns a newly constructed array. So I'm not exactly sure what you would expect to be optimized here. I guess what you are saying is that there is no native `sizeof` operator for Objects, but this doesn't seem like some crazy decision.

[Spivak]

I think the argument is that JSDoc already gives them type validation. If you're going to go the effort of porting to a completely different language and add a compilation step that new language better provide some benefits beyond types like papering over warts like Kotlin does.

[Zamicol]

>type validation library to assist with this example?

We don't, thus "[TypeScript] didn't solve the biggest issue[s] we had with Javascript".

Also just noticed that I used the singular "issue", I meant the plural "issues", as there are many.

If I had an option to use an alternative to JavaScript, I would in a heart beat. But it's not practical to not use Javascript

[hn_throwaway_99]

I am honestly curious what issues you hit with JavaScript that you find difficult for developers to avoid. I do think JS has a lot of weirdness and pitfalls, but I feel like the things you are actually ever reasonably likely to hit are easy to enumerate and learn:

1. Understanding truthy/falsey

2. The difference between null and undefined (but this is an area where Typescript helps).

3. == vs ===, but this one feels pretty easy to avoid, e.g. just set up eslint to forbid == if so desired.

4. Understand the details of how JS treats 'this' in different contexts. I think this (pun intended) is probably the most important thing to understand.

5. The bizarreness that typeof null === 'object'.

There are of course other issues, but I honestly feel like I rarely if ever hit them, and I've been coding in JS/Node for many years now. I mean everyone loves to point out some of the insane implicit casting rules of JS (e.g. the JSFuck language), but I don't ever hit those in my day-to-day.

I just feel Typescript plus some strongly opinionated eslint rules take 99% of the "gotchas" out of JS.

[quest88]

Of course it does. You're calling a static function that procudes an array. You want to use a Map and use its size property.

[rpearl]

If you've got enough keys that it matters you probably want to use a `Map` instead of an object? Maps are faster to write and read is approximately the same.