3 ms·

It's 200KB minified, 60KB gzipped, so not quite that bad but still quite large. It definitely does more than you'd expect from the documentation on a page like

It's 200KB minified, 60KB gzipped, so not quite that bad but still quite large. It definitely does more than you'd expect from the documentation on a page like https://developers.facebook.com/docs/plugins/like-button https://developers.facebook.com/docs/plugins/like-button, and then there's all the other stuff I noted in OP like it including a ton of polyfills and legacy code. An example feature the SDK gives you is the ability to subscribe to an event that's triggered once the user successfully adds a Like, there's all kinds of extra stuff like that buried in there that you wouldn't expect when you just want to add a Like button.

derefr 9y ago
> subscribe to an event that's triggered once the user successfully adds a Like A.K.A. the "like this page in order to enable the download link below" API. I wish they'd never made it; it has so many evil use-cases and I can't think of a single non-evil one (that wouldn't be better served by just async querying aggregate data.)
- eknkc 9y ago
  I don't think that you can easily check if the user already liked your page so that approach would not work.
  - derefr 9y ago
    Right, that was my point—if only an async+aggregate-statistical API for likes to a page was exposed, you wouldn't be able to implement [accurate] like-gating in terms of that (i.e. you wouldn't be able to be Evil), but you'd still be able to do most other things people use the like-button API for, like showing current number of likes (i.e. not Evil).
- ssttoo 9y ago
  This "likegating" is against the terms of use
ssttoo 9y ago
There's a certain amount of legacy code, because the SDK supports old browsers. Therefore it needs polyfills. And it cannot rely on, say `if ('JSON' in window){}` because there are buggy polyfill implementations out there. So the SDK needs to bring its own polyfills. Additionally it cannot just do `Array.prototype.map = ...` because fiddling with the host page's globals is a sin. Hence every post-ES3 method call is wrapped in a local `ES()` function. Oh the joys of third-party javascripting :)

derefr 9y ago

> subscribe to an event that's triggered once the user successfully adds a Like A.K.A. the "like this page in order to enable the download link below" API. I wish they'd never made it; it has so many evil use-cases and I can't think of a single non-evil one (that wouldn't be better served by just async querying aggregate data.)

eknkc 9y ago
I don't think that you can easily check if the user already liked your page so that approach would not work.
- derefr 9y ago
  Right, that was my point—if only an async+aggregate-statistical API for likes to a page was exposed, you wouldn't be able to implement [accurate] like-gating in terms of that (i.e. you wouldn't be able to be Evil), but you'd still be able to do most other things people use the like-button API for, like showing current number of likes (i.e. not Evil).
ssttoo 9y ago
This "likegating" is against the terms of use

ssttoo 9y ago

There's a certain amount of legacy code, because the SDK supports old browsers. Therefore it needs polyfills. And it cannot rely on, say `if ('JSON' in window){}` because there are buggy polyfill implementations out there. So the SDK needs to bring its own polyfills. Additionally it cannot just do `Array.prototype.map = ...` because fiddling with the host page's globals is a sin. Hence every post-ES3 method call is wrapped in a local `ES()` function. Oh the joys of third-party javascripting :)