Love Josh's work and usually always learn something new from his tutorials.
However, this time, I was really hoping the example implementations would use CSS transforms instead of properties that require repaints, especially since the rationale given here for using sprites is performance.
Maybe layer compositing warrants its own article and is beyond the scope here, but you can really tell when whoever built a frontend knows their stuff because all animations are hitting a consistent 60fps.
I think animation was the less common use case. Sprites were a nice way to get multiple images in a single HTTP request. Latency on dialup was murder and getting more in a single round trip was better. If you have a bunch of similarly-sized elements stick them all in a single file and use CSS to make multiple references to the same file display different images.
Additionally, the file size of the sprite sheet image is often smaller than the combined file sizes of the individual images. (I never looked into why but expect it has to do with sharing overhead and the compression dictionary)
Yeah. If your images have similarity at all, being in the same compression container helps a bit; and there is some per file overhead, smallest PNG is reportedly 67 bytes, plus http overhead, and maybe you're serving one request per http connection (but hopefully not for images) . If you're feeling really optimizy, you can probably shuffle the order of the sprites and get bigger or smaller sprite sheets. But then you also need to consider the impact on your css when you shift the sprite sheet around, I don't think that would be big, but it might be.
Josh, I was reading, and then a little man slid in from the left side, blocking the text I was reading, and said "Hey, friend! Would you like to subscribe to the newsletter?" I believe the site used CSS animation-timing-function:ease-in-out. My intuition told me that the slide was completely wrong for the situation.
First, the most important signal that any animation provides is this: the computer is doing this for you. This goes in the negative too: if you click and drag a file icon, the drag sprite may be translucent or highlighted somehow, but it should not 'animate' to your mouse cursor. The file icon should be attached to the cursor location with no delay.
However, suppose you drop it somewhere it can't go. The interface should then animate the file back to where it belongs; that's the computer 'putting it back'. Now, the timing function; how should the file go back? Slowly back away from the cursor? Accelerate to the return location, then slow back down again? No, it should very quickly snap away from the cursor, then settle where it belongs. You'll notice things like this as part of fit and finish; they are communication.
The man coming from the left eased in and then slowly stopped. This is profoundly wrong, like a person sneaking out of a dark place, then slowly coming to rest in front of you staring into your eyes, it is very much threat behavior. You want the person to come in a friendly way, so he can sell you something or convince you to smash the subscribe button. The correct animation is to simply appear halfway in, far enough you can see his smile; stop for 0.5s, indicating he is occupying the space; then slowly ease-in-ease-out the rest of the way.
Then the speech bubble should fade in, indicating that the computer is talking, and you as the user must act, like when a dialog says "Save your work now. I take your laptop away in 30 seconds. Look in my eyes, I am the user now."
I built 8bitsmith.com as a tool to make controlled sprite sheets.
It was an experiment in vibe-coding and controlled asset creation, so pricing is basically a pass-through cost of using Gemini.
I remember Microsoft Front Page had a feature about doing buttons with image sprites and it spitted a ton of JS gibberish.
I don't think the example of the trophy in the article is a good use case this days, you could draw that trophy as a SVG and animate the flames with GSAP or something, or draw each flame frame as a <symbol> and animate that with CSS.
I love Josh's blog and writing. I have to wonder what place this kind of content has in an age where agents are writing all the CSS. It sort of feels like hand tool woodworking now - there are people that will still get a kick out of designing things themselves, but it's going to be much less common. Maybe it already was like that anyway.
LLM are actually really bad at writing CSS. CSS is 20% logic and 80% art. The machines just don't understand what is attractive and what is ugly. I hand write all of my CSS and I don't see that changing any time soon.
I had this opinion recently until I started using the Figma MCP with Claude to import my live app into Figma Make, get it to edit things where it actually understands layout and margins and what looks good, and then pull it back into the app with MCP. I was shocked at how good it works. Sure, Claude sucks at CSS, but Figma nails it even for the worst designed pages.
Love Josh's work and usually always learn something new from his tutorials.
However, this time, I was really hoping the example implementations would use CSS transforms instead of properties that require repaints, especially since the rationale given here for using sprites is performance.
Maybe layer compositing warrants its own article and is beyond the scope here, but you can really tell when whoever built a frontend knows their stuff because all animations are hitting a consistent 60fps.
I think animation was the less common use case. Sprites were a nice way to get multiple images in a single HTTP request. Latency on dialup was murder and getting more in a single round trip was better. If you have a bunch of similarly-sized elements stick them all in a single file and use CSS to make multiple references to the same file display different images.
Additionally, the file size of the sprite sheet image is often smaller than the combined file sizes of the individual images. (I never looked into why but expect it has to do with sharing overhead and the compression dictionary)
Yeah. If your images have similarity at all, being in the same compression container helps a bit; and there is some per file overhead, smallest PNG is reportedly 67 bytes, plus http overhead, and maybe you're serving one request per http connection (but hopefully not for images) . If you're feeling really optimizy, you can probably shuffle the order of the sprites and get bigger or smaller sprite sheets. But then you also need to consider the impact on your css when you shift the sprite sheet around, I don't think that would be big, but it might be.
Josh, I was reading, and then a little man slid in from the left side, blocking the text I was reading, and said "Hey, friend! Would you like to subscribe to the newsletter?" I believe the site used CSS animation-timing-function:ease-in-out. My intuition told me that the slide was completely wrong for the situation.
First, the most important signal that any animation provides is this: the computer is doing this for you. This goes in the negative too: if you click and drag a file icon, the drag sprite may be translucent or highlighted somehow, but it should not 'animate' to your mouse cursor. The file icon should be attached to the cursor location with no delay.
However, suppose you drop it somewhere it can't go. The interface should then animate the file back to where it belongs; that's the computer 'putting it back'. Now, the timing function; how should the file go back? Slowly back away from the cursor? Accelerate to the return location, then slow back down again? No, it should very quickly snap away from the cursor, then settle where it belongs. You'll notice things like this as part of fit and finish; they are communication.
The man coming from the left eased in and then slowly stopped. This is profoundly wrong, like a person sneaking out of a dark place, then slowly coming to rest in front of you staring into your eyes, it is very much threat behavior. You want the person to come in a friendly way, so he can sell you something or convince you to smash the subscribe button. The correct animation is to simply appear halfway in, far enough you can see his smile; stop for 0.5s, indicating he is occupying the space; then slowly ease-in-ease-out the rest of the way.
Then the speech bubble should fade in, indicating that the computer is talking, and you as the user must act, like when a dialog says "Save your work now. I take your laptop away in 30 seconds. Look in my eyes, I am the user now."
I built 8bitsmith.com as a tool to make controlled sprite sheets. It was an experiment in vibe-coding and controlled asset creation, so pricing is basically a pass-through cost of using Gemini.
I remember Microsoft Front Page had a feature about doing buttons with image sprites and it spitted a ton of JS gibberish.
I don't think the example of the trophy in the article is a good use case this days, you could draw that trophy as a SVG and animate the flames with GSAP or something, or draw each flame frame as a <symbol> and animate that with CSS.
I love Josh's blog and writing. I have to wonder what place this kind of content has in an age where agents are writing all the CSS. It sort of feels like hand tool woodworking now - there are people that will still get a kick out of designing things themselves, but it's going to be much less common. Maybe it already was like that anyway.
LLM are actually really bad at writing CSS. CSS is 20% logic and 80% art. The machines just don't understand what is attractive and what is ugly. I hand write all of my CSS and I don't see that changing any time soon.
I had this opinion recently until I started using the Figma MCP with Claude to import my live app into Figma Make, get it to edit things where it actually understands layout and margins and what looks good, and then pull it back into the app with MCP. I was shocked at how good it works. Sure, Claude sucks at CSS, but Figma nails it even for the worst designed pages.
I don't understand why this is downvoted. But then, I don't really understand HN moderation at all.