[Robin]: My day job is at Sentry and I’ve never worked at a place where everyone cares so intensely about the quality of the codebase and the design. But one thing that I think could be improved is our CSS and so each Friday afternoon I focus just on that. It’s a couple of hours where I try to make a difference, scour through the codebase looking for things I don’t understand, but this tiny amount of time is already starting to prove how valuable small changes in the right direction can be.
So long as you’re patient and so long as you have a list.
At Sentry, we use the CSS-in-JS library Emotion to help us style our React components but we also used to have Bootstrap styles in Less that are then loaded in the head of the HTML. I noticed that as I was navigating the app that we had duplicate styles loading all over the place. We also had a ton of custom components in React that we really didn’t need — we could let the cascade in our app provide the base styles for lots of things instead. And so after rummaging about looking at a component I realized that there were all sorts of places where our styles were coming from: there was no single source of truth.
So! Instead of panicking, the first thing I did was make a list of every problem I could see with our styles. Then, the more spelunking into our codebase that I did, I started to refine that list into tasks. What files needed to be deleted? Which should we keep?
There are a lot more steps to this refactor than just this stuff, but it’s a start. This list of tasks isn’t really meant to be added to a Jira board or anything, it’s really just to inspire me to break up my pull requests into tiny chunks and then ship code every Friday afternoon. Each list item should ideally be one shippable chunk of code.
The end goal is a consistent and easily-understandable base of core styles: CSS declarations that affect every single page in our app whether or not that’s been refactored into Emotion yet. And I guess I don’t have any big advice here or anything other than it’s sometimes important to slow down on work like this. This project isn’t urgent, it’s not going to make the company a ton of money tomorrow, but once it’s complete in several months time, it’ll make our lives a tiny bit easier.
Tangled webs we weave
Boy howdy, do I love blot. It’s a blogging platform that feels like just the right level of complexity for most folks: you can just throw some files into Dropbox and it’ll deploy a real live website right away.
I think this is what prevents a lot of folks from writing more on the web today: that painful act of maintenance. And connecting wires together across different technologies. So to get your CSS working you have to make sure that your build process is working, and that webpack is doing X, Y, and Z, and also you’ve got to make sure that…
Dave Rupert wrote about this just the other day in a post called Tangled webs we weave:
So my little mashup, which was supposed to be just 3 technologies ended up exposing me to ~20 different technologies and had me digging into nth-level dependency source code after midnight. If there’s an allegory for what I don’t like about modern day web development, this is it. You want to use three tools, but you have to know how to use twenty tools instead. If modules and components are like LEGO, then this is dumping out the entire bin on the floor just to find one tiny piece you need.
I think this bloated complexity affects much more than just web development though. I reckon it prevents folks from moving into the field of web design in the first place. And I’m not saying we should throw our computers into the ocean and return to the caves from whence we came, but there’s a breaking point here. And I think that tiny tools like blot show us the way.
Animating the SVG viewBox
Last month, Louis Hoebregts made this smart demo where he shows how you can animate the viewBox of an SVG and create a nifty camera effect that zooms in and out.
I guess this is super handy if you want to draw attention to particular details of an illustration. But I think this is just a good thing to keep in mind: instead of loading multiple SVGs or doing something more complex, we can let this tiny attribute do a lot of the work for us. Also: it’s super cute!
Also, also: look at this fancy dragon animation!
Speaking of animations, here’s a darn lovely animation from Cassie Evans that I spotted not so long ago. You can twirl this highly stylized dragon around your screen to your heart’s content but each time you refresh the page it’ll change the colors of the dragon, too. Lovely stuff.
Vue 3 just launched
New version with new docs and everything. There’s a lot to love here: improved performance, smaller bundle sizes, and new APIs:
Vue had a simple mission from its humble beginning: to be an approachable framework that anyone can quickly learn. As our user base grew, the framework also grew in scope to adapt to the increasing demands. Over time, it evolved into what we call a “Progressive Framework”: a framework that can be learned and adopted incrementally, while providing continued support as the user tackles more and more demanding scenarios.
Today, with over 1.3 million users worldwide*, we are seeing Vue being used in a wildly diverse range of scenarios, from sprinkling interactivity on traditional server-rendered pages, to full-blown single page applications with hundreds of components. Vue 3 takes this flexibility even further.
It’s still extremely cool to me that you can use Vue without a complex build step. You don’t need webpack or some command line magic to get things going, you just need a humble <script> tag.
Enforcing perf budgets with webpack
webpack has a lot of features to help you achieve smaller bundles and control the loading priority of resources. The most compelling of them is code splitting, which provides a way to split your code into various bundles that can then be loaded on demand or in parallel. Another one is performance hints which indicates when emitted bundle sizes cross a specified threshold at build time so that you can make optimizations or remove unnecessary code.
Ayooluwa Isaiah has the scoop on all this stuff when it comes to enforcing performance budgets with webpack, showing how easy they are to setup and encouraging everyone to stay under a certain threshold. It’s as simple as adding something like this to your webpack.config.js:
module.exports = {
performance: {
maxAssetSize: 50000,
maxEntrypointSize: 50000,
}
};There’s a few edge cases though that are worth watching out for in your builds, like you might want to exclude certain assets.
Optimizing CSS for faster page loads
Tomas Pustelnik wrote about the who, what, and why when it comes to making CSS lightning fast. He begins by asking: why does loading time even matter?
Because Time is money. That proverb is especially true for webpage load times. Your page load time has a direct impact on your profit. People are more likely to buy something on a fast e-shop than on the slow one. According to study Milliseconds make millions improvement by 0.1s on mobile site increased conversions by 10.1% and order value by 1.9% on Travel sites. That can be a lot of money.
So if you want to build a profitable business, you shouldn’t underestimate your page load times.
One thing I hear a lot is why start with CSS? The biggest performance bottleneck is JavaScript and the bundle, so we should start there. But my argument is that everything helps. Every tiny bit of performance work builds a culture of caring for making things fast, for not bloating our webpages with useless crap. And that has to start somewhere, so why not CSS?
Sponsor
Troubleshoot Puppeteer and Playwright Tests Faster with Testim.io
Open source testing frameworks are great—until your test fails. Testim Root Cause simplifies screenshot capture, highlighting the UI action to visually identify where the test failed. Store in the cloud, Or use the open source version locally.
Sponsor
Microsoft Create: Serverless
Hey hey! I (Chris) will be speaking at Microsoft’s Create: Serverless conference coming up this September 30th. In fact, I’ll be giving the first presentation along with Chris Nwamba, where we’ll be talking about the whole landscape of Serverless together. Then the rest of the day is back to back sessions on tooling, security, best practices, workshops, and open-mic community networking sessions.
This is a one-of-a-kind live event that’s free to attend, so register now, get it on your calendar and learn about this brave new world of serverless.
[Chris]: I have a feeling that when CMSs are selected for projects, it’s not the result of a detailed processes looking into the landscape of CMSs, comparing detailed features, exploring concerns, and giving each of them a trial run. A lot of times the CMS is just kinda chosen and you roll with it.
It seems like the latter is a much more adult and reasonable thing to do on a software project, but I don’t mind and understand just choosing — mostly because it’s not choosing randomly out of a hat, but probably based on a bunch of other reasonable and important things: previous usage familiarity, understanding of the CMS landscape, and gut-instinct about what will work best. That is: industry experience. That is worth about the same as an audit, in my mind (although both are probably best). Not to mention that a good audit takes time and money, and I have to admit I’m a get to work kinda guy, assuming the choice doesn’t raise any serious concerns about long-term maintenance.
But the bigger the project, the more people involved, the more visible the choice is, and the more an audit is appropriate. Wanna see a great one? Here’s a CMS audit by Marie Manandise for Studio 24 on the job of selecting a CMS for the W3C. It factors in previous familiarity, which is very smart to mention. This particular audit is focused on the actual needs of the project, which are clearly defined, and looks at WordPress vs. Statamic vs. CraftCMS.