We’ve gathered together a host of writers and front-end folk to tell you what they learned during this year into this 2020’s End of Year Thoughts. There’s so much to learn from in here (and there are lots more coming, stay tuned!).
Take this post from Matthias Ott where he argues that making a personal website is important and, also, fun!
On your personal website, you own your work. You decide what and when to publish. You decide when to delete things. You are in control. Your work, your rules, your freedom.
Your personal website is also a wonderful playground to tinker, prototype, experiment, explore, and learn about web standards and new technologies by experience. Want to improve your accessibility skills? Want to learn CSS Grid or try out variable fonts? Want to implement your first Service Worker or fine-tune the performance of your site? Your personal website is the perfect place for that!
Matthias has a few bits of advice if you don’t have personal website and want to know how to get started. My own bit of advice to add to this post is this: build it in public.
Start with just the HTML, then publish that; no fancy styles, no animations, no Big Thoughts about Things. Not even good type styles. Just get a small bio up and then maybe links to each post. From there each week you can build on top of those foundations, change things as you go.
A while back I remember reading about how Jonnie Hallman had taken this approach with his personal site; slowly documenting how he’s building things from the very beginning and shipping tiny improvements each week. It was inspiring but it was also somewhat of a relief for me when I started work on mine. No one could tell me what to do or how to do it, I didn’t have to get my work reviewed.
And I think that’s what I like about this post from Matthias because he believes that starting your own personal website is somewhat liberating. And I do, too.
Unconventional Stock Image Sources
Looking to make a beautiful website? Well, there might be no better place to start than with this collection of stock image sources that Mel Choyce has gathered together. There‘s a ton of great websites; from museums and national photography archives to public libraries with great batches of images for us to gawp over, remix, and use.
Mel writes:
Finding high-quality, totally free stock imagery can be a huge hassle. But I’ve found, with some creativity and some patience, there are far more options than I knew!
There’s so much great stuff in here that’s worth bookmarking for later.
The HTTP Archive’s Annual State of the Web Report
The folks over at the HTTP Archive looked at the data from over 7 million websites and collected their findings into their 2020 report. Somehow I missed the report last year but I’m so very glad I caught it this time around because I think there’s a ton of interesting information in here.
The report looks at how languages like HTML, CSS, and JavaScript were used across those sites and then all of that info is broken down further their findings on performance, security, and a host of other things. I particularly enjoyed reading about this breakdown of how fonts are used across all these websites:
npm ruin dev
This year Jeremy Keith built a website with nothing but HTML: no frameworks, no content generators, just plain ol’ hand-written markup. Gadzooks! In this post, he writes about how writing HTML is actually preferable to using the latest tool and gadget.
Jeremy writes:
The website isn’t very big, though it will grow with time. I had a think about what the build process for the site should be and after literally seconds of debate, I settled on a build process of none. Zero. Nada.
This turned out to be enormously liberating. It felt very hands-on to write the actual HTML and CSS that will be delivered to end users, without any mediation. I felt like I was getting my hands into the soil of the site.
His argument? Start with a boring baseline, and continuously build things from there.
Very Extremely Practical CSS Art
Miriam Suzanne writes about CSS art and how folks like Lynn Fisher and have been doing some extraordinary and fun work with nothing but CSS.
But how is it useful?
Well, says Miriam, we should learn all the tricks and techniques of making CSS art because that can help us in our day jobs from time to time, too. But also? Websites and web tech can be just…for fun? Miriam has this to say:
Any time CSS art starts getting attention, there is always someone around to say “that’s not practical” or “just use SVG” or something similarly dismissive and boring. It’s a terrible argument, even if it was true — no one is required to be Practical At All Times. What a terrible world that would be.
The Power of Web Development Outside Tech
I love this post by Jennifer Wong. It’s all about how we can apply our web development skills to make the world a better place. There are all sorts of contributions we can make:
Our skills are valuable to the essential work of political organizing. Tools for those working for social good and the betterment of society should be the best. We can help!
Late to Logical
See that illustration above? That’s a breakdown of logical CSS properties and they look like this:
p {
margin-block-start: 1em;
margin-block-end: 1em;
margin-inline-start: 0px;
margin-inline-end: 0px;
}With these styles we can now change our design based on the language of the user—many languages don’t read from left to right, like English—which is why this post from Adam Argyle all about logical properties is so darn interesting:
…a logical property is one that references a side, corner, or axis of the box model in context of the applicable language direction. It’s akin to referencing someone’s strong arm, rather than assuming it’s their right arm. “Right” is a physical arm reference, “strong” is a logical arm reference, contextual to the individual.
So we can now write styles relative to the user’s language! Oh and, on that note, Geoff Graham riffs on this whole point when he says that the CSS language itself is all about relativity. When you write something like this…
p {
font-size: 2em;
}…you’re connecting this line of code to wherever the font-size of the parent element is set to. That’s the power of CSS and also the thing about CSS that annoys folks the most, encouraging some to turn to CSS-in-JS solutions where they can control this relativity stuff.
Sponsor
DataStax Astra DBaaS
Start building modern data applications with simple APIs, using your favorite frameworks.
With Astra DBaaS you can deliver apps faster with any API. Get started with 5 GB free, then pay-as-you-use.
[Chris]: Let’s kick a couple of performance links around this week.
- Here’s a video from Stuart Langridge: “You Really Don’t Need All That JavaScript, I Promise” Stuart makes a lot of the points you likely think he is going to: JavaScript is slow, fragile, and there are lots of situations where uses don’t have it. The point, though, is that the whole web stack is “smarter than it used to be” and you can probably do what you want to do without, like, megabytes of JavaScript. Stuart even advocates for plenty of modern JavaScript solutions in the video. I would hope that the result of people finger-pointing at JavaScript like this is just to push the needle back the other way a bit and have people consider what they are doing when going all-in on front-end JavaScript. Maybe you can do less. Or maybe you’ll double-down and npm install like 10 things because somehow people questioning JavaScript is a personal affront to you (lol Twitter).
- Tim Kadlec: Effective Skeleton Screens. Skeleton screens are loading spinners. Only instead of spin, they show you a wireframe scaffold that mimics (if you’re lucky) about the shape of the content that is about to show up (if you’re lucky). If you’re going to do it, you should be 1) doing the research to know what users are needing and getting them that ASAP 2) don’t lie about what’s going to load in 3) show incremental progress so the waiting is active instead of passive.
- Addy Osmani: Optimizing Performance with the Import-on-Interaction Pattern. The concept is quite simple: a feature on a page needs HTML/CSS/JavaScript to work, but you don’t load it until the user has literally asked for it (e.g. by clicking a button). Auth, YouTube Embeds, Chat Widgets, Sharing functionality… there are loads of examples, and Addy’s all have pretty huge buckets of JavaScript needed to make them work, which makes the pattern all the more vital. I’ve rollercoastered on this over the years. I would hand-roll a modal, such that when the modal is opened, it would fetch it’s own HTML, CSS, and JavaScript all as separate requests. I’d even have to write nested Ajax calls because even Promise wasn’t really a thing yet. Sometimes I’d do all this manual work just to save a handful of KB, and then I’d decide the technical debt isn’t worth it. But I gotta say, modern JavaScript tooling makes this a lot easier with lazy loaded imports.
