The pic above is representation of skeleton screen on youtube.com when opened in browser
Placeholder with same dimension or colors as actual content, which will get replaced it keep user engaged rather having a blank screen that suddenly fills or spinners.
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.
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…
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
No examples, no mention of why someone would want this, site is broken on mobile.
Hm... A Twitter comment is not documentation, but:
> 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.
I've never personally seen a skeleton screen. I don't know why anyone would need this, and struggling to think of what problems are solved by them.
You may have seen.
https://i.postimg.cc/qqCYtL6V/Screenshot-2026-04-08-134800.j...
The pic above is representation of skeleton screen on youtube.com when opened in browser
Placeholder with same dimension or colors as actual content, which will get replaced it keep user engaged rather having a blank screen that suddenly fills or spinners.
Ahhh okay, have never seen it called that before. Thanks!
Thanks, I had not heard this term before.
Been working on websites on and off since 1999
But it has animated logo (that you have to click on to start) and chart of GitHub stars progression in time!
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.
I have no idea what this means, and I don't think I'm alone. Make a video dammit.
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 do this often, and they do! Yours is the same question I had.
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.
Their doc linked at the bottom actually has a pretty nice example.
https://boneyard.vercel.app/how-it-works
Appreciate this! For anyone looking for examples of skeletons it generates, you can visit their doc
I love seeing things that support Svelte.
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…
Was this an April fools joke?
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