If I had asked my customers what they wanted, they would have said ‘faster horses’.

There is no actual evidence that Ford ever said this - regardless, it has become a favorite adage for people talking about creativity and innovation. It’s often accompanied by a smirk and an air of superiority. The essential message being that users don’t actually know what they want or what true innovation looks like until a visionary comes along who presents it to them.

That mindset of “innovation against popular demand” seems quite pervasive in the IT industry these days, now that every tech company on the planet has decided that AI is the way to go.

Even though there’s an overwhelming chorus of consumer voices saying “we don’t actually want this”, most tech giants are so convinced that AI is the future that they’re still pushing it on every service and product under the sun.

Here’s the thing: that approach to innovation is a huge gamble. It really only works if the new, innovative thing is so undeniably better that once they see it, people will want to use it straight away.

The success of the iPhone, for example, was evident from the moment Steve Jobs first showed a breathless audience how to pinch-and-zoom a photo. Nobody had to force people to use it.

In contrast, most major tech companies have now started to opt-in users to their AI features against their will, sometimes making it almost impossible to disable them again.

Feature adoption doesn’t work if it’s forced; it has to come from a genuine user belief that the new feature can help them achieve their goals. And it certainly doesn’t work if the feature actually creates a worse user experience and degrades the quality of the product.

Google implementing AI search results has led to countless examples of misinformation, factual errors and hallucination. Google was already excellent at ranking information, guessing the intent behind a search phrase and modifying its results accordingly. They have now augmented that with a solution that gives either false (even dangerous) information or may just dream up answers on the spot.

The people might have asked for faster horses, but instead they got donkeys on LSD.

I get that it’s not as fun to build “a faster horse”. To just make the thing you already have better, more reliable, more helpful. It doesn’t get your shareholders excited, and it doesn’t make you look like a visionary genius.

But in my opinion, the tech industry desperately needs less disruptive new shit for the sake of innovation and more listening to the actual problems users are facing out there.

To close, here’s a quote by Henry Ford that he did in fact say:

If there is any one secret of success, it lies in the ability to get the other person’s point of view and see things from that person’s angle as well as from your own.

This year’s annual review post is a bit different.

In previous years, I reflected on the work that I did, the web projects I built, the posts that I wrote and so on. There was lots of that in 2024 too of course (well maybe except the blogging part, that seems to become a pattern).

But the truth is, most of my energy this year went towards building a life for our new family.

My son was born in November, and he’s happily sleeping on my chest as I am typing this. I’ve never felt more grateful or proud about anything in my life, and I still can’t believe he’s with us now.

The months leading up to his arrival were quite stressful at times, supporting my wife’s pregnancy and preparing everything as best I could for the steps ahead. We’re planning a move next year, and there’s still lots of work to do before we can settle into our new home.

But all of it is very rewarding, and I can’t wait to see where 2025 takes us. Despite everything that’s going wrong in the world right now, I feel hopeful for the future.

It’s just a simple change, so you log on via FTP, edit your style.css file, hit save - and reload the page to see your changes live.

Did that story resonate with you? Well then congrats A) you’re a nerd and B) you’re old enough to remember a time before bundlers, pipelines and build processes.

Now listen, I really don’t want to go back to doing live updates in production. That can get painful real fast. But I think it’s amazing when the files you see in your code editor are exactly the same files that are delivered to the browser. No compilation, no node process, no build step. Just edit, save, boom.

There’s something really satisfying about a buildless workflow. Brad Frost recently wrote about it in “raw-dogging websites”, while developing the (very groovy) site for Frostapalooza.

So, how far are we away from actually working without builds in HTML, CSS and Javascript? The idea of “buildless” development isn’t new - but there have been some recent improvements that might get us closer. Let’s jump in.

HTML

The main reason for a build process in HTML is composition. We don’t want to repeat the markup for things like headers, footers, etc for every single page - so we need to keep these in separate files and stitch them together later.

Oddly enough, HTML is the one where native imports are still an unsolved problem. If you want to include a chunk of HTML in another template, your options are limited:

• PHP or some other preprocessor language
• server-side includes
• frames?

There is no real standardized way to do this in just HTML, but Scott Jehl came up with this idea of using iframes and the onload event to essentially achieve html imports:

<iframe
    src="/includes/something.html"
    onload="this.before((this.contentDocument.body||this.contentDocument).children[0]);this.remove()"
></iframe>

Andy Bell then repackaged that technique as a neat web component. Finally Justin Fagnani took it even further with html-include-element, a web component that uses native fetch and can also render content into the shadow DOM.

For my own buildless experiment, I built a simplified version that replaces itself with the fetched content. It can be used like this:

<html-include src="./my-local-file.html"></html-include>

That comes pretty close to actual native HTML imports, even though it now has a Javascript dependency 😢.

Server-Side Enhancement

Right, so using web components works, but if you want to nest elements (fetch a piece of content that itself contains a html-include), you can run into waterfall situations again, and you might see things like layout shifts when it loads. Maybe progressive enhancement can help?

I’m hosting my experiment on Cloudflare Pages, and they offer the ability to write a “worker” script (very similar to a service worker) to interact with the platform.

It’s possible to use a HTML Rewriter in such a worker to intercept requests to the CDN and rewrite the response. So I can check if the request is for a piece of HTML and if so, look for the html-include element in there:

// worker.js
export default {
    async fetch(request, env) {
        const response = await env.ASSETS.fetch(request)
        const contentType = response.headers.get('Content-Type')

        if (!contentType || !contentType.startsWith('text/html')) {
            return response
        }

        const origin = new URL(request.url).origin
        const rewriter = new HTMLRewriter().on(
            'html-include',
            new IncludeElementHandler(origin)
        )

        return rewriter.transform(response)
    }
}

You can then define a custom handler for each html-include element it encounters. I made one that pretty much does the same thing as the web component, but server-side: it fetches the content defined in the src attribute and replaces the element with it.

// worker.js
class IncludeElementHandler {
    constructor(origin) {
        this.origin = origin
    }

    async element(element) {
        const src = element.getAttribute('src')
        if (src) {
            try {
                const content = await this.fetchContents(src)
                if (content) {
                    element.before(content, { html: true })
                    element.remove()
                }
            } catch (err) {
                console.error('could not replace element', err)
            }
        }
    }

    async fetchContents(src) {
        const url = new URL(src, this.origin).toString()
        const response = await fetch(url, {
            method: 'GET',
            headers: {
                'user-agent': 'cloudflare'
            }
        })
        const content = await response.text()
        return content
    }
}

This is a common concept known as Edge Side Includes (ESI), used to inject pieces of dynamic content into an otherwise static or cached response. By using it here, I can get the best of both worlds: a buildless setup in development with no layout shift in production.

CSS

Historically, we’ve used CSS preprocessors or build pipelines to do a few things the language couldn’t do:

1. variables
2. selector nesting
3. vendor prefixing
4. bundling (combining partial files)

Well good news: we now have native support for variables and nesting, and prefixing is not really necessary anymore in evergreen browsers (except for a few properties). That leaves us with bundling again.

CSS has had @import support for a long time - it’s trivial to include stylesheets in other stylesheets. It’s just … really frowned upon. 😅

Why? Damn performance waterfalls again. Nested levels of @import statements in a render-blocking stylesheet give web developers the creeps, and for good reason.

But what if we had a flat structure? If you had just one level of imports, wouldn’t HTTP/2 multiplexing take care of that, loading all these files in parallel?

Chris Ferdinandi ran some benchmark tests on precisely that and the numbers don’t look so bad.

So maybe we could link up a main stylesheet that contains the top-level imports of smaller files, split by concern? We could even use that approach to automatically assign cascade layers to them, like so:

/* main.css */
@layer default, layout, components, utils, theme;

@import 'reset.css' layer(default);
@import 'base.css' layer(default);
@import 'layout.css' layer(layout);
@import 'components.css' layer(components);
@import 'utils.css' layer(utils);
@import 'theme.css' layer(theme);

Design Tokens

Love your atomic styles? Instead of Tailwind, you can use something like Open Props to include a set of ready-made design tokens without a build step. They’ll be available in all other files as CSS variables.

You can pick-and-choose what you need (just get color tokens or easing curves) or use all of them at once. Open props is available on a CDN, so you can just do this in your main stylesheet:

/* main.css */
@import 'https://unpkg.com/open-props';

Javascript

Javascript is the one where a build step usually does the most work. Stuff like:

• transpiling (converting modern ES6 to cross-browser supported ES5)
• typechecking (if you’re using TypeScript)
• compiling JSX (or other non-standard syntactic sugars)
• minification
• bundling (again)

A buildless worflow can never replace all of that. But it may not have to! Transpiling for example is not necessary anymore in modern browsers. As for bundling: ES Modules come with a built-in composition system, so any browser that understands module syntax…

<script src="/assets/js/main.js" type="module"></script>

…allows you to import other modules, and even lazy-load them dynamically:

// main.js
import './some/module.js'

if (document.querySelector('#app')) {
    import('./app.js')
}

The newest addition to the module system are Import Maps, which essentially allow you to define a JSON object that maps dependency names to a source location. That location can be an internal path or an external CDN like unpkg.

<head>
    <script type="importmap">
        {
            "imports": {
                "preact": "https://unpkg.com/htm/preact/standalone.module.js"
            }
        }
    </script>
</head>

Any Javascript on that page can then access these dependencies as if they were bundled with it, using the standard syntax: import { render } from 'preact'.

Conclusion

So, can we all ditch our build tools soon?

Probably not. I’d say for production-grade development, we’re not quite there yet. Performance tradeoffs are a big part of it, but there are lots of other small problems that you’d likely run into pretty soon once you hit a certain level of complexity.

For smaller sites or side projects though, I can imagine going the buildless route - just to see how far I can take it.

Funnily enough, many build tools advertise their superior “Developer Experience” (DX). For my money, there’s no better DX than shipping code straight to the browser and not having to worry about some cryptic node_modules error in between.

I’d love to see a future where we get that simplicity back.

Links

• Repo for my demo code
• Getting started with buildess
• A simple dev server for a buildless workflow
• “A Real “Buildless” Modern Web Development Workflow? Oh Yes!” by Jared White
• “Writing Javascript without a build system” by Julia Evans

When someone makes changes to the content via the CMS, they usually don’t get it done in one go and hit publish - it’s an iterative process, going back and forth between CMS and website. Editors might need to check whether a piece of text fits the layout, or they may have to tweak an image so the crop looks good on all devices. To do this, they’ll typically need some sort of visual preview that shows the new content in the actual context of the website.

For static websites, that’s easier said than done.

Content changes on static websites require a rebuild, and that process can take a while. When you’re editing content in a headless CMS like Sanity, you don’t have access to a local dev server - you need to preview changes on the web somehow. Even for small sites and even with blazingly fast SSGs like Eleventy, building and deploying a new version can take a minute.

That doesn’t sound like much, but when you’re in the middle of writing, having to wait that long for every tiny change to become visible can feel excrutiatingly slow. We need a way to render updates on demand, without actually rebuilding the entire site.

Here’s what we’re trying to achieve:

Serverless Functions to the Rescue?

This is quite a common problem, so there are existing solutions. They revolve around making some parts of your Eleventy site available for on-demand rendering by using serverless functions.

Eleventy Serverless

Eleventy has the ability to run inside a serverless function as well, and it provides the Serverless Bundler Plugin to do that. Basically, the plugin bundles your entire site’s source code (plus some metadata) into a serverless function that you can call to trigger a new partial build.

The most common scenario here is to have such a function run on the same infrastructure that hosts the regular static site. Providers like Netlify, Vercel, AWS or Cloudflare all have slightly different expectations when it comes to serverless functions, so the exact implementation varies. All dependencies of your build process need to be packaged and bundled along with the function, and some platforms (in our case Cloudflare) don’t run them in a node environment at all, which is its own set of trouble.

One of the coolest things about Eleventy is its independence from frameworks and vendors. You can host a static Eleventy site anwhere from a simple shared webserver to a full-on bells-and-whistles cloud provider, and switching between them is remarkably easy (in essence, you can drag and drop your output folder anywhere and be done with it).

For the Sanity × Eleventy setup we’re building at Codista, we really wanted to avoid getting locked-in to a specific provider and their serverless architecture. We also wanted to have more control over the infrastructure and the associated costs.

So we did what every engineer in that position would do: We rolled our own solution. 😅

Do-it-Yourself

The basic idea for our preview service was to have our own small server somewhere. Everytime someone deploys a new version of our 11ty project, we would automatically push the latest source code to that preview server too and run a build, to pre-generate all the static assets like CSS and Javascript early on.

A node script running on there will then accept GET requests to re-build parts of our site when the underlying Sanity content changes and spit out the updated HTML. We could then show that updated HTML right in the CMS as a preview.

To get this off the ground, we essentially need three things:

1. A way to render specific parts of the site on-demand
2. A way to fetch unpublished data changes from the CMS
3. A way to display the rendered preview HTML to content editors in Sanity

Let’s jump in!

1. On-Demand Building

The first piece of the puzzle is a way to trigger a new build when the request comes in. Usually, builds would be triggered from the command line or from a CI server, using the predefined npx eleventy command or similar. But it’s also possible to run Eleventy through its programmatic API instead. You’ll need to supply an input (a file or a directoy of files to parse), an output (somewhere for Eleventy to write the finished files) and a configuration object.

Here’s an example of such a function:

// preview/server.js
import Eleventy from '@11ty/eleventy'

async function buildPreview(request) {
    // get some data from the incoming GET request
    const { path: url, query } = request
    let preview = null

    // look up the url from the request (i.e. "/about")
    // and try to match it to a input template src (i.e. "aboutPage.njk")
    // using the JSON file we saved earlier
    const inputPath = mapURLtoInputPath(url)

    // Run Eleventy programmatically
    const eleventy = new Eleventy(inputPath, null, {
        singleTemplateScope: true,
        inputDir: INPUT_DIR,
        config: function (eleventyConfig) {
            // make the request data available in Eleventy
            eleventyConfig.addGlobalData('preview', { url, query })
        }
    })
    // write output directly to memory as JSON instead of the file system
    const outputJSON = await eleventy.toJSON()

    // output will be a list of rendered pages,
    // depending on the configuration of our input source
    if (Array.isArray(outputJSON)) {
        preview = outputJSON.find((page) => page.url === url)
    }

    return preview
}

Let’s say we want to call GET preview.codista.com/myproject/about from within the CMS to get a preview of the “about us” page. First, we will need a way to translate the permalink part of that request (/about) to an input file in the source code like src/pages/about.njk that Eleventy can render.

Luckily, Eleventy already does this in reverse when it builds the site - so we can hook into its contentMap event to get a neat map of all the URLs in our site to their respective input paths. Writing this map to a JSON file will make it available later on at runtime, when our preview function is called.

// eleventy.config.js
eleventyConfig.on('eleventy.contentMap', (map) => {
    const fileName = path.join(options.outputDir, '/preview/urls.json')
    fs.writeFileSync(fileName, JSON.stringify(map.urlToInputPath, null, 2))
})

The generated output then looks somehing like this:

{
    "/sitemap.xml": {
        "inputPath": "./src/site/sitemap.xml.njk",
        "groupNumber": 0
    },
    "/": {
        "inputPath": "./src/site/cms/homePage.njk",
        "groupNumber": 0
    },
    "/about/": {
        "inputPath": "./src/site/cms/aboutPage.njk",
        "groupNumber": 0
    },
    ...
}

Listen for preview requests

We use a small express server to have our script listen for preview requests. Here’s a (simplified) version of how that looks:

// preview/server.js
import express from 'express'
const app = express()

app.get('*', async (req, res, next) => {
    const { path: url } = req

    // check early if the requested URL matches any input sources.
    // if not, bail
    if (mapURLtoInputPath(url)) {
        res.status(404).send(`can't resolve URL to input file: ${url}`)
    }

    try {
        // call our preview function
        const output = await buildPreview(req)

        // check if we have HTML to output
        if (output) {
            res.send(output.content)
        } else {
            throw new Error(`can't build preview for URL: ${url}`)
        }
    } catch (err) {
        // pass any build errors to the express default error handler
        return next(err)
    }
})

Putting all that together, we end up with a script that we can run on our preview server. You can find the final version here. We’ll give it a special environment flag so we can fine-tune the build logic for this scenario later.

$ NODE_ENV=preview node preview/server.js

Right, that’s the on-demand-building taken care of. Let’s move to the next step!

2. Getting Draft Data from Sanity

In our regular build setup, we want to fetch CMS data from the Sanity API whenever a new build runs. Sanity provides a helpful client package that takes care of the internal heavy lifting. It’s a good idea to build a little utility function to configure that client first:

// utils/sanity.js
import { createClient } from '@sanity/client'

export const getClient = function () {
    // basic client config
    let config = {
        // your project id in sanity
        projectId: process.env.SANITY_STUDIO_PROJECT_ID,
        // datasets are basically databases. default is "production"
        dataset: process.env.SANITY_STUDIO_DATASET,
        // api version takes any date and figures out the correct version from there
        apiVersion: '2024-08-01',
        // perspectives define what kind of data you want, more on that in a second
        perspective: 'published',
        // use sanity's CDN for content at the edge
        useCdn: true
    }
    return createClient(config)
}

Through the Eleventy data cascade, we can make a new global data file for each content type, for example data/cms/aboutPage.js. Exporting a function from that file will then cause Eleventy to fetch the data for us and expose it through a cms.aboutPage variable later. We just need to pass it a query (Sanity uses GROQ as its query language) to describe which content we want to have returned.

// src/data/cms/aboutPage.js
import { getClient } from '../utils/sanity.js'

const query = `*[_type == "aboutPage"]{...}`

export default async function getAboutPage() {
    const client = getClient()
    return await client.fetch(query)
}

Perspectives in Sanity

When an editor makes changes to the content, these changes are not published straight away but rather saved as a “draft” state in the document. Querying the Sanity API with the regular settings will not return these changes, as the default is to return only “published” data.

If we want to access draft data, we need to pass an adjusted configuration object to the Sanity client that asks for a different “perspective” (Sanity lingo for different views into your data) of previewDrafts. Since that data is private, we’ll also need to provide a secret auth token that can be obtained through the Sanity admin. Finally, we can’t use the built-in CDN for draft data, so we’ll set useCdn: false.

// utils/sanity.js
import { createClient } from '@sanity/client'

export const getClient = function () {
    // basic client config
    let config = {
        projectId: process.env.SANITY_STUDIO_PROJECT_ID,
        dataset: process.env.SANITY_STUDIO_DATASET,
        apiVersion: '2024-08-01',
        perspective: 'published',
        useCdn: true
    }

    // adjust the settings when we're running in preview mode
    if (process.env.NODE_ENV === 'preview') {
        config = Object.assign(config, {
            // tell sanity to return unpublished drafts as well
            // note that we need an auth token to access that data
            token: process.env.SANITY_AUTH_TOKEN,
            perspective: 'previewDrafts',
            // we can't use the CDN when fetching unpublished data
            useCdn: false
        })
    }

    return createClient(config)
}

By making these changes directly in the API client, we don’t need to change anything about our data fetching logic. All builds running in the preview node environment will automatically have access to the latest draft changes.

3. Displaying the Preview

We’re almost there! We already have a way to request preview HTML for a specific URL and render it with the most up-to-date CMS data. All we’re missing now is a way to display the preview, enabling the editors to see their content changes from right within the CMS.

In Sanity, we can achieve that using the Iframe Pane plugin. It’s a straightforward way to render any external URL as a view inside Sanity’s “Studio”, the CMS Interface. Check the plugin docs on how to implement it.

The plugin will pass the currently viewed document to a function, and we need to return the URL for the iFrame from that. In our case, that involves looking up the document slug property in a little utility method and combining that relative path with our preview server’s domain:

// studio/desk/defaultDocumentNode.js
import { Iframe } from 'sanity-plugin-iframe-pane'
import { schemaTypes } from '../schema'
import { getDocumentPermalink } from '../utils/sanity'

// this function will receive the Sanity "document" (read: page)
// the editor is currently working on. We need to generate
// a preview URL from that to display in the iframe pane.
function getPreviewUrl(doc) {
    // our custom little preview server
    const previewHost = 'https://preview.codista.dev'
    // a custom helper to resolve a sanity document object into its relative URL like "/about"
    const documentURL = getDocumentPermalink(doc)
    // build a full URL
    const url = new URL(documentURL, previewHost)

    // append some query args to the URL
    // rev: the revision ID, a unique string generated for each change by Sanity
    // token: a custom token we use to authenticate the request on our preview server
    let params = new URLSearchParams(url.search)
    params.append('rev', doc._rev)
    params.append('token', process.env.SANITY_STUDIO_PREVIEW_TOKEN)
    url.search = params.toString()

    return url.toString()
}

// this part is the configuration for the Sanity Document Admin View.
// we enable the iFrame plugin here for certain document types
export const defaultDocumentNode = (S, { schemaType }) => {
    // only documents with the custom "enablePreviewPane" flag get the preview iframe.
    // we define this in our sanity content schema
    const schemaTypesWithPreview = schemaTypes
        .filter((schema) => schema.enablePreviewPane)
        .map((schema) => schema.name)

    if (schemaTypesWithPreview.includes(schemaType)) {
        return S.document().views([
            S.view.form(),
            S.view
                // enable the iFrame plugin and pass it our function
                // to display a preview URL for the viewed document
                .component(Iframe)
                .options({
                    url: (doc) => getPreviewUrl(doc),
                    reload: { button: true }
                })
                .title('Preview')
        ])
    }
    return S.document().views([S.view.form()])
}

Aaaand that’s it!
Near-instant live previews from right within Sanity studio.

This was quite an interesting challenge, since there are so many moving parts involved. The end result turned out great though, and it was nice to see it could be accomplished without relying on third-party serverless functions.

Please note that this may not be the route to take for your specific project though, as always: your experience may vary! 😉

This iteration of mxb.dev is already 7 years old, so some of its internal dependencies had become quite dusty. Thankfully with static sites that didn’t matter as much, since the output was still good. Still, it was time for some spring cleaning.

Switching to ESM

A big change in v3 is that Eleventy is now using ECMAScript Module Syntax (ESM). That brings it in line with modern standards for JS packages.

In “Lessons learned moving Eleventy from CommonJS to ESM”, Zach explains the motivation for the switch.

I’ve already been using ESM for my runtime Javascript for quite some time, and I was very much looking forward to get rid of the CommonJS in my build code. Here’s how to switch:

Step 1: Package Type

The first step is to declare your project as an environment that supports ES modules. You do that by setting the type property in your package.json to “module”:

//package.json
{
    "name": "mxb.dev",
    "version:": "4.2.0",
    "type": "module",
    ...
}

Doing that will instruct node to interpret any JS file within your project as using ES module syntax, something that can import code from elsewhere and export code to others.

Step 2: Import Statements

Since all your JS files are now modules, that might cause errors if they still contain CommonJS syntax like module.exports = thing or require('thing'). So you’ll have to change that syntax to ESM.

You don’t need to worry about which type of package you are importing when using ESM. Recent node versions support importing CommonJS modules using an import statement.

In an Eleventy v2 project, you’ll typically have your eleventy.config.js, files for filters/shortcodes and global data files that may look something like this:

const plugin = require('plugin-package')
// ...
module.exports = {
    something: plugin({ do: 'something' })
}

Using ESM syntax, rewrite these files to look like this:

import plugin from 'plugin-package'
// ...
export default {
    something: plugin({ do: 'something' })
}

There are ways to do this using an automated script, however in my case I found it easier to go through each file and convert it manually, so I could check if everything looked correct. It only took a couple of minutes for my site.

It’s also helpful to try running npx eleventy --serve a bunch of times in the process, it will error and tell you which files may still need work. You’ll see an error similar to this:

Original error stack trace: ReferenceError: module is not defined in ES module scope
[11ty]  This file is being treated as an ES module because it has a '.js'
        file extension and 'package.json' contains "type": "module".
        To treat it as a CommonJS script, rename it to use the '.cjs' file extension.
[11ty]  at file://mxb/src/data/build.js?_cache_bust=1717248868058:12:1

If you absolutely have to use CommonJS in some files, renaming them to yourfile.cjs does the trick.

Gotchas

Some minor issues you may encounter:

• the minimum required node version for v3 is node 18.
• you may need to npm install with the --legacy-peer-deps flag if some of your deps have trouble with the alpha release.
• if you used __dirname in your CJS files, you might have to replace that with import.meta.url
• if you import something like a json file, you might need to specify the type:
  import obj from "./data.json" with { "type": "json" }

Eleventy Image Transform

Eleventy v3 also comes with a very useful new way to do image optimization. Using the eleventy-img plugin, you now don’t need a shortcode anymore to generate an optimized output. This is optional of course, but I was very eager to try it.

Previously, using something like an async image shortcode, it was not possible to include code like that in a Nunjucks macro (since these don’t support asynchronous function calls).

In v3, you can now configure Eleventy to apply image optimization as a transform, so after the templates are built into HTML files.

Basically, you set up a default configuration for how you want to transform any <img> element found in your output. Here’s my config:

// eleventy.config.js
eleventyConfig.addPlugin(eleventyImageTransformPlugin, {
    extensions: 'html', // transform only <img> in html files
    formats: ['avif', 'auto'], // include avif version and original file type
    outputDir: './dist/assets/img/processed/', // where to write the image files
    urlPath: '/assets/img/processed/', // path prefix for the img src attribute
    widths: ['auto'], // which rendition sizes to generate, auto = original dimensions
    defaultAttributes: {
        // default attributes on the final img element
        loading: 'lazy',
        decoding: 'async'
    }
})

Now that will really try to transform all images, so it might be a good idea to look over your site and check if there are images that either don’t need optimization or are already optimized through some other method. You can exclude these images from the process by adding a custom <img eleventy:ignore> attribute to them.

All other images are transformed using the default config.
For example, if your generated HTML output contains an image like this:

<img
    src="bookcover.jpg"
    width="500"
    alt="Web Accessibility Cookbook by Manuel Matuzovic"
/>

The plugin will parse that and transform it into a picture element with the configured specs. In my case, the final HTML will look like this:

<picture>
    <source
        srcset="/assets/img/processed/Ryq16AjV3O-500.avif 500w"
        type="image/avif"
    />
    <img
        src="/assets/img/processed/Ryq16AjV3O-500.jpg"
        width="500"
        alt="Web Accessibility Cookbook by Manuel Matuzovic"
        decoding="async"
        loading="lazy"
    />
</picture>

Any attributes you set on a specific image will overwrite the default config. That brings a lot of flexibility, since you may have cases where you need special optimizations only for some images.

For example, you can use this to generate multiple widths or resolutions for a responsive image:

<img
    src="doggo.jpg"
    width="800"
    alt="a cool dog"
    sizes="(min-width: 940px) 50vw, 100vw"
    eleventy:widths="800,1200"
/>

Here, the custom eleventy:widths attribute will tell the plugin to build a 800px and a 1200px version of this particular image, and insert the correct srcset attributes for it. This is in addition to the avif transform that I opted to do by default. So the final output will look like this:

<picture>
    <source
        sizes="(min-width: 940px) 50vw, 100vw"
        srcset="
            /assets/img/processed/iAm2JcwEED-800.avif   800w,
            /assets/img/processed/iAm2JcwEED-1200.avif 1200w
        "
        type="image/avif"
    />

    <img
        src="/assets/img/processed/iAm2JcwEED-800.jpeg"
        width="800"
        alt="a cool dog"
        sizes="(min-width: 940px) 50vw, 100vw"
        srcset="
            /assets/img/processed/iAm2JcwEED-800.jpg   800w,
            /assets/img/processed/iAm2JcwEED-1200.jpg 1200w
        "
        decoding="async"
        loading="lazy"
    />
</picture>

I ran a quick lighthouse test after I was done and using the image transform knocked my total page weight down even further! Good stuff.

Other Stuff

I refactored some other aspects of the site as well - most importantly I switched to Vite for CSS and JS bundling. If you’re interested, you can find everything I did in this pull request.

New feature fatigue

Right now, we’re in the middle of a real renai-css-ance (the C is silent). It’s a great time to write CSS, but it can also feel overwhelming to keep up with all the new developments.

Prominent voices at conferences and on social media have been talking about the new stuff for quite some time, but real-world usage seems to lag behind a bit.

Quick question: how many of these have you actively used in production?

• Container Queries
• Style Queries
• CSS Layers
• Subgrid
• Native CSS Nesting
• :has, :is, :where
• Dialog, Popover
• Logical Properties
• Scroll-Linked Animations
• View Transitions

👉 (Disclaimer: I’ve used one.)

All of these are very useful, and support for most is pretty good across the board - yet adoption seems to be quite slow.

Granted some things are relatively new, and others might be sort of niche-y. But take container queries, for example. They were the number one feature requested by front-end devs for a looong time. So why don’t we use them more, now that they’re finally here?

From my own experience, I think there’s different factors at play:

The support excuse

I can’t use [feature X], I need to support [old browser].

That old chestnut.
Browser support is an easy argument against most new things, and sometimes a convenient excuse not to bother learning a feature.

The answer there is usually progressive enhancement - except that’s easier to do for actual “enhancements”, if they are optional features that don’t impact the usability of a site that much.

For some of the new features, theres no good path to do this.

CSS Layers or native nesting for example are not something you can optionally use, they’re all-or-nothing. You’d need a separate stylesheet to support everyone.

And while support for Container Queries is green in all modern browsers, people still seem reluctant to go all-in, fearing they could break something as fundamental as site layout in older browsers.

Invisible improvements

Why use [feature X] if the usual way works fine?

Some of you might be old enough to remember the time when CSS3 features first hit the scene.

Things like border radius or shadows were ridiculously hard to do back in the day. Most of it was background images and hacks, and it required a substantial amount of work to change them.

Suddenly, these designs could be achieved by a single line of CSS.
Writing border-radius: 8px instead of firing up Photoshop to make a fucking 9-slice image was such a no-brainer that adoption happened very quickly. As soon as browser support was there, nobody bothered with the old way anymore.

A big chunk of the new features today are “invisible” though - they focus more on code composition and architecture.

Layers, Container Queries, etc are not something you can actually see in the browser, and the problems they solve may not be such an obvious pain in the ass at first glance. Of course they offer tremendous advantages, but you can still get by without using any of them. That might slow down adoption, since there is no urgency for developers to switch.

Examples and design trends

I don’t know where I would even use [feature X] in my project.

The initial use-case for container queries I always heard was “styling an element that could be in the main column or the sidebar”. I think that came from a very common WordPress blog design at the time where you had “widgets” that could be placed freely in different-width sections of the site.

Nowadays, the widget sidebar isn’t as common anymore; Design trends have moved on. Of course there are plenty of other use-cases for CQs, but the canonical example in demos is usually still a card component, and people seemed to struggle for a while to find other applications.

The bigger issue (most recently with masonry grids) is that sometimes the need for a CSS feature is born out of a specific design trend. Standards move a lot slower than trends though, so by the time a new feature actually ships, the need might not be that strong anymore.

Spec authors do a very good job of evaluating the long-term benefits for the platform, but they also can’t predict the future. Personally, I don’t think the new features are tied to any specific design - but I think it’s important to show concrete, real-world usecases to get the developer community excited about them.

Breaking the habit

Whatever the technical reasons may be, I guess the biggest factor in all of this are our own habits.

Our monkey brains still depend on patterns for problem solving - if we find a way of doing things that works, our minds will quickly reach for that pattern the next time we encounter that problem.

While learning the syntax for any given CSS feature is usually not that hard, re-wiring our brains to think in new ways is significantly harder. We’ll not only have to learn the new way, we’ll also have to unlearn the old way, even though it has become muscle memory at this point.

So how can we overcome this? How can we train ourselves to change the mental model we have for CSS, or at least nudge it in the new direction?

Re-thinking established patterns

If we want to adopt some of the broader new architectural features, we need to find ways to think about them in terms of reusable patterns.

One of the reasons BEM is still holding strong (I still use it myself) is because it provides a universal pattern of approaching CSS. In a common Sass setup, any given component might look like this:

// _component.scss
.component {
    // block styles
    position: relative;

    // element styles
    &__child {
        font-size: 1.5rem;
    }

    // modifier styles
    &--primary {
        color: hotpink;
    }

    // media queries
    @include mq(large) {
        width: 50%;
    }
}

The BEM methodology was born in an effort to side-step the cascade. While we now have better scoping and style encapsulation methods, the basic idea is still quite useful - if only as a way to structure CSS in our minds.

I think learning new architectural approaches is easier if we take existing patterns and evolve them, rather than start from scratch. We don’t have to re-invent the wheel, just put on some new tyres.

Here’s an example that feels similar to BEM, but sprinkles in some of the new goodness:

/* component.css */

/* Layer Scope */
@layer components.ui {
    /* Base Class */
    .component {
        /* Internal Properties */
        --component-min-height: 100lvh;
        --component-bg-color: #fff;

        /* Block Styles */
        display: grid;
        padding-block: 1rem;
        min-block-size: var(--component-min-height);
        background-color: var(--component-bg-color);

        /* Child Elements, Native CSS Nesting */
        & :is(h2, h3, h4) {
            margin-block-end: 1em;
        }

        /* States */
        &:focus-visible {
            scroll-snap-align: start;
        }

        &:has(figure) {
            gap: 1rem;
        }

        /* Style Queries as Modifiers */
        @container style(--type: primary) {
            font-size: 1.5rem;
        }

        /* Container Queries for component layout */
        @container (min-inline-size: 1000px) {
            --component-min-height: 50vh;
            grid-template-columns: 1fr 1fr;
        }

        /* Media Queries for user preferences */
        @media (prefers-color-scheme: dark) {
            --component-bg-color: var(--color-darkblue);
        }

        @media (prefers-reduced-motion: no-preference) {
            ::view-transition-old(component) {
                animation: fade-out 0.25s linear;
            }
            ::view-transition-new(component) {
                animation: fade-in 0.25s linear;
            }
        }
    }
}

My preferred way of learning new techniques like that is by tinkering with stuff in the safe playground of a side project or a personal site. After some trial and error, a pattern might emerge there that sort of feels right. And if enough people agree on a pattern, it could even become a more common convention.

One step at a time

When learning new things, it’s important not to get overwhelmed. Pick an achieveable goal and don’t try to refactor an entire codebase all at once.

Some new features are good candidates to test the water without breaking your conventions:

You can try to build a subtle view transition as a progressive enhancement to your site, or you could build a small component that uses container queries to adjust its internal spacing.

In other cases, browser support also does not have to be 100% there yet. You can start using logical properties in your project today and use something like postcss-logical to transform them to physical ones in your output CSS.

Whatever you choose, be sure to give yourself enough space to experiment with the new stuff. The devil is in the details, and copy-pasting some new CSS into your code usually doesn’t give you the best insight - kick the tyres a bit!

Finding inspiration

One thing I’d really love to see more of are “best practice” examples of complete sites, using all the new goodness. They help me see the bigger picture of how all these new techniques can come together in an actual real-life project. For me, the ideal resource there are (again) the personal sites of talented people.

• How do they structure their layers?
• How do they set up containers?
• What sort of naming conventions do they use?
• What problems are they solving, and how does the new architecture improve things?

Answering these questions helps me to slowly nudge my brain into new ways of thinking about all this.

Having said all that: you absolutely don’t have to use all the latest and greatest CSS features, and nobody should feel guilty about using established things that work fine. But I think it helps to know which specific problems these new techniques can solve, so you can decide whether they’re a good fit for your project.

And maybe we can still learn some new CSS tricks after all.

Work

We built a lot of interesting projects in 2023 with Codista, and we’ve had a very good year working with established clients and partners. Some of it has been quite challenging, but we managed to pull off a stellar track record of successful projects, and I’m really proud of our small company!

We also hired our first front-end developer (other than myself). I’ve posted the job listing on our own website and on Mastodon, and with the help from the web dev community, we found somebody who fits our team really well and I’m very happy with them. A big thanks to everyone who boosted the post or mentioned it at meetups!

Health

I’ve struggled a bit with personal health issues this year. I have a moderately severe form of atopic dermatitis, an auto-immune disease of the skin. I’ve had it all my life. Some days it feels OK, while on others it feels like my skin is on fire and it’s hard to concentrate on anything else besides the impulse to scratch. If you’ve ever seen me give a talk and my face was bright red, it’s not (only) because I’ve been drinking the night before.

When I was younger I’ve tried different forms of therapy, but none of them really worked - so I’ve become pretty much used to living with it. But then it got a lot worse in 2023. I couldn’t sleep properly anymore and it started to affect other areas of my life, so I decided to take another shot at fighting it.

I got a new doctor and started treatment with a new drug that recently got EMA approval. After half a year, I switched to a different drug, which I’m currently still evaluating. First results have been promising though, so fingers crossed that this is the one. Would certainly make my 2024 more pleasant.

Traveling

I was fortunate enough to see some beautiful places this year. Event though my pre-pandemic days of traveling the more remote parts of the world are likely over, it’s still nice to get out and explore again.

I went to Zurich for a client workshop in the spring, and immediately followed that up with a trip to Amsterdam for CSS Day 2023. That conference was one of the best I’ve ever been to. Even though I caught a pretty bad cold and had to skip some of the fun - the talks, people and just overall atmosphere of that event were amazing.

I’m grateful I got to see so many familiar faces and talk to some of my web friends in person. I also left the conference feeling very inspired and (as always) a little guilty that I can’t find enough time for community work and writing. Hopyfully next year my schedule will allow for a bit more of that.

In the summer, we went for a vacation in the south of Croatia and spent two weeks on the Dalmatian coast.

We also did some more work on our small garden house in Lower Austria and had a few lovely days in autumn hiking the surrounding hills and vineyards.

Music, Movies, Books and Stuff

I enjoyed lots of stuff this year, so I’ll just give you the top 3 of each:

Music

• GoGo Penguin (Jazz/Fusion)
• Run The Jewels (Hip Hop)
• Broken Bells (Indie Rock)

Movies

• Renfield (Horror/Action)
• Everything, Everywhere, All at once (Action/Sci-Fi)
• Barbie Movie (Comedy)

Books

• “The Expanse” by James S.A. Corey (9-part Series, Sci-Fi)
• “Felix Blom” by Alex Beer (German, Thriller)
• “Novacene” by James Lovelock (Non-Fiction)

Stuff

• Anker Nebula Capsule Max - a great portable projector the size of a beer can, supports streaming and external drives
• Fender Paramount PD-220E - acoustic guitar I got after my old one was stolen. really bright, warm sound
• Superdry Sports Puffer - just a nice comfy winter jacket

Tech

I think I’ve grown a bit weary of the tech industry this year. I still love the web and I love what I do for work, but I lost some of my interest in new developments, new frameworks, the hot tech of the day. I just don’t care as much anymore.

It may also be the rising topic of AI that is popping up everywhere you look, or the crypto-esque attitude that seems to go along with it. Instead of being excited about new possibilites, I feel a bit disheartened by the trends I see. AI looks like a great tool, but everything I read about how it’s actually applied comes from the same hyper-captitalist mindset that brought us gems like bitcoin mining and NFTs. I don’t know, maybe I’m just tired.

There are other trends as well that I feel more optimistic about. Ones that call for a weirder web with more original, human content. It could just be wishful thinking, but I’ve caught glimpses of that version of the future for a while now. Here’s hoping.

Well, that’s all folks. See you in 2024!

Ok fine, I trash-talked Manuel’s website on Mastodon and he correctly pointed out that while I wrote an impressive two (2) blogposts last year, he wrote around 90 (while also doing talks, audits, raising an infant daughter and probably training for a marathon or some shit like that, I mean let’s face it the guy is annoyingly productive).

I know I was slacking off a bit and those numbers speak for themselves. While I generally want to write, ideas rarely make it all the way to a published post.

Like many others, “write more” is high up on my imaginary list of life improvements and although I don’t usually do new year’s resolutions, now feels like a good time to re-evaluate what’s stopping me there.

I came up with seven reasons that I use to justify why I’m not writing. In a confusing twist of perspective, I’m also going to try and talk myself out of them by explaining to you, dear Reader, why they are bullshit.

I don’t have time

This is the big one, right? We all have other things to do, and writing takes time. In my case, I’ve been really swamped with client projects and other work last year.

I think if you actually want to write though, it’s more a lack of routine than a lack of time itself. People who consistently produce content have learned to make a habit out of it. I read “Atomic Habits” by James Clear a couple of months ago and its message kinda stuck with me. It’s about conditioning yourself to do certain things more often by building a routine.

Take 15 minutes every day before you check your email and just write. Or do it on your commute to work if possible! The trick is to use amounts of time that are so small you can’t possibly not fit them in your schedule. It may not be enough for a fully-fledged article, but enough to build a habit.

It’s also worth noting that your writing doesn’t always have to be well-crafted longform blogposts. It can just be a few paragraphs about your thoughts, linking out to other stuff. Chris does a great job at this, and others have recently adopted even shorter formats, mimicking social media posts in length.

I don’t have anything interesting to say

The classic impostor syndrome comes out here. I don’t know anything special, so why bother?

The truth is that everyone has something interesting to say because everyone faces different challenges. You don’t have to go viral and make buzzword-riddled thinkpieces about the current hot topic - There’s enough sites who already do that, and AI will soon produce a shitton more of it.

A better plan is to write about what you know and experience in your day-to-day life instead. Authentic posts are always helpful, and you will solidify your own knowledge in the process too.

Here are a few common writing prompts and examples for blogposts I love to read:

• “I learnt something” (TIL)
  Michelle Barker: Negative Animation Delay
• “I noticed something”
  Dave Rupert: I’m Shadow Banned by DuckDuckGo (and Bing)
• “I built something”
  Lynn Fisher: lynnandtonic.com Refresh
• Year in Review
  Sophie Koonin: 2022: The year in lists
• Personal Stuff!
  Cassie Evans: My typical day

I gotta fix [X] on my site first

This one is especially popular among developers. “How can I possibly write anything before the typography is perfect? How can I ever publish anything when comments are not implemented yet?” We love to tinker with our websites and that’s cool, but at some point it gets in the way of actually using your blog and creating content.

Despite what we tell ourselves, it really doesn’t matter too much how a blog looks or what features it has. People come for the content, and as long as they can read it, they’re happy. Throw in an RSS feed so everyone can use their own reader and you’re golden. It pains me to say it but Manuel is absolutely correct here.

And if he can be “redesigning in the open” for three years while churning out massive amounts of CSS knowledge, your site will be fine too. 😉

Others have already written about this

Sometimes I’ve got a great idea for a post, but an initial Google search reveals that someone else already beat me to it. The novelty has worn off and that other post is way better than what I could have come up with anyway, I tell myself.

That’s not a real reason of course, nobody has a monopoly on a subject. Others may have already covered the topic - but not in your voice, not from your perspective. You could write a post about the exact same thing and still provide valuable information the other author has missed. Or you could approach the subject from a different angle, for a different skill-level or for a different audience.

Another way is to read the material that is already available and take notes about all the questions you still have afterwards. Try to actually do the thing (write the code, use the app, whatever) and see what other information would have been helpful for you to have. Write that!

The moment for this has passed

There are writing ideas that are inspired by some event or conversation. Maybe something big happened on the web or I’ve had a particularly interesting discussion on social media. So I sketch out a quick outline for a post and stick it in my drafts folder, thinking I’ll get back to it later.

Three weeks pass and that lonely draft sits around gathering dust, and by the time I remember it, the moment has passed. The conversation has moved on, and so the post is abandoned and eventually deleted.

The internet moves pretty fast and there’s always a “hot topic of the day”, but that doesn’t mean that nobody is interested in anything else. A beautiful thing about blogs is that they’re asynchronous. You can just write things and put them out there, and even if they don’t hit a nerve immediately, people can discover them in their own time.

Older posts can also get re-discovered years later and get a second wind, not to mention that people constantly search for specific things - and your post might be just what they’re looking for then! Some of my old posts about webrings and the IndieWeb have recently found readers again since Twitter has started going down the drain. You never know!

I can’t get it to sound right

Most of the (tech) blogs I read are in English, even though its authors are from all over the world. For a non-native english speaker like myself, it can sometimes be daunting to write in a foreign language. This is a barrier when it comes to producing “polished” text - there’s extra brain cycles involved in getting your ideas to “sound” right.

This is probably not a big deal though. People don’t expect to read world-class literature when they come to check out a blogpost about “Lobster Mode”. As long as you can get your point across, it’s fine if you don’t use fancy words. It can also be an advantage: for an international audience, simple English might even be easier to understand.

That being said, this is a usecase where AI might actually be helpful! While LLMs like GPT-3 and co are useless at creating actual content or original thoughts, they’re great at making sentences sound nice. Tools like Jasper can rewrite your copy and improve the tone without changing the contained information. Sort of like prettier but for English prose.

Nobody’s going to read it anyway

Let’s be honest: nobody likes to shout into the void. Everyone wants their content to be seen, and social validation is the sweet sweet dopamine reward we all crave.

There’s nothing wrong with sharing your work on social media or popular orange link aggregators either, but sometimes there just won’t be much of a reaction after you publish. That can feel frustrating - but ultimately I think obesessing over vanity metrics is not worth it anyway. Just because something doesn’t make the frontpage of Reddit does not mean it’s not valuable.

Don’t underestimate how many people actively read personal blogs though! The web dev community is especially fond of RSS, and with the Fediverse gaining more and more popularity, original content on your own domain has a much better reach now than before.

Who’s gonna read your personal blog because it has an RSS feed? I’m gonna read your personal blog because it has an RSS feed. pic.twitter.com/mtcyKhEVet

— Chris Coyier (@chriscoyier) January 7, 2020

Right, I realize it’s a bit weird to write a post about how I don’t write posts. But I hope to push back on this in 2023 and find more time for writing. I also suspect that other people have similar reasons and maybe talking about them helps a bit.

In any case, that’s one more post in the bank!

Since there’s a good chance that you -like me- are involved in web development and/or have a special interest in technology, I want you to play along and engage in a thought experiment for this post:

Imagine you’re a regular user.

Imagine you have never heard of git branches, postgres or a “webpack config” (lucky you). You really don’t care about all of that, but you do care about your friends and your connections online.

Ever since Elon took over (and actually even some time before that) Twitter has been feeling increasingly hostile. People start leaving, and you hear them talk about alternatives. You’re curious, so you type “mastodon” into Google and see what comes up.

You find the website and want to sign up. It tells you to choose a server:

Ok wait, you wanted to join mastodon, what’s all this now? Tildes? Furries? Some Belgian company? Why do you have to apply? Everyone else had that mastodon.social handle - Can’t you just use that? The real one? What the hell is a fediverse?

Confused, you close the site. This seems like it’s made for someone else. Maybe you’ll stick around on Twitter for a while longer, while it slowly burns down.

You can be a developer again now.

You and I know the reasons for that experience. We know that a decentralized system has to look like this, and that the choice of instance doesn’t even matter all that much. But I’ve heard this exact story a couple of times now, all from people outside my IT filter bubble.

Why was it so easy to drive these people away?

The Web as a Commodity

Being on the web has been heavily commoditized.

In the days of IRC and message boards, or later in the 2000s blogging era, federation was very much the norm. It was the default mode of the web: people grouping together in small communities around shared interests, but scattered on many different sites and services. It was normal to explore, find new places and discover new things by venturing out.

Through the rise of social media though, people have gotten used to being in one place all the time. Now we expect a system that’s easy to set up, handles millions of users at once and makes every interaction frictionless. We expect it to know what we want, and give it to us instantly. Anything too weird or tech-y and you start to lose people.

Mastodon is not supposed to be a second Twitter. Many of its features were designed specifically to avoid becoming another content silo and repeating the same mistakes, yet the assumption seems to be that everything should stay the same as before.

It’s like everyone has spent the last few years in a giant all-inclusive resort, screaming at each other for attention at the buffet. Now we’re moving into nice little bed-and-breakfast places, but we’re complaining because it takes slightly more effort to book a room, and the free WIFI isn’t as fast.

Maybe its time to rethink some of these expectations. Maybe we need some of that early internet vibe back and be ok with smaller, closer communities. Maybe we can even get some of the fun back and start exploring again, instead of expecting everything to be automatically delivered to us in real time.

We can remind ourselves of what social media used to be: a way to connect around shared interests, talk to friends, and discover new content. No grifts, no viral fame, no drama.

Lowering the Barrier

Adjusting expectations is one part - but at the same time, we as developers have to try and make these systems as approachable as possible without compromising on their independence. A lot of alternative content publication methods are still very much geared towards the IT bubble.

You could loosely map some of them by how easy it is to get started if you have no technical knowledge:

Generally speaking: The more independence a technology gives you, the higher its barrier for adoption.

I love the IndieWeb and its tools, but it has always bothered me that at some point they basically require you to have a webdevelopment background.

How many of your non-tech friends publish RSS feeds? Have you ever seen webmentions used by someone who isn’t a developer? Hell, even for professional devs it’s hard to wire all the different parts together if you want to build a working alternative to social media.

If you want the independence and control that comes with some of these IndieWeb things, you just have to get your hands dirty. You can’t do it without code, APIs, servers and rolling your own solutions. It’s just harder.

My point is this: it shouldn’t be.

Owning your content on the web should not require extensive technical knowledge or special skills. It should be just as easy as signing up for a cellphone plan.

I know it’s no small feat to lower that barrier. Making things feel easy and straightforward while handling the technical complexity behind them is quite a challenge. Not to mention the work and financial cost involved in running systems that don’t generate millions of ad revenue.

Mastodon, Ghost, Tumblr, micro.blog and others are working hard on that frontier; yet I feel they are still not widely used by the average person looking to share their mind.

Seizing Momentum

I think we’re at a special moment right now. People have been fed up with social media and its various problems (surveillance capitalism, erosion of mental health, active destruction of democracy, bla bla bla) for quite a while now. But it needs a special bang to get a critical mass of users to actually pack up their stuff and move.

When that happens, we have the chance to build something better. We could enable people to connect and publish their content on the web independently – the technology for these services is already there. For that to succeed though, these services have to be useable by all people - not just those who understand the tech.

Just like with migration to another country, it takes two sides to make this work: Easing access at the border to let folks in, and the willingness to accept a shared culture - to make that new place a home.

Growing up with the web as a teenager meant having access to an infinite treasure chest of content. A lot of that content was spread across blogs, forums and personal websites.

The overwhelming motivation behind it seemed to be “I made something, here it is”. Sharing things for the sake of showing them to the world. Somebody had created something, then put it online so you could see it. Visit their website (wait for the dial-up to finish), and it’s yours.

Follow any link on the web today and you’ll likely be met with a different scenario:

• Cookie consent pops up, intentionally confusing.
  (You're tired - just hit "Accept All".)
• App download banner asks you to install the native app.
  (Dismiss.)
• Newsletter modal blocks the site, asking for your email address. (Close it.)
• Start reading a few paragraphs, before another modal requires you to create an account. (Leave site, frustrated.)

Notice how everything about that interaction is designed to extract value from your visit. The goal here is not for you to read an article; it’s to get your analytics data, your email, your phone and your money.

It’s the symptom of a culture that sees the web purely as a business platform. Where websites serve as eloborate flytraps and content as bait for unsuspecting users.

In this culture, the task of the self-appointed web hustler is to build something fast & cheap, then scale it as much as possible before eventually cashing out.

• You see it in email bots, spamming blogs for link placements and sponsored posts.
• You see it in Twitter accounts where grifters try to monetize their “communities” with useless ebooks.
• You see it in crypto, burning the planet for quick profits.

web3 and NFTs are the latest evolution of this culture. The latest attempt to impose even more artificial locks and transactions on users, to extract even more money.

This is the web as envisioned by late-stage capitalism: a giant freemium game where absolutely everyone and everything is a “digital asset” that can be packaged, bought and sold.

Don’t bring wall street to a web fight

Sure, the web has changed since the 90s. It has “grown up”.

Of course there are lots of legitimate reasons to monetize, and creators deserve to be compensated. It’s not about people trying to make a buck. It’s about those treating the web simply as a market to run get-rich-quick schemes in, exploiting others out of pure greed.

We’ve gotten so used to it that some can’t even imagine the web working any other way - but it doesn’t have to be like this.

At its very core, the rules of the web are different than those of “real” markets. The idea that ownership fundamentally means that nobody else can have the same thing you have just doesn’t apply here. This is a world where anything can easily be copied a million times and distributed around the globe in a second. If that were possible in the real world, we’d call it Utopia.

It’s also a world that can be shaped by the consumer:

Large companies find HTML & CSS frustrating “at scale” because the web is a fundamentally anti-capitalist mashup art experiment, designed to give consumers all the power.

Sorry I didn’t quote tweet anything in order to say that.

— Mia, with valuable secrets 🤫 (@TerribleMia) November 24, 2019

This “mashup art experiment”, as Mia calls it, is what made the web great in the first place. It’s the reason it became a global phenomenon and much of it is centered around the idea that digital content is free and abundant.

Resource Scarcity doesn’t make sense on the web. Artificially creating it here serves no other purpose than to charge money for things that could easily have been free for all. Why anyone would consider that better is beyond me.

Freedom of content

The online game Wordle recently took the world by storm. To the utter shock of many, it is just a free piece of content. A free and open web game millions can enjoy, no strings attached.

Its creator, Josh Wardle, originally built the game for his partner and put it online. “I made something, here it is”. Despite its success, he had no intention to monetize it through apps or subscriptions - and the world is richer for it. When questioned about it, he said this:

I think people kind of appreciate that there’s this thing online that’s just fun. It’s not trying to do anything shady with your data or your eyeballs. It’s just a game that’s fun.

Because the notion that monetization is the only worthwhile goal on the web is so widespread, this is somehow a very controversial take. You can actually stand out of the crowd by simply treating the web platform as what it is: a way to deliver content to people.

Despite what web3 claims, it’s possible to “own” your content without a proof of it on the blockchain (see: IndieWeb). It’s also possible to create things just for the sake of putting them out into the world.

The best growth hack is still to build something people enjoy, then attaching no strings to it. You’d be surprised how far that can get you.

Make free stuff! The web is still for everyone.

👉 Update: On Feb 1, Wordle was eventually sold to the New York Times for upwards of a million dollars. Josh Wardle claims the game will still remain free to play for all.

Ethan, who coined the term responsive web design over a decade ago, has recently said that media-query-less layouts are certainly within bounds:

Can we consider a flexible layout to be “responsive” if it doesn’t use any media queries, but only uses container queries? [...] I’d be inclined to answer: yes, absolutely.

Over at CSS-Tricks, Chris had similar thoughts. He issued a challenge to examine how and where media queries are used today, and if they will still be necessary going forward:

A common refrain, from me included, has been that if we had container queries we’d use them for the vast majority of what we use media queries for today. The challenge is: look through your CSS codebase now with fresh eyes knowing how the @container queries currently work. Does that refrain hold up?

Fair enough.
I took the bait and had a look at some of my projects - and yes, most of what I use @media for today can probably be accomplished by @container at some point. Nevertheless, I came up with a few scenarios where I think media queries will still be necessary.

For page layout

While container queries can theoretically be used to control any element, they really shine when applied to reusable, independent components. The canonical example is a card component: a self-contained piece of UI you can put anywhere.

Page layouts, on the other hand, are better suited for media queries in my opinion. Page layouts are usually at the very top level of the DOM, not nested in another container. I’ve never encountered a case where the main page layout had to adapt to any other context than the viewport.

.layout {
    display: grid;
}
@media (min-width: 60em) {
    .layout {
        grid-template-rows: 4rem 1fr auto;
        grid-template-columns: 25% 1fr;
        grid-template-areas: 
            "header header"
            "sidebar main"
            "footer footer";
    }
}

For global tokens

Another good usecase for media queries is to set global design tokens, like spacing or font-sizes. With CSS custom properties it’s now much easier to have fine-grain control over global styles for different devices.

For example, you might want to have bigger text and more whitespace on a large TV than you want for a mobile screen. A larger screen means the user’s head will be physically farther away.

It only makes sense to use a media query there - since the reason for the change is the size of the device itself, not the width of any specific element.

:root {
    /* Font Sizes */
    --font-size-headline-l: 1.875rem; 
    --font-size-headline-m: 1.75rem; 
    --font-size-headline-s: 1.5rem;
    --font-size-copy-l: 1.125rem;
    --font-size-copy-s: 0.875rem;

    /* Global Spacing */
    --spacing-x: 1rem;
    --spacing-y: 1rem;
}
@media (min-width: 48em) {
    :root {
        --font-size-headline-l: 2.5rem;
        --font-size-headline-m: 2rem;
        --font-size-headline-s: 1.75rem;
        --font-size-copy-l: 1.25rem;
        --font-size-copy-s: 1rem;

        --spacing-x: 2rem;
        --spacing-y: 2rem;
    }
}

For user preference and actual “media” queries

Screen dimensions are not the only things we can detect with media queries. The Media Queries Level 4 Spec (with Level 5 currently a working draft) lists many different queries related to user preference, like:

• prefers-reduced-motion
• prefers-contrast
• prefers-reduced-transparency
• prefers-color-scheme
• inverted-colors
• and others

We can use these to better tailor an experience to the current user’s specific needs.

Other media queries allow for micro-optimizations based on a device’s input method (i.e. touch or mouse):

/* fine pointers (mouse) can hit smaller checkboxes */
@media (pointer: fine) {
  input[type="checkbox"] {
    width: 1rem;
    height: 1rem;
    border-width: 1px;
    border-color: blue;
  }
}

/* coarse pointers (touch) need larger hit areas */
@media (pointer: coarse) {
  input[type="checkbox"] {
    width: 2rem;
    height: 2rem;
    border-width: 2px;
  }
}

Finally, there are actual “media type” queries like @media print that won’t go anywhere. And there are experimental ideas being discussed for new media queries, like this one for “foldable” devices:

:root {
    --sidebar-width: 5rem;
}
/* if there's a single, vertical fold in the device's screen, 
   expand the sidebar width to cover the entire left side. */
@media (spanning: single-fold-vertical) {
    :root {
        --sidebar-width: env(fold-left);
    }
}
main {
    display: grid;
    grid-template-columns: var(--sidebar-width) 1fr;
}

For fixed-to-window stuff

Components that are taken out of the normal document flow don’t have to care about their containers. Some UI elements are fixed to the viewport itself, usually oriented along an edge of the screen.

Have a look at Twitter’s “Messages” tab at the bottom of the screen for example. Its relevant container is the window, so it makes sense to use a media query here and only apply position: fixed at some breakpoint.

For heights

The current implementation of @container only allows querying the width of an element (its “inline” axis), not its height.

👉 Update: Miriam tells me that it is possible to query the height of containers, provided they are defined as size rather than inline-size. The exact value name of this is still in flux at the time of writing.

Style adjustments in relation to width are probably the primary use case for most UI elements anyway, but there are still cases where screen height is an issue. Here’s an example from a “hero image” component:

.hero {
    display:flex;
    flex-direction: column;
    height: 100vh;
}
/* if the screen is really tall, don't fill all of it */
@media (min-height: 60em) {
    .hero {
        height: 75vh;
    }
}

Mix Container Queries and Media Queries

While I think container queries will eventually replace most “low level” responsive logic, there are still a lot of good usecases for trusty media queries.

A combination of both techniques will probably be the best way forward. @media can handle the big picture stuff, user preferences and global styles; @container will take care of all the micro-adjustments in the components themselves.

A perfect team!

I came up with this demo of a book store. Each of the books is draggable and can be moved to one of three sections, with varying available space. Depending on where it is placed, different styles will be applied to the book. The full source code is up on Codepen. Here’s how it looks:

Here’s what’s going on

Each of these books is a custom element, or “web component”. They each contain a cover image, a title and an author. In markup they look like this:

<book-element color="#ba423d">
    <img slot="cover" src="/books/1984.avif" alt="cover by shepard fairey" />
    <span slot="title">1984</span>
    <span slot="author">George Orwell</span>
</book-element>

This then gets applied to a template which defines the internal Shadow DOM of the component. The <slot> elements in there will get replaced by the actual content we’re passing in.

<template id="book-template">
    <style></style>
    <article class="book">
        <div class="front">
            <slot name="cover"></slot>
        </div>
        <div class="meta">
            <h2 class="title"><slot name="title"></slot></h2>
            <p class="author"><slot name="author"></slot></p>
        </div>
    </article>
</template>

Alright, nothing too fancy yet, just some basic structure.

The magic happens when we apply some internal styling to this. Everything inside that <style> tag will be scoped to the component - and since styles can not leak out of the shadow DOM and we can’t (easily) style its contents from the outside, we have real component encapsulation.

Container Queries are one of the last few missing puzzle pieces in component-driven design. They enable us to give components intrinsic styles, meaning they can adapt themselves to whatever surroundings they are placed in.

The new key property there is container-type - it lets us define an element as a container to compare container queries against. A value of inline-size indicates that this container will response to “dimensional queries on the inline axis”, meaning we will apply different styles based on its width.

We can also give our container a name using the container-name property. It is optional in this example, but you can think of it in the same way that grid-area lets you define arbitrary names to use as references in your code later.

<template id="book-template">
    <style>
    /* Use Web Component Root as the Layout Container */
    :host {
        display: block;
        container-type: inline-size;
        container-name: book;
    }
    </style>
    ...
</template>

In the bookstore demo, I created three variants that depend on the width of the component’s :host (which translates to the <book-element> itself). I’ve omitted some of the styling for brevity here, but this part is where we define the multi-column or 3D book styles.

/* Small Variant: Simple Cover + Title */
@container (max-width: 199px) {
    .book {
        padding: 0;
    }
}
/* Medium Variant: Multi-Column, with Author */
@container (min-width: 200px) and (max-width: 399px) {
    .book {
        display: grid;
        grid-template-columns: 1fr 1fr;
        gap: 1rem;
    }
}
/* Large Variant: 3D Perspective */
@container (min-width: 400px) {
    .book {
        position: relative;
        transform-style: preserve-3d;
        transform: rotateY(-25deg);
    }
}

By adding Dragula.js to enable drag-and-drop functionality, we can then move the individual components around. As soon as they’re moved to a different section in the DOM, its internal styles are re-calculated to match the new environment, and the corresponding CSS block is applied. Magic!

The Bento Box Idea

Now theoretically, we could have achieved a similar effect by using the cascade itself. We could for example apply the 3D styles to all .books inside .stage. But that would have some problems:

• it wouldn’t be responsive - if .stage ever gets too narrow, it would break
• it would create an unwanted dependency context between parent and child
• it would break component encapsulation and mix layout with content styles

It’s generally a good idea in CSS to separate “layout” from “content” components and let each handle their own specific areas of responsibility. I like to think of Japanese bento boxes as a metaphor for this: a container divided into specific sections that can be filled with anything.

For example, the layout for our bookstore looks like this:

It’s a grid divided into three sections, the middle one containing a nested flexible grid itself.

<div class="layout">
    <div class="stage"></div>
    <main class="content">
        <ul class="itemlist"></ul>
    </main>
    <div class="cart"></div>
</div>

/* main layout sections */
.stage,
.content,
.cart {
    padding: var(--spacing);
}

/* nested sub-grid */
.itemlist {
    display: grid;
    grid-template-columns: repeat(auto-fill, minmax(200px, 1fr));
    gap: var(--spacing);
}

/* desktop layout */
@media (min-width: 1024px) {
    .layout {
        display:grid;
        height: 100vh;
        grid-template-columns: 480px 1fr 130px;
    }
}

The parts of the layout are only concerned with the alignment and dimensions of boxes. They have no effect whatsoever on their children other than giving them a certain amount of space to fill. Just like a bento box, it doesn’t care what we put into it, so we could easily re-use the layout for a completely different product. It is content-agnostic.

That’s why Container Queries pair so well with Web Components. They both offer ways to encapsulate logic to build smart, independent building blocks. Once they’re defined, they can be used anywhere.

Container Queries bring us one step closer to “Intrinsic Layouts” and a future of truly independent, component-driven design. Exciting stuff ahead!

Further Reading

• CSS Container Queries - MDN
• Container Queries Explainer & Proposal - Miriam Suzanne
• Component-level art direction with CSS Container Queries - Sara Soueidan
• Discussion about Container Queries in srcset and sizes - CSSWG on Github

While some static site generators have a standardized way of handling assets, Eleventy does not. That’s a good thing - it gives you the flexibility to handle this any way you want, rather than forcing an opinionated way of doing things on you that might not fit your specific needs.

That flexibility comes at a price though: you need to figure out your preferred setup first. I’ve tinkered with this a lot, so I wanted to share my learnings here. BTW: My personal setup “Eleventastic” is also available on Github.

The most common requirement for an asset pipeline is to build CSS and Javascript. That process can have different flavors - maybe you need to compile your stylesheets through Sass or PostCSS? Maybe you want Tailwind? Maybe your Javascript is “transpiled” in Babel (translated from modern ES6 to the more compatible ES5 syntax) or bundled by webpack? Or maybe you want to do something entirely different, like build SVG icon sprites or optimize images?

Whatever you want to achieve, it usually involves plugging some tool into your Eleventy workflow. I’ve looked at several ways to tackle that problem - here are a few possible approaches you can take.

NPM scripts for everything

One solution is to let Eleventy handle just the SSG part (producing HTML) and define other processes to take care of your assets outside of it. The most common way to do this is through npm scripts. If you’re not familiar with these, they are essentially shortcuts to run node commands, defined in your package.json file.

So if you wanted to i.e. compile your CSS from a bunch of Sass files, you could set up your NPM scripts like this:

// package.json

"scripts": {
  "watch:sass": "sass --watch _src/sass:_site/assets/styles",
  "build:sass": "sass _src/sass:_site/assets/styles",
  "watch:eleventy": "eleventy --serve",
  "build:eleventy": "eleventy",
  "start": "npm-run-all build:sass --parallel watch:eleventy watch:sass",
  "build": "npm-run-all build:eleventy build:sass"
}

The watch:sass and build:sass scripts here both run the Sass compilation command, just with a different configuration depending on context.

With utilities like npm-run-all, you can even run multiple scripts at once. So one “main command” like npm start will run Eleventy and simultaneously start watching your Sass files for changes, and recompile them when they do.

This solution is extremely flexible. There are node tools for everything, and there’s no limit to what you can do. However depending on how complex your build is, the setup can get a bit unwieldy. If you want to manage multiple asset pipelines that have to run in a specific order with a specific configuration, it’s not that easy to keep track of things.

And since each of these scripts is a separate process that runs outside of Eleventy, it has no knowledge about any of them. You can tell Eleventy to watch for changes that these external builds cause, but things can get complex if tasks depend on each other. You can also run into situations where multiple passes are required to achieve the desired output, and since Eleventy can’t optimize for processes outside of itself, large pages can take longer to build.

Manage build tasks with Gulp

Another popular solution is to use Gulp to manage assets. Although it is not the hottest new tech on the block anymore (pssst: it’s OK to use tools that are older than a week), it’s still a perfect tool for the job: Gulp takes in a bunch of source files, runs them through any transformations you want and spits out static files at the end. Sounds exactly right!

Gulp is a node-based task runner lets you define your asset pipelines as functions in a “Gulpfile” like this:

// Gulpfile.js

const gulp = require('gulp')
const sass = require('gulp-sass')

// define sass compilation task
gulp.task('styles', function() {
    return gulp
        .src('/main.scss')
        .pipe(
            sass({
                precision: 10,
                outputStyle: 'expanded'
            }).on('error', sass.logError)
        )
        .pipe(gulp.dest('/assets/styles'))
})

// define script bundling task
gulp.task('scripts', ...)

// Run the different tasks in the asset pipeline
gulp.task('assets', gulp.parallel('styles', 'scripts', 'icons', 'whatever'))

Then you kick things off from a single npm script like this:

"scripts": {
    "assets": "gulp:assets",
    "build": "eleventy --serve",
    "start": "npm-run-all --parallel build assets"
}

This is more readable and versatile than npm scripts, but really you’re doing the same thing under the hood. Gulp runs all the different processes behind the scenes and outputs the finished .css or .js files into our build folder.

The drawback here is that it locks you into the Gulp world of doing things. You often need gulp-wrapper packages for popular tools (e.g. gulp-sass instead of node-sass) to work with the “streaming” nature of it. Plus you’re still running external builds, so all of the pitfalls that come with npm scripts still apply.

One build to rule them all

The underlying issue with both these methods is the same: they need external build processes. That’s why some Eleventy setups are going a slightly different route: instead of running asset pipelines on the outside, they teach Eleventy itself to handle them. That way everything runs through a single, integrated process.

Think of your assets as just another static “page” here. Instead of markdown, a template takes Sass or ES6 as input, and instead of generating HTML, it runs it through a tool like node-sass or webpack and outputs CSS or JS.

By leveraging Javascript templates, you can configure Eleventy to process almost any file you want. To use them, first add the 11ty.js extension to the list of recognized input formats in your .eleventy.js config file:

// .eleventy.js

module.exports = function (eleventyConfig) {
    // add "11ty.js" to your supported template formats
    return {
        templateFormats: ['njk', 'md', '11ty.js']
    }
}

Now you can set up your asset pipeline by making a new template somewhere in your input folder. Let’s call it styles.11ty.js for example. It could look something like this:

// styles.11ty.js

const path = require('path')
const sass = require('node-sass')

module.exports = class {
    // define meta data for this template,
    // just like you would with front matter in markdown.
    async data() {
        return {
            permalink: '/assets/styles/main.css',
            eleventyExcludeFromCollections: true,
            entryFile: path.join(process.cwd(), '/main.scss')
        }
    }

    // custom method that runs Sass compilation
    // and returns CSS as a string
    async compileSass(options) {
        return new Promise((resolve, reject) => {
            const callback = (error, result) => {
                if (error) reject(error)
                else resolve(result.css.toString())
            }
            return sass.render(options, callback)
        })
    }

    // this function is mandatory and determines the contents of the
    // generated output file. it gets passed all our "front matter" data.
    async render({ entryFile }) {
        try {
            return await this.compileSass({ file: entryFile })
        } catch (error) {
            throw error
        }
    }
}

The permalink property here lets you define which file the template generates and where to put it. You can use any type of data as input, then transform it somehow and return it in the render method. We’ve essentially done the same thing as defining a Sass task in Gulp, but this time it’s part of the Eleventy build itself!

This gives you even more control over the process. For example - if the compilation fails, you can use that information in the build. You can catch errors in the Sass code and display a message as an overlay in Eleventy’s dev server:

Check out the Eleventastic source to see how to achieve this. (HT to “Supermaya” by Mike Riethmuller for the idea)

A single template can also build multiple files this way. Using Eleventy’s pagination feature, you can i.e. generate different Javascript bundles from different source files:

// scripts.11ty.js

const ENTRY_POINTS = {
    app: 'app.js',
    comments: 'comments/index.js',
    search: 'search/index.js'
}

module.exports = class {
    // again, the data() function does esentially the same
    // as defining front matter in a markdown file.
    async data() {
        return {
            // define a custom property "entryPoints" first
            entryPoints: ENTRY_POINTS,

            // then take each of the files in "entryPoints"
            // and process them separately as "bundleName"
            pagination: {
                data: 'entryPoints',
                alias: 'bundleName',
                size: 1
            },

            // for each bundle, output a different Javascript file
            permalink: ({ bundleName }) => `/assets/scripts/${bundleName}.js`,

            // keep the scripts.11ty.js itself out of collections
            eleventyExcludeFromCollections: true
        }
    }

    // a custom helper function that will be called with
    // each separate file the template processes.
    async compileJS(bundleName) {
        const entryPoint = path.join(process.cwd(), ENTRY_POINTS[bundleName])
        // do compilation stuff inhere like
        // run file through webpack, Babel, etc
        // and return the result as a string

        // --- omitted for brevity ---

        return js
    }

    // output the compiled JS as file contents
    render ({ bundleName }) {
        try {
            return await this.compileJS(bundleName)
        } catch (err) {
            console.log(err)
            return null
        }
    }
}

I personally prefer the fully-integrated way of doing things, because it’s easier for my brain to think of assets this way. HTML, CSS, JS, SVG: it’s all handled the same. However, your personal preference might differ. That’s OK - there really is no “right way” of doing this.

The beauty of unopinionated tools like Eleventy is that you get to choose what fits you best. If it works, it works! 😉

This feature was first made popular by Medium, where authors can pick a “top highlight” in a post and hovering it will show a tooltip with sharing options. I wanted something like this for independent blogging too, so I came up with a custom solution.

Here’s how that looks in action:

Here’s some highlighted text you can share! You shouldn’t though, this is obviously just a demo. Lorem Ipsum Dolor to you, friend!

How it works

The base of this feature is a <mark> tag wrapped in a custom <share-highlight> element.

If the Web Share API is supported (currently in Safari, Edge and Android Chrome), clicking the element will bring up your share options and insert the quoted text and a link to the current page. You can share it on any platform that registers as a share target.

If the API is not supported, the component will fall back to sharing on Twitter via tweet intent URL. The tooltip will show the Twitter icon and clicking the highlight opens a new tab with a pre-filled tweet:

How to use it

If you want to use this on your own site, follow these steps. (keep in mind that this is an early version though, and there are probably still some issues to sort out.)

1. Download the plugin with NPM by running npm i eleventy-plugin-share-highlight --save on the command line in your project’s root folder (where the package.json file is).
2. Add the plugin to your .eleventy.js configuration file:

// .eleventy.js
const pluginShareHighlight = require('eleventy-plugin-share-highlight');

module.exports = function (eleventyConfig) {
    eleventyConfig.addPlugin(pluginShareHighlight, {
        // optional: define the tooltip label.
        // will be "Share this" if omitted.
        label: "Teilen"
    })
}

3. This will register the highlight shortcode. You can use it in your templates or markdown files like this:

<!-- blogpost.md -->
{% highlight %}Here's some highlighted text you can share!{% endhighlight %}

This will highlight the containing text in a <mark> tag and wrap it in the custom element <share-highlight>. So the output HTML will look something like this:

<share-highlight label="Share this">
    <mark>Here's some highlighted text you can share!</mark>
<share-highlight>

If Javascript or Custom Elements are not supported, or if your post is displayed e.g. in an RSS reader, the <mark> tag will still be valid and give the highlighted text the correct semantics.

4. To further enhance that with the instant sharing function, you need to add the custom element definition first. Depending on your setup, you can either include that as part of a bundle by importing it directly:

import 'eleventy-plugin-share-highlight/share-highlight'

…or copy the file and add it directly to your HTML with something like:

<head>
    <script src="/js/share-highlight.js" async defer></script>
</head>

5. To style the highlight, add this piece of CSS and customize it to match your design:

/* general styles for text highlight */
mark {
    background-color: yellow;
}
/* styling if webcomponent is supported */
share-highlight {
    /* default state */
    --share-highlight-text-color: inherit;
    --share-highlight-bg-color: yellow;
    /* hover/focus state */
    --share-highlight-text-color-active: inherit;
    --share-highlight-bg-color-active: orange;
    /* tooltip */
    --share-highlight-tooltip-text-color: white;
    --share-highlight-tooltip-bg-color: black;
}

Accessibility Considerations

This is my first Eleventy plugin and also my first web component. I’m fairly confident that the Eleventy part is sound, but I don’t have much experience with web components, and I have some concerns.

My biggest issue with this is accessibility. I want the element to be keyboard-accessible, so I made it focusable and added keyboard listeners to trigger it with the Enter key. The tooltip label also doubles as the aria-label property for the component, but I don’t quite know how screenreaders handle custom elements with no inherent semantics.

I guess the cleanest option would be to use an actual <button> to trigger the share action, but I also need the element to be inline-level, so the highlighting doesn’t break text flow.

If you know your way around webcomponents and have a suggestion on how to improve this thing, please feel free to submit a PR!

It’s not often that a website stays up mostly unchanged for 25 years. So out of curiosity, I ran a quick check on both sites.

Unsurprisingly, the new site is a lot heavier than the original: with 4.673KB vs. 120KB, the new site is about 39 times the size of the old one. That’s because the new site has a trailer video, high-res images and a lot more Javascript:

This is keeping with the general trend of websites growing heavier every year, with the average site weighing in at around 1.900KB now.

But since our connection speeds and device capabilities are significantly better now - that’s fine. Everything is way faster now than it was back in the days of Michael Jordan’s first Looney Tunes adventure.

Is it though? Let’s find out.

Party like it’s 1996

1996 was a different time. The Spice Girl’s “Wannabe” was in anti-shock discmans everywhere, and the most common network connection was 56k dial-up modems. So of course the original developers had a smaller performance budget to work with, and the site is much lighter. Fair enough - so how long did it take to load the original Space Jam site back then?

I ran a webpagetest with a simulated '96 connection: dial-up on an average desktop computer. Dial-up had a maximum speed of 56 kbit/s, but in reality it came in at something around 40-50 kbit/s.

Here’s how that looked (fire up the dial-up noise in another tab for the full experience):

Test Summary | Film Strip View

We can see the first content (the “press box shuttle” menu item) after 4 seconds. The other menu items -all separate GIF images- come in slowly after that. Since the HTML renders as soon as it is parsed, you could theoretically already click on the items before the rest of the page has finished though. The whole site is done after 28.1 seconds in this test.

Back to the Future: 2021

Now let’s look at the current, futuristic state of the web. Luckily we don’t use dial-up anymore. The most common connection these days is a mobile 3G network, and the most common device is an Android phone (a Moto G4 in this test). A typical 3G connection comes in at around 1.5 Mbp/s, so it is roughly 30 times faster than dial-up. This shouldn’t take long:

Test Summary | Film Strip View

Funnily enough, the first meaningful paint also shows up after about 4 seconds. It’s not actual content though, it’s the loading screen, informing us that we’ve now loaded 0% of the site.

We reach 100% at 12 seconds, but the first real piece of content is not rendered until 21.5 seconds: it’s a youtube video in a modal window. The site is finally ready after 26.8 seconds, although actually playing the video would take some more loading time.

Results

Right. So after 25 years of technological progress, after bringing 4.7 billion people in the world online, after we just landed a fifth robot on Mars, visiting the Space Jam website is now 1.3 seconds faster. That seems… underwhelming.

__

I know that this is just a movie promo site. And of course the requirements for a website are different now - people expect rich content. But I think this speaks to a larger point:

Although connection speeds and devices keep getting better and better, the web is actually getting slower. We see the increasing bandwidth as an invitation to use more and more stuff in our websites. More images, more videos, more JavaScript.

We just keep filling the available space, jamming up the pipes in the process so nothing actually gets faster. Well, at least the dial-up sound is gone now.

However, it can get difficult to see what’s going on with them - especially if there’s a lot of “background noise”. Many sites just scrape content from well-known blogs and republish it for SEO juice. If that content includes a link to your site, it can lead to webmention spam.

Unlike on social media, you also don’t get notifications or reports about incoming webmentions. You’re just handed a bunch of raw data to use however you like. That’s part of the beauty of the Indieweb though: you can tailor it to whatever suits you best.

I recently started playing around with the data I get from webmention.io to see if it could be displayed in a more meaningful way. The result is a new side project I call:

✨✨✨ Webmention Analytics ✨✨✨
You can see it in action in this demo on my site.

I built this with Eleventy and Netlify, mainly because that’s my favorite tech stack to tinker with. But for analytics that don’t have to be real-time, static site generators are actually a really good fit.

Expensive computations like parsing and analyzing 8000+ data points like this can be run once a day through a periodic build hook. The reports it generates are then instantly available to the user, while still being up-to-date enough.

Features

• group webmention data by month
• overview of webmentions by type (like, reply, repost, mention, bookmark…) and day
• show top source URLs sending webmentions to your site
• show top target URLs on your site receiving webmentions
• show top tweets generating webmentions through brid.gy
• check incoming webmentions against a blocklist of known “content scrapers” and spam domains
• automatic daily updates with cron job

Get your own instance!

If you also use webmention.io to show webmentions on your site, you can fork the code on Github and make your own instance of webmention-analytics. Just follow the instructions in the README to get started.

That’s usually what you want to ensure everything is up-to-date. But there are special cases when keeping parts of the previous build around makes sense. For example, If you fetch lots of data from an external source during your build, it might make sense to cache that data and re-use it again in the future.

I recently found such a case when working on the Eleventy webmentions feature. For each build, a script queries the webmention.io API and fetches all the webmentions for the site. That can be a lot of data - and most of it stays the same, so fetching everything new again each time is sort of wasteful.

A Cache Folder

A better solution is to store the fetched webmentions locally in a separate _cache folder as JSON and give them a lastFetched timestamp. On the next go, we can load the old data straight from there and only query the API for webmentions newer than that timestamp.

My webmentions code does exactly that - but it had a big problem: that only worked locally. Since Netlify (where my site is hosted) throws everything out the window each time, I couldn’t use the cache there.

Plugins to the Rescue

To edit anything related to the Netlify build process itself, you need a build plugin. There is a directory of plugins available for you to choose from, but you can also define your own plugins and deploy them alongside the rest of your code.

To define a custom plugin, make a new directory called plugins and within that, a new directory for your code:

_cache
_site
src
plugins
└── webmention-cache
    ├── index.js
    └── manifest.yml
package.json
netlify.toml

Your plugin should contain at least two files: a manifest with some metadata, and the actual plugin code.
For the manifest file, let’s just set a name:

# manifest.yml
name: webmention-cache

The meat of the plugin is in the index.js file. There are lots of things you could do here- but for this usecase, it’s enough to define an object with two functions. These are hooks that will be called on specific parts of the build process that Netlify runs.

Both functions will be given some arguments, and among them is the utils object we can use to access the internal build cache:

// index.js
module.exports = {
    // Before the build runs,
    // restore a directory we cached in a previous build.
    // Does not do anything if:
    //  - the directory already exists locally
    //  - the directory has never been cached
    async onPreBuild({ utils }) {
        await utils.cache.restore('./_cache')
    },
    // After the build is done,
    // cache directory for future builds.
    // Does not do anything if:
    //  - the directory does not exist
    async onPostBuild({ utils }) {
        await utils.cache.save('./_cache')
    }
}

1. The onPreBuild hook looks for a previously cached _cache folder and restores it within the build.
2. The onPostBuild hook takes the final build output, looks for changes in the _cache folder and saves it for later.

Because these hooks only look at changes that happen between the start and end of your build, your code needs to create the cache directory itself and write files to it as it runs. You can do that by using node’s filesystem functions, similiar to what I’ve done here.

Register the Plugin

The last thing to do is to let the Netlify build script know you intend to use your plugin. You can register it with a line in your netlify.toml configuration file:

# netlify.toml
[[plugins]]
    package = "./plugins/webmention-cache"

Now, when you run a new build, you should see something like these lines in your deploy log:

2:02:08 PM: ❯ Loading plugins
2:02:08 PM:    - ./plugins/webmention-cache from netlify.toml
2:02:08 PM: ​
2:02:08 PM: ────────────────────────────────────────────────────────────────
2:02:08 PM:   1. onPreBuild command from ./plugins/webmention-cache         
2:02:08 PM: ────────────────────────────────────────────────────────────────
2:02:09 PM: ​
2:02:09 PM: (./plugins/webmention-cache onPreBuild completed in 302ms)
2:02:09 PM: ​
2:02:09 PM: ────────────────────────────────────────────────────────────────
2:02:09 PM:   2. build.command from netlify.toml                            
2:02:09 PM: ────────────────────────────────────────────────────────────────
2:02:09 PM: ​
2:02:09 PM: $ npm run build

...[lines omitted]...

2:02:12 PM: >>> 4240 webmentions loaded from cache
2:02:12 PM: >>> 6 new webmentions fetched from https://webmention.io/api
2:02:12 PM: >>> webmentions saved to _cache/webmentions.json

...[lines omitted]...

2:02:29 PM: ────────────────────────────────────────────────────────────────
2:02:29 PM:   3. onPostBuild command from ./plugins/webmention-cache        
2:02:29 PM: ────────────────────────────────────────────────────────────────
2:02:29 PM: ​
2:02:29 PM: (./plugins/webmention-cache onPostBuild completed in 53ms)

And that’s about it!

Still, I want to continue the tradition of “end-of-the-year” blogposts and since there’s already enough doom out there these days, I’m trying to focus on the good things that happened instead.

Work

The web industry is among the fortunate ones that are very well suited for remote and distributed work, which is why I was able to keep working from home throughout most of the year.

We rented a great new office in the spring that I’ve hardly been to since, but our team at Codista is quite used to working remote and we already had all the necessary infrastructure in place.

We had more than enough projects on our hands and we did some really interesting, challenging stuff that I can’t talk about (yet) 😉 - so all in all, work was good.

Writing

I wrote nine posts in 2020 - which is fewer than last year, but all things considered, that’s ok. The most popular ones were:

• The Return of the 90s Web: a look at some early trends on the web and how they might be resurrected
• The Emergency Website Kit: an attempt to build a template for critical information websites
• Color Theme Switcher: a case study of this blog’s weird color scheme feature (see header)

Side Projects

When the first lockdown hit, I kept occupied by building things - mostly in and around Eleventy, which helped me get ideas off the ground quickly. Here are some of these:

• Eleventastic: my personal starter kit for Eleventy projects. I wanted to get rid of “external” build tools like Gulp and manage all pipelines inside Eleventy itself.

• Eleventy Resumé: a simple microsite that functions as a CV/Resumé in web and print.

• Whimsical Website Club: a collection of websites that spark joy by doing things a little bit less serious.

Speaking

I had some talks planned for 2020 which of course didn’t happen. I did a few online talks though and I participated in Inclusive Design 24, a free 24-hour livestream event where I talked about another side project, the “Emergency Website Kit”:

Events

The Webclerks team and I had the pleasure of hosting our own little virtual meetup event “Vienna Calling” on Twitch, and we had a phenomenal lineup. A big thank you again to all the speakers who joined us, as well as the rest of the team who made this happen behind the scenes.

BTW: You can find the full event as a playlist on Youtube:

Traveling

In the summer, the situation improved enough for me and my girlfriend to take some much needed vacation time. With international travel still closed, we decided to go on a road trip through Austria instead and it was awesome. This country has some really beautiful places in store.

We need the Web

This year, more than ever, I realized the enormous impact the web has on all of us, and how important it is to keep it free and open. I know we’re all sick of doing things online all the time, but imagine for a moment what this year would have looked like had the web never been invented.

Millions of people would be completely isolated, even more would be out of their jobs. Schools could not operate. Civil rights movements would be almost impossible to organize. Global research projects like the development of a vaccine would take years longer. And you probably wouldn’t have seen the faces of your loved ones in months.

The web has become such an integral part of our lives that we sometimes take it for granted. It’s not. In fact this shitshow of a year should probably remind us that we need to take really good care of the things that are still connecting us.

Goals for 2021

I’m not going to compare my goals from last year with what I’ve accomplished in 2020. I don’t think it matters. Give yourself a break this year - it’s OK if things didn’t turn out the way you wanted.

I’ll see you all in 2021. And hopefully we’ll all have a vaccine in our system and a better year ahead of us.

Other Year-in-Review Posts

Have you written one of these yourself? Let me know and get added here.

• Hidde de Vries
• Marcus Herrmann

It used to be cooler. It used to be weirder.

As Sarah Drasner puts it in “In Defense of a Fussy Website”:

While we’re all laser-focused on shipping the newest feature with the hottest software and the best Lighthouse scores, I’ve been missing a bit of the joy on the web. Apps are currently conveying little care for UX, guidance, richness, and — well, for humans trying to communicate through a computer, we’re certainly bending a lot to… the computer.

I really liked that post, so I made small website meant to showcase how a more personal web could look like, and hopefully give someone else inspiration to make their own corner of the web a bit weirder.

More whimsy, please!

Introducing: The Whimsical Web - a curated list of sites with an extra bit of fun.

I’ve collected a few of my favorites to start, but anyone can add a site to the list if it’s fun, quirky and personal.
Just open an issue on Github and let me know.

Let’s see some fussy websites!

When I look at some of the trends on the web today, I wonder if we’re at that point yet. I wonder if we’re ready to revisit some of the ideas of the early web again.

Probably not in design - I’m afraid dancing-baby.gif is gone for good. But some of the broader ideas from back then are picking up a second wind lately, and I like it.

Serverside Rendering

After spending the better part of the last decade shifting rendering logic to the client, it looks like the pendulum is about to swing into the other direction again.

With projects like Phoenix Liveview or hey.com’s recent “it’s-just-HTML” approach, it seems like server-side rendering (SSR) is stepping back into the spotlight.

If you think that sounds like the web of 25 years ago, you’re right! Except the HEY front-end stack progressively enhances the “classic web” to work like the “2020 web,” with all the fidelity you’d expect from a well-built SPA.

— Sam Stephenson (@sstephenson) June 15, 2020

It makes sense - servers are really good at this, and sending compressed HTML through the network can be lightning fast. The classic request-response cycle has evolved as well: HTTP/2 and smart techniques like Turbolinks or just-in-time preloading allow for a much better experience now than when you first tried to load that Michael Jordan photo on the Space Jam website over dial-up.

Taking the responsibility of rendering UI and all the Javascript that comes with it off users’ shoulders would be a great old new strategy for the next generation of web apps.

No-Code Tools

Frontpage and Dreamweaver were big in the 90s because of their “What You See Is What You Get” interface. People could set up a website without any coding skills, just by dragging boxes and typing text in them.

Of course they soon found that there was still source code underneath, you just didn’t see it. And most of the time, that source code was a big heap of auto-generated garbage - it ultimately failed to keep up with the requirements of the modern web.

Today our understanding of the web has improved, and so have our tools. Webflow is one of the contenders for the “no-code editor” trophy. The output it generates is far better.

These tools will probably not be a replacement for developers as a whole - complex projects still require tons of human brainpower to work. But for all the landing pages and marketing sites, this could be the holy grail of WYSIWYG we thought we had in the 90s.

Personal Websites

It might just be my IndieWeb filter bubble talking, but I think there is a renewed interest in personal websites. A lot of big social media giants are falling out of favor, and it becomes cool again to own a space on the web rather than being one of a billion usernames.

Our digital identities are becoming increasingly more important, and people become aware that they’re not in control of their data. Personal sites were very popular in the era before Myspace and Facebook, and it’s now easier than ever to build one.

Services like Carrd offer a straightforward way to create simple one-pagers, and their numbers show a lot of interest:

Totals for 2019:

🙋 213k new users
🌐 381k new sites
💵 $308k https://t.co/k3mNeiIyzL

— aj ⚡️ 🍜 (@ajlkn) January 1, 2020

Blogging is gaining popularity again as well, used as a tool for self-marketing or simply to express opinions. There are lots of good options for people who want to pick up blogging - either on their own sites or with platforms like micro.blog, that offer more independence than Medium & Co.

Curated Feeds and Discovery

Another issue created by social media is the prevalence of “algorithmic feeds”. We decided that the constant stream of input for our eyeballs should never end, so we built these complex systems to generate new content for us based on our interests.

But these are giant black boxes, and nobody really knows what signals go into them. Throw advertising, “fake news” and a couple of trolls into the mix, and you get the mess we all know now.

That’s why many people crave a more controlled reading experience on their own terms. Chronological, personal, relevant - a bespoke magazine of trusted sources. A curated feed.

One way to achieve something like that is through plain ol’ boring RSS. One more thing that was said to be dead but is growing in popularity again:

Who’s gonna read your personal blog because it has an RSS feed? I’m gonna read your personal blog because it has an RSS feed. pic.twitter.com/mtcyKhEVet

— Chris Coyier (@chriscoyier) January 7, 2020

Another possibility is to discover new content through human connections instead of algorithms. People we already know for their content recommend others in the same field, creating decentralized clusters of trusted information.

Website owners used to do this a lot in the days before search engines, by providing Blogroll Pages or forming Webrings with links to others in their cluster.

Smaller Communities and Web Monetization

Many independent creators are moving away from big “everyone’s on them” platforms back to private, more niche communities. New models for membership sites like Ghost’s “Members” feature enable creators to build communities on their content. People teach courses, self-publish books or provide APIs for specific topics.

Where the 90s had chatrooms and message boards, today there are tools like Discord or Twitch that help people with shared interests to connect with each other. These niche communities can then be a powerful userbase for independent businesses.

Of course the problem of monetization has existed from the very start of the web, and it’s still not easy today to earn money without splattering ads everywhere. But new standards like the Web Monetization API could be a very interesting solution, enabling creators to receive micro-payments for their content.

Learning from the Past

I don’t know if all of these trends will really play out, or if we’re up for something completely different. I do think it’s a good idea to learn from the past though, because that is what keeps us moving forward.

So maybe the second 90s can be even better than the first. At least we’re done with NSYNC this time.

Through my developer-centric filter bubble, I sometimes see the tech world react to times of crisis. Often our first instinct seems to be to turn to technology. Build something to fix this.

I get that if all you have is a hammer, everything looks like a nail. I’m guilty of this myself. That knee-jerk reaction might come from a genuine desire to help - and if code is what we know best, it’s understandable that we want to apply these skills here too.

But some problems can’t be solved with technology.

You can’t code away systemic racism, and you can’t design your way out of a human rights crisis.

No blockchain, no cloud and no A.I. will get us out of this.

There are problems that have to be solved with humans. They have to be solved in our laws, our culture, and ultimately our minds. It’s a long, hard, uncomfortable and sometimes violent process.

Technology can only help that process by taking a step back. By amplifying voices that would otherwise not be heard, and by providing tools for people to take action.

The web is an amazing tool in bringing us together. Yet some of the best and brightest minds of our generation are working on how to get more people to click on ads. Imagine what technology could be capable of if it focused all that energy on the problems in our communities instead.

There are examples of code being used for the greater good in this:

• People organize on independent websites and encrypted messaging apps
• People document police brutality online and try to hold them accountable
• When the “black squares” campaign drowned out images of the movement on Instagram, someone wrote a bot to reach out to posters to take them down.

There’s many more I’m sure, but they all stand back behind the actual human beings in the streets, protesting for justice.

Code won’t bring us forward here. People will.

And so every operating system, app and even some websites (mine included) suddenly had to come up with a dark mode. Fortunately though, this coincided nicely with widespread support for CSS custom properties and the introduction of a new prefers-color-scheme media query.

There’s lots of tutorials on how to build dark modes already, but why limit yourself to light and dark? Only a Sith deals in absolutes.

That’s why I decided to build a new feature on my site:
dynamic color themes! Yes, instead of two color schemes, I now have ten! That’s eight (8) better!

Go ahead and try it, hit that paintroller-button in the header.
I’ll wait.

If you’re reading this somewhere else, the effect would look something like this:

Nice, right? Let’s look at how to do that!

Define Color Schemes

First up, we need some data. We need to define our themes in a central location, so they’re easy to access and edit. My site uses Eleventy, which lets me create a simple JSON file for that purpose:

// themes.json
[
    {
        "id": "bowser",
        "name": "Bowser's Castle",
        "colors": {
            "primary": "#7f5af0",
            "secondary": "#2cb67d",
            "text": "#fffffe",
            "border": "#383a61",
            "background": "#16161a",
            "primaryOffset": "#e068fd",
            "textOffset": "#94a1b2",
            "backgroundOffset": "#29293e"
        }
    },
    {...}
]

Our color schemes are objects in an array, which is now available during build. Each theme gets a name, id and a couple of color definitions. The parts of a color scheme depend on your specific design; In my case, I assigned each theme eight properties.

In addition to the “default” and “dark” themes I already had before, I created eight more themes this way. I used a couple of different sources for inspiration; the ones I liked best are Adobe Color and happyhues.

All my themes are named after Mario Kart 64 race tracks by the way, because why not.

Transform to Custom CSS Properties

To actually use our colors in CSS, we need them in a different format. Let’s create a stylesheet and make custom properties out of them. Using Eleventy’s template rendering, we can do that by generating a theme.css file from the data, looping over all themes. We’ll use a macro to output the color definitions for each.

I wrote this in Nunjucks, the templating engine of my choice - but you can do it in any other language as well.

/* theme.css.njk */
---
permalink: '/assets/css/theme.css'
excludeFromSitemap: true
---
/*
  this macro will transform the colors in the JSON data
  into custom properties to use in CSS.
*/
{% macro colorscheme(colors) %}
    --color-bg: {{ colors.background }};
    --color-bg-offset: {{ colors.backgroundOffset }};
    --color-text: {{ colors.text }};
    --color-text-offset: {{ colors.textOffset }};
    --color-border: {{ colors.border }};
    --color-primary: {{ colors.primary }};
    --color-primary-offset: {{ colors.primaryOffset }};
    --color-secondary: {{ colors.secondary }};
{% endmacro %}

/* 
  get the "default" light and dark color schemes
  to use if no other theme was selected
*/
{%- set default = themes|getTheme('default') -%}
{%- set dark = themes|getTheme('dark') -%}

/*
  the basic setup will just use the light scheme
*/
:root {
    {{ colorscheme(default.colors) }}
}
/*
  if the user has a system preference for dark schemes,
  we'll use the dark theme as default instead
*/
@media(prefers-color-scheme: dark) {
    :root {
        {{ colorscheme(dark.colors) }}
    }
}

/*
  finally, each theme is selectable through a 
  data-attribute on the document. E.g:
  <html data-theme="bowser">
*/
{% for theme in themes %}
[data-theme='{{ theme.id }}'] {
    {{ colorscheme(theme.colors) }}
}
{% endfor %}

Using colors on the website

Now for the tedious part - we need to go through all of the site’s styles and replace every color definition with the corresponding custom property. This is different for every site - but your code might look like this if it’s written in SCSS:

body {
    font-family: sans-serif;
    line-height: $line-height;
    color: $gray-dark;
}

Replace the static SCSS variable with the theme’s custom property:

body {
    font-family: sans-serif;
    line-height: $line-height;
    color: var(--color-text);
}

It’s fine to mix static preprocessor variables and custom properties by the way - they do different things. Our line height is not going to change dynamically.

Now do this for every instance of color, background, border, fill … you get the idea. Told you it was gonna be tedious.

Building the Theme Switcher

If you made it this far, congratulations! Your website is now themeable (in theory). We still need a way for people to switch themes without manually editing the markup though, that’s not very user-friendly. We need some sort of UI component for this - a theme switcher.

Generating the Markup

The switcher structure is pretty straightforward: it’s essentially a list of buttons, one for each theme. When a button is pressed, we’ll switch colors. Let’s give the user an idea what to expect by showing the theme colors as little swatches on the button:

Here’s the template to generate that markup. Since custom properties are cascading, we can set the data-theme attribute on the individual buttons as well, to inherit the correct colors. The button also holds its id in a data-theme-id attribute, we will pick that up with Javascript later.

<ul class="themeswitcher">
{% for theme in themes %}
    <li class="themeswitcher__item">
        <button class="themepicker__btn js-themepicker-themeselect" data-theme="{{ theme.id }}" aria-label="select color theme '{{ theme.name }}'">
            <span class="themepicker__name">{{ theme.name }}</span>
            <span class="themepicker__palette">
                <span class="themepicker__swatch themepicker__swatch--primary"></span>
                <span class="themepicker__swatch themepicker__swatch--secondary"></span>
                <span class="themepicker__swatch themepicker__swatch--border"></span>
                <span class="themepicker__swatch themepicker__swatch--textoffset"></span>
                <span class="themepicker__swatch themepicker__swatch--text"></span>
            </span>
        </button>
    </li>
{% endfor %}
</ul>

.themepicker__swatch {
    display: inline-block;
    width: 1.5em;
    height: 1.5em;
    border-radius: 50%;
    box-shadow: 0 0 0 2px #ffffff;

    &--primary {
        background-color: var(--color-primary);
    }
    &--secondary {
        background-color: var(--color-secondary);
    }
    &--border {
        background-color: var(--color-border);
    }
    &--textoffset {
        background-color: var(--color-text-offset);
    }
    &--text {
        background-color: var(--color-text);
    }
}

There’s some more styling involved, but I’ll leave that out for brevity here. If you’re interested in the extended version, you can find all the code in my site’s github repo.

Setting the Theme

The last missing piece is some Javascript to handle the switcher functionality. This process is a bit more involved than we might initially assume. We need to check the user’s system preference through the prefers-color-scheme media query. But crucially, we also need to enable the user to override that preference, and then store the selected theme choice for later.

I’ve omitted some stuff here for brevity - see the full script on Github for all the details.

// let's make this a new class
class ThemeSwitcher {
    constructor() {
        // define some state variables
        this.activeTheme = 'default'

        // get all the theme buttons from before
        this.themeSelectBtns = document.querySelectorAll('button[data-theme-id]')
        this.init()
    }

    init() {
        // determine if there is a preferred theme
        const systemPreference = this.getSystemPreference()
        const storedPreference = this.getStoredPreference()

        // explicit choices overrule system defaults
        if (storedPreference) {
            this.activeTheme = storedPreference
        } else if (systemPreference) {
            this.activeTheme = systemPreference
        }

        // when clicked, get the theme id and pass it to a function
        Array.from(this.themeSelectBtns).forEach((btn) => {
            const id = btn.dataset.themeId
            btn.addEventListener('click', () => this.setTheme(id))
        })
    }

    getSystemPreference() {
        // check if the system default is set to darkmode
        if (window.matchMedia('(prefers-color-scheme: dark)').matches) {
            return 'dark'
        }
        return false
    }

    getStoredPreference() {
        // check if the user has selected a theme before
        if (typeof Storage !== 'undefined') {
            return localStorage.getItem("theme")
        }
        return false
    }
}

// this whole thing only makes sense if custom properties are supported -
// so let's check for that before initializing our switcher.
if (window.CSS && CSS.supports('color', 'var(--fake-var)')) {
    new ThemeSwitcher()
}

When somebody switches themes, we’ll take the theme id and set is as the data-theme attribute on the document. That will trigger the corresponding selector in our theme.css file, and the chosen color scheme will be applied.

Since we want the theme to persist even when the user reloads the page or navigates away, we’ll save the selected id in localStorage.

setTheme(id) {
    // set the theme id on the <html> element...
    this.activeTheme = id
    document.documentElement.setAttribute('data-theme', id)

    // and save the selection in localStorage for later
    if (this.hasLocalStorage) {
        localStorage.setItem("theme", id)
    }
}

On a server-rendered site, we could store that piece of data in a cookie instead and apply the theme id to the html element before serving the page. Since we’re dealing with a static site here though, there is no server-side processing - so we have to do a small workaround.

We’ll retrieve the theme from localStorage in a tiny additional script in the head, right after the stylesheet is loaded. Contrary to the rest of the Javascript, we want this to execute as early as possible to avoid a FODT (“flash of default theme”).

👉 Update: Chris Coyier came up with the term “FART” (Flash of inAccurate ColoR Theme) for this, which of course is way better.

<head>
    <link rel="stylesheet" href="/assets/css/main.css">
    <script>
        // if there's a theme id in localstorage, use it on the <html>
        localStorage.getItem('theme') && 
        document.documentElement.setAttribute('data-theme', localStorage.getItem('theme'))
    </script>
</head>

If no stored theme is found, the site uses the default color scheme (either light or dark, depending on the users system preference).

Get creative

You can create any number of themes this way, and they’re not limited to flat colors either - with some extra effort you can have patterns, gradients or even GIFs in your design. Although just because you can doesn’t always mean you should, as is evidenced by my site’s new “Lobster Life” theme.

Please don’t use that one.

This again addresses the over-reliance on powerful Javascript frameworks like React, even in cases where simple semantic HTML might be better suited for the task.

I’m currently putting my self-isolated weekend time towards side projects, and I thought this could be something I can tackle. So I built something new:

A résumé template

This is a static micro-site generated by Eleventy that can be used as an online résumé. The output is basically just a simple index.html file.

Features:

• Fully Customizable
• Semantic HTML
• Accessible (WCAG AA)
• Print Styles
• h-resume Microformat
• Integrated Spellcheck Linter
• Self-Contained (no external resources)
• Search Engine Optimized (meta, JSON-LD)
• Critical CSS Inlined

Many people are out of work due to the pandemic already, and even more might still lose their jobs as the world is headed towards a massive economic fallout. There is little we can do to stop that, but a tool like this might hopefully be a small help for people to find new work once the situation improves.

Just received a shelter-in-place emergency alert with a web address for more information. Clicked the link. The site is down. All emergency sites should be static.

— Nicholas C. Zakas (@slicknet) March 17, 2020

To make things worse, natural disasters can also damage local network infrastructure, sometimes leaving people with very poor mobile connections.

I’ve written about the practice of publishing minimal “text-only” versions of critical news websites before and I think it makes a lot of sense to rely on the rule of least power for these things. When it comes to resilience, you just can’t beat static HTML.

An Emergency Website Kit

Like so many others, I’m currently in voluntary quarantine at home - and I used some time this weekend to put a small boilerplate together for this exact usecase.

Here’s the main idea:

• generate a static site with Eleventy
• minimal markup, inlined CSS
• aim to transmit everything in the first connection roundtrip (~14KB)
• progressively enable offline-support w/ Service Worker
• set up Netlify CMS for easy content editing
• one-click deployment via Netlify

The site contains only the bare minimum - no webfonts, no tracking, no unnecessary images. The entire thing should fit in a single HTTP request. It’s basically just a small, ultra-lean blog focused on maximum resilience and accessibility. The Service Worker takes it a step further from there so if you’ve visited the site once, the information is still accessible even if you lose network coverage.

The end result is just a set of static files that can be easily hosted on cloud infrastructure and put on a CDN. Netlify does this out of the box, but other providers or privately owned servers are possible as well.

Not Everyone is a Developer

I’m aware that not everyone, especially the people in charge of setting up websites like this, is familiar with things like Node or the command line. I want to keep the barrier to entry as low as possible.

Taking a hint from the excellent servicerelief.us project, it is possible to configure the template in such a way that all configuration can be done via environment variables.

These are set in the Netlify UI when the site is first deployed, meaning a user would only need a free Github and Netlify account to get started - without ever touching a line of code or having to mess around with npm or Eleventy itself. The content editing can all be done through Netlify CMS, which offers a much more useable graphical interface.

In the meantime, if you want to set up an emergency website and need help to get started, let me know!

Update 25.04.

I recently did a short talk about this project at an online meetup. You can watch it here:

I also loved making flyers, posters and CD artwork for local bands - It’s actually what got me started in design and ultimately led me to build for the web. You see I can’t really draw, so my only option to create the images in my head was with the help of computers, which I was able to use. Creating posters became a hobby of mine.

These days, I’m usually too busy to find time for that hobby. But I keep a collection of my favourite gigposters and once in a while, when an occasion arises, I get to do one myself.

I still do vocals in one band, and so fortunately that occasion comes once a year in the form of a Rage Against the Machine cover gig we play in my hometown. The event is called “Rage/Aid” because all of the proceeds are donated to charity.

TL;DR: Here’s the poster I did for that show, and how I made it.

Concept

The hardest part for me is coming up with a good idea. Much like a website, a gigposter is a mixture of information and art - and should be tailored to the general vibe of the band/show. That being said, there really are no rules as to which motives fit which genre. You get to freely explore different ideas and concepts.

I usually start with a few crudely-drawn pencil sketches of possible motives. Just shoot these out real quick and let your mind wander - you can care about making them look good later. You can get inspiration from anywhere: art, nature, architecture, movies… whatever captures your attention.

For this one, I liked the idea of referencing a famous painting, “The Son of Man” by René Magritte. It’s the one with the apple in front of a man’s face - you might know it.

I thought I could take the concept of the faceless, anonymous person and put a twist on it. I also knew I wanted fire in there somehow to symbolize Rage against the Machine’s anger and spirit of revolution, so I drew a lit match instead of the apple.

It really doesn’t have to be clever or deep or anything though, it’s a fucking poster, not an arts degree. 🧐 I just liked the visual and thought it would go well with the vibe, so that’s what I used.

Illustration

As I mentioned earlier, I can’t draw for shit. There are some insanely talented poster artists out there that do it all by hand and I greatly admire their skill - but I have to rely on digital trickery to make my stuff look good.

So I took to a stock photo site to find something I could base my illustration on. After some searching, I came across this series of backlit faces that seemed like a nice fit.

I like to have the main motive as a vector drawing because that’s just easier to work with. I can tweak certain parts or recolor it later without too much trouble. Plus if I need it on the side of a bus someday, I can always scale it up. So my first step is usually to get the motive vectorized.

I opened the stock photo in Illustrator and began tracing the outline with the pen tool. I also separated the colors into three layers, from dark to light. This sort of thing is common in stencil or screenprint artwork, and I wanted to recreate that style. It works best on high-contrast images like this.

I played around with different filters and effects to give the silhouette shape more detail. The one I chose is the halftone filter: it transforms the shapes into thousands of “print dots”. The size and density of these dots then determine the lightness.

This breaks a bit with the stencil style, but I like how it blends the edges of the three color layers together, and it reminds me of old newspapers and billboards.

For the match, I googled for a random picture as a base, applied a treshold and vectorized it in Illustrator. The flame is just a doodle I made with the pen tool, with a few extra points and distortion added to make the edges more jagged. The zigzag filter can help with that.

Putting the main motive together already looks cool; the flame fits nicely inside the silhouette shape. Good enough for now - I’ll let that sit for a while and work on other stuff.

Background

For the background, I switched to Photoshop as it’s pixel-based. It’s important to work in CMYK colors here and make sure the document is at least 300dpi, large enough for the intended poster size - it’s a pain to scale pixel artwork up later on.

I started with a flat color and then progressively layered other stuff on top to give it more detail. The base here was a bright red.

I then used a watercolor texture, a bit of speckle/noise and a grunge brush to make it look more eroded. I was going for a screenprint-like style, where the color often doesn’t distribute evenly across the paper and has these interesting imperfections. The nice thing about blending these layers together in Photoshop is that you can still easily tweak the base color afterwards and try out different color schemes.

Another trick I like is to give the artwork a “frame”, again to make it look a bit more handmade:

This is just an extra mask layer, where the sides are drawn with a paintroller brush that gives you these nice rough edges. These are small details, but they all add to the general look and feel of the poster.

Typography

Gigposters let you get really creative with type. There are some awesome pieces that use crazy custom letterforms and make them a part of the artwork itself. For my poster, I just wanted something simple that matched the illustration style.

I found this nice big brush font called “Generous” by Danish type foundry PizzaDude. It has broad strokes and rough edges that go well with the background, and work nicely as the display font. I paired it with the clean sans-serif Brandon Grotesque for the body copy.

There are some other pieces of information that just have to be on there, like the date and venue. Rather than doing one big text block though, I like to break these up a bit and play with ways to integrate them into the artwork.

I put the supporting act in a separate badge to make it stand out more, and I made a little cutaway in the frame to hold the venue logo.

Getting to Print

Colors always look different on screen than in print. A piece of paper doesn’t glow, so they are usually a bit darker and less saturated in CMYK. To make sure they turn out right, you can proof your work before you send it off. If you know your color profile, Photoshop can simulate how colors will look in print.

A color profile is a bit of data that sets things like the color space, maximum ink application and other instructions for the printer. My local printer for example uses one called “ISO Coated v2 300%” (print companies will usually tell you which profile to use on their website). You can download and install these for free.

After everything is ready, I import the poster without all the type and vector elements into InDesign, then add them back in there. That way they’ll actually end up in the final PDF as vectors and are guaranteed to look sharp. InDesign also lets you set things like bleed and crop marks, which are sometimes required by the printer.

Final Result

And here’s the whole thing put together (click for full PDF):

Work

At the beginning of 2019, I became a partner at Codista, the software studio where I’ve been working for some time now. Thomas, Luis and I now run the company as a trio, and building together has been great.

Besides working as a frontend developer on a number of challenging projects this year, I was also responsible for the rebranding of our own identity. There are some interesting new ideas in the works for our studio in 2020, and I’m excited to see them come to life.

Writing

Counting this one, I’ve written ten new posts in 2019. That’s more than last year, but I’d still like to increase that number.

The most popular posts were:

• The CSS Mindset: a collection of helpful mental models for writing CSS,
• On Simplicity: how sometimes “less is more” in tech, and
• Static Indieweb pt2: Using Webmentions: a rundown of how to implement webmentions with Eleventy.

The feedback from the web community on these posts was amazing, and it never gets old to hear that anything you’ve made actually helped people in some way.

Like in 2018, all my writing was published on my own website. I’m increasingly fond of the IndieWeb and the principles behind it, and I want to continue striving for more independence. Eleventy and Netlify both have been very valuable improvements for my personal site this year, and I really like working with them.

Speaking

I wrote two new talks in 2019 and had the chance to speak at a few community events.

First I was invited as a guest speaker to the Mozilla Developer Roadshow, where I had a really interesting “Fireside Chat” about CSS with HJ Chen. It was awesome meeting her and I’m very grateful for the opportunity to speak there.

Following my blog post about the topic, I gave a talk on the CSS Mindset at CSS-Minsk-JS in September and had a wonderful time. A big thank you to the organizers and attendees, who made me feel very much at home in Minsk.

A big part of this year was devoted to making our own Webclerks Conference happen in Vienna. It was the first time for me to be involved in the organization of such an event and I really had no idea how it would turn out, so I’m overjoyed that it went so well.

I also shared my experiences with the IndieWeb in a talk called “Rage against the Content Machine” there. I’d love to do that one again in the new year.

Traveling

I’ve been fortunate enough to see many beautiful places on this planet now. I made a little map to keep track of them here.

This year, I visited Portugal, Georgia, Belarus, the Czech Republic and the Azores. My personal favourites were the ancient city of Tbilisi and the raw nature of São Miguel island, both fascinating places in their own regard.

Personal

2019 was also a source of frustration in many ways. From the ongoing global shift to right-wing populism to increasingly dystopian technology trends to the looming threat of climate change. I’ve had some issues with worrying and stress in my personal life as well.

But I’d like to think that the new decade can be an opportunity to learn from past mistakes and change things for the better. I’m going to try and focus on that going forward.

Goals for 2020

• help to further grow Codista into a sustainable, ethical business
• write more regularly
• continue involvement in the IndieWeb community
• attend and speak at more conferences
• make more music
• read more non-tech books
• keep up with friends and enjoy life a little more

That’s all folks. See you tomorrow!

I have been to quite a few web development conferences as an attendee, and lately even as a speaker. But the organization of such events always eluded me. I of course noticed when an event was particularly well put together, but I always assumed that the people running the show had a large team, lots of experience and were just very talented organizers.

That’s why it felt so weird to suddenly find myself in that group. Clearly we’re just a bunch of people who thought it would be cool to invite some of our heroes and heroines to Vienna, with little prior experience in creating an event at that scale.

But then it worked! We’d somehow gotten ourselves an absolutely incredible line-up of speakers and a sold out venue.

Welcome to Webclerks Conference

Fast forward to last Monday, when months of work finally resulted in that one special day. Sleep had been rare in the days before, and the tension was high.

None of us really knew how this would turn out, so we just gave it our best shot. And the feedback so far from speakers and attendees alike has been great:

It's hard to believe that the @wearewebclerks conference was the first one ever by the organisers. It was slick, welcoming, friendly, and interesting. Thanks for asking me to speak! ♥️ #webclerks

— Charlie Don't Surf (@sonniesedge) November 26, 2019

The @wearewebclerks conference today was seriously awesome! Great talks, great organization and great people! And all of that in Vienna ♥️ Looking forward to the next year #webclerks pic.twitter.com/GHOqfgzsNB

— Lisa Gringl (@kringal) November 25, 2019

✅ brilliant speakers
✅ surprise acts
✅ live captions
✅ tasty food from "Speisen ohne Grenzen"
✅ water bottles to reduce waste

Congratulations to the organizers of a great #webclerks community conference pic.twitter.com/sOflfHkA1F

— Harald Atteneder (@urbantrout) November 25, 2019

This conference was a great example of getting it right from the beginning. Amazing speakers, inclusive, accessible and with all details taken care of. Congratulations to the team! I'm really looking forward to next year's event #webclerks pic.twitter.com/YlRfzyt5kD

— Magdalena Adrover (@madrovergaya) November 25, 2019

Lessons Learned

Here are some of my personal takeaways from the experience:

• It really pays off to have a good tech team. We could not have asked for a better crew than ALC, they handled the event flawlessly by themselves. A huge thing to get off your shoulders as an organizer.

• If you want to livestream an event on youtube, that apparently requires a “brand account”. These take 24 hours to approve, so it’s best to not discover this the night before the conference. (Thankfully Joschi from a11yclub helped us out there!)

• The glass water bottles we put into everyone’s goodie bag were a big hit. People liked that they could refill anytime. Less waste, more hydration!

• You can make your own rules! Not all tech confs have to follow the same recipe. In fact some of the little differences are what makes you stand out.

• We’re not a faceless recruiting event, but a community of humans, and we wanted to be as inclusive as possible. That thought went into a lot of aspects of our conference from ticket pricing to info emails to food choices. Definitely something to keep.

Roll Credits

I really have to highlight the insane amount of work that Manuel and Claudi have put into this event. There’s an internal Trello board with about a gazillion tasks on it, and most of those had their names on them. It is beyond me how they did it.

Daniel has been an absolute beast as well - he did all the designs, printed badges, flags, shirts, stickers - you name it. If you thought webclerks looked like a professional brand, it’s because of him.

We also had lots of help from awesome volunteers who dedicated their time and energy to our event. Jeannine, Kerstin, Michel, Anne and Gregor have been incredibly helpful and I’m so glad they joined our team.

Community Matters

I honestly can’t think of many industries where it would have been possible to put an event like this together from scratch. I believe the reason this worked at all is the incredible openness displayed in the web community.

Where international speakers come to a small local conference to share their knowledge. Where companies like mozilla support a relatively unknown event and fund inclusiveness. Where attendees pay it forward to enable underrepresented others to join.

I’m happy and proud to be a part of that community.

Thank you! 🎉

First plans look promising. It’s really nice and modern. The old road had sidewalks and a bike lane, but these don’t really fit in with the new design and take too much time to build. Nobody on the planning committee knows any pedestrians or cyclists anyway, so the project doesn’t really focus on that.

Soon people get to work. Instead of regular concrete though, the construction crew decides to use a new cutting-edge synthetic asphalt. It was developed by a big construction company from the city that uses it to build a 12-lane highway in the nation’s capital - but they say anyone can use it.

Everyone in construction is very excited to work with this new material. You can do amazing stuff with it, and the team needs less time to get things done. They say this process will make the new road a lot better than the old one, and every modern construction crew does it this way now.

The friction point of the new asphalt is quite high though, so people will need a bit more horse power to drive on it - and it also takes about five times more fuel than usual. Luckily everybody on the construction team earns a very nice salary and drives a big BMW, so that isn’t really an issue. They do a couple of test drives and it all works fine.

The road is almost finished and everybody is really happy with it. But it was expensive to build, and the town wants to get that money back in some way. They don’t really like to put up toll booths, as these tend to scare drivers off. Instead they make a deal with some of the bigger advertising companies to put up some cameras.

Every car that drives on the new road will be photographed and analysed, and the ad firms can then decide to put up billboards in the middle of the road that are perfectly tailored to each driver. That is a bit distracting and slows the cars down somewhat, but it will generate revenue for the town. Plus, all these photos of drivers will tell the planners more about how it is working.

Finally, the road is finished.
There are fewer people using it now. That’s ok though, the new road isn’t for everyone.

Some might even feel that the old road was better in a way, potholes and all. It didn’t have all the fancy new features, but it got them where they wanted to go.
But that’s the nature of progress - just how these things are done today.

It’s the future.

Posting a new short “note” on my site currently requires me to commit a new markdown file to the repository on Github. That’s doable (for a developer), but not really convenient, especially when you’re on the go and just want to share a quick link. Twitter and other social media platforms literally make this as easy as clicking a single button, which makes it tempting to just post stuff straight to them. That’s why I wanted to improve this process for my site.

A quick Google search revealed that smarter people have already solved that problem. I came across this blog post by Tim Kadlec who describes adapting someone else’s link sharing technique for his (Hugo-powered) blog. That just left me the task of adapting it for my setup (Eleventy, Netlify) and customizing a few details.

The new link sharing basically has three main parts:

• a small Javascript bookmarklet to act as a “share button”
• a form that collects and sends the shared link data, and
• a serverless function to process it and create a new file.

Here’s how they work together:

The Bookmarklet

The button to kick things off is just a small bit of Javascript that takes the current page’s title, URL and optionally a piece of selected text you may want to quote along with the link.

It then sends these things as GET parameters to mxb.dev/share by opening a new window to it.

function(){
    // get link title
    var title = document.getElementsByTagName('title')[0].innerHTML;
    title = encodeURIComponent(title);

    // get optional text selection
    var selection = '';
    if (window.getSelection) {
        selection = window.getSelection().toString();
    } else if (document.selection && document.selection.type != 'Control') {
        selection = document.selection.createRange().text;
    }
    selection = encodeURIComponent(selection);

    // generate share URL
    var url = 'https://mxb.dev/share/?title='+title+'&body='+selection+'&url='+encodeURIComponent(document.location.href);

    // open popup window to sharing form
    var opts = 'resizable,scrollbars,status=0,toolbar=0,menubar=0,titlebar=0,width=680,height=700,location=0';
    window.open(url,'Sharer',opts);
})()

The bookmarklet looks like this:
Share on MXB

…and can then be dragged to the bookmarks bar for quick access.

The Sharing Form

At mxb.dev/share, I’ve created a small preact app. It will take the GET params passed in via the URL and generate a live preview of the resulting note, so I know what the end product will look like.

There’s also a form that will be pre-populated with the values, which lets me include additional information and edit everything before posting.

The form also has fields for the Github username and security token, necessary for authentification. My password manager will fill those in automatically.

The Handler Script

When I hit the submit button, the form will send the data along to another endpoint. I’ve built a serverless function to handle the processing, so I could theoretically send data from other sources there too and keep the posting logic in one place. Netlify Functions seemed to be a nice fit for this.

Here’s the full script if you’re interested. It reads the posted data and generates a new markdown file from it, called something like 2019-08-11-amphora-ethan-marcotte.md:

---
title: "Amphora - Ethan Marcotte"
date: "2019-08-11T16:57:13.104Z"
syndicate: false
tags: link
---

...we've reached a point where AMP may "solve" the web's 
performance issues by supercharging the web’s accessibility problem. 
(via [@beep](https://twitter.com/beep))

[ethanmarcotte.com/wrote/amphora](https://ethanmarcotte.com/wrote/amphora/)

It will then use the Github API to post that file as a base64-encoded string to a predetermined location in the site’s repository (in my case the folder where I keep all my notes).

Here’s the core function responsible for that:

const postFile = async data => {
    const { title, token } = data
    const fileName = getFileName(title)
    const fileContent = getFileContent(data)
    const url = API_FILE_TARGET + fileName

    const payload = {
        message: 'new shared link',
        content: Buffer.from(fileContent).toString('base64'),
        committer: {
            name: 'Max Böck',
            email: 'hello@mxb.dev'
        }
    }

    const options = {
        method: 'PUT',
        body: JSON.stringify(payload),
        headers: {
            'Content-Type': 'application/vnd.github.v3+json',
            Authorization: `token ${token}`
        }
    }

    return await fetch(url, options)
}

That’s pretty much it! After the file is committed, Netlify will kick in and re-build the static site with the new content. If I have marked the “syndicate to Twitter” flag, another script will then cross-post the link there. (More on that in Static Indieweb pt1: Syndicating Content).

Mobile Share Target

A caveat of this technique is the use on mobile. Javascript bookmarklets are not as easily available in mobile browsers, which complicates the process again.

Thankfully Aaron Gustafson recently pointed out that it’s possible to define a “Share Target” for Progressive Web Apps. That means if your site is a PWA (it probably should be), you can add an entry like this to its manifest file:

// site.webmanifest
{
    ...,
    "share_target": {
        "action": "/share/",
        "method": "GET",
        "enctype": "application/x-www-form-urlencoded",
        "params": {
            "title": "title",
            "text": "text",
            "url": "url"
        }
    }
}

That little bit of JSON registers your site as an application that can share things, just like Twitter, WhatsApp and the others. So after I “install” my PWA (read: create a shortcut link on my device home screen), it shows up as an option in the native Android “share” dialog:

I’m quite happy with how this turned out, as it feels really simple and straightforward. One step closer to IndieWeb bliss!

The original concept starts to look shallow or irrelevant, and the phrases sound awkward and repetitive. It just doesn’t feel good anymore.

I don’t think that’s unique to me - In fact I guess one of the reasons why many people would rather write a series of tweets than a longform blog post is that the expectations we set for ourselves are much higher with the latter. Posts need to be “done right” - there’s a greater risk of falling into the trap of perfectionism.

I know the anxiety of sharing something with the world. I know there is a pressure to match the quality we see elsewhere on the web. But maybe we should stop trying to live up to somebody else’s standards and focus on just getting stuff out there instead. Maybe our “imperfect” things are already helpful to someone. Maybe this shouldn’t be so hard.

Perfect is the Enemy of Done

Don’t get me wrong, I don’t mean we should all half-ass our writing. There are a lot of details to get right, and going the extra mile certainly pays off as it makes for better articles.

However at least for me, there is a point where a post is about 80% done, and I start to get in my own head:

“Maybe this isn’t as good as I thought it would be.”

“Seems like everyone already knows that.”

“This is missing something new and exciting.”

“I’m sure somebody already covered this way better.”

This is where posts die.
They get swallowed by these voices of doubt and end up collecting dust in a drafts folder as “maybe I’ll come back and finish this later” pieces. I’ve got about six of these currently, and it seems like I’m not the only one.

Just Publish It

So now I’m trying a new approach to avoid this:

I’ll publish something as soon as I feel confident that all the important points I want to get across are there. I try to ignore the voice screaming “it’s not ready” just for long enough to push it online. Then I share the link on Twitter.

Right away, the act of making a post public forces me to read it again. And of course the minute it’s out there I’ll immediately notice a bunch of errors I didn’t spot before. It’s a law of nature or something. That’s ok though, I can just push a couple of fixes.

Doing a thing now were I publish stuff early to avoid "It's-not-ready-anxiety" and get it out there. Fixing shit later, sorry 🙃 pic.twitter.com/MYCY382Pn9

— Max Böck (@mxbck) June 6, 2019

Then there’s the feedback aspect. Publishing might either go largely ignored, or the post might get shared or commented on.

If it’s ignored, well - no harm done. It’s out there, that’s all that matters. But if it gains traction, that’s not only a sign that the post is interesting to people, it’s also a motivation boost to get me over that last 20%.

Most importantly though, publishing early is an exercise for my brain. It’s ignoring the feelings of self-doubt. It’s forcing myself to actively decide that something is good enough.

Fix it in Post

One of the benefits of writing on your own site is that you can always go back and edit stuff later.

Maybe you have a good idea for an additional paragraph that makes a certain point clearer. Maybe you find a better way to write a piece of code. Maybe somebody points out a thing you haven’t considered yet, and you want to include it. Well, why wouldn’t you? Nobody says blog posts should be set in stone. Improve it for the next reader who comes along.

You can even retroactively change the way your post is displayed on social media. For example, if you add an open graph image to your post after publishing it, you can use Twitter’s Card Validator to scrape the URL again, and all the links people may have already shared will update.

I know of some people doing this in web development, for example in open redesigns of their personal sites. I don’t know if anyone tried it with writing yet though. Maybe it’s a bad idea.

But for now, I like it.

Further Reading

• Just write by Sara Soueidan
• Out there by Matthias Ott
• My Blog Post Workflow by Ali Spittel

I don’t know why CSS sparks so many different emotions in developers, but I have a hunch as to why it can sometimes seem illogical or frustrating: You need a certain mindset to write good CSS.

Now, you probably need a mindset for coding in general, but the declarative nature of CSS makes it particularly difficult to grasp, especially if you think about it in terms of a “traditional” programming language.

Robin Rendle makes a very good point in this CSS-Tricks Newsletter where he finds that CSS lives somewhere between rigid, logical systems like Math and flexible, adaptive systems like natural languages:

Other programming languages often work in controlled environments, like servers. They expect certain conditions to be true at all times, and can therefore be understood as concrete instructions as to how a program should execute.

CSS on the other hand works in a place that can never be fully controlled, so it has to be flexible by default. It’s less about “programming the appearance” and more about translating a design into a set of rules that communicate the intent behind it. Leave enough room, and the browser will do the heavy lifting for you.

For most people who write CSS professionally, the mindset just comes naturally after a while. Many developers have that “aha!” moment when things finally start to click. It’s not just about knowing all the technical details, it’s more about a general sense of the ideas behind the language.

This is true whether you write CSS-in-JS, Sass or plain vanilla stylesheets. The output will always be CSS - so knowing these concepts will be helpful regardless of your tooling choice.

I tried to list some of them here.

Everything is a Rectangle

This seems obvious, given that the box model is probably one of the first things people learn about CSS. But picturing each DOM element as a box is crucial to understanding why things layout the way they do. Is it inline or block level? Is it a flex item? How will it grow/shrink/wrap in different contexts?

The Cascade is your Friend

The Cascade - a scary concept, I know. Say “Cascade” three times in front of a mirror and somewhere, some unrelated styling will break.

While there are legitimate reasons to avoid the cascade, it doesn’t mean that it’s all bad. In fact, when used correctly, it can make your life a lot easier.

As much as necessary, as little as possible

Aim to write the minimal amount of rules necessary to achieve a design. Fewer properties mean less inheritance, less restriction and less trouble with overrides down the line. Think about what your selector should essentially do, then try to express just that. There’s no point in declaring width: 100% on an element that’s already block-level. There’s no need to set position: relative if you don’t need a new stacking context.

Shorthands have long effects

Some CSS features can be written in “shorthand” notation. This makes it possible to declare a bunch of related properties together. While this is handy, be aware that using the shorthand will also declare the default value for each property you don’t explicitly set. Writing background: white; will effectively result in all these properties being set:

background-color: white;
background-image: none;
background-position: 0% 0%;
background-size: auto auto;
background-repeat: repeat;
background-origin: padding-box;
background-clip: border-box;
background-attachment: scroll;

Always Be Flexible

CSS deals with a large amount of unknown variables: screen size, dynamic content, device capabilities - the list goes on. If your styles are too narrow or restrictive, chances are one of these variables will trip you up. That’s why a key aspect in writing good CSS is to embrace its flexibility.

Your goal is to write a set of instructions that is comprehensive enough to describe what you want to achieve, yet flexible enough to let the browser figure out the how by itself. That’s why its usually best to avoid “magic numbers”.

Magic numbers are random hard values. Something like:

.thing {
    width: 218px; /* why? */
}

Whenever you find yourself tapping the arrow key in your devtools, adjusting a pixel value to make something fit - that’s probably a magic number. These are rarely the solution to a CSS problem, because they restrict styles to a very specific usecase. If the constraints change, that number will be off.

Instead, think about what you actually want to achieve in that situation. Alignment? An aspect ratio? Distributing equal amounts of space? All of these have flexible solutions.

Context is Key

For many layout concepts it’s imperative to understand the relationship between elements and their container. Most components are sets of parent and child nodes. Styles applied to the parent can affect the descendants, which might make them ignore other rules. Flexbox, Grid and position:absolute are common sources of such errors.

Content will change

The number one mistake made by designers and developers alike is assuming that things will always look like they do in the static mockup. I can assure you, they will not.

Strings may be longer than intended or contain special characters, images might be missing or have weird dimensions. Displays may be very narrow or extremely wide. Those are all states you need to anticipate.

Find Patterns and re-use them

When you set out to turn a design mockup into code, it’s often helpful to take inventory of the different patterns included first. Analyse each screen and take note of any concept that occurs more than one. It might be something small like a typographic style, or large like a certain layout pattern. What can be abstracted? What’s unique?

Use consistent Names

A surprisingly large part of programming in general is coming up with good names for stuff. In CSS, it helps to stick to a convention. Naming schemes like BEM or SMACSS can be very helpful; but even if you don’t use them, stick to a certain vocabulary. You’ll find that certain component patterns come up over and over - but is it called a “hero” or a “stage”? Is it “slider” or “carousel”?

All these things were important for me to understand, but your personal experience as to what matters most might be different. Did you have another “aha” moment that made you understand CSS better? Let me know!

Update: I did a talk about the CSS Mindset at CSS-Minsk-JS in September. There’s also a video recording available, if you prefer that.

Further Reading

• How to learn CSS by Rachel Andrews
• The Secret Weapon to learning CSS by Robin Rendle
• CSS doesn’t suck by Andy Bell

What’s a Webring?

It’s a blast from the past: In the 90s, sites about a common topic could join together in a central index. To be a member, you had to embed a little widget on your page that contained a “forward”, a “backward”, and a “random” button. These buttons would then link to the next or previous site in the ring.

A curated community

To keep the ring from getting spammed or flooded with trolls, it has to be curated. The project does that by hosting the member index on Github, in a simple JSON file. Admins can accept or decline pull requests from people who want to join the ring, after reviewing their sites. There’s also a Code of Conduct that every member has to follow in order to be part of the ring.

For people who are not technical enough to submit a pull request, there’s also a simple signup form (using Netlify forms) to send the admin your site’s info via email and let them add you.

Free and Open

I wanted to make this as easy as possible, so people can start linking their personal sites together straight away. So I made the boilerplate using Eleventy. After forking the codebase, the proud webring admin only needs to set a title and a bit of meta data.

Eleventy then generates a site like this that lists all the members, shows the Code of Conduct and the instructions on how to join.

You can deploy it to Netlify, a free static site host, with just a few clicks. Netlify also lets you either use one of their subdomains, or a custom one you own.

A central widget

Members of the ring can copy a code snippet to embed a banner on their site. I borrowed a bit from Twitters embed widget here: The basic markup is just a link to the index, and the prev/random/next links. But if you also include the script tag, it will replace that with a custom web component, designed by the ring admin.

<webring-banner>
    <p>Member of the <a href="https://webringdemo.netlify.com">An Example Webring</a> webring</p>
    <a href="https://webringdemo.netlify.com/prev">Previous</a>
    <a href="https://webringdemo.netlify.com/random">Random</a>
    <a href="https://webringdemo.netlify.com/next">Next</a>
</webring-banner>
<script async src="https://webringdemo.netlify.com/embed.js" charset="utf-8"></script>

This will automatically show the title, member count, maybe a logo. And it can be edited from a central location. It might look something like this:

RSS Feeds

If a member publishes an RSS feed on their site, they can add that to the ring as well: the index page will generate an OPML file, so people can subscribe to all members at once.

Host your own Ring!

If you want to start your own webring, go ahead! Fork the repository on Github and follow the instructions there - It’s free and doesn’t take long!

Read More

• Webrings by Charlie Owen, further elaborating on Tatiana’s tweet.
• Let’s bring Fan Sites and webrings back! by Bryan Robinson, who wrote a first implementation of webring lambda functions.

“That shit’s unsafe”, they say (I’m paraphrasing), so they attach a complicated wall-mounted seat to the inside. When the ship launches, that seat starts to pick up heavy vibrations and violently breaks apart. Foster releases her seatbelt seconds before it kills her and ultimately finds that the design was perfect all along, enjoying the rest of the ride in smooth anti-gravity.

We assume that complex problems always require complex solutions. We try to solve complexity by inventing tools and technologies to address a problem; but in the process we create another layer of complexity that, in turn, causes its own set of issues.

Simplicity as a Feature

Obviously not every problem has a simple solution, and most complex tools exist because of real usecases. But I think there’s a lot of value in actively questioning the need for complexity. Sometimes the smarter way to build things is to try and take some pieces away, rather than add more to it.

Static sites are on the rise again now, precisely because they are simple. They don’t try to manage serverside code with clever abstractions - they don’t have any. They don’t try to prevent security breaches with advanced firewalls - they get rid of the database entirely.

Some of the most important things in the world are intentionally designed “simple”. In any system, the potential for error directly increases with its complexity - that’s why most elections still work by putting pieces of paper in a box.

Think for Yourself, Question Complexity

Developers are obsessed with the notion of “best practice”.
It implies that there is one correct way of doing things, and all other solutions are either imperfect or, at worst, “anti-patterns”. But the definition of best practice changes everytime a new technology arises, rendering the previous solution worthless garbage (even though it still gets the job done).

There is an undeniable ego factor to the way we use technology in our projects. To show everyone else how clever we are, we come up with harder and harder ways to achieve our tasks. And of course they all solve specific problems - but that does not mean they are always the best solution, regardless of context.

It’s cool to use the latest and greatest tech; but we should always ask if our choices really benefit the user, or if we do it mostly for ourselves. After all, the “Developer Experience” is only a means to an end.

And if we’re talking DX - I’ll take simplicity over features any day.

The real value of social media (apart from the massive ad revenue and dystopian data mining) is in the reactions we get from other people. The likes, reposts and replies - they’re what makes it “social”. To gain control over our own content, we need to capture these interactions as well and pull them back to our sites. In indieweb terms, that’s known as “backfeed”.

Hello Webmentions

To make a site support webmentions, it needs to declare an endpoint to accept them. That endpoint can be a script hosted on your own server, or in the case of static sites, a third-party service like webmention.io.

Webmention.io is a free service made by indieweb pioneer Aaron Parecki that does most of the groundwork of receiving, storing and organizing incoming webmentions for you. It’s awesome!

To use it, sign up for a free account there using the IndieAuth process, then include a link tag in the head of your site:

<link rel="pingback" href="https://webmention.io/mxb.dev/xmlrpc">
<link rel="webmention" href="https://webmention.io/mxb.dev/webmention">

Turning social media interactions into webmentions

Cool. So that’s all very nice, but the real party is still over at [currently hip social network], you say. Nobody ever sends me any webmentions.

Well, while your platform of choice is still around, you can use a tool to automatically turn social media interactions into beautiful open webmentions. Bridgy is another free service that can monitor your Twitter, Facebook or Instagram activity and send a webmention for every like, reply or repost you receive.

So if you were to publish a tweet that contains a link back to your site, and somebody writes a comment on it, Bridgy will pick that up and send it as a webmention to your endpoint!

The resulting entry on webmention.io then looks something like this:

    {
      "type": "entry",
      "author": {
        "type": "card",
        "name": "Sara Soueidan",
        "photo": "https://webmention.io/avatar/pbs.twimg.com/579a474c9b858845a9e64693067e12858642fa71059d542dce6285aed5e10767.jpg",
        "url": "https://sarasoueidan.com"
      },
      "url": "https://twitter.com/SaraSoueidan/status/1022009419926839296",
      "published": "2018-07-25T06:43:28+00:00",
      "wm-received": "2018-07-25T07:01:17Z",
      "wm-id": 537028,
      "wm-source": "https://brid-gy.appspot.com/comment/twitter/mxbck/1022001729389383680/1022009419926839296",
      "wm-target": "https://mxb.dev/blog/layouts-of-tomorrow/",
      "content": {
        "content-type": "text/plain",
        "value": "This looks great!",
        "text": "This looks great!"
      },
      "in-reply-to": "https://mxb.dev/blog/layouts-of-tomorrow/",
      "wm-property": "in-reply-to",
      "wm-private": false
    }

But wait, there’s more!

The beauty of webmentions is that unlike with regular social media, reactions to your content are not limited to users of one site. You can combine comments from Facebook and Twitter with replies people posted on their own blogs. You can mix retweets and shares with mentions of your content in newsletters or forum threads.

You also have complete control over who and what is allowed in your mentions. Content silos often only allow muting or blocking on your own timeline, everyone else can still see unwanted or abusive @-replies. With webmentions, you’re free to moderate reactions however you see fit. Fuck off, Nazis!

Including webmentions in static sites

Once the webmention endpoint is in place, we still need to pull the aggregated data down to our site and display it in a meaningful way.

The way to do this depends on your setup. Webmention.io offers an API that provides data as a JSON feed, for example. You can query mentions for a specific URL, or get everything associated with a particular domain (allthough the latter is only available to site owners.)

My site uses Eleventy, which has a conventient way to pull in external data at build time. By providing a custom function that queries the API, Eleventy will fetch my webmentions and expose them to the templates when generating the site.

// data/webmentions.js
const API_ORIGIN = 'https://webmention.io/api/mentions.jf2'

module.exports = async function() {
    const domain = 'mxb.dev'
    const token = process.env.WEBMENTION_IO_TOKEN
    const url = `${API_ORIGIN}?domain=${domain}&token=${token}`

    try {
        const response = await fetch(url)
        if (response.ok) {
            const feed = await response.json()
            return feed
        }
    } catch (err) {
        console.error(err)
        return null
    }
}

The feed can now be accessed in the {{ webmentions }} variable.

Here’s the complete function if you’re interested. Other static site generators offer similiar methods to fetch external data.

Parsing and Filtering

Now that the raw data is available, we can mold it into any shape we’d like. For my site, the processing steps look like this:

• Filter the raw data for each post, only include mentions targeting that URL.
• Only allow “mentions” and “replies” in the comment section. Likes and Reposts go somewhere else.
• Remove entries that dont have any content to display.
• Sanitize the output - strip HTML tags, truncate long content, etc.

// filters.js
const sanitizeHTML = require('sanitize-html')

function getWebmentionsForUrl(webmentions, url) {
    const allowedTypes = ['mention-of', 'in-reply-to']

    const hasRequiredFields = entry => {
        const { author, published, content } = entry
        return author.name && published && content
    }
    const sanitize = entry => {
        const { content } = entry
        if (content['content-type'] === 'text/html') {
            content.value = sanitizeHTML(content.value)
        }
        return entry
    }

    return webmentions
        .filter(entry => entry['wm-target'] === url)
        .filter(entry => allowedTypes.includes(entry['wm-property']))
        .filter(hasRequiredFields)
        .map(sanitize)
}

In Eleventy’s case, I can set that function as a custom filter to use in my post templates.
Each post will then loop over its webmentions and output them underneath.

<!-- webmentions.njk -->
{% set mentions = webmentions | getWebmentionsForUrl(absoluteUrl) %}
<ol id="webmentions">
{% for webmention in mentions %}
    <li class="webmentions__item">
        {% include 'webmention.njk' %}
    </li>
{% endfor %}
</ol>

You can see the result by scrolling down to the end of this post (if there are any replies 😉).

Client-Side Rendering

Because static sites are, well, static - it’s possible that new mentions have happened since the last build. To keep the webmention section up-to-date, there’s an extra step we can take: client side rendering.

Remember I said the webmention.io API can be used to only fetch mentions for a specific URL? That comes in handy now. After the page has loaded, we can fetch the latest mentions for the current URL and re-render the static webmention section with them.

On my site, I used Preact to do just that. It has a very small (~3kB) footprint and lets me use React’s mental model and JSX syntax. It would probably also have been possible to re-use the existing nunjucks templates, but this solution was the easiest and most lightweight for me.

I essentially used the same logic here as I did in the static build, to ensure matching results. The rendering only starts after the API call returned valid data though - if anything goes wrong or the API is unavailable, there will still be the static content as a fallback.

// webmentions/index.js
import { h, render } from 'preact'
import App from './App'

...
const rootElement = document.getElementById('webmentions')
if (rootElement) {
    fetchMentions()
        .then(data => {
            if (data.length) {
                render(<App webmentions={data} />, rootElement)
            }
        })
        .catch(err => {
            console.error(err)
        })
}

There are of course still some missing pieces, most notably the ability to send outgoing webmentions to URLs linked to in your own blog posts. I might have to look into that.

Update: Outgoing Webmentions!

Remy Sharp has recently published a very useful new tool that takes care of handling outgoing webmentions for you. Webmention.app is a platform agnostic service that will check a given URL for links to other sites, discover if they support webmentions, then send a webmention to the target.

You can use that service in a number of ways, including your own command line. If you host your site on Netlify though, it’s also very straightforward to integrate it using deployment webhooks!

Jekyll Plugin

My implementation was heavily inspired by Aaron Gustafson’s excellent Jekyll Plugin (link below), which goes even further with customization and caching options. If you’re running a Jekyll site, use that for almost instant webmention support 👍.

Further Resources

• W3C Recommendation for the Webmention Standard
• Webmention.io Jekyll Plugin by Aaron Gustafson
• Indieweb Examples of people using Webmentions on their sites

However, the main reason why people publish on Twitter / Medium or other platforms is that they can reach a much bigger audience there - everyone’s on them, so you have to be too. Publishing on a personal site can cut you off from those readers. That’s why it might be a good idea to automatically post copies of your content on these sites whenever you publish something new.

This practice is known as “POSSE” (Publish on your Own Site, Syndicate Elsewhere). It enables authors to reach people on other platforms while still keeping control of the original content source.

For the recent relaunch of my personal website, I wanted to embrace some of these ideas. I included a section called notes featuring small, random pieces of content - much like tweets. These notes are perfect candidates for syndication to Twitter.

Syndication on Static Sites

My site is built with Eleventy, a static site generator based on node, and hosted on Netlify. Static sites are awesome for a variety of reasons, but interacting with other platforms typically requires some serverside code - which they don’t have.

Luckily though, Netlify provides a service called “Functions”, which lets you write custom AWS lambda functions without the hassle of dealing with AWS directly. Perfect! 🤘

A content feed

The first step is to publish a machine-readable feed of the content we want to syndicate. That’s exactly what RSS-Feeds are for - but they’re usually in XML format, which is not ideal in this case.

For my own site, I chose to provide notes as a simple JSON object. I already have an atom feed for content readers, and JSON makes the note processing easier later on.

My feed looks something like this:

// notes.json
[
    {
        "id": 1,
        "date": "2018-12-02T14:20:17",
        "url": "https://mxb.dev/notes/2018-12-02/",
        "content": "Here's my first note!",
        "syndicate": true
    },
    {...}
]

All entries also include a custom syndicate flag that overrides the auto-publishing behaviour if necessary.

Event-Triggered Functions

Now for the tricky part: we need to write a lambda function to push new notes to Twitter. I won’t go into detail on how to build lambda functions on Netlify, there are already some great tutorials about this:

• Build and deploy a serverless function to Netlify (scotch.io)
• Lambda functions playground (netlify.com)

To trigger our custom function everytime a new version of the site was successfully deployed, we just need to name it deploy-succeeded.js. Netlify will then automatically fire it after each new build, while also making sure it’s not executable from the outside.

Whenever that function is invoked, it should fetch the list of published notes from the JSON feed. It then needs to check if any new notes were published, and whether they should be syndicated to Twitter.

// deploy-succeeded.js
exports.handler = async () => {
    return fetch('https://mxb.dev/notes.json')
        .then(response => response.json())
        .then(processNotes)
        .catch(err => ({
            statusCode: 422,
            body: String(err)
        }))
}

Since we will have to interact with the Twitter API, it’s a good idea to use a dedicated helper class to take some of that complexity off our hands. The twitter package on npm does just that. We will have to register for a developer account on Twitter first though, to get the necessary API keys and tokens. Store those in your project’s .env file.

TWITTER_CONSUMER_KEY=YourTwitterConsumerKeyHere
TWITTER_CONSUMER_SECRET=YourTwitterConsumerSecretStringHere
TWITTER_ACCESS_TOKEN_KEY=12345678-YourTwitterAccessTokenKeyHere
TWITTER_ACCESS_TOKEN_SECRET=YourTwitterAccessTokenSecretStringHere

Use these keys to initialize your personal Twitter client, which will handle the posting for your account.

// Configure Twitter API Client
const twitter = new Twitter({
    consumer_key: process.env.TWITTER_CONSUMER_KEY,
    consumer_secret: process.env.TWITTER_CONSUMER_SECRET,
    access_token_key: process.env.TWITTER_ACCESS_TOKEN_KEY,
    access_token_secret: process.env.TWITTER_ACCESS_TOKEN_SECRET
})

Right. Now we need to look at the notes array and figure out what to do. To keep it simple, let’s assume the latest note is a new one we just pushed. Since the JSON feed lists notes in descending date order, that would be the first item in the array.

We can then search twitter for tweets containing the latest note’s URL (we will include that in every syndicated tweet to link back to the original source). If we find anything, then it’s already been published and we don’t need to do anything. If not, we’ll go ahead.

const processNotes = async notes => {
    // assume the last note was not yet syndicated
    const latestNote = notes[0]

    // check if the override flag for this note is set
    if (!latestNote.syndicate) {
        return {
            statusCode: 400,
            body: 'Latest note has disabled syndication.'
        }
    }

    // check twitter for any tweets containing note URL.
    // if there are none, publish it.
    const search = await twitter.get('search/tweets', { q: latestNote.url })
    if (search.statuses && search.statuses.length === 0) {
        return publishNote(latestNote)
    } else {
        return {
            statusCode: 400,
            body: 'Latest note was already syndicated.'
        }
    }
}

Next, we need to prepare the tweet we want to send. Since our self-published note does not have the same restrictions that twitter has, we should format its content first.

My implementation simply strips all HTML tags from the content, makes sure it is not too long for Twitter’s limit, and includes the source url at the end. It’s also worth noting that Eleventy will escape the output in the JSON feed, so characters like " will be encoded to " entities. We need to reverse that before posting.

// Prepare the content string for tweet format
const prepareStatusText = note => {
    const maxLength = 200

    // strip html tags and decode entities
    let text = note.content.trim().replace(/<[^>]+>/g, '')
    text = entities.decode(text)

    // truncate note text if its too long for a tweet.
    if (text.length > maxLength) {
        text = text.substring(0, maxLength) + '...'
    }

    // include the note url at the end.
    text = text + ' ' + note.url
    return text
}

When everything is done, we just need to send our note off to Twitter:

// Push a new note to Twitter
const publishNote = async note => {
    const statusText = prepareStatusText(note)
    const tweet = await twitter.post('statuses/update', {
        status: statusText
    })
    if (tweet) {
        return {
            statusCode: 200,
            body: `Note ${note.date} successfully posted to Twitter.`
        }
    }
}

Hopefully that all worked, and you should end up with something like this in your timeline:

I did some housekeeping over the holidays and switched my website to @eleven_ty and @Netlify !

👉 https://t.co/oq0OyPyjRs

— Max Böck (@mxbck) January 4, 2019

🎉 You can find the finished lambda function here.

Further Resources

• Indieweb Notes The concept behind this.
• eleventyone by Phil Hawksworth A starter for Eleventy sites, including lambda functions and netlify-lambda.
• Twitter API Docs

To help them, news platforms like CNN and NPR provide text-only versions of their sites:

We have a text-only version of our website for anyone who needs to stay up-to-date on Hurricane Florence news and keep their battery and data usage to a minimum: https://t.co/n2UDDKmlja

— NPR (@NPR) September 14, 2018

That’s a great thing. Here’s how it looks:

Less is More

Text-only sites like these are usually treated as a MVP of sorts. A slimmed-down version of the real site, specifically for emergencies.

I’d argue though that in some aspects, they are actually better than the original. Think about it- that simple NPR site gets a lot of points right:

• It’s pure content, without any distractions
• It’s almost completely fail-safe
• It’s responsive by default and will work on any device
• It’s accessible
• It’s search engine friendly
• It’s machine readable and translatable
• It has close to perfect performance scores:

Most importantly, it’s user friendly. People get what they came for (the news) and are able to accomplish their tasks.

The only thing missing here might be a few sensible lines of CSS to set better typography rules. Those could still be inlined in the head though, easily coming in under the 14KB limit for the first connection roundtrip.

This is the web as it was originally designed. Pure information, with zero overhead. Beautiful in a way.

The “full” NPR site in comparison takes ~114 requests and weighs close to 3MB on average. Time to first paint is around 20 seconds on slow connections. It includes ads, analytics, tracking scripts and social media widgets.

Meanwhile, the actual news content is roughly the same. The articles are identical - apart from some complementary images, they convey exactly the same information.

If the core user experience can be realized with so little, then what is all that other stuff for?

The Cost of Comfort

Of course the main NPR site offers a lot more than just news, it has all sorts of other features. It has live radio, podcasts, video and more. Articles are preloaded via AJAX. It’s a much richer experience - but all that comes at a price.

I recently read this great article by Alex Russel, in which he compares Javascript to CO₂ - in the sense that too much of it can be harmful to the ecosystem.

Javascript enables us to do amazing things and it can really enhance the user experience, if done right. But it always has a cost. It’s the most expensive way to accomplish a task, and it’s also the most fragile. It’s easy to forget that fact when we develop things on a highspeed broadband connection, on our state-of-the-art devices.

That’s why websites built for a storm do not rely on Javascript. The benefit simply does not outweigh the cost. They rely on resilient HTML, because that’s all that is really necessary here.

That NPR site is a very useful thing that serves a purpose, and it does so in the simplest, most efficient way possible. Personally, I’d love to see more distilled experiences like this on the web.

… “Well, this might work for a news site - but not every usecase is that simple.”, I hear you say.

True. The web is a text-based medium, and it works best with that type of content. But the basic approach is still valid in any other scenario:

Figure out what the main thing is people want from your site and deliver it - using the simplest, least powerful technology available. That’s what “the rule of least power” tells us, and it’s still the best strategy to a make a website truly resilient.

Make it withstand hurricanes.

We don’t design sites for specific screen dimensions anymore, we make them responsive. We don’t assume ideal browsers and devices, we use progressive enhancement. When it comes to connectivity though, we still treat that as a binary choice: you’re either on- or offline.

Real connections are not that simple. Depending on your location, network condition or data plan, speeds can range from painfully slow to blazingly fast. The concept of “online” can be a drastically different experience for different users, especially on mobile.

What if there was a way to adapt websites based on our users connections, just like we do for varying display widths and browser capabilities? The Network Information API might enable us to do so.

The Network Information API

This API is an editor’s draft by the WICG and currently available in Chrome. It can be accessed through the read-only property navigator.connection (MDN), which exposes several properties that provide information about a user’s current connection:

• connection.type:

Returns the physical network type of the user agent as strings like “cellular”, “ethernet” or “wifi”.

• connection.downlink:

An effective bandwidth estimate (in Mb/s), based on recently observed active connections.

• connection.rtt:

An estimate of the average round-trip time (in milliseconds), based on recently observed active connections.

• connection.saveData:

Returns true if the user has requested “reduced data mode” in their browser settings.

• connection.effectiveType:

This is a combined estimation of the network quality, based on the round-trip time and downlink properties. It returns a string that describes the connection as either: slow-2g, 2g, 3g or 4g. Here’s how these categories are determined:

Responding to Changes

There is also an Event Listener available on the connection property that fires whenever a change in the network quality is detected:

function onConnectionChange() {
    const { rtt, downlink, effectiveType } = navigator.connection
    console.log(`Round Trip Time: ${rtt}ms`)
    console.log(`Downlink Speed: ${downlink}Mb/s`)
    console.log(`Effective Type: ${effectiveType}`)
}
navigator.connection.addEventListener('change', onConnectionChange)

Support

👉 Be aware that all of this is still experimental. Only Chrome and Samsung Internet browsers have currently implemented the API. It’s a very good candidate for progressive enhancement though - and support for other platforms is on the way.

Connection-aware components

So how could this be used? Knowing about connection quality enables us to custom-fit resources based on network speed and data preferences. This makes it possible to build an interface that dynamically responds to the user’s connection - a “connection-aware” frontend.

By combining the Network Information API with React, we could write a component that renders different elements for different speeds. For example, a <Media /> component in a news article might output:

• offline: a placeholder with alt text
• 2g / reduced data mode: a low-resolution image, ~30kb
• 3g: a high resolution retina image, ~200kb
• 4g: a HD video ~1.8MB

Here’s a (very simplified) example of how that might work:

class ConnectionAwareMedia extends React.Component (
    constructor(props) {
        super(props)
        this.state = {
            connectionType: undefined
        }
    }

    componentWillMount() {
        // check connection type before first render.
        if (navigator.connection && navigator.connection.effectiveType) {
            const connectionType = navigator.onLine 
                ? navigator.connection.effectiveType
                : 'offline'
            this.setState({
                connectionType
            })
        }
    }

    render() {
        const { connectionType } = this.state
        const { imageSrc, videoSrc, alt } = this.props

        // fallback if network info API is not supported.
        if (!connectionType) {
            return <Image src={imageSrc.hires} alt={alt} />
        }

        // render different subcomponents based on network speed.
        switch(connectionType) {
            case 'offline':
                return <Placeholder caption={alt} />

            case '4g':
                return <Video src={videoSrc} />

            case '3g':
                return <Image src={imageSrc.hires} alt={alt} />

            default:
                return <Image src={imageSrc.lowres} alt={alt} />
        }
    }
)

Using a Higher-Order Component

The above example makes our component a bit unpredictable - it renders different things, even when given the same props. This makes it harder to test and maintain. To simplify it and enable reuse of our logic, moving the network condition check into a separate higher-order component might be a good idea.

Such a HoC could take in any component we want and make it connection-aware, injecting the effective connection type as a prop.

function withConnectionType(WrappedComponent, respondToChange = false) {
    return class extends React.Component {
        constructor(props) {
            super(props)
            this.state = {
                connectionType: undefined
            }
            // Basic API Support Check.
            this.hasNetworkInfoSupport = Boolean(
                navigator.connection && navigator.connection.effectiveType
            )
            this.setConnectionType = this.setConnectionType.bind(this)
        }

        componentWillMount() {
            // Check before the component first renders.
            this.setConnectionType()
        }

        componentDidMount() {
            // optional: respond to connectivity changes.
            if (respondToChange) {
                navigator.connection.addEventListener(
                    'change', 
                    this.setConnectionType
                )
            }
        }

        componentWillUnmount() {
            if (respondToChange) {
                navigator.connection.removeEventListener(
                    'change', 
                    this.setConnectionType
                )
            }
        }

        getConnectionType() {
            const connection = navigator.connection
            // check if we're offline first...
            if (!navigator.onLine) {
                return 'offline'
            }
            // ...or if reduced data is preferred.
            if (connection.saveData) {
                return 'saveData'
            }
            return connection.effectiveType
        }

        setConnectionType() {
            if (this.hasNetworkInfoSupport) {
                const connectionType = this.getConnectionType()
                this.setState({
                    connectionType
                })
            }
        }

        render() {
            // inject the prop into our component.
            // default to "undefined" if API is not supported.
            return (
                <WrappedComponent
                    connectionType={this.state.connectionType}
                    {...this.props}
                />
            )
        }
    }
}

// Now we can reuse the function to enhance all kinds of components.
const ConnectionAwareMedia = withConnectionType(Media)

👉 This small proof-of concept is also available on CodePen, if you want to play around.

Further Reading

• Network Information API Draft - WICG
• Dev Thread in Chromium Forum- Intent to Ship
• Official Example for Chrome - shows all currently available properties

which one of the two possible websites are you currently designing? pic.twitter.com/ZD0uRGTqqm

— Jon Gold (@jongold) 2. Februar 2016

It mocks the fact that a lot of today’s websites look the same, as they all follow the same standard layout practices that we’ve collectively decided to use. Building a blog? Main column, widget sidebar. A marketing site? Big hero image, three teaser boxes (it has to be three).

When we look back at what the web was like in earlier days, I think there’s room for a lot more creativity in web design today.

Enter CSS Grid

Grid is the first real tool for layout on the web. Everything we had up until now, from tables to floats to absolute positioning to flexbox - was meant to solve a different problem, and we found ways to use and abuse it for layout purposes.

The point of these new tools is not to build the same things again with different underlying technology. It has a lot more potential: It could re-shape the way we think about layout and enable us to do entirely new, different things on the web.

Now I know it’s hard to get into a fresh mindset when you’ve been building stuff a certain way for a long time. We’re trained to think about websites as header, content and footer. Stripes and boxes.

But to keep our industry moving forward (and our jobs interesting), it’s a good idea to take a step back once in a while and rethink how we do things.

If we didn’t, we’d still be building stuff with spacer gifs and all-uppercase <TABLE> tags. 😉

So, how could things look?

I went over to dribbble in search of layout ideas that are pushing the envelope a bit. The kind of design that would make frontend developers like me frown at first sight.

There’s a lot of great work out there - here’s a few of my favorites:

I especially like that last one. It reminds me a bit of the “Metro Tiles” that were all the rage in Windows 8. Not only is this visually impressive, its very flexible too - I could see this working on a phone, a tablet, even on huge TV screens or in augemented reality, as suggested by the designer.

How hard is it to make something like this, given the tools we have today? I wanted to find out and started building a prototype.

I tried to approach this with real production constraints in mind. So the interface had to be responsive, performant and accessible. (It’s not required to be pixel-perfect everywhere though, cause you know - that’s not a real thing.)

Here’s how it turned out: