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

[dummdidumm]

To me that's more of an argument how valuable it is to properly document stuff The assets repo is pretty well understood by now

[Rich-Harris]

It might be well understood, but it's certainly not desirable. If you were designing the system without constraints, you would choose colocation, you would never choose 'have a separate repo and rely on institutional knowledge plus people finding the place where we decided to document it'. Documentation is a last resort, to be employed when you've failed to make something sufficiently self-explanatory.

Putting things in external repos has a real cost, beyond the cognitive overhead — stuff we put there can never be removed even when it's no longer required (e.g. we decide to swap out the images on the homepage), because it's impossible to know what depends on it. And it's friction that discourages us from adding new assets (video embeds in blog posts, diagrams in documentation and so on).

To me it seems very clear that the assets belong in this repo. The only question is whether the technical barriers to putting them where they belong are larger than the costs of not doing so. If we don't want LFS, then in a world with git clone --depth 1 how big a problem is it to have no-longer-used assets in the history?

[dummdidumm]

It's not just no-longer-used, if we switch up the ordering (and we have done so a lot the past weeks) then we'll pay the cost aswell, wouldn't we? There's a clear path towards making this work quickly, and that's putting it in the assets repo. I would prefer that for now (and the future, too, TBH)

[Rich-Harris]

if we switch up the ordering (and we have done so a lot the past weeks) then we'll pay the cost aswell, wouldn't we?

No, why would we? If you git mv a file (whether explicitly, or because you moved a file within the repo and git noticed that it's a move rather than a delete+create, which it invariably will in the case of assets) only the move is recorded

[Rich-Harris]

Since the original issue is fixed I've repurposes this as a place to discuss moving assets into this repo — see top comment