3 ms·

If you only use JS to collect statistics you are only collecting statistics about JS users. And that is not everyone. And I'm not just talking about weird nerds

If you only use JS to collect statistics you are only collecting statistics about JS users. And that is not everyone. And I'm not just talking about weird nerds like myself that intentionally disable it but also the underserved billions of the world without the latest year's smartphone. It's a fatal flaw in pretty much all modern web stats collection that makes it seem like JS and bleeding edge JS support are far more of the pie than they are. And any time it's brought up those same people say it's not worth actually collecting information about all hits, say, via the webserver logs, because it's small. But they never connect the dots...

bhouston 3y ago
> you are only collecting statistics about JS users. And that is not everyone. Okay. I can assume that anyone who has JS disabled, and I know how to detect that in the iframe, as also not having WebGPU available. Because WebGPU is exclusively JS and if JS is disabled, it effectively disables WebGPU. I'll add that.
- danielheath 3y ago
  Users with an older smartphone on a slow connection could fail to run the script even if it's not disabled, if it's a separate network request.
  - bhouston 3y ago
    > Users with an older smartphone on a slow connection could fail to run the script even if it's not disabled, if it's a separate network request. Hmm... technically correct, but I wonder if this is statistically relevant? Remember that I am currently collecting 30K browser samples per day. I'd have to miss 300 samples in a day this way for it to cause an error of 1%.
    - superkuh 3y ago
      From what kind of sites? The kind that know and care about WebGPU support enough to include your iframe? That's some heavy selection bias if my assumption is true. Not a lot of low end smart phones visiting the kind of person that runs that kind of site.
      - bhouston 3y ago
        I list the "supporters" of https://web3dsurvey.com https://web3dsurvey.com prominently on the homepage.
        superkuh 3y ago
        That's what I figured. So that supports the idea that it's only measuring a very skewed set of visitors from Webgl, JS, and gfx designer type sites. I'd put the iframe on my very non-JS, non-webgl, non-gfx sites to skew the other way but I don't put JS scripts on sites.
  - arp242 3y ago
    But then it wouldn't report anything, and assuming those cases are roughly representative for cases where it does work, it doesn't really skew the results.
CJefferson 3y ago
What do you mean by "the underserved billions of the world without the latest year's smartphone"? Sure, there is a small set of people who choose not to run JS, or use something like lynx that doesn't support it, but almost every browser version released in the last 20 years, certainly all the graphical ones, have by default good enough JS support to gather basic statistics and send them back to the server.
- superkuh 3y ago
  Look at collector.js, in the first dozen characters it's already using ECMAScript 6 standards like promises. At the very least you need to change that "last 20 years" to the last 5 years.
  - reissbaker 3y ago
    Promises have been supported since 2014 in both Chrome for Android and Safari on iOS. Even pretty old phones generally run web browsers more recent than that — and that's not "the last five years," that's nearly twice as long.
    - superkuh 3y ago
      If you are going by the dates that Google and Apple browsers supported it for the first time. But if you tried to use ECMAScript 6 features back in 2014? Hah! The support would not be there. 5 years is a realistic number.
      - reissbaker 3y ago
        You argued that using these features today blocked "billions" of people using old smartphones. Promises have been supported by smartphone browsers for over nine years. I do not think that using promises today prevents anywhere near billions of people from running your code, nor do I think that "5 years is a realistic number" for a feature that has been supported for 9. We're discussing whether using promises today impacts a significant number of web users.

bhouston 3y ago

> you are only collecting statistics about JS users. And that is not everyone. Okay. I can assume that anyone who has JS disabled, and I know how to detect that in the iframe, as also not having WebGPU available. Because WebGPU is exclusively JS and if JS is disabled, it effectively disables WebGPU. I'll add that.

danielheath 3y ago
Users with an older smartphone on a slow connection could fail to run the script even if it's not disabled, if it's a separate network request.
- bhouston 3y ago
  > Users with an older smartphone on a slow connection could fail to run the script even if it's not disabled, if it's a separate network request. Hmm... technically correct, but I wonder if this is statistically relevant? Remember that I am currently collecting 30K browser samples per day. I'd have to miss 300 samples in a day this way for it to cause an error of 1%.
  - superkuh 3y ago
    From what kind of sites? The kind that know and care about WebGPU support enough to include your iframe? That's some heavy selection bias if my assumption is true. Not a lot of low end smart phones visiting the kind of person that runs that kind of site.
    - bhouston 3y ago
      I list the "supporters" of https://web3dsurvey.com https://web3dsurvey.com prominently on the homepage.
      - superkuh 3y ago
        That's what I figured. So that supports the idea that it's only measuring a very skewed set of visitors from Webgl, JS, and gfx designer type sites. I'd put the iframe on my very non-JS, non-webgl, non-gfx sites to skew the other way but I don't put JS scripts on sites.
- arp242 3y ago
  But then it wouldn't report anything, and assuming those cases are roughly representative for cases where it does work, it doesn't really skew the results.

CJefferson 3y ago

What do you mean by "the underserved billions of the world without the latest year's smartphone"? Sure, there is a small set of people who choose not to run JS, or use something like lynx that doesn't support it, but almost every browser version released in the last 20 years, certainly all the graphical ones, have by default good enough JS support to gather basic statistics and send them back to the server.

superkuh 3y ago
Look at collector.js, in the first dozen characters it's already using ECMAScript 6 standards like promises. At the very least you need to change that "last 20 years" to the last 5 years.
- reissbaker 3y ago
  Promises have been supported since 2014 in both Chrome for Android and Safari on iOS. Even pretty old phones generally run web browsers more recent than that — and that's not "the last five years," that's nearly twice as long.
  - superkuh 3y ago
    If you are going by the dates that Google and Apple browsers supported it for the first time. But if you tried to use ECMAScript 6 features back in 2014? Hah! The support would not be there. 5 years is a realistic number.
    - reissbaker 3y ago
      You argued that using these features today blocked "billions" of people using old smartphones. Promises have been supported by smartphone browsers for over nine years. I do not think that using promises today prevents anywhere near billions of people from running your code, nor do I think that "5 years is a realistic number" for a feature that has been supported for 9. We're discussing whether using promises today impacts a significant number of web users.