xdomain vendoring

[shinenelson]

we're fetching xdmomain from https://unpkg.com in proxy.html ( at least for the production website ).

we also have an outdated version of xdomain vendored in vendor/xdomain. I understand that this was probably done for working offline

questions :

1. do we really need to keep the outdated vendoring? if yes, then why not just use it for the main website as well? that'd be one third-party request ( and cookie ) lesser when loading the katas online ( apart from https://cdn.jsdelivr.net, https://cdnjs.cloudflare.com and https://ajaxorg.github.io that are being called from https://tddbin.com anyway ). also, if yes, we need to update the vendored script.

2. if we decided to stick with the script being fetched from a CDN, then can we please change the CDN from unpkg to cloudflare or JSDelivr?

the argument here is to reduce the number of third-parties being called from the root domain.

aside : I'll open another issue at tddbin-frontend to unify all the library loading to a single provider.

---

next, coming to the usage of the vendored script itself.

like I mentioned earlier, I understand that the vendoring was done to work offline. however, when I looked at build-for-offline.sh, it has been outdated for at least 8 months now because the script src domain in proxy.html was changed from https://cdn.rawgit.com to https://unpkg.com but not in the script. so now, the question is, do we need the offline build capability at all? I know that's a dumb question ( because Wolfram seems to say that quite a lot in a different places ;) ). I'm going to assume the answer is yes, but its just that the script was just missed to be updated.

---

for context, the reason I'm asking these questions is because I'm trying to optimize the build scripts ( and in turn the CI system as well ) and I'd like to know what capabilities to maintain support and spend time on. It would be useless to spend time to extend the functionality so a feature that is seldom used.

[wolframkriesing]

i think all the xdomain stuff is caused by gh pages not having cors, which if it had, would allow to remove all the xdomain stuff, iirc ... but i didnt think about that lately.