A static website is a website where the initial HTML is prepared ahead of time, not dynamically generated by a server on request.

I like this definition. I think it does a good job of encapsulating why static sites are beneficial whilst also being clear that there are very few things a static site can't be. As Josh demonstrates through several examples, he has static sites that interact with databases; static sites that allow users to create generative art (via a load of client-side JavaScript); and normal websites that would only ever want static pages anyway.

Better yet, static sites let you shift computation (where possible) from the user to the server. Sites like this one where all pages are rendered on build. Plus, it gives you additional resilience to mistakes; a production error that crashes a build doesn't impact a live site, and even live errors can simply be rolled back one deploy if you're using a service like Netlify.

Static sites are more performant, more resilient, have better SEO, better user experience, better accessibility, they can be more easily cached. Yes, there will always be some web uses which don't fit the model (a static Slack would be a nightmare) but for a lot of websites, it could be a better choice, particularly as we get features like Incremental Builds.

We’re dealing with the results of bad defaults, deployed at a terrible scale.

The way we make websites is built on a false assumption: that the tools we use are the right ones for the job. Now – more than ever – we should be questioning why common frameworks, dependencies, libraries, and other packages are often poorly optimised. Engineers can put in the work (and many do) to fix those issues, but if the default state is broken then most won't.

In other words, they have to give a damn. But giving a damn doesn’t scale.

It's the users that pay in the short-term, but in the long-term Ethan makes a valid point that it may ultimately mean the tech industry will require greater oversight and regulation. Some of what makes the web great might be lost in that process but, as he puts it:

If other industries follow building codes and regulations, why shouldn’t we?

A really like Eric's latest redesign. I'm a huge fan of ink drawings in general, so it figures I'd like this, but more than the graphic elements I feel like the layout manages to strike a great balance of feeling refreshingly different and yet immediately obvious, particularly on desktop. Snooping the source code shows that there's some clever CSS grid wizardry going on here with negative column/row indices that I'll definitely want to remember 🕵️‍♂️

An in-progress project looking to create a CSS reset that creates modern defaults, rather than just focusing on standardising behaviour across browsers or removing irritating legacy features in browser user agent stylesheets.

You, however, don't have to stay in the past. You can override the UA styles with more modern ideas of how CSS should work by default. Introducing CSS Remedy.

User experience, even over developer experience.

Jeremy has some solid thoughts on what makes a good design principle. In brief, it should be a little provocative and not automatically achievable; it needs to be something to actually drives behaviour and guides decision making, rather than being bland, boring, and already achieved. Something like that initial statement, which I agree should be a fairly universal principle. I also agree with his follow up:

Sadly, I think the current state of “modern” web development reverses that principle. Developer efficiency is prized above all else. Like I said, that would be absolutely fine if we’re talking about technologies that only developers are exposed to, but as soon as we’re talking about shipping those technologies over the network to end users, it’s negligent to continue to prioritise the developer experience.

A simple idea: collate all your feeds (RSS, ATOM, MF2, whatever) into one place. Marcus suggests a pattern of using the /feeds page (his is here). There have been some valid discussions on the IndieWeb slack about whether an English-language specific pattern is ideal, but overall I feel like it's a positive step until something better comes along. Personally I'd be interested in expanding on the idea and also having silo feeds (Twitter, Instagram etc.) linked on that page too, a little like Marcus does with Mastodon.

A collection of hyper-optimised SVG logos for social media, popular websites, and tech companies. Every logo, whether in PNG or SVG form, is less than 1kb in size and have a base scale of 512px.

Solid reasoning – with a clear example – of the potential dangers of using an array index as the key value in ReactJS. Not something I'd ever considered (and something I do a lot) but makes sense.

I think there's some real merit to Andy's ideas behind Cube CSS. It's a middle-ground between everything-in-JS or BEM that throw out the cascade entirely and the free-for-all that can happen if you don't have any structure at all. That makes it flexible and scalable. It also feels a lot more like a pace layer approach.

Sure, in the old days of Internet Explorer, the cascade was a bit tricky, but using old knowledge and techniques as the base of a modern approach is like feeding horse feed to a car.

1. Composition. These are classes which define the foundational layout, the content skeleton if you will. I imagine this being your grid and flexbox classes.
2. Utility. Largely these are just utility classes (.wrapper, .inline, .centre etc.). They do "one thing, and do it well". Makes sense. Not sure I'm a fan of the use of colours as utility glasses; I'd rather use variables for that. In fact, personally I feel like CSS variables are a form of utility class, so would group those two together.
3. Block. Pretty much how it is in BEM, a block == a component. Ideally you have very little of these; how you specifically deal with sub-rules is up to you.
4. Exception. Exceptions make use of data-attributes. I like that a lot. They let you manipulate blocks, reversing card order (for example) or highlighting a specific card, and they don't leave you fighting the cascade too much.

I didn't know you could use square brackets within the class attribute, which is suggested for ordering classes into "primary block", "blocks", and "utility" segments:

class="[ card ] [ section box ] [ bg-case color-primary ]"

Pipes are also acceptable and useful.

I feel like CUBE CSS neatly fits into a model I've been thinking about a lot recently. I've found my approach to using big stylesheets in React more frustrating over time, whilst I really like lumping component-specific styles into, well, the component. I prefer CSS modules, but CSS-in-JS achieves the same thing. The problem is, if that's all you do you end up with repetition and inconsistency. With Growable, we used a combination of CSS modules and a global.css stylesheet which struck a good balance but still felt like it could be better optimised. I think CUBE CSS maybe hits on a method to achieve that optimisation. I'd be intrigued to give it a go.

There's been a lot of chatter about Spinosaurus recently, thanks to the new revelations about its tail morphology, but I think Mark has put together the best overall argument for what the new papers tell us and what that means for reconstructions. Also, as ever, he's created an amazing illustration. In brief (and with the caveat of as the evidence currently suggests):

• Bipedalism looks likely to be the main form of locomotion, based both on tail weighting and position/size of neck and hindlimb musculature;
• How – or if – Spinosaurus swam is still unclear and the new tail doesn't necessarily help with objections based on buoyancy modelling, but these calculations should be redone. Basically, it's still really weird and unlike anything extant, so we can't really make definitive claims;
• The sail is basically confusing. Depending on what fossils you prioritise, it could be S-shaped or C-shaped or somewhere in between the two. This is muddied by the question of whether the new specimen is a distinct species from the holotype or not;
• Mark has revised his earlier misgivings around tail flexion, particularly as to whether it could be used in a sculling motion like newts or crocodilians do. It looks like the neural spines are thin enough to both withstand and forgive the level of flex required, so they wouldn't snap or overpower musculature. That said, there's still some debate here as the paper itself claims a minimal tail musculature, so perhaps it was more rigid than implied;
• Lips are still very viable and there is little evidence to suggest the jaws were much more specialised than other theropods.

In short, we don't know a lot, but we know a little more than we did. I still like the idea of Spinosaurus as a Cretaceous mega-heron though 😁

At the start of the pandemic, Eric made a strong case that all critical websites needed to rapidly optimise for high traffic and accessibility (here very much meaning both a11y and device/situation inclusion). I keep returning to it in my mind so wanted to note it here. Eric was specifically calling out sites for public health, government services, etc. – the social infrastructure that happens to live online – but it's universally relevant advice.

As much as you possibly can, get it down to static HTML and CSS and maybe a tiny bit of enhancing JS, and pare away every byte you can. Because too many sites are already crashing because their CMSes can’t keep up with the traffic surges. And too many sites are using dynamic frameworks that drain mobile batteries and shut out people with older browsers. That’s annoying and counter-productive in the best of times, but right now, it’s unacceptable.

Apparently, there has been a discussion around whether the term "user" is in some way derogatory. I must say I don't get it, but I do agree with Heydon: if there is a better, more descriptive, more accurate, or more meaningful word – such as contributor or team member – then use it. Otherwise, "user" will do just fine:

But where we have to use the term person to remind ourselves that the person using our product is more than just a user of our product, that says more about the arrogance with which we approach product design than any tokenistic attempts at sounding humane can ever make up for.

The term user is fine, just don’t sell meth.

(bold emphasis mine)