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

A truly responsive website should adapt to all kinds of situations. Besides different viewport sizes, there are other factors to consider. A change in connectivity is one of them.

Earlier this week, I was sitting in a train on my way to speak at a local meetup. InterCity trains in Austria all have WIFI now, so I was doing some last-minute work on my slides online. Train WIFI being what it is though, the network wasn’t exactly reliable. The connection kept dropping everytime we went through a tunnel or too many passengers were logged on.

This is quite a common scenario. People are on the move, network coverage can be poor, internet connections fail. Luckily, we can prepare our websites for this and make them more resilient by building them offline-first.

Offline support is awesome, however your users might not be aware of these capabilites - and they shouldn’t have to be. In some cases they might not even know that they’ve gone offline. That’s why it’s important to communicate what’s going on.

Chances are not every part of your site will work offline. Certain things may not be cached, others may require server interaction. This is fine of course, but the interface should reflect that. Just like a responsive layout adapts to changes in viewport size, your offline-optimized site should adapt to changes in connectivity.

Checking for Offline

The key ingredients here are the offline event and the navigator.onLine property. By combining them, we can check for network changes and react accordingly.

Here’s an example of a simple connectivity check:

let isOffline = false;
window.addEventListener('load', checkConnectivity);

// when the page has finished loading,
// listen for future changes in connection
function checkConnectivity() {
  updateStatus();
  window.addEventListener('online', updateStatus);
  window.addEventListener('offline', updateStatus);
}

// check if we're online, set a class on <html> if not
function updateStatus() {
  if (typeof navigator.onLine !== 'undefined'){
    isOffline = !navigator.onLine;
    document.documentElement.classList.toggle('is-offline', isOffline);
    ...
  }
}

⚠️ Note: With the online event, there’s a slight possibility of false positives: A user might be connected to a network (which is interpreted as being online), but something higher up might block actual internet access. The offline event is a bit more reliable, in the sense that an “offline” user can be expected NOT to have access.

Get Notified

Now we want to display some kind of notification to offline users, so they know what’s going on. This can be done in a number of ways; however I would recommend using aria-live regions to make it accessible and have screen readers announce the connection change as well.

Using such a notification bar is pretty straightforward. First, define an element to display messages on your page:

<!-- notification container -->
<div 
  class="notification" 
  id="notification" 
  aria-live="assertive" 
  aria-relevant="text" 
  hidden
></div>

The aria-live attribute tells screen readers to announce changes to this element. “assertive” means it will interrupt whatever it is currently announcing at the time and prioritize the new message. The aria-relevant tells it to listen for changes in the text content of the element.

You can extend the handler function from before to populate the notification area whenever you detect that a user has gone offline:

function updateStatus() {
  ...
  const notification = document.querySelector('#notification');
  if (isOffline) {
    notification.textContent = 'You appear to be offline right now.';
    notification.removeAttribute('hidden');
  } else {
    notification.textContent = '';
    notification.setAttribute('hidden');
  }
}

This is a very simple implementation - you can of course always get a bit fancier with an animated notification bar (or “toast message”). There are also some nice pre-made components for this.

If you’re reading this on my site, you can see a version of these notifications in action if you simply switch off your WIFI for a second.
Go ahead, I’ll wait.

If you’re somewhere else or your browser doesn’t support service worker / offline events, here’s how this could look:

Telling the User what’s available

Notifications are a good start, but it would be even nicer if we could give the user some visual indication of which parts they can actually use offline, and which not.

To do this, we can loop over all the links on page load and check their href against the cache. If they point to a cached resource (e.g. will work offline), they get a special class.

const links = document.querySelectorAll('a[href]');
Array.from(links).forEach((link) => {
  caches.match(link.href, { ignoreSearch: true }).then((response) => {
    if (response) {
      link.classList.add('is-cached');
    }
  });
});

Once the offline event fires, we toggle a class on the body and visually disable all links that aren’t cached. This should only apply to URLs, so we can ignore tel:, mailto: and anchor links.

.is-offline {
  /* disable all links to uncached pages */
  a:not(.is-cached) {
    cursor:not-allowed;
    pointer-events: none;
    opacity:.5;
  }
  /* ignore anchors, email and phone links */
  a[href^="#"],
  a[href^="mailto"],
  a[href^="tel"] {
    cursor:auto;
    pointer-events: auto;
    opacity:1;
  }
}

Offline Forms

Another way we might use this is to prevent users from filling out forms. Most forms pass data to the server and require a connection to work, so they won’t be very useful when offline.

What’s worse is that users might not know there is a problem until it’s too late: imagine filling out a lengthy form and finally hitting the submit button, only to find a network connection error page and all your inputs gone. That’s frustrating.

/* Disable Forms when offline */
.is-offline form {
  position:relative;
  opacity:.65;
  cursor:not-allowed;
  pointer-events:none;
  
  &::after {
    content: 'Sorry, you\'re offline.';
    display:block;
    position:absolute;
    top:50%;
    left:50%;
    transform:translate(-50%, -50%);
    color:#FFFFFF;
    background-color:#2D2D2D;
    padding:1rem 2rem;
  }
}

That effectively disables every form on the page, indicating that this functionality is currently not available. Depending on what your form does, you might also consider applying these styles just to the submit button - that way a user could pre-fill the form (possibly even have it validated in JS), and then submit it once they come back online.

If you’re doing this, remember to suppress “submit on enter” as well, and make sure the user knows why submitting won’t work at the moment.

UPDATE: I found a better way to handle this - by storing form submissions in localStorage and then checking for them once the connection comes back online. Read about it in “Offline-Friendly Forms”.

Further Reading

• Intro: OfflineFirst.org
• Google Developers: Offline Storage
• Jake Archibald at I/O 2016: Building offline-first PWAs (Video)

I built this product slider as part of a wine shop I was working on in 2015, and since it's also featured in a case study here on my site, I had a couple of people asking me how the animation was done.

Well, it’s really quite simple – so here’s a quick rundown on how to make the bottles dance. You can see the actual live thing in action on one of the product pages here. Grab some Grüner Veltliner while you’re at it.

The Slider

Markup is pretty straightforward, just your standard slider structure. A parent div and an ul with some list items. The real production version obviously has a little bit more going on, what with that fancy ratings popover and all. But for now, this should do the job:

<div class="slider">
  <ul class="slider__content">

    <li class="slider__item">
      <a href="link/to/product">
        <img src="image_of_bottle.jpg" alt="" />
      </a>
    </li>

    <li class="slider__item">...</li>
    <li class="slider__item">...</li>

  </ul>
</div>

To make this into a slider widget, you will need some CSS and a bit of Javascript. I used a jQuery plugin called Flexslider for this one, and I like it a lot. But almost any other slider would work too. The only important part for this effect is a callback function that gets triggered before each sliding transition.

Flexslider does exactly that with its before method. You pass it the $slider variable (the parent element), and then apply a class to it that later controls the animation state. After the animation has finished, we need to remove that class again. My wiggle lasts about a second, so I put in a setTimeout for that duration (plus a little more for good measure).

$slider.flexslider({
  //animation: 'slide',
  //selector: '.slider__item',
  //animationLoop: false,
  //slideshow: false,
  before: function($slider){
    $slider.addClass('slider--shaking');
    window.setTimeout(function(){
      $slider.removeClass('slider--shaking');
    }, 1200);
  }
});

The Animation

Next up is the actual CSS keyframe animation that makes the bottles swing from side to side. Mine looks like this:

@keyframes wiggle {
  25%  { transform: rotate3d(0, 0, 1, 6deg)  }
  50%  { transform: rotate3d(0, 0, 1, -4deg) }
  75%  { transform: rotate3d(0, 0, 1, 2deg)  }
  100% { transform: rotate3d(0, 0, 1, 0deg)  }
}

We tilt the items first right, then left, then right again, losing momentum in each turn to simulate the inertia a real bottle would have.
The rotate3d is to force graphic acceleration, which makes for smoother animation performance. Also, be sure to include vendor prefixes for the transform - or, if you’re lazy like me, let Autoprefixr do that for you.

The last step is to apply the keyframe animation to your slider every time it gets triggered.
Two things are important here:

1. define the transform-origin for each object. This will be the fixed point that anchors the animation, it corresponds to the center of gravity in the real world. For my bottles, that would be center bottom.

2. 💡__PRO TIP:__ to make it seem more realistic, apply a little delay to every other bottle, so they dont all wiggle in unison. A small offset in timing does the trick.

.slider--shaking .slider__item {
  //disable hover effects while transitioning
  pointer-events:none;

  //set up the wiggle animation
  animation-name: wiggle;
  animation-duration: 1s;
  animation-fill-mode: both;

  //set the 'fixed point' of the animation
  transform-origin:bottom center;
}

.slider--shaking .slider__item:nth-child(2n) {
  //slightly offset every other item
  animation-delay:.1s;
}

Aaand you’re done! Not much to it, but makes for a nice touch and a cool thing to show off. 🍾