Hacker News Reader

Comment by rcme | Hacker News Reader

What kind of pitfalls are you talking about?

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.

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.

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.

>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

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.

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.

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.

Reply on news.ycombinator.com