> if your application was freezing for 78 seconds waiting for a screen redraw

78 seconds was the compile time. The runtimes were almost identical: 0.45 seconds to run the entire test suite in the fastest case vs 1.3 in the slowest.

The slowest is three times slower than the fastest! That’s not almost identical at all, and could easily be the difference between a useable interface and an unbearable one...

It could be. And when I have evidence that user experience is affected, I'll care about the difference. But what if it's 1ms vs 3ms? Or 3ms vs 9ms? And the 9ms time is a much more expressive, productive, high-level language?

I'm not going to care about the difference just because "omg one number is 3x another number!?!"

For an soft realtime application like game that’s the difference between 10fps and 30fps. Or 30 and 90. Basically total failure or success.

I was referring to response time in a GUI app -- 9ms is undetectable.

Again, if you have a reason the speed matters, then it matters. The specific numbers here are not relevant to my argument, which boils down to: being "slow", in and of itself, is meaningless.

0.45 vs 1.3 is mentioned as being almost irrelevant in the article - from article: “Another interesting observation is that it makes no difference what hardware you use to run it. If the solution is fast, it’ll be fast on a notebook as well as on a beefed-up workstation-class desktop. Sure, it might be twice or thrice slower, but it’ll be a difference between 10ms and 30ms.”

All up the article starts with reasonable discussion about how different solutions can have more than 6 orders of magnitude time difference, then it segues irrelevantly to a complaint about electron.