News for hackers. Stuff that matters.
Re:How V8 handles JavaScript properties internally by pier25 on Wednesday August 30, 2017 @08:16PM (#15137200)
I think the worst part about JS is not really performance but the language itself.

I wish I could just write that I'm expecting to receive a User object in a function without having to resort to TypeScript. It would make code so much more readable.

Re:How V8 handles JavaScript properties internally by ridiculous_fish on Thursday August 31, 2017 @02:13AM (#15138472)
JavaScript is fractally bad: you can find mistakes at every levels, as you zoom in or out.

On the zoomed-in scale we see things like tricky semantics for regexp or Math.round(), which major implementations still get wrong.

On the zoomed-out scale, we see things like property iteration order. This touches on array semantics and hidden classes. Why does v8 permit two objects to have the same properties but different hidden classes? Because JS requires that properties be enumerated in their definitional order - something no other language requires, and which puts serious constraints on implementations.

TypeScript can layer types on top, but can't make arrays sane or fix the other deep language issues.

Re:How V8 handles JavaScript properties internally by bzbarsky on Thursday August 31, 2017 @12:42PM (#15141576)
JS used to not require that iteration order match definition order. Iteration order was explicitly unspecified.

But initial implementations just stored properties in a flat list, so in practice all had iteration order matching definition order. And then websites were created depending on that behavior.

So now you had a spec saying "the order can be anything" but real-world compat constraints meant that in any implementation shipping in a web browser the order had to be definition order. At some point this compat constraint was simply documented in the spec, so there wouldn't be a gotcha lurking for a new implementation.

So it's hard to blame this problem on JS, really. It's more like Postel's Law (or a failure thereof, depending on who you're talking to, but I feel like in this case the output is the iteration order, and having it be fixed corresponds to being conservative in what you do. The pages that failed on different iteration orders correspond to _not_ being liberal in what you accept from others...

Re:How V8 handles JavaScript properties internally by pitaj on Thursday August 31, 2017 @11:51AM (#15141136)
Can you expand on your hatred of JS arrays? I don't understand how iteration semantics really affect anything with them since the spec gaurantees that numerical properties come first, in order, regardless.
Re:How V8 handles JavaScript properties internally by ridiculous_fish on Thursday August 31, 2017 @11:23PM (#15145877)
The biggest issue is precisely concerning the definition of "numerical properties". Here are some "numerical properties:"

    5
    -0
    "3"
    3.0
    4294967294
But these are not "numerical properties:"

    "-0"
    -1
    "3.0"
    4294967295
Which means that, when setting a property on an array, you must attempt to parse the object in a very peculiar way so that you can make a decision about iteration order, and whether to adjust the length property.
Re:How V8 handles JavaScript properties internally by pier25 on Thursday August 31, 2017 @11:14AM (#15140867)
> JavaScript is fractally bad

This made my morning. :)

I will quote you on this.