Update targetjs

[wasfi2]

• Renamed from targetj to targetjs to align with naming conventions for JavaScript libraries
• Updated the framework to the latest version

I also appreciate the new changes in the framework: it runs faster and the results are more consistent.

[krausest]

I'm afraid targetjs is causing issues for my duration measurement logic:

The duration for clear row was measured as 1.5 msecs, whereas all other frameworks are > 8.6 msecs. The benchmark drivers measures the time from the start of the click event to the commit paint event. But targetjs appears to invoke the logic for clearing the rows in the pointerup event. And the click event happens after pointerup and thus doesn't include the clear logic.

Is there a chance that you could move your event handling to the click event?
Otherwise I'd have to adapt the benchmark driver (but to be honest I'm not sure whether mousedown/pointerdown would be a better start point. Some frameworks seem to have a somewhat random delay between those and the click start event.)

[wasfi2]

You are correct that targetjs uses the pointerup event rather than the click event but it seems from the screenshot that you attached that the click event is invoked right after the pointerup event and it is measured less than 1 millisecond. Is that correct?
Wouldn't this issue affect all the other tests as well? Also, just to clarify, are you referring to removing all rows rather than just one row?

[krausest]

Yes. The duration as currently calculated is something like 1,7 msecs:

But it would be correct to compute 12,2 msecs:

I noticed that targetjs is incredibly fast in the clear all rows benchmark. But yes, this might affect all benchmarks.

[wasfi2]

I think you are correct that the script portion isn't being accounted for. For example, in vanillajs test 7, I have the following results:
total: [399.8,396.6,394,379.4,395,395.7,393.6,393,391.6,397.5,402.4,399.1,393.5,382.7,393.7]
script: [25.9,26.7,26.3,26.3,27,26,26.3,26.1,25.8,25.9,26.3,26.1,26.8,26.2,26.3]
paint: [365.4,361.4,359.3,344.7,359.6,361.2,359,358.6,357.3,363.2,365.3,364.5,358.2,348.1,359]

while in targetjs test 7, the results are:
total: [384.9,383.8,378.8,377.6,387.1,379.5,373.6,377,374.9,382,375.5,377.9,375.5,374.2,374.6]
script: [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
paint: [376.3,375.5,370.1,369.4,378.6,371.1,365.3,368,366.3,373.4,367.1,369.5,367,365.7,366.2]

This is applicable in all the tests that the script portion is not included. Is targetjs the only framework that is creating this issue? is that something that you can do? Such as measuring it from the moment your test script triggers the click event, rather than relying on the browser to measure the click event time?

The average script execution time for VanillaJS on my machine across all tests is as follows:
test 1: 2.2
test 2: 4.88666
test 3: 0.72
test 4: 0.42
test 5: 0.32
test 6: 0.49333
test 7: 26.26666
test 8: 2.20666
test 9: 10.55333

so definitely significant in almost all the tests

[krausest]

Yes, I believe targetjs is currently the only framework (I think some time ago somebody put the logic explicitly in mousedown, which could be changed easily).
I ran a check over the traces that measures the duration between mousedown and click and reports if the duration is longer the 3 msecs.
targetjs stands out as taking often longer than the 3 msecs (but some runs are fast enough to evade detection !)

There are some spurious events like for lit:

or angular:

Selection starts with mousedown event, it's so tiny you can't see it in the trace and goes to click event. If I just changed the logic to compute from mousedown to the end of paint I'd add some random 3 msecs. It really seems to me that the framework has no chance to influence that delay and thus it'd only increase variance.

What I could do is offer two ways to measure and put an info in the package.json which to choose: Something like "js-framework-benchmark.startEvent = mousedown".

I suppose there's no way to change the event you're listening to in the benchmark implementation code?

[krausest]

I implemented it that way. I'll continue with the chrome 132 run and if it looks good I'll commit that change. So you can keep your code as is.

But I'm afraid intermediate results don't look that good for targetjs now:

But it seems plausible:

This trace for create rows was 49.81 msecs and thus an average of 49.4 sounds plausible.

[wasfi2]

The results look bad actually. I wasn't aware that the script time wasn't included in the calculation, but it makes sense now that I’ve measured it manually. When are you planning to publish the updated results? I know you're managing a lot of frameworks. I’d like to improve the framework and submit a new solution, but it will take me a few days. What options do I have?

[krausest]

I'm currently preparing the chrome 132 run and plan to release it the next few days. I could move targetjs to the broken_frameworks folder (yes, I know it's a misnomer in this case) or I could just delete it from git and you can submit a new PR. What would you prefer?

[wasfi2]

Let's delete it, please. Could TargetJS be added to Chrome 132's results after they are published, or would we have to wait until Chrome 133 is released?

[krausest]

Thanks, I'll do.
I can add it to the unofficial results before chrome 133. Chrome 132 results are frozen once they're published.

[wasfi2]

Thank you! I'll work on the improvements in the meantime - definitely appreciate your flexibility and the effort you put into creating the framework.