This is a great way to organise code snippets—listed by use case, and searchable too!
Next time you’re stuck on some DOM scripting, before reaching for a framework or library, check here first.
It was a few years before I realized that worry stones had a name, that they were borrowed from cultures other and older than mine. Heck, it’s been more than a few years since I’ve even held one. But in the last few weeks, before and after launching the redesign, I’ve kept working away at this website, much as I’d distractedly run my fingers over a smooth, flat stone.
This surprises me. But forewarned is forearmed.
The minimum dependency for a web site should be an internet connection and the ability to parse HTML.
In my experience, 99% of the time Web Performance boils down to two problems:
- “You wrote too much JavaScript.”
- “You have unoptimized images.”
But as Dave points out, the real issue is this:
I find that Web Performance isn’t particularly difficult once you understand the levers you can pull; reduce kilobytes, reduce requests, unblock rendering, defer scripts. But maintaining performance that’s a different story entirely…
This is a great walkthough of making a common form pattern accessible. No complex code here: some HTML is all that’s needed.
Now that all modern browsers support SVG favicons, here’s how to turn any emoji into a favicon.svg:
<svg xmlns="http://w3.org/2000/svg" viewBox="0 0 100 100"> <text y=".9em" font-size="90"> 💩 </text> </svg>Useful for quick apps when you can’t be bothered to design a favicon!
I have to admit, I don’t think I even knew of the existence of the playsinline attribute on the video element. Here, Chris runs through all the attributes you can put in there.
I’m constantly forgetting the difference between the async attribute and the defer attribute on script elements—this is a handy explanation.
CSS only truly exists in a browser. As soon as we start writing CSS outside of the browser, we rely on guesses and memorization and an intimate understanding of the rules. A text editor will never be able to provide as much information as a browser can.
CSS is frustrating because you have to actually think of a website like a website and not an app. That mental model is what everyone finds so viscerally upsetting. And so engineers do what feels best to them; they try to make websites work like apps, like desktop software designed in the early naughts. Something that can be controlled.
This is very open and honest. Thank you for writing it, Zell.
This is a great step-by-step explanation of event handling in JavaScript!
A cute walkthrough for flexbox and grid.
I can see this coming in very handy at Codebar—pop any CSS selector in here and get a plain English explanation of what it’s doing.
Garrett’s observation is spot-on here:
I’ve been trying to understand the appeal of these frameworks by giving them an objective chance. I’ve expanded my knowledge of JavaScript and tried to give them the benefit of the doubt. They do have their places, but the only explanation I can come up with is that developers are taking a similar approach as Ruby and focusing on developer convenience and productivity. Only, instead of Ruby’s performance being tied to the CPU level, JavaScript frameworks push the performance burden to the client.
In both cases, the tradeoff happens in the name of developer happiness and productivity, but the strategies have entirely different consequences. With Ruby, the CPU is still (mostly) the responsibility of the development team, and it can be upgraded. With JavaScript, the page weight becomes an externality pushed onto visitors.
Well, this is a grim collection from Dave:
There are some cases where even using plain ol’ HTML causes accessibility problems. I get frustrated and want to quit web development whenever I read about these types of issues. Because if browsers can’t get this right, what hope is there for the rest of us.
It’s worth clicking through each link he lists—the situation is often much more nuanced than simply “Don’t use X.”
Some solid research here. Turns out that using input type=”text” inputmode=”numeric” pattern="[0-9]*" is probably a better bet than using input type="number".
Why do people respect JavaScript or other languages enough to learn them inside-out, and yet constantly dunk on CSS?
The headline begs the question, but Robin makes this very insightful observation in the article itself:
I reckon the biggest issue that engineers face — and the reason why they find it all so dang frustrating — is that CSS forces you to face the webishness of the web. Things require fallbacks. You need to take different devices into consideration, and all the different ways of seeing a website: mobile, desktop, no mouse, no keyboard, etc. Sure, you have to deal with that when writing JavaScript, too, but it’s easier to ignore. You can’t ignore your the layout of your site being completely broken on a phone.
How and when did I get to the point where I would consider a page weight of 4 MB on a large page and 500 KB on a small page normal?
This isn’t just a well-earned rant from Manuel. I mean, it *is that, but it’s also packed with practical performance advice.