3 ms·

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 app

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 3y ago
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 3y ago
  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 3y ago
  >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 3y ago
    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.
rpearl 3y ago
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.
quest88 3y ago
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.

hn_throwaway_99 3y ago

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 3y ago
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 3y ago
>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 3y ago
  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.

rpearl 3y ago

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.

quest88 3y ago

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.