Yesterday, in a fit of inspiration, I decided to add a live feed of Google I/O to the dev.to home page.
I would love this platform to be the destination for discovery and discussion of what is going on, even more so than it currently is, and this was an experiment of sorts. Because the design of the site was friendly to this kind of addition, it was basically just a matter of adding a YouTube embed to the home page and making use of our existing feature toggling infrastructure to manage it.
Thought it'd be fun to show the #IO17 keynote on the https://t.co/E4yHRJkeOg home page. From idea to launch in 5 mins. Coding is fun 😊 pic.twitter.com/lsilQMCqGV
— Ben Halpern (@bendhalpern) May 17, 2017
But it's never that simple
The site became janky. Jank is when the browser's frame rate drops below the accepted threshold of about 60fps and things get glitchy weird. The browser's framerate, and other tools used to debug this sort of stuff can be found in Chrome's dev tools. Other browsers have similar setups.
The jank, as is often the case, was brought by the addition of weighty embeds like the YouTube player. There's not a whole lot we can do about that, besides complain.
Google: Please make light, jank-free websites that load quickly.
— The Practical Dev (@thepracticaldev ) April 2, 2017
Also Google: Use our super janky Youtube tags, ads, and tracking scripts. pic.twitter.com/ZnFv3wcVKs
But this page became very janky. So it had to be more than just the YouTube embed. If I add a YouTube player to a plain old HTML page, the jank will be minimal. There had to be more.
So that's when I first opened my dev tools. The window's side panel opened up and I went to work.
But the jank was gone
That's right. When I opened up my dev tools, the problem went away. How could this be? The browser is in a different state when that panel is open, depending on what you have running within the tools. So I poked around and tried to find the answer. I could not.
What the hell?
I toggled some settings, changed some stuff around, and simply could not get to the bottom of it–But then I figured it out! It wasn't that the dev tools had fixed the problem, it was another variable: The slimmer window size brought on by the opening of the side panel had fixed the problem. When the window was smaller, there was no jank.
But why?
At first I thought something on the sidebar column of the page must be causing jankiness. When the sidebar goes away, things get better. But this was not the case. Then I thought it might have to do with some super inefficient CSS that only applies to certain media queries. That got me closer. The breaking point for jank was 850px. That is effectively when the page's layout changes between the slim look and the "desktop" look.
Looking at how the CSS varied between the different media queries, I could not eyeball what would possibly be causing so much jank. It was clear using the "Border Layers" dev tool, that there was a significant difference in how the browser was handling the rendering. Over 850px, the browser was working way harder whenever I scrolled.
So I did what any professional software engineer does when faced with this kind of uncertainty.
No book or teacher can beat good old fashion poking around. pic.twitter.com/4JjAYA6p8G
— The Practical Dev (@thepracticaldev ) April 13, 2016
I toggled lines of CSS on and off until something happened. I'd run about ten cycles of toggle-then-check with no results.
And then it happened
border-radius: 3px;
That was the line. Commenting it out fixed all my problems. Rounded fucking corners. The main "articles list" area of the home page had a 3px border radius in the desktop view. Smaller than 850px, the list just takes up the whole screen, with no rounded corners.
This is not my first rodeo. I actually knew that border radius and box shadow and some other seemingly innocent CSS attributes can cause jank in certain scenarios, but I didn't think one element with rounded corners could cause these kinds of problems in practice.
One 👠Element 👠With 👠Rounded 👠Corners
Try telling a designer they can't use rounded corners because it will cause the page to be basically unusable. Try having that conversation. I've had those kind of conversations. They are not easy to have because some of the browser's rules are so counterintuitive. Sometimes I can recalculate 1000 values per second and render complicated visuals, and sometimes I can't use fucking rounded corners.
We can put a man on the moon but we can't effectively add rounded corners to a div 😓 pic.twitter.com/AJHq83QgYT
— The Practical Dev (@thepracticaldev ) May 18, 2017
I found it ironic that this experience came about by trying to show a live stream of Google engineers and executives getting on stage and talking about the future of insane artificial intelligence, amazing new browser features, and all-in-all extolling the amazingness of the web, while I'm sitting here trying to render rounded-fucking-corners.
But this post isn't about why we cannot have nice things, it's about learning and doing better. It is true, we can't have nice things, but there are definitely some takeaways.
🔑 Hire folks with T-shaped skills
It's scenarios like this that make me want to hire and work with people with T-shaped skillsets. That is, they have their specialty, but they have a breadth of understanding as well. In this case, if I were working with a designer, I would hope they have a basic understanding of how browsers deal with certain issues with rendering and how it's kind of counterintuitive and treated differently on different browsers. They don't need to know every detail, but designers who throw things over the wall are very unhelpful in this scenario.
T-Shaped Skills
Likewise, engineers who don't respect the needs of designers are equally unhelpful. It's easy to veto a designer's decision instead of working with them to reach a compromise. In my case, I was both roles and I had to have this discussion with myself. It wasn't a very long discussion. I got rid of the rounded corners and I actually like it better this way.
🔑 Know your tools and use them
My other takeaway is that it pays to know your tools and use your tools early. I've faced situations in the past where I acted dumbfounded and allowed a problem to persist simply because I didn't really know how to deal with it. Having earned more experience with these tools, I was able to deal with this much sooner. And by dealing with the problem when it came up instead of thinking it was "good enough for now," it was easier to fix when it was all still in my head.
🔑 Coding is fun
My last takeaway is that coding is fun. I am glad I had the chance to take this chance and ship this feature on a whim. You can't always do that, but I am very glad my team trusts me to do things like this. I think we will learn a lot by trying out this idea of what the platform could be used for.
Happy coding â¤ï¸
Top comments (0)