Blog | Navillus

The case for boring tech, five years later

Mon, 04 May 2026 12:00:00 GMT

Almost five years ago we published The power of simplicity, arguing that "the boring tools make your life easier in the long run." We'd just rebuilt the site on Astro and Forestry CMS and were feeling pleased with ourselves about it.

Forestry got wound down by its own team. Half the JavaScript ecosystem we name-checked is on a different version, deprecated, or quietly forgotten. The "Jamstack" branding has folded back into the rest of the web.

So how did the thesis hold up?

tl;dr; Better than we expected, and for reasons we mostly didn't predict. The boring stuff outlasted the shiny stuff. We were also wrong about who the post was for.

What aged well

The list of "old, boring tools" we cited (JSON, git, markdown, HTML, CSS, JavaScript) is exactly the same list we'd cite today, with the same versions still in widespread use. Nobody has had to relearn how to write a <form> tag.

A few additions to the boring-tech canon since:

Postgres is more entrenched than ever. The five-year-old startup using it is still using it. The hot new managed-Postgres service that launched in 2022 has since been acquired by another managed-Postgres service that launched in 2024.
SQLite quietly took over half the small things we build. It runs at the edge, it ships inside the binary, it backs single-user apps and multi-tenant ones, and it's still a single file you can copy.
Astro, which we called "shiny new" in the original post, is now five years old and behaves like the boring tools: backwards-compatible upgrades, slow API churn, content collections that haven't broken twice.

The pattern is the same one we noticed in 2021: tools that don't make you relearn them every year tend to compound. Tools that do, don't.

What didn't survive

The Forestry team rebuilt their product as TinaCMS, which is tied to React, and wound the original CMS down. Snipcart got acquired by Duda back in 2021 and isn't the standalone story it used to be. Gatsby went from one of three default React choices to a footnote. The serverless-backend startup we evaluated in 2021 is gone; the one that replaced it is being acquired; the one that's replacing that is making the same architectural promises in a slightly different colour scheme.

We're not gloating. We picked Forestry. We were wrong. The lesson isn't "we predicted this." It's that the cost of being wrong about a vendor was much higher than the cost of being wrong about a framework. Migrating from Astro to Eleventy is a weekend's work. Migrating off a deprecated CMS is a re-platform.

What we got wrong

Two things, mainly.

We wrote the post for developers. That made sense in 2021. We were in a Twitter thread loop with other devs about Jamstack architecture. Five years on, the argument matters even more for the people who aren't developers: the small business owner whose site keeps breaking after WordPress updates, the nonprofit director whose previous developer disappeared and took the deployment credentials with her. They don't have the option of "I'll just learn the new framework." For them, boring tech isn't an aesthetic preference. It's the only honest answer to "will this still be running in five years."

We undersold the human side. The original post celebrated long-lived tech without addressing the social problem: who maintains it after you leave? "Boring" isn't valuable because it's old. It's valuable because the next person can pick it up. Postgres is boring because millions of developers know it. HTML is boring because every browser implements it. A weird stack is "interesting" right up until the day you need to hand it off, at which point it's a liability.

What changed since

A few things genuinely shifted.

AI writes a lot of code now. We use it. It doesn't change the boring-tech argument. If anything, it sharpens it. AI is excellent at reading and writing well-trodden patterns: plain JavaScript, Postgres queries, a basic Astro page. It struggles with bespoke architectures, custom DSLs, and the tangled middleware of a 15-plugin WordPress install. The cheaper AI gets at maintaining your code, the more you should write code AI can read.

The web platform caught up. A lot of what required a framework in 2021 now ships in the browser: view transitions, the popover API, native dialogs, container queries. The ratio of "HTML you write" to "framework you wrap it in" keeps tilting toward HTML. Good.

Edge and serverless settled. The "should I deploy to 27 regions or 3?" debate quieted down. Most small sites and most internal tools want one good region, sometimes a CDN, sometimes a worker at the edge for one specific job. Almost nobody actually needs the architectural complexity that was being sold as table stakes.

Why this matters more for our clients

Five years ago we were writing for ourselves. Today we build websites and internal tools for small businesses and non-profits, and the stakes are different.

A nonprofit running on a $30/month hosting bill cannot afford a year of refactoring to chase a framework deprecation. A community center whose donor data lives in a Retool dashboard does not need a microservices migration. The local business whose website does seven things does not benefit from a stack that could theoretically scale to seven million.

For them, "boring" isn't conservative. It's competent. It's the difference between a website that costs $0 to leave running and one that quietly accumulates a $400/month SaaS bill nobody can explain.

What still holds up

The closing line of the original post was: "There's always a new tool to try or pattern to learn, but at the end of the day it's much more satisfying to ship a product rather than trying out a new tool."

That still stands. We'd add one thing: ship a product that the next person can pick up without you. Not because they will, but because if they have to, the project survives.

That's what boring tech actually buys.

How to use Web Components in Astro

Mon, 23 Aug 2021 17:51:19 GMT

Web components have had a bit of a rocky past, to put it lightly. The API design has gone through multiple iterations, a few unexpected rough edges really hindered their usefulness. And if it wasn't already confusing enough, the level of excitement around the vision of custom elements has led to over 50 different patterns and frameworks to get the job done.

I've honestly not given custom elements much of a chance since the early iterations of the spec, and its about time I give it a proper chance again. Like many web developers I really love the vision of having a standard for building native custom components without reaching for the usual JavaScript frameworks.

tl;dr; Web components aren't the magic bullet I'd hoped for, but they've come a long way in the last couple years. When paired with Astro's new resolve API you end up with a dead simple way to quickly author simple pure JavaScript web components, bundle them for production, and hydrate them on the client. Check out a live demo or jump right into the source code on GitHub.

Do web components require a framework?

No! There are great options if you're ready to go all-in on frameworks though, I strongly recommend you checkout webcomponent.dev's detailed breakdown of all the different ways it can be done.

At the end of the day though, the frameworks are just going to compile down to JS (I haven't seen any WASM implementations yet). Frameworks like Lit let you skip the boilerplate and can help avoid some of the gotchas along the way, but what's a basic web component even look like?

Less complicated than it sounds

Web components can be daunting - shadow roots, <template>s, and extend HTMLElement aren't exactly old hack for most web developers. Let's break down the basic structure first, then jump into an full example.

Web component basics

Fair warning, I'm by no means an expert on web components - please hit me up on Twitter if I misrepresent something here!

Shadow roots

One of the more contentious parts of the spec, and the cause of many of the limitations, is the shadow DOM. The idea is to encapsulate each custom element from the rest of the DOM - if you've ever worked with iframes this will sound familiar.

The key here is that code outside of the custom element can reach down into the shadow DOM and change things, styling for example. It doesn't work the other way around though, elements and styles inside the shadow DOM can't reach outside and affect the outside world.

Sounds great, until you want a web component to change it's style based on the content around it - theming can be tricky and force you to jump through hoops.

Thankfully, the shadow DOM is actually opt-in and you can extend HTMLElement without losing access to the rest of the DOM.

HTML `template`s

Web components are meant to be reusable, and for that to be possible you need to be able to define a template with the element's initial HTML elements and styles.

This can be done a few different ways, but the most common way is to use template literals right in your web component's JS file. I'll be using one of the excellent examples from webcomponents.dev as a starting point.

const template = document.createElement('template')
template.innerHTML = `
  <style>
    /* your styles */
  </style>
  <span id="count"></span>
`

Feels a little weird writing HTML in a template literal, right? It gets the job done though, and in my opinion plain JS web components really shine with small components so this shouldn't get too crazy to maintain.

All this really does is create a new <template> tag, just like if you directly included it in your index.html. The template contains all the initial styling and HTML used to initialize the component.

extending HTMLElement

This is where it gets really interesting. Ever wonder why you can't make your own <select> or <input> elements? Well now you can (kind of)! I wouldn't recommend trying to actually replace existing HTML tags - I don't know if that would even work and it sounds like a nightmare for accessibility tools.

But you can make your own <my-counter> component, that's definitely not part of the HTML specs.

class MyCounter extends HTMLElement {
  constructor() {
    super()
    this.count = 0
    // open mode keeps all elements accessible to the outside world
    this.attachShadow({ mode: 'open' })
  }
  // ...
}

// tell the browser to use this class for all `<my-counter>` elements
customElements.define('my-counter', MyCounter)

Notice the open mode there? I mentioned earlier that you can avoid the one-way encapsulation of the shadow DOM, that's all it takes. It's a shame having to turn off one of the key features of custom elements, but theming and styling really can be a big problem for real world apps!

Filling in the details

I'll leave it up to you to check out the full source code on GitHub. I also recommend checking out the examples from webcomponents.dev as well to see what all I had to change. Spoiler: not much!

How does this work in Astro?

One huge benefit of Astro is the heavy focus on minimizing, or even completely avoiding, the amount of JavaScript used on a site. I've written before about how important simplicity is in web development, so I'll spare you the rant here.

For me, the big promise of web components is the ability to easily share basic elements across multiple projects without being tied to one specific framework. I'm not ready to build an entire PWA in web components, but when it comes to the base-level building blocks for a site I'd love to share a single <nv-button>, <nv-spinner> etc.

Maybe one of these days I'll find the time to build a full OpenUI toolkit to use for all of our client projects...

Oops, our web component breaks SSR!

const template = document.createElement('template')

Well that didn't take long, literally the first line of code breaks our Astro build 🤣

Astro is a static site generator, the entire build runs in Node.js. That means we can't actually touch the browser-only document object.

// Just create a shared string here, no more document reference
const template = `
  <style>
    /* your styles */
  </style>
  <span id="count"></span>
`

class MyCounter extends HTMLElement {
  constructor() {
    super()

    const elem = document.createElement('template')
    elem.innerHTML = template

    this.count = 0
    this.attachShadow({ mode: 'open' }).appendChild(
      elem.content.cloneNode(true)
    )
  }
}

customElements.define('my-counter', MyCounter)

There we go! Don't touch the document element at all until the constructor is called. Note that this really could/should be cleaned up to move elem outside the class and only initialize it once, but for the sake of this demo I kept the code easier to follow.

Great, but how do we actually load the script?

Astro just recently released version 0.19, one of the cool new features is the Astro.resolve() API. With it, you can take a relative URL to another file in your src/ directory and resolve it to the built file path.

This is handy for images, Astro.resolve('../images/penguin.png'), but we're going to take it a step further and use this new API to pull in our web component's JS file.

In the demo project, the web component is defined in src/components/my-counter.js. Inside the homepage at src/pages/index.astro,

<head>
  <title>Welcome to Astro</title>

  <script type="module" src={Astro.resolve('../components/my-counter.js')}
  ></script>
</head>

<body>
  <my-counter></my-counter>
</body>

That's all there is to it! From there Astro will be aware of the JS file, bundle it during production builds, and replace the Astro.resolve call with the URL needed to load in the component.

Future reading

Follow us on Twitter or subscribe to our RSS feed so you don't miss a future post covering more complex web components written with Lit!

Conclusion

Web components aren't a magic bullet, but I found this experience much less frustrating than the last time I tried it out. To be fair, that was probably back in 2017 when the spec was still an early work in progress.

I'm still not sure that I'd go through the effort to build an entire site in custom web components just yet, but I won't actually be surprised if that's a great option in the not too distant future.

Until then, browser support is surprisingly good and web components can be a great solution to reusable base components. Whether you're managing multiple projects or just preparing for the next big shakeup in frontend frameworks, it's worth giving native custom elements a second look in 2021.

The power of simplicity

Sat, 07 Aug 2021 17:42:35 GMT

Our last post highlighted the benefits of using Astro and Forestry CMS (catch up here in case you missed it). Forestry actually shared our post with a really important point that I thought was worth digging into with a proper blog post.

The beauty of embracing open formats like Markdown and JSON on top of Git is that a CMS you designed more than 5 years ago, works perfectly with the latest modern web tooling.

Now go check @astrodotbuild to ship faster websites 🚀 https://t.co/0o6OgCfkgx
— Forestry CMS (@forestryio) August 5, 2021

Follow @forestryio on Twitter if you don't already! Their git-based CMS tools are a huge win for any Jamstack project and should you have any questions or issues, their team is extremely responsive and helpful.

tl;dr; The web development landscape is constantly in flux. It's easy to see the latest tools, languages, and frameworks get hyped on your favorite blogs and podcasts, but at the end of the day you probably need to build quality sites that can be easily maintained for years. More often than not, the boring tools make your life easier in the long run!

A bit of history

It wasn't so long ago that sites were edited by handed - good old fashioned HTML,CSS, and (maybe) JS. A site contained more <marquee>s than pages, RIP marquee!, and the querySelector wasn't a thing.

Browsers are still fundamentally the same today. Yes they are much bigger and feature packed, but at the end of the day a browser takes markup in the form of HTML, styles in the form of CSS, and JavaScript for interactivity. We have more APIs to play with, and more caching problems to manage, but at the end of the day it's the development workflow that has really complicated.

Modern web development

Jumping ahead a few years (or 20) and now its not uncommon to start a project by deciding on the 5+ tools and platforms you will be bolting together. Do you want static site generation (SSG), server-side rendering (SSR), or client-side rendering(CSR)? Are you standing up and maintaining a backend server, or jumping on the serverless backend? Will plain CSS do the trick, or is SASS/SCSS/LESS your preferred approach? What about this CSS in JS and styled components madness?!?

Oh wait, you also need to host it somewhere. Does the project need continuous integration (CI) with automated testing, automated deployments, staging environments, etc? Better schedule another few days to decide on those tools, setup accounts, and bootstrap the basics together before you start coding!

Does it have to be so complicated?

No! Sure, all these tools and processes were created for good reason. CI can save a huge amount of time. Transpilers, build tools, and linters can help catch common mistakes and enforce team coding standards. Frontend frameworks can really be a lifesaver, especially if you need to build interfaces with complex interactivity and state management.

But all these advancements can turn into a real nightmare, too. Ever tried onboarding a new hire that is an experienced web developer but not familiar with the latest React trends like styled components or hooks? Is the time spent ramping up on these abstractions really worth the effort for a simple marketing site or statically hosted e-commerce store?

Long-term value

The tech stack you chose can be a much larger commitment than it first seems to be. I would be very surprised if react was no longer used a couple years down the road, but what about the 15 libraries you pull in to that react app?

If a project is built on an everything but the kitchen sink™ app platform like Nuxt.js, Next.js, or SvelteKit can really let you hit the ground running, but will they still be supported a few years down the road? Will developers still be excited to work with them, or will it be the butt of too many developers' jokes like WordPress?

Keep it simple, stupid

Back to the entire reason we're here, sticking with "boring" tech may not be such a bad idea. The JSON spec is around 20 years old, git is 16 years old, and markdown is 17 years old. Though the HTML/CSS/JS standards are a constant work in progress they go back as far as 1993 (ok, 1995 for JavaScript).

Even better, these are all open standards that may evolve but will never go away.

What about this site though?

This very site is built with a shiny new SSG, Astro, isn't that a bit hypocritical? I don't think so, but hear me out!

Take a look at the sourcecode for this project and you'll see that the real meat of the site is based entirely on the standards above. SCSS is used for styling, but honestly the only reason we even used that was because CSS nesting isn't supported yet.

Most of the site's pages are authored in markdown and various bits of data are stored in JSON.

Page templates and components are in .astro files that really just consists of JavaScript in the form of frontmatter, styles are either in global .css files or component-level <style> blocks, and markup is mostly HTML with a bit of JSX-like javascript inline for conditionals and for-each loops.

It would take a matter of a few hours to migrate the entire site to a different SSG, or even an entirely different platform like Next.js.

So yes, we're technically using a few new build tools to wire templates together, but at the end of the day it's easy to use Astro and forget that you aren't using the basic, web-native HTML/CSS/JS stack.

Innovation is amazing, just don't get stuck

It's a very common mistake, especially for developers newer to web development, to get stuck on the hamster wheel chasing the latest toy. Don't avoid innovation, just be strategic and selective in where you invest your time and efforts!

There's always a new tool to try or pattern to learn, but at the end of the day it's much more satisfying to ship a product rather than trying out a new tool with sample projects that never sees the light of day!

I feel like I bashed on react here - don't get me wrong, react is an excellent and extremely powerful tool. React still has a huge lead in usage compared to the other frontend frameworks and, especially if you're in the job market, it's much easier to find job listing that require react experience than listings that don't mention react at all. But if you find yourself running in circles, getting frustrated with a build pipeline that's fighting you or magic hooks that you don't understand, take a step back and learn the basic (boring) 20 year old tools. Ship fast, don't break the build!

Keeping it simple with Astro

Mon, 14 Jun 2021 17:41:41 GMT

Frontend frameworks have taken over much of the web, but the question remains - do we really need all that JavaScript in the browser?

Keeping it simple

Client-side rendering can be an extremely powerful tool, and in some cases can solve problems that are nearly impossible to solve strictly with server rendering. A vast majority of the web is pretty simple though - mostly static content with a bit of interactivity sprinkled in.

The Navillus is a perfect example. It has a mobile menu taking advantage of Svelte's excellent built-in transition, and we recently added in a dark mode toggle. That's it for interactions on our site though, the rest is entirely static.

Here's a screenshot of devtools with our homepage loaded. A grand total of ~78KB transferred, including all the HTML, CSS, JavaScript, images, and fonts. Don't get me wrong, there's more to web design and development than just minimizing bundle size, but performance matters and small wins can add up quickly.

What's the trick?

When designing our site we had performance in mind from the beginning. You may notice that we purposely don't have any images on our homepage, and the only icons used are actually taking advantage of the SVG sprites technique to load all the icons in a single file.

Just finished rebuilding https://t.co/UcT54hdIY5 with @astrodotbuild

Progressively enhanced with @sveltejs and clocking in at a whopping 12.5KB of total JS. Really digging how easy its becoming to build tiny sites these days
— Navillus (@navillus_dev) June 11, 2021

As of last week, though, we officially swapped our site over to Astro. Why go through all that effort to trust our site with an early beta of a totally new project? Well, why not!

We didn't actually plan to go live with an Astro version of our site, expecting to kick the tires and keep an eye on the project. The build was surprisingly straightforward though, and the results don't lie.

Shipping just enough JavaScript

The main bit of JavaScript on our site is the mobile menu - we hadn't actually added the dark theme toggle yet when first starting the Astro project. We already posted about how we built our progressively enhanced menu, but the key is that we wanted to use Svelte to easily work with or without JavaScript. If the JS loads, we pull in Svelte's slide transition to nicely animate the menu in and out.

With Astro, we can build 98% of our site with little more than HTML templates and markdown while adding in a tiny amount of JavaScript to improve the experience. No client side routing, no frontend framework dynamically rendering the page, no hydration issues or content flickers.

Note: Astro isn't opinionated about what component library you prefer. They shipped with Vue, React, Svelte, and Preact out of the box and more are being added as you read this.

Speaking of hydration

One of the most interesting ideas about Astro is partial hydration. By default a component's JavaScript won't even load in the browser, it will only be used on the server. That's not always enough though, and Astro gives you a few options for how to load it on the client.

<Component:load />
<Component:idle />
<Component:visible />

Say it's a component that really needs to be available as soon as possible, just tack :load onto the component and it will be loaded on the client when the page loads.

Maybe the component is common but not needed immediately, adding :idle instead will tell Astro to wait for the browser to initially load the page and go idle before pulling down the component, boosting performance on initial load.

They have you covered for components further down the page too, :visible will take advantage of the IntersectionObserver API to only load the component if a user scrolls down to it. This might be useful for a contact form at the bottom of a marketing page where you need custom JS validation logic but don't want to risk any performance hiccups when every conversion matters.

Coming soon to an Astro near you

<Component:media ="(min-width: 40em)"></Component:media>

This is only a proposed feature still open on Github and the syntax may very likely change, but the concept here will be a huge win.

Take our mobile menu again. We're using :idle to allow our whole page to load before enhancing the menu, but on desktop that menu is never even used. With :media or similar we could make sure that the menu's JS is only loaded on mobile viewports, why even both loading it?

Wrapping up

Keep your eye on Astro, follow their Github repo (or star it if you prefer), and check out the community Discord linked on their homepage to give feedback and share your ideas for the future of Astro!

The power of Svelte actions

Thu, 03 Jun 2021 17:48:11 GMT

Svelte does an excellent job of blurring the lines between frontend frameworks and plain old HTML/JS. Leaning on Svelte's reactivity model, property binding, and event directives will get you 99% of the way to a finished app, but every once in a while you just really need to work directly with the HTMLElement.

This can be done in a one-off way with the bind:this approach to getting a local reference to a DOM element, but there's a better way. The use: directive allows for reusable logic to be pulled out of the component itself.

Let's take a look at a really common use for this - listening for clicks/taps outside an area of the UI. I used this recently for Kamfly's modals, instead of adding a one-off click listener in the Modal component I created a clickOutside action that can be reused elsewhere. This can also help make testing a whole lot easier, testing the async nature of a full blown Modal component can be tricky, testing just the action itself is much less complicated!

tl;dr; Check out the final example in this Live REPL demo.

Svelte actions

Svelte's official tutorial has an excellent walk through of what actions are, but basically you can think of actions as lifecycle hooks for DOM elements themselves. An action works much like onMount or onDestroy, but actions are tied to DOM elements themselves rather than entire Svelte components.

Why bother with actions?

It's easier to reach for bind:this when the component you're working on needs to interact with a DOM element. I won't jump into the DRY design principles debate, instead just look at the testing challenges.

Many projects end up needing a modal at some point, and they're almost always ignored in automated testing. When the component itself is responsible for hiding/showing the modal, managing a stack of multiple open modals, etc. the logic gets tricky fast.

Testing asynchronous behavior like animations or modals hiding/showing based on user input can be a chore. What if you could move some of that logic out to a reusable function?

Anatomy of an action

action = (node: HTMLElement, parameters: any) => {
	update?: (parameters: any) => void,
	destroy?: () => void
}

That's really all there is to it! An action in Svelte takes in the DOM element and (optionally) user defined parameters. The action function can run initialization logic on the element before returning update and destroy handlers (both optional).

`use:` clickOutside

Let's look at a really common UX pattern - a modal is open on screen and you want it to hide when the user clicks/taps outside the modal (often on some kind of grayed out background).

This isn't a big deal to do in the Modal component itself - add an extra DOM element for the grayed out background and add a click handler to it. But what if you want a similar interaction for your mobile menu? That component is almost certainly different, if you copy the code over now you have duplicated JS in your site and you need complicated test coverage testing the close functionality for both components.

The clickOutside action

export default (node, _options = {}) => {
  const options = { onClickOutside: () => {}, ..._options }

  function detect({ target }) {
    if (!node.contains(target)) {
      options.onClickOutside()
    }
  }
  document.addEventListener('click', detect, { passive: true, capture: true })

  return {
    destroy() {
      document.removeEventListener('click', detect)
    },
  }
}

There's a few things going on here, let's break that down.

First, the action is taking in optional parameters (_options). The action expects options.onClickOutside to be a callback function, if one wasn't provided it's defaulted to a noop function.

The detect function does the real work of checking to see if a click event on the page was inside the original DOM element. The event listener is using passive to avoid scrolling performance issues, and capture to make sure that all clicks bubble up to the listener.

Finally, the action returns a destroy callback that will clean up the event listener when the element is being removed from the DOM.

Allow components to whitelist elements to ignore

export default (node, _options = {}) => {
  const options = { include: [], onClickOutside: () => {}, ..._options }

  function detect({ target }) {
    if (
      !node.contains(target) ||
      options.include.some((i) => target.isSameNode(i))
    ) {
      options.onClickOutside()
    }
  }

  /** Same as above */
}

A little extra functionality here allows components to pass in other DOM elements that should be considered as "inside" the action (rather than "outside").

How to test it

UI testing will be a topic for another day, but you can see how much easier this will be to test. Instead of having to write tests that can reliably wait for a Modal component to animate into view before testing the click away scenario, tests could work more closely to the REPL demo (below). DOM elements for a test wouldn't need to animate at all, they just need to accept a click event so the test can count how many times the onClickOutside handler was called!

Live REPL demo

That's all, folks! Check out the Live REPL demo for a working example.

Introducing chisel.css

Wed, 02 Jun 2021 17:37:30 GMT

Have you ever really tried rendering some HTML without any CSS? It's a hot mess! Modern browsers are operating systems unto themselves these days - I don't envy anyone who has to sift through the complexity to add even a basic feature to a browser these days. But damn do I wish they would add spend a couple days to ship some decent looking default styles for HTML5 elements!

Enter chisel.css

Yes, it's another CSS framework. No, we don't want to see it being used for the next 10 years. If we have our way, chisel.css will make clear just how easy it could be to have modern designs with out-of-the-box HTML elements.

We've included the most common browser resets, similar to normalize.css or sanitize.css, along with modern styling based on CSS custom properties.

Why the name?

Ask any woodworker that's dabbled in hand tools and fine joinery what tool they'd keep if they could have only one, it'd be the chisel. Most people never even think about it, but when it comes down to it almost every tool used on wood is basically just a chisel anyway.

Take a close look at a saw (be careful!). See all those tiny chisels we call saw teeth? Now look at a drill bit - yep, it's pretty much a chisel blade twisted around a stick.

We realized we kept starting with the same basic CSS resets and element styles for virtually every Navillus project, after pasting it a half dozen times we figured it was time to standardize. The project quickly took aim at building one CSS framework that can be a complete reset for both browser vendor issues and horribly styled HTML elements.

Change a few variables here and there, but the goal is for chisel to help every site look good without immediately, ready for your throw in your custom CSS (or wrap a chisel around a stick if you still can't find that damn 3/8" drill bit).

How to use it

Check out the docs for full details, but it really is as simple as

npm i -s chisel.css

or from a CDN

<link href="https://unpkg.com/chisel.css" rel="stylesheet" />

Minified and compressed the entire bundle is ~3.2KB, with full support for dark mode and basic app theming.

Eating our own dog food

We recently updated navillus.dev to use chisel as a basis for styling, you can see the complete pull request on GitHub. I'm always a fan of seeing a pull request full of red, gotta love code cleanup!

Granted we're a bit biased here, most of the common CSS we copy into every Navillus sites made it's way into chisel. The power of CSS variables lets you make some pretty drastic changes though, with very little effort.

Want a different primary color? No problem, change --chisel-primary and you're all set. Prefer a different type scale? That's simple too, check the docs for our variables like --chisel-h1 or --chisel-p.

Dark theme

Dark theme support is one that gave us more headaches than expected. We wanted chisel to support both browser's native prefers-color-scheme as well as a fallback option. We landed on a custom HTML data property, data-chisel-theme. In the future we plan to ship predefined color palettes that will also take advantage of the HTML dataset property.

So what went wrong? If you take a look at v0.4.0, we added custom CSS properties for component-level styling similar to --chisel-button-bg. This worked great for making it simple to custom style buttons, say if you want a button variant like .button-hollow. Each component property defaulted to one of the main color palette styles, a la --chisel-button-bg: var(--chisel-primary).

There in lies the problem.

At least on some browsers, CSS variable scope isn't always what you'd expect.

[data-chisel-theme='dark'] {
  ---chisel-primary: #002244;
}

You'd think this would also update any CSS properties referencing this variable. Nope! If --chisel-button-bg is only defined on the :root scope it isn't necessarily going to be updated to the new color code. This seems like a bug to me, and I have it on my list to dig through the spec to see if that's actually expected behavior, but in the meantime we will avoid it.

Yes, we could use component variables if we redefined --chisel-button-bg in the dark theme selector as well. That'd lead to way to much bloat and extra CSS though, it wasn't worth the extra KB.

WIP

Chisel is still very much a work in progress. Head over to the GitHub repo to file bugs, request new features, and star the project to follow the latest updates!

Including json+ld structured data in Svelte

Mon, 17 May 2021 17:40:47 GMT

Ever wonder how Google search results include shopping results for products, or location results for local businesses? Their search bot is constantly being improved to better find that kind of content on your site, but ultimately if you care at all about SEO on your site it's important to include structured data on the page.

Structured data allows you to give search bots scrubbing your page a helping hand by adding metadata that describes your business, product, or even your blog posts.

JSON+LD is a lightweight specification for including structured data as a simple JSON object, something we're all comfortable with in the frontend world.

tl;dr; Check out this Svelte REPL example for a working example in JS. Keep reading to get full TypeScript validation for your Schema objects!

JSON+LD by example

Let's take a look at a basic example first. I pulled this straight from the JSON-LD Playground - it's an excellent reference for quickly messing around with the different schema and data types.

{
  "@context": "http://schema.org/",
  "@type": "Person",
  "name": "Jane Doe",
  "jobTitle": "Professor",
  "telephone": "(425) 123-4567",
  "url": "http://www.janedoe.com"
}

Nothing crazy going on there (yet). When a search bot comes by to index a page with this JSON, it's guaranteed to find Professor Jane Doe's contact information. This contact information is probably included elsewhere on the page, say in a sidebar or page footer, but chances are the way the HTML is setup could prevent the search from connecting the link from a phone number to the person's name.

How do you include it on a page?

This is where JSON+LD really stands out compared to other structured data formats that require special HTML attributes.

<script type="application/ld+json">
	{
		"@context": "http://schema.org/",
		"@type": "Person",
		"name": "Jane Doe",
		"jobTitle": "Professor",
		"telephone": "(425) 123-4567",
		"url": "http://www.janedoe.com"
	}
</script>

Yep, that's really all there is to it. Wrap the JSON object in a script tag, mark it as a type of application/ld+json and you're all set. There's way more to the different kinds of schemas you may want to include - check out the JSON-LD docs for a much better walk through of all the details than I would ever fit into a single blog post.

JSON+LD in Svelte

The beauty of Svelte is how closely it follows standard web technologies. Components are written in a single file with a script tag for all the JavaScript, style tag for the component's CSS, and one or more HTML elements for the actual DOM elements.

While that makes authoring Svelte components a nearly frictionless experience for web developers, it can throw a wrench in the JSON+LD department. Tooling built for Svelte like the VS Code plugin, and even the Svelte compiler itself, can cause headaches if you try to write an application/ld+json script in your components.

This may very well get cleaned up in the future, but for now you'll likely run into warnings and errors related to having more than one script tag in a component. A Google search will lead you down a rabbit hole of different combinations of Svelte's @html expressions and string literals to get it to compile.

There's a much better way to do this though, and even better it can be combined with TypeScript to add extra type validations for your JSON schema objects.

Serialize your JSON+LD to a script

The first part of the magic trick is getting around issues related to parsing extra script tags in your Svelte component. This is where many will reach for some combination of {$html} and string literals.

I prefer to move this out of the Svelte component all together. With the logic in a plain old JavaScript file it can be unit tested and will never run into issues with tools trying to parse .svelte files.

export function serializeSchema(thing) {
  return `<script type="application/ld+json">${JSON.stringify(thing)}</script>`
}

There's not much magic going on here, the function just takes in a JavaScript object and spits out the ld+json script tag for it.

Type checking with TypeScript

We'll lean on the schema-dts package for full Schema.org type definitions.

import type { Thing, WithContext } from 'schema-dts'

export type Schema = Thing | WithContext<Thing>

export function serializeSchema(thing: Schema) {
  return `<script type="application/ld+json">${JSON.stringify(
    thing,
    null,
    2
  )}</script>`
}

schema-dts defines types for all of the different schema objects, see below for a more detailed example with an Organization object. This is a huge win, it's easy to accidentally structure the JSON wrong or have a typo in one of the property names. Setting it up to use TypeScript definitions we can make sure that our JSON objects are validated at build.

Defining our Schema.org objects

Here's the Organization object used by this very site.

import site from `$data/site.json`;

export const organizationSchema: WithContext<Organization> = {
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": `${site.url}#organization`,
  url: site.url,
  name: site.company.name,
  description: site.description,
  sameAs: [`https://twitter.com/${site.social.twitter}`],
  logo: `${site.url}/favicon.svg`,
};

Data specific to our site is pulled in from a local JSON file. This could be data exposed through a Git-based CMS like Forestry or pulled down from a headless CMS like Sanity. The important thing here is that our Organization object is defined in TypeScript, verified at build-time, and can be unit tested if you want to make sure the site.json data is hooked up properly.

What is WithContext doing? That's a clever setup from schema-dts, the top-level JSON+LD object should have a @context property. You can nest objects though, and they even have support for using an object graph format for multiple objects. Any nested objects, or every object in the graph, doesn't need @context. WithContext is a TypeScript wrapper for another type, in the example above I could have removed @context from the object and it would be a valid Organization type.

Importing into Svelte

Finally, let's add the JSON+LD into the DOM. Most of our projects end up with a LDTag.svelte component similar to

<script lang="ts">
  import { serializeSchema } from '$utils/json-ld'
  import type { Schema } from '$utils/json-ld'

  export let schema: Schema
</script>

<svelte:head>
  {@html serializeSchema(schema)}
</svelte:head>

Multiple Svelte components on a page can inject their own application/ld+json script into the document's head. This works great with SvelteKit too, a layout or route component could inject page-level schemas.

Working REPL example

Take a look at our Svelte REPL example to see a full working JavaScript example.

Web Accessibility: Hidden links make all the difference

Mon, 10 May 2021 17:26:48 GMT

Accessibility is a bit of a polarizing topic when it comes to web technologies, but it doesn't have to be. Accessibility isn't an all or nothing game and more often then not there are small, simple changes that can make a huge difference in both keyboard and screen reader support. Let's take a look at an accessibility easter egg that may not be new but is still sorely lacking on many of even the most popular sites.

"Skip navigation" links

Every web developer should try using a screen reader at some point. If you've ever tried tabbing through a website you'll get the general idea, the screen reader (or your keyboard's focus) move one by one through every element on the page. We can modify that behavior with aria tags, tabindex, and certain CSS properties, but one not so obvious solution is to actually hide links on the page that only show up once they are given focus by the keyboard or screen reader.

Curious what that looks like? Go over to GitHub's main site and logout if you are currently signed in (or use a private tab). Click in the address bar to put focus just above the page's content, then start tabbing down. You'll likely tab through some of the browser's chrome first, but as soon as focus gets to the site's content you'll see a big blue "Skip to content" button appear in the top left corner.

What's it for?

Even on a small site the navigation header likely has 6 to 10 interactive elements (brand logos, page links, login/logout buttons). Visually that isn't a big deal, navigation headers are almost always designed to pack all that content into a relatively small portion of the screen. Functionally, though, that's 6 or 10 different elements the user would need to walk through before even hearing the main title in the hero section. That's a huge barrier to entry!

Back to the GitHub example, when "Skip to content" has focus and is visible on screen you can still tab past it and walk through every link in their navigation. The real trick is what happens if you hit Enter on that hidden link - the window's focus skips past the navigation header and puts focus into the hero section. In the case of GitHub, after you click "Skip to content" the next Tab will focus on the email signup form rather than the logo in their navigation header.

How it works

The trick here requires two elements on the page. The very first focusable element on the page will be a new <a> that is the hidden link itself. We want this to work whether JavaScript is enabled or not, so let's make sure to progressively enhance this feature.

Time to code it

Actually implementing this hidden button can be a bit confusing at first, Let's take it one step at a time.

Start with the HTML

<body>
  <a href="#start-of-content" class="sr-only sr-only-focusable">
    Skip to content
  </a>

  <header>
    <!-- Your header content goes here -->
  </header>

  <div id="start-of-content" class="sr-only"></div>

  <section>
    <!-- Your awesome hero section -->
  </section>
</body>

Nothing to crazy here. You're exact implementation might look different, but the key is adding a new anchor tag at the top of the page and a new div immediately after the header.

The <a> doesn't necessarily have to be the first child of the page's body, but it's important that it is the first focusable element in the DOM.

Add a little CSS

.sr-only {
  border: 0;
  padding: 0;
  margin: 0;
  position: absolute !important;
  height: 1px;
  width: 1px;
  overflow: hidden;
  /* IE6, IE7 - a 0 height clip, off to the bottom right of the visible 1px box */
  clip: rect(1px 1px 1px 1px);
  /* maybe deprecated but we need to support legacy browsers */
  clip: rect(1px, 1px, 1px, 1px);
  /* modern browsers, clip-path works inwards from each corner */
  clip-path: inset(50%);
  /* added line to stop words getting smushed together (as they go onto seperate lines and some screen readers do not understand line feeds as a space */
  white-space: nowrap;
}

.sr-only.sr-only-focusable:focus {
  width: auto;
  height: auto;
  padding: 0;
  margin: 0;
  overflow: visible;
  clip: auto;
  clip-path: initial;
  white-space: normal;
}

Update: .sr-only class updated based on some excellent feedback from Inclusivity Hub on dev.to

You have likely seen sr-only helper classes elsewhere, most CSS frameworks like Bootstrap and Tailwind include them out of the box.

If you haven't seen sr-only-focusable before, that's just an extra helper class that allows the element to be visible only when it has :focus.

Enhance it with JavaScript

Update: Looking for a no-JS solution? Skip the JS logic and point your "Skip to Content" link straight to your <main id="main"> block!

This feature already works as-is, no JavaScript at all. There is a catch though, clicking anchor tags with with href="#start-of-content" will update the URL in the address bar. That's not always ideal and could even break your page if you are using hash routing.

function onSkipToContent(event) {
  // Stop the event's default behavior
  // In this case, don't let it actually change the page's URL
  event.preventDefault()

  // Find the hidden target div
  const target = document.getElementById('start-of-content')

  if (!target) {
    return
  }

  // Find the next element in the DOM
  const content = target.nextElementSibling

  if (content instanceof HTMLElement) {
    // Make sure the content div can't be tabbed to again, the give it focus
    content.setAttribute('tabindex', '-1')
    content.focus()
  }
}

// Find the hidden "Skip to content" link and hook up tje click event
const link = document.querySelector('a[href="#start-of-content"]')
if (link) {
  link.addEventListener('click', onSkipToContent())
}

This will look a little different depending on how your frontend JS is setup and whether you are using a framework like React or Svelte. The concept should be easy to transfer though, you just want to take over the <a> element's click event and manually send the window's focus down the page.

Why bother with nextElementSibling? Well it may not be necessary, but we added that div as a bookmark and don't want it to actually take focus in the window. Instead, we want to find that bookmark and give focus to whatever comes next in the DOM.

That's all, folks!

Adding two elements and a bit of CSS gives us a fully functional "Skip to content" link for keyboard and screen reader users. Another dozen or so lines of JavaScript and we progressively enhanced the link to work as expected with any JavaScript framework or routing scheme the site might be using.

Stay tuned for more accessibility posts in the future!

Progressively enhancing Svelte with JavaScript

Sat, 08 May 2021 17:49:14 GMT

We've all heard about "mobile first" designs, but what about JavaScript last? It'll need a catchier name to really stick, but many of us ignore how important it is that basic site functionality works even if JavaScript is disabled or has failed. Browsing the web with JavaScript disabled can be a real pain but it happens more then you'd expect.

My trusty Kobo Aura H20 has a browser in it, but JavaScript is disabled and frankly there's no way the hardware could handle modern JS-heavy sites. Ride a subway in New York and you'll quickly realize how spotty your cell signal can be, and how broken a site will be if the markup loaded but the 1.3MB of JavaScript didn't finish before your connection dropped out.

tl;dr; Click here for a working example in the Svelte REPL. Or try out the menu on this site - disable your Javascript and shrink the window down to get the mobile view, the menu still works!

Don't break your mobile menu

The hamburger menu is still king of mobile navigation designs, for better or worse. With a hidden menu, the last thing you want is for a visitor to not even be able to move around your site because they chose to disable JS. Even worse, if your site hits an unhandled exception that might break your JavaScript entirely.

The menu is almost certainly going to be interacted with, making design and animations a high priority there. The key is to build your menu so that it works with HTML and CSS only. Your JavaScript should enhance the menu with things like notification badges or animations that can't be done well in CSS.

Learn by example

We'll take a look at how this can be done in Svelte, but the same concepts can be applied to any framework.

Go ahead and try a working example right here, this site's menu works similarly. Once scripts are loaded the menu takes advantage of Svelte's built in slide transition. Disable JS in your browser though and our menu still works - it doesn't animate in but visitors can open and navigate around no problem.

A basic header in Svelte

<script>
  import { slide } from 'svelte/transition'

  let menuOpen = false
</script>

<header>
  <div class="header__top">
    <h1>Navillus</h1>
    <button on:click={() => menuOpen = !menuOpen}>
      &#9776;
    </button>
  </div>

  {#if menuOpen}
  <nav transition:slide>
    <!-- NAV LINKS GO HERE -->
  </nav>
</header>

Nothing too crazy going on here yet. If you aren't familiar with Svelte, transition:slide adds an entry and exit animation to the <nav> element.

Hide/show a menu without JS

HTML checkboxes have a pseudo selector for :checked, let's take advantage of that to show/hide our menu from CSS.

<header>
  <div class="header__top">
    <h1>Navillus</h1>
    <label for="toggle">&#9776;</label>
  </div>

  <input id="toggle" type="checkbox" class="sr-only"/>

  <nav>
    <!-- NAV LINKS GO HERE -->
  </nav>
</header>

<style>
  #toggle ~ nav {
    display: none;
  }

  #toggle:checked ~ nav {
    display: block;
  }
</style>

What's going on there exactly? Instead of a <button> there's a <label> tied to the checkbox. In CSS, the nav element is hidden by default and only shown when the checkbox is :checked.

The best of both worlds

<script>
  import { onMount } from 'svelte'
  import { slide } from 'svelte/transition'

  let menuOpen = true
  let mounted = false

  onMount(() => {
    menuOpen = false
    mounted = true
  })
</script>

<header>
  <div class="header__top">
    <h1>Navillus</h1>
    <label for="toggle">&#9776;</label>
  </div>

  <input id="toggle" type="checkbox" class="sr-only" class:js={mounted} bind:checked={menuOpen} />

  {#if menuOpen}
  <nav>
    <!-- NAV LINKS GO HERE -->
  </nav>
  {/if}
</header>

<style>
  #toggle:not(.js) ~ nav {
    display: none;
  }

  #toggle:not(.js):checked ~ nav {
      display: block;
  }
</style>

Wait, what?

Let's break that one down step by step.

First, menuOpen is set to true initially and reset to false in Svelte's onMount lifecycle hook. If onMount is called we have JavaScript support and can enhance the menu, until then we stick to the HTML/CSS approach.

We also added in a second boolean flag for mounted, and with class:js={mounted} we're telling Svelte to add the js class to our checkbox once the component's scripts have mounted.

Finally, the CSS has been updated to change the menu's display only as long as the checkbox doesn't have the js class. That's the real magic, let CSS handle the show/hide functionality until JavaScript has mounted and Svelte's slide transition is ready to animate the menu.

Oops! It's very easy to inadvertently create accessibility bugs. When manually testing I realized the hidden checkbox wasn't binding to our menuOpen state in svelte. The code block above was updated June 2, 2021 to include bind:checked={menuOpen} to make sure keyboard users can toggle the menu after Svelte hydrates.

Bonus points

Svelte's use:action feature can be used to make this a bit more reusable. Actions deserve their own full blog post, but in short an action in Svelte is function you can add in markup that will get called with the HTML node once it is created.

Check out the REPL example for a working example a custom enhance action replacing the mounted and onMount() logic above.