Chris makes the valid observation that JavaScript programmers who bemoan the “global scope” of CSS are handily forgetting that JavaScript also has global scope by default.
JS is also global by default. We use IIFEs and wrapper functions to add scope.
And for all this talk about CSS being global, you can actually scope styles when you need to. It’s more-or-less the same way you do it in JavaScript.
This is superbly in-depth and easy-to-follow article from Cassie—everything you need to know about motion paths in SVG and CSS! It’s worth reading just for the wonderful examples.
I feel my trajectory as a musician maps to the trajectory of the web industry. The web is still young. We’re all still figuring stuff out and we’re all eager to get better. In our eagerness to get better, we’re reaching for more complexity. More complex abstractions, build processes, and tools. Because who wants to be bored playing in 4/4 when you can be playing in 7/16?
I hope we in the web field will arrive at the same realization that I did as a musician: complexity is not synonymous with quality.
Can I get an “Amen!”?
This was a really fun podcast chat—nice and snappy at just 20 minutes.
A one-stop shop for all the metacrap you can put in the head of your HTML documents.
Lynn gives a step-by-step walkthrough of the latest amazing redesign of her website. There’s so much joy and craft in here, with real attention to detail—I love it!
This is such a great way to explain a technology! Chris talks through his thought process when using flexbox for layout.
A series of really nice CSS grid demos based on two-page magazine spreads.
Aaron outlines some sensible strategies for serving up images, including using the Cache API from your service worker script.
Supporting Internet Explorer 11 doesn’t mean you need to give it the same experience as a modern browser:
Making sure (some of) your code works in older browsers, does not mean all functionality has to work everywhere. But, mind you, ninety percent of web development means putting text and images in boxes.
And to be honest, there is no reason to not enable this everywhere. Same for form submissions. Make it boring. Make it solid. And sprinkle delight on it.
This is a fascinating way to present a code tutorial! It reminds of Tim’s Tutorial Markdown that I linked to a while back (which in turn reminds me of Bret Victor’s work).
I’m really enjoying this end-of-the-year round-up from people speaking their brains. It’s not over yet, but there’s already a lot of thoughtful stuff to read through.
There are optimistic hopeful thoughts from Sam and from Ire:
Only a few years ago, I would need a whole team of developers to accomplish what can now be done with just a few amazing tools.
And I like this zinger from Geoff:
HTML, CSS, and JavaScript: it’s still the best cocktail in town.
Then there are more cautious prognostications from Dave and from Robin:
The true beauty of web design is that you can pick up HTML, CSS, and the basics of JavaScript within a dedicated week or two. But over the past year, I’ve come to the conclusion that building a truly great website doesn’t require much skill and it certainly doesn’t require years to figure out how to perform the coding equivalent of a backflip.
What you need to build a great website is restraint.
A very handy web component from Paul—this works exactly like a regular YouTube embed, but is much more performant.
The fat JavaScript stacks-du-jour have a lot of appeal. They promise you to be able to do more with less. But what if I want to do less?
This is a terrific little (free!) online book all about modest JavaScript. The second part has practical code, but it’s the first part—all about the principles of staying lean—that really resonates with me.
Don’t build more JS than you can maintain over the long term. If you’re going to be building something for a long time, make sure what you are building will grow with you. Make sure you don’t depend on other people’s work too much, lest you want to keep refactoring your code when the framework you picked goes out of style.
Let us not overlook the fact that a semantic HTML web site is inherently accessible by default. When we bend the web to our will, we break that. So we have a responsibility to correct it. Sure the new technologies are neat, but the end result is usually garbage. This all requires some next-level narcissism that our goals and priorities as developers are far more important than that of the audience we’re theoretically building software to serve.
This chimes nicely with my recent post on third-party scripts. Here, Jeremy treats third-party JavaScript at technical debt and outlines some solutions to staying on top of it.
Convenience always has a price, and the web is wracked by our collective preference for it. JavaScript, in particular, is employed in a way that suggests a rapidly increasing tendency to outsource whatever it is that We (the first party) don’t want to do. At times, this is a necessary decision; it makes perfect financial and operational sense in many situations.
But make no mistake, third-party JavaScript is never cheap. It’s a devil’s bargain where vendors seduce you with solutions to your problem, yet conveniently fail to remind you that you have little to no control over the side effects that solution introduces.
This would be a fascinating experiment to run in Firefox nightly! This is in response to that post I wrote about third-party scripts.
(It’s fascinating to see how different this response is to the responses from people working at Google.)
Here are the slides from my opening keynote at Beyond Tellarrand on Thursday. They don’t make much sense out of context.
Thanks to the quick work of Marc and his team, the talk I gave at Beyond Tellerrand on Thursday was online within hours!
I’m really pleased with how this turned out. I wasn’t sure if anybody was going to be interested in the deep dive into history that I took for the first 15 or 20 minutes, but lots of people told me that they really enjoyed that part, so that makes me happy.
It’s time for a look at the state of the web when it comes to JavaScript usage. Here’s the report powered by data from HTTP Archive:
JavaScript is the most costly resource we send to browsers; having to be downloaded, parsed, compiled, and finally executed. Although browsers have significantly decreased the time it takes to parse and compile scripts, download and execution have become the most expensive stages when JavaScript is processed by a web page.
Sending smaller JavaScript bundles to the browser is the best way to reduce download times, and in turn improve page performance. But how much JavaScript do we really use?
When it comes to frameworks and UI libraries, there are some interesting numbers. Given the volume of chatter in the dev world, you’d be forgiven for thinking that React is used on the majority of websites today. The real number? 4.6% of websites. That’s less than the number of websites using CSS custom properties.
This is reminding me of what I wrote about dev perception.