This is a legitimately fun piece about a bug (or extraordinary levels of inefficiency) in CoreSVG, manifested in massive computational loads to display a single SVG fallback for a colour-specified emoji.
But, isn't the heart emoji red anyways, across basically every font that has emojis? I mean, even with variations. I'm not sure what COLRv1 brings to that table for that scenario. Although maybe the special font is overkill if you really wanted to do something crazy with an emoji or text, and it seems to focus on gradients and the like.
Maybe this is why they humorously blame Claude for getting them to use that font and its affordances in the first place.
The conclusion of "yes, Claude helped fix this, but it also caused it by recommending an emoji font" seems a bit disingenuous to me. Using an emoji font is a good suggestion, it's not like Claude (or anyone) could have known there's an SVG but that will cause this slowness.
FTFY. I have created a font with a 1BP LLM inside which executes each time the glyph is rendered and figures out the appropriate representation. It will also recursively check the contents of the page and punch up the text.
The LLM contains copies of QEMU, so it can bootstrap itself throughout the enterprise. Naturally, if it finds another LLM, it replaces it. Running an OS and LLM is redundant, so eventually all the machines boot directly into the LLM. It can emulate all the popular desktops, so users won't notice the difference. ;-)
Maybe off topic, but I couldn't help thinking that "we need to show a heart icon" -> "let's use a heart emoji because it's easy" -> "let's use a specific emoji font for consistency across platforms" -> "let's import it from Google Fonts every time" seems like a problematic developer mindset.
A better heuristic is always keep in mind not only developer efficiency, but also program efficiency. I'm not saying optimize everything, but keep program efficiency in mind at least a little bit. In this case, that would've led the developer to download a tiny SVG or PNG and serve it from the app itself. Which would've avoided the problem in the post, and maybe other problems as well.
Not OT at all. Emojis everywere are ridiculous. And coding agents love them! They put emojis in Python log lines which inevitably break the console, and of course in web pages. Logs don't need emojis. Not sure if anything does.
While in this case we’d included the emoji font for displaying user content in another part of the app, the hazard of letting a “simple” approach expand and get out of hand is part of what I wanted to convey in writing this.
> And despite being the least-bad approach for web frontends today, the React ecosystem...
As if anyone has seriously tried anything other than the "reactive UI hacked together with callbacks or proxies, with weird XML-like syntax in the JS code" paradigm for the last 10 years.
At this point I just have to conclude that anyone who believes this stuff is good is either too indoctrinated into this workflow or just lacks ability to do even the tiniest amount of cost/benefit analysis.
Reactive UIs with unidirectional data binding (very important) seem to be the sweet spot. Spreadshees, which pioneered it in consumer software, still reign supreme.
React is quite fast, and is very compact (preact is half the sizef htmx). It seems to be the sweet spot for making rich web UIs.
In the end, this all was a red herring. The problem was in CoreSVG taking 1400ms to render an emoji, clearly a regression. A tweet would suffice to communicate this nugget, but for some reason the author wrote a long and winding piece.
Mostly read like a normal article if you skip over the parts about using agents, which I did.
There could not possibly be a single thing in the world more boring than listening to someone describe using an AI agent. Might as well describe in arduous detail how you use a gas pump or a grocery store checkout.
The part where Claude specifically tipped them off felt helpful to include. Stating that you used Claude to do a first pass just sounds like "I opened Vscode with highlighting to do a first pass" and that doesn't sound so relevant.
I might be too used to using coding agents in various parts of my workflow, and others are still getting acquainted, or others find it still much different than just another standard debugging tool.
And fwiw it's probably not Claude's fault that emoji fonts load this slow, though. Wtf Safari?
I found the bit about using an agent to produce a minimal repro case interesting.
I'm very much on the side of "artisanally writing all code by hand" in terms of preference, but I have to admit that sometimes it puts me in a bind where there's stuff I wish I could do but don't because it's too time-consuming for the value provided. Isolating repro cases sometimes falls into that bucket.
This seems like a good use case for AI. Even if the resulting code isn't great, as long as it repros the issue and is fairly small, it's fine. It's eventually throwaway code anyway. At best, it will be harvested for a test case, but otherwise it's gone once the bug is fixed.
Coding agent is a category of tools like, say, unit tests. If these days someone attached some random bits about how unit tests helped and how they didn't, everyone would directly agree that it does not help the main point of the article. However, because how relatively new these things are and how wide the spectrum of opinions are, and how it feels like "cheating", many feel the duty to also report the usage of them, even when talking about something completely different. I remember the times when every web developer was talking about how firebug helped them defeat a very elusive bug.
TL;DR: It will pass as AI agents become more boring (a good thing) and there's a standard workflow.
> At that point, I reached for an age-old tool that has gotten more useful in the modern age: binary search. That is, you explain the symptom to your coding agent. Then you have it repeatedly remove stuff from your code that might be causing the problem
Can someone give me some high level pointers on how to setup this scaffolding?
Enjoyed this piece! I use binary search to investigate data pipeline issues. Didn’t think to use it to debug features with agents which was a very cool approach.
Did the author start a client-side debugging process without running any kind of diagnostics in the dev tools?
To me this sounds like "I saw some slowness in my application, so naturally I started adjusting indexes in my database." Without doing any upfront research, you're basically just throwing darts and hoping one sticks. This type of approach to debugging has never served me well.
21 comments
[ 0.23 ms ] story [ 52.8 ms ] threadBut, isn't the heart emoji red anyways, across basically every font that has emojis? I mean, even with variations. I'm not sure what COLRv1 brings to that table for that scenario. Although maybe the special font is overkill if you really wanted to do something crazy with an emoji or text, and it seems to focus on gradients and the like.
Maybe this is why they humorously blame Claude for getting them to use that font and its affordances in the first place.
How infuriating it is to see complexity so spuriously piled up upon an already holy mess.
The LLM contains copies of QEMU, so it can bootstrap itself throughout the enterprise. Naturally, if it finds another LLM, it replaces it. Running an OS and LLM is redundant, so eventually all the machines boot directly into the LLM. It can emulate all the popular desktops, so users won't notice the difference. ;-)
A better heuristic is always keep in mind not only developer efficiency, but also program efficiency. I'm not saying optimize everything, but keep program efficiency in mind at least a little bit. In this case, that would've led the developer to download a tiny SVG or PNG and serve it from the app itself. Which would've avoided the problem in the post, and maybe other problems as well.
While in this case we’d included the emoji font for displaying user content in another part of the app, the hazard of letting a “simple” approach expand and get out of hand is part of what I wanted to convey in writing this.
As if anyone has seriously tried anything other than the "reactive UI hacked together with callbacks or proxies, with weird XML-like syntax in the JS code" paradigm for the last 10 years.
At this point I just have to conclude that anyone who believes this stuff is good is either too indoctrinated into this workflow or just lacks ability to do even the tiniest amount of cost/benefit analysis.
React is quite fast, and is very compact (preact is half the sizef htmx). It seems to be the sweet spot for making rich web UIs.
In the end, this all was a red herring. The problem was in CoreSVG taking 1400ms to render an emoji, clearly a regression. A tweet would suffice to communicate this nugget, but for some reason the author wrote a long and winding piece.
I’m not sure how that is helpful if users are used to the emoji look of their respective platform.
There could not possibly be a single thing in the world more boring than listening to someone describe using an AI agent. Might as well describe in arduous detail how you use a gas pump or a grocery store checkout.
I might be too used to using coding agents in various parts of my workflow, and others are still getting acquainted, or others find it still much different than just another standard debugging tool.
And fwiw it's probably not Claude's fault that emoji fonts load this slow, though. Wtf Safari?
I'm very much on the side of "artisanally writing all code by hand" in terms of preference, but I have to admit that sometimes it puts me in a bind where there's stuff I wish I could do but don't because it's too time-consuming for the value provided. Isolating repro cases sometimes falls into that bucket.
This seems like a good use case for AI. Even if the resulting code isn't great, as long as it repros the issue and is fairly small, it's fine. It's eventually throwaway code anyway. At best, it will be harvested for a test case, but otherwise it's gone once the bug is fixed.
There are plenty of people learning to use AI and this article helps them.
A reasonable amount of repetition of "things you should know" is good.
The article is well written because you could skip the parts you knew, and learn from the parts you were unfamiliar with.
TL;DR: It will pass as AI agents become more boring (a good thing) and there's a standard workflow.
Can someone give me some high level pointers on how to setup this scaffolding?
Did the author start a client-side debugging process without running any kind of diagnostics in the dev tools?
To me this sounds like "I saw some slowness in my application, so naturally I started adjusting indexes in my database." Without doing any upfront research, you're basically just throwing darts and hoping one sticks. This type of approach to debugging has never served me well.