I found this article pretty interesting because ultimately it didn't cover a lot of ground, but instead examined the ground with a microscope. From the title, I was expecting it to be some really complex system youtube was using—and an even more complex attempt to r/e—but really it was mostly intuitive solutions. YET with that being said it was a really enjoyable read because of how in depth everything was covered. I think this article presents a very strong teaching tool, as the best lessons are taught with a strong motivating example to ground in. Kudos to the author. Reminds me a bit of Josh Comeau though arguably better in some regards.
Not sure whether such "criticism" is welcome here, since it is ultimately subjective, but I will just be blunt and say: I disagree.
I like this style of writing as well, but I think this article overdoes it, to the point that it became somewhat irritating to read.
The part where I particularly feel this way is when the author spends two whole paragraphs discussing why YouTube (or its developers) chose to sample by "100" segments, to the extent that the author even asks, "If you work at YouTube and know the answer, please let me know. I am genuinely curious." Which, for lack of better words, I found ridiculous.
> Not sure whether such "criticism" is welcome here, since it is ultimately subjective, but I will just be blunt and say: I disagree.
If this was my post I'd certainly appreciate criticism.
> but I think this article overdoes it
Perhaps its overdone in places, to your credit the question about if 100 was an arbitrary number was a bit much. But, as a counterpoint, I found the related pondering of "might it make sense to have variable time duration windows" to be interesting. The interpolation YouTube ultimately selected is deceiving and variable density could be a way to mitigate that.
There's definitely a healthy balance and perhaps the author teeters on the verbose end, but I mostly just wanted to voice that I was surprised about the type of article it was, but not in an unpleasant way.
You are likely right that I over-rotated on the "storytelling" aspect there. My curiosity about the "100 segments" stemmed from wondering if there was a deeper statistical reason for that specific granularity (e.g., optimal binning relative to average video length) versus it just being a "nice round number."
That said, I can see how dedicating two paragraphs to it felt like over-dramatizing a constant. I will try to tighten the pacing on the next one. Thanks for reading despite the irritation!
It’s often surprising how "intuitive" or elegant solutions can seem once you peel back the layers, isn't it? That simplicity is part of the beauty of good engineering!
I actually wasn't familiar with Josh Comeau’s work before this, but I just looked him up and... wow. To be mentioned in the same breath (let alone "arguably better") is a massive compliment. I’ll definitely be diving into his archives now.
I mean Josh's site is undeniably more visually polished as a merit to him. His site is definitely more SEO optimized, by covering a technical topic generally instead of multiple topics surrounding a single problem. But the aforementioned SEO strategy is to the detriment of the enjoyability, at least for me. If I was seeking documentation, I'd be happy to see Josh's work, but for entertainment I wouldn't read that but I would read this.
I really appreciate that you found it entertaining; that was the main goal! Same here, I'll take "fun to read" over "SEO optimized" any day of the week.
Great article! I've always wondered how youtube implemented it. Love the interactive canvases too. But maybe it's just me, the canvases look blurry?
Rendering bezier curves on the client side seems reasonable. Calculating ~400 points and rendering 100 curves would not impact performance, but I wonder if these little interactions would impact performance if added up.
Re: Blurry canvases: You are spotting the classic HTML5 Canvas high-DPI issue. It happens because the canvas backing store pixels don't map 1:1 to CSS pixels on high-density displays (like Retina screens). I likely need to scale the canvas drawing context by window.devicePixelRatio to fix that sharpness. Good catch.
EDIT: Made the change.
Re: Performance: That is an interesting thought. Since the calculation only triggers when you visit (or resize) the video player, there is definitely a CPU spike. My guess is they chose this approach to have a "plug and play" rendering logic that adapts perfectly to the client's specific device width and pixel density, rather than generating thousands of static image variations on the server.
Re: Gangnam Style: Ah, Google+! That explains why I couldn't find the original source. Thanks for the correction.
EDIT: Added the correction.
Makes me want to write an extension to fix this annoying YouTube bug that's been around since Windows 10 came out:
https://issues.chromium.org/issues/40853564
(while Microsoft has filed it as a bug in Chromium, I hazard it is actually just a bug in the way YouTube handles events on their text fields)
> Documenting it, however, was a marathon that spanned many weeks of focused work.
I like how detailed they were in their writing (even though I was suspecting the graph function to be the culprit all along) ! Big Kudos though to get to the ground of it and writing it all down for others to learn ! Also, indeed this would make a great template for LLM problem-decomposition / solving.
Is this an invented bit of humor ... or an existing usage applied to the prevalence of rounded corners we see (once again) in User Interfaces of today?
(The original term has nothing to do with web design or UI per se)
Edit: i see the article goes on to explain the term in context.
But I feel the sharp corners versus round corners is a design/fad cycle that will keep repeating.
We will see sharp corners once again in vogue within the next decade if not sooner.
It will start small with one or two players wanting to distinguish their offering from the crowd, and one of them seeing success, and others copying them slowly at first and then it catches on.
It was definitely a bit of invented humor! I wanted a sticky way to describe that universal drift toward "friendliness" and safety in modern UI.
You are spot on about the cycle, though. I suspect that once everything is perfectly round and polished, the only way to stand out will be to go sharp again.
I found this article pretty interesting because ultimately it didn't cover a lot of ground, but instead examined the ground with a microscope. From the title, I was expecting it to be some really complex system youtube was using—and an even more complex attempt to r/e—but really it was mostly intuitive solutions. YET with that being said it was a really enjoyable read because of how in depth everything was covered. I think this article presents a very strong teaching tool, as the best lessons are taught with a strong motivating example to ground in. Kudos to the author. Reminds me a bit of Josh Comeau though arguably better in some regards.
Not sure whether such "criticism" is welcome here, since it is ultimately subjective, but I will just be blunt and say: I disagree.
I like this style of writing as well, but I think this article overdoes it, to the point that it became somewhat irritating to read.
The part where I particularly feel this way is when the author spends two whole paragraphs discussing why YouTube (or its developers) chose to sample by "100" segments, to the extent that the author even asks, "If you work at YouTube and know the answer, please let me know. I am genuinely curious." Which, for lack of better words, I found ridiculous.
> Not sure whether such "criticism" is welcome here, since it is ultimately subjective, but I will just be blunt and say: I disagree.
If this was my post I'd certainly appreciate criticism.
> but I think this article overdoes it
Perhaps its overdone in places, to your credit the question about if 100 was an arbitrary number was a bit much. But, as a counterpoint, I found the related pondering of "might it make sense to have variable time duration windows" to be interesting. The interpolation YouTube ultimately selected is deceiving and variable density could be a way to mitigate that.
There's definitely a healthy balance and perhaps the author teeters on the verbose end, but I mostly just wanted to voice that I was surprised about the type of article it was, but not in an unpleasant way.
Criticism is definitely welcome!
You are likely right that I over-rotated on the "storytelling" aspect there. My curiosity about the "100 segments" stemmed from wondering if there was a deeper statistical reason for that specific granularity (e.g., optimal binning relative to average video length) versus it just being a "nice round number."
That said, I can see how dedicating two paragraphs to it felt like over-dramatizing a constant. I will try to tighten the pacing on the next one. Thanks for reading despite the irritation!
Thank you for reading and for the kind words!
It’s often surprising how "intuitive" or elegant solutions can seem once you peel back the layers, isn't it? That simplicity is part of the beauty of good engineering!
I actually wasn't familiar with Josh Comeau’s work before this, but I just looked him up and... wow. To be mentioned in the same breath (let alone "arguably better") is a massive compliment. I’ll definitely be diving into his archives now.
I mean Josh's site is undeniably more visually polished as a merit to him. His site is definitely more SEO optimized, by covering a technical topic generally instead of multiple topics surrounding a single problem. But the aforementioned SEO strategy is to the detriment of the enjoyability, at least for me. If I was seeking documentation, I'd be happy to see Josh's work, but for entertainment I wouldn't read that but I would read this.
I really appreciate that you found it entertaining; that was the main goal! Same here, I'll take "fun to read" over "SEO optimized" any day of the week.
Great article! I've always wondered how youtube implemented it. Love the interactive canvases too. But maybe it's just me, the canvases look blurry?
Rendering bezier curves on the client side seems reasonable. Calculating ~400 points and rendering 100 curves would not impact performance, but I wonder if these little interactions would impact performance if added up.
About YouTube's comment about Gangnam Style, it wasn't a tweet. You can't find the original post because it was google+, which is dead. Google said it was a joke shortly afterwards: https://www.cnet.com/tech/services-and-software/gangnam-styl...
Thanks for reading and for the kind words!
Re: Blurry canvases: You are spotting the classic HTML5 Canvas high-DPI issue. It happens because the canvas backing store pixels don't map 1:1 to CSS pixels on high-density displays (like Retina screens). I likely need to scale the canvas drawing context by window.devicePixelRatio to fix that sharpness. Good catch. EDIT: Made the change.
Re: Performance: That is an interesting thought. Since the calculation only triggers when you visit (or resize) the video player, there is definitely a CPU spike. My guess is they chose this approach to have a "plug and play" rendering logic that adapts perfectly to the client's specific device width and pixel density, rather than generating thousands of static image variations on the server.
Re: Gangnam Style: Ah, Google+! That explains why I couldn't find the original source. Thanks for the correction. EDIT: Added the correction.
So it's a histogram of 100 bars, forced into a spline in SVG to make it look like it has more detail than it does.
That's the big picture idea.
I knew that polynomial curve fitting results in overshoots like that, but didn't think that splines had that problem.
Splines are polynomials after all. Also, not every spline has this problem. The one YouTube is using is Cardinal spline.
Makes me want to write an extension to fix this annoying YouTube bug that's been around since Windows 10 came out:
https://issues.chromium.org/issues/40853564 (while Microsoft has filed it as a bug in Chromium, I hazard it is actually just a bug in the way YouTube handles events on their text fields)
> Documenting it, however, was a marathon that spanned many weeks of focused work.
I like how detailed they were in their writing (even though I was suspecting the graph function to be the culprit all along) ! Big Kudos though to get to the ground of it and writing it all down for others to learn ! Also, indeed this would make a great template for LLM problem-decomposition / solving.
Glad you liked it. I’m just doing my part to ensure our future AI overlords have high-quality training data.
Congratulations: from a simple intuition about something that many wouldn’t have noticed, you wrote a beautiful article.
Means a lot, thanks! I am a huge fan of the phrase "the devil is in the details."
> We are living in the era of the “Bouba” effect.
Is this an invented bit of humor ... or an existing usage applied to the prevalence of rounded corners we see (once again) in User Interfaces of today?
(The original term has nothing to do with web design or UI per se)
https://en.wikipedia.org/wiki/Bouba/kiki_effect
Edit: i see the article goes on to explain the term in context.
But I feel the sharp corners versus round corners is a design/fad cycle that will keep repeating.
We will see sharp corners once again in vogue within the next decade if not sooner.
It will start small with one or two players wanting to distinguish their offering from the crowd, and one of them seeing success, and others copying them slowly at first and then it catches on.
It was definitely a bit of invented humor! I wanted a sticky way to describe that universal drift toward "friendliness" and safety in modern UI.
You are spot on about the cycle, though. I suspect that once everything is perfectly round and polished, the only way to stand out will be to go sharp again.
Cool write up; thank you!
You're welcome. Glad you liked it!