move assets into this repo

[Rich-Harris]

Edit: the original issue is now fixed because we're not using cross-origin isolation everywhere anymore, but there's still a valuable discussion to be had about where assets should live.

I think it makes sense for assets used in blog posts and the like to be in this repo:

• they're sensibly colocated (colocating stuff sensibly is 90% of making a codebase maintainable)
• they become part of the build, which means they get immutable URLs, and in theory we could optimise stuff
• fewer moving parts, less stuff to keep track of
• less friction involved in adding assets
• when something is no longer used, we can confidently delete it

The only real counter-argument I've heard is 'but the assets will be part of this repo forever because git remembers everything', to which my response is... so? It's not like we're talking terabytes. It only really affects cloning, and a) you don't do that very often, b) bandwidth is plentiful, c) if it's not, git clone --depth 1 is a thing.

[benmccann]

There was another blog post where I noticed a dead video and it was because it was being loaded from youtube-nocookie.com or something like that and that entire site was down

[Conduitry]

This one isn't loaded from YouTube, it's a hosted MP4 - https://svelte-technology-assets.surge.sh/just-write-css.mp4

Side note - surge.sh?? Woah.

[benmccann]

The video on the homepage also has also never worked for me on the omnisite

[Conduitry]

Does it work for you now? That video works for me as of #207.

[benmccann]

Oh thanks. Yeah, the homepage video works for me now

[Rich-Harris]

@Conduitry does your (reasonable) opposition to storing large assets in git repos extend to this repo?

[dummdidumm]

We can just pull this into the assets repo and it will work (the other videos pulled in from there do work). That surge.sh thing is missing a "allow cross origin" header AFAICT. What is even on there? I've never seen it before.

[Conduitry]

If we can just serve this from GitHub Pages like we are the other assets, that sounds ideal, yeah.

I have slightly less, but not non-existent, reservations about checking large assets into this repository.

[Rich-Harris]

It wouldn't be GitHub Pages, it'd be part of the deployment itself. One of the reasons this would be a welcome change is that we could e.g. colocate assets with blog posts, so that a) we don't have another 'wtf is this surge thing?', b) we get nice hashed URLs, and c) it would eliminate a class of cross-origin isolation headaches

[Conduitry]

What Simon was saying, I think, is that GitHub pages is already sending the appropriate HTTP headers. See, for example, the Svelte Origins clip on the homepage, which is being served from GitHub Pages. I believe we just need to copy the video from Surge to the assets repo, point to it there, and we'd be good to go.

The main thing that's making me so hesitant about making the change you propose is that you can't undo it. You're stuck with them forever. See: the classical music MP3s that everyone downloads every time they clone the Svelte repo. Serving these from GitHub pages seems to be working fine.

[Rich-Harris]

Is Git LFS an option? The colocation and hashed URL benefits aren't nothing

[benmccann]

www.youtube-nocookie.com seems to be back up now, so the videos in the blog posts are working for me now. Not sure if it's just because I was on starlink earlier and maybe it's blocked there or if it was a temporary outage

[benmccann]

I've never used Git LFS before. Would that mean anyone wanting to work on this repo would need to install Git LFS? (if it's even a separate thing to be installed as I assume it is). That might be enough of a headache that I'd want to avoid it

[dummdidumm]

Assets are rare yet big enough that I prefer keeping the separate GitHub repo approach, i.e. copy this mp3 into the assets repo and be done with it.
Is there anything else on that surge deployment? It seems like some ancient artifact from ages ago?

[Rich-Harris]

That's exactly the problem — I have absolutely no idea! This is why colocation is so valuable