Am I understanding this right - in order to make ‘accurate’ placeholder content, it preloads the actual content, then uses that to guide the appearance of the placeholder content, that it shows while you’re waiting for your actual content to load…
This is cool but I'm confused - it says it generates the bones at "build time" not at "runtime." But you're calling this headless bone generator while your app is running, right? That sounds like runtime.
Seems interesting, but I wonder how this would be better than just asking an LLM to implement the skeletons?
For most components, current generation models should be able to understand the component code and produce skeletons that occupies exactly the same space
I don't like skeletons that much but it's really creative to have the headless browser inspect your running dev env and capture element size & placement snapshots.
I was going to say it seems potentially useful, but engagement stats for this on Github and X seem unnatural and the anon crypto author makes it a hard no for me
18 comments
> every skeleton screen you've ever hand-coded is a waste of time
> you're literally measuring padding and guessing widths to build a worse version of a layout that already exists in your DOM
> so I made a package that just reads the real one
Linked from the readme.
Was this an April fools joke?
For most components, current generation models should be able to understand the component code and produce skeletons that occupies exactly the same space
https://boneyard.vercel.app/how-it-works