13 ms·

Contents property itself is not a private API. Quality of docs I can't speak to, but it's a different issue than private API (which is stuff that's not in the p

by om2 7y ago

Contents property itself is not a private API. Quality of docs I can't speak to, but it's a different issue than private API (which is stuff that's not in the public SDK).

lern_too_spel 7y ago
The second link has private APIs, and the header file to access those private APIs still exists in WebKit for MacOS. I mentioned both undocumented and private. The first link just shows that if you are Apple, you can correctly call APIs that provide a performance increase on MacOS. Because of that, my recommendation is to just stop using MacOS if you care about browser performance.
- saagarjha 7y ago
  > The second link has private APIs Private APIs which were used back in 10.4 when NSAppKitVersionNumberWithDeferredWindowDisplaySupport (documented here https://developer.apple.com/documentation/appkit/nsappkitversionnumberwithdeferredwindowdisplaysupport https://developer.apple.com/documentation/appkit/nsappkitver...) was not available. > the header file to access those private APIs still exists in WebKit for MacOS The most these headers can do is maybe help with rendering performance, of which I'm not completely certain that there are still APIs that Safari uses that other browsers don't. I cannot see how benchmark scores from e.g. JavaScriptCore would be affected. > Because of that, my recommendation is to just stop using MacOS if you care about browser performance. Your point doesn't logically follow.
  - lern_too_spel 7y ago
    > Private APIs which were used back in 10.4 when NSAppKitVersionNumberWithDeferredWindowDisplaySupport (documented here https://developer.apple.com/documentation/appkit/nsappkitver... https://developer.apple.com/documentation/appkit/nsappkitver...) was not available. And private APIs that still aren't available, as I noted in the second section you responded to. > The most these headers can do is maybe help with rendering performance Exactly. Everything I referenced was about rendering performance. I never claimed otherwise, so don't derail the argument by strawmanning JavaScriptCore vs. V8 on MacOS. > Your point doesn't logically follow. If you want the most speed, you want to use a platform that gives everyone access to APIs that enable it. QED.

by om2 7y ago

Contents property itself is not a private API. Quality of docs I can't speak to, but it's a different issue than private API (which is stuff that's not in the public SDK).

lern_too_spel 7y ago

The second link has private APIs, and the header file to access those private APIs still exists in WebKit for MacOS. I mentioned both undocumented and private. The first link just shows that if you are Apple, you can correctly call APIs that provide a performance increase on MacOS. Because of that, my recommendation is to just stop using MacOS if you care about browser performance.

saagarjha 7y ago
> The second link has private APIs Private APIs which were used back in 10.4 when NSAppKitVersionNumberWithDeferredWindowDisplaySupport (documented here https://developer.apple.com/documentation/appkit/nsappkitversionnumberwithdeferredwindowdisplaysupport https://developer.apple.com/documentation/appkit/nsappkitver...) was not available. > the header file to access those private APIs still exists in WebKit for MacOS The most these headers can do is maybe help with rendering performance, of which I'm not completely certain that there are still APIs that Safari uses that other browsers don't. I cannot see how benchmark scores from e.g. JavaScriptCore would be affected. > Because of that, my recommendation is to just stop using MacOS if you care about browser performance. Your point doesn't logically follow.
- lern_too_spel 7y ago
  > Private APIs which were used back in 10.4 when NSAppKitVersionNumberWithDeferredWindowDisplaySupport (documented here https://developer.apple.com/documentation/appkit/nsappkitver... https://developer.apple.com/documentation/appkit/nsappkitver...) was not available. And private APIs that still aren't available, as I noted in the second section you responded to. > The most these headers can do is maybe help with rendering performance Exactly. Everything I referenced was about rendering performance. I never claimed otherwise, so don't derail the argument by strawmanning JavaScriptCore vs. V8 on MacOS. > Your point doesn't logically follow. If you want the most speed, you want to use a platform that gives everyone access to APIs that enable it. QED.