DEV Community: Callum

It's time we stop over-engineering website frontends

Callum — Fri, 21 Aug 2026 17:40:21 +0000

I thought I would share a rant regarding JavaScript usage on modern websites.

To clarify, this discussion focuses primarily on content sites rather than complex web applications requiring heavy client side interactivity.

In recent years, frontend developers frequently chased shiny new tools without pausing to evaluate necessity. Building websites now routinely involves an endless list of dependencies, a node_modules directory large enough to form a black hole, and countless supply chain vulnerabilities. Standard websites frequently consume over 500 megabytes of RAM in a single browser tab. We have thoroughly over-engineered the web.

Why did we start using JavaScript and React to generate simple HTML in the first place? Perhaps because it felt convenient at the time.

Frontend Libraries

Frontend libraries and metaframeworks empower developers to build anything from a static marketing page to a massive enterprise application. However, we often fell into the trap of applying heavy over-engineering to simple web projects. Frontend libraries are crucial for large applications, but completely unnecessary for smaller websites.

I used to love NextJS, but much of its overhead felt redundant for standard publishing needs. It simplified building fast experiences, server-generating JavaScript, and leveraging features like page link prefetching on hover. Yet we have successfully generated HTML on the server for over thirty years. Did we really need to reinvent that foundation?

What I am Building

In recent projects, I took a step back to earlier days of web development before everything became overly complicated. I discovered Datastar a while ago, and it fundamentally changed my workflow. Think of it as using the server to generate UI elements, utilizing server-sent events, client-side signals, and lightweight interactivity. I now build websites containing perhaps 10-20kb of JavaScript in total while requiring no compiler step. The performance is great, the API remains simple, and dependency tracking risks are gone since there are no external packages to manage.

My transition toward lightweight websites began when AstroJS first came on the scene. The philosophy of shipping zero JavaScript by default for static HTML was refreshing to see again. Fast forward a couple of years, and I needed to build an interactive website with server-driven content and chose Astro. To solve this, I built a Datastar plugin for AstroJS, which proved really useful and I published it on NPM.

Several examples are live om Datastar Astro project: https://astro-datastar.wrux-6a1.workers.dev/examples/. Feel free to inspect the network tab while testing them and to get an idea of how Datastar works.

I am currently build a project that uses a Cloudflare worker running Rust and WebAssembly to generate pages. It operates as a streamlined backend setup that reads from a CMS, handles caching, and outputs pages very efficiently. Datastar has a native Rust integration that performs exceptionally fast inside workers compiling to WebAssembly. This architectural shift allowed me to drop Vercel, which frequently hit resource limits, and migrate to Cloudflare for free up to 100,000 monthly page views while getting much better TTFB on webpages.

Consequently, I can now deliver an interactive website that generates pages in under 10ms while sending only 16 kilobytes of JavaScript down to the client. I also dropped Tailwind entirely and built a custom design system, though that is a topic for another rant. With Brotli compression enabled, the total asset weight sent to the client is nearly negligible.

Let's Use More Browser APIs

The web landscape evolved significantly, and modern browsers improve continuously. It is time to return to building simple websites by relying more heavily on native web standards.

Implementing lazy-loading images once required custom JavaScript solutions, but today it is handled natively via a single loading="lazy" attribute. Creating accessible dialog elements used to involve complex workarounds, yet we now possess the native <dialog> element and a straightforward API.

NextJS and Astro gained popularity partly by offering useful utility tooling, such as pre-loading subsequent pages to create an instant perceived performance boost on click. This capability has already arrived in browsers as a native standard via the Speculation Rules API.

Below is an example code snippet implementing the Speculation Rules API to instruct the browser which links to prefetch on hover. This is supported in Chromium based browsers, highlighting how native browser implementations are replacing features once locked inside proprietary metaframeworks.

<script type="speculationrules">
  {
    "prefetch": [
      {
        "where": {
          "and": [
            { "href_matches": "/*" },
            { "not": { "href_matches": "/api/*" } }
          ]
        },
        "eagerness": "moderate"
      }
    ]
  }
</script>

Minimising Analytics Overhead

Every developer knows the frustration of putting immense effort into building a lean content website with pristine performance metrics, only for marketing teams to then request 500kb of tracking scripts.

Managing this tension is always challenging. I have experimented with Plausible and similar privacy-focused alternatives, though marketing managers sometimes find them restricted in certain reporting dimensions.

Many stakeholders still expect traditional platforms like Google Analytics by default. If anyone has practical insights on how to maintain robust tracking without bloating client-side JavaScript payloads, I would love to hear your approach.

Creating Favicons for Light and Dark Mode UIs

Callum — Wed, 07 Jul 2021 06:29:24 +0000

Dark mode UIs are becoming increasingly popular. Often the legibility of a favicon is not great in light or dark mode, so a dynamic solution is needed to display correctly in both modes.

Luckily, SVG favicons provide the functionality we need. If you are not using SVG favicons on your site yet, then go and change them now. You can drop those 20+ PNG icons in favour of a single SVG.

So here's the thing, we can use CSS in SVGs, meaning you can also use the prefers-color-scheme media query to adjust the SVG.

Here's an example icon with some CSS to set the default path fill colour to black. The media query then changes the fill colour to white if the user has dark mode enabled.

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 429.056 429.056">
  <style>
    path { fill: #000; }

    @media (prefers-color-scheme: dark) {
      path { fill: #fff; }
    }
  </style>
  <path d="M413.696 182.272h-21.504v-68.096c-.512-8.192-7.168-14.848-15.36-15.36H229.888V4.608h-30.72v94.208H52.224c-8.192.512-14.848 7.168-15.36 15.36v68.096H15.36c-8.704 0-15.36 6.656-15.36 15.36v101.376c0 8.704 6.656 15.36 15.36 15.36h21.504v94.72c.512 8.192 7.168 14.848 15.36 15.36h324.608c8.192-.512 14.848-7.168 15.36-15.36v-94.72h21.504c8.704 0 15.36-6.656 15.36-15.36V197.632c0-8.704-6.656-15.36-15.36-15.36zm-313.344 36.352c0-24.576 19.968-44.544 44.544-44.544s44.544 19.968 44.544 44.544-19.968 44.544-44.544 44.544-44.544-19.968-44.544-44.544zm181.76 133.632H146.944v-30.72h135.168v30.72zm46.592-133.632c0 24.576-19.968 44.544-44.544 44.544-25.088 0-45.056-19.968-45.568-44.544 0-25.088 19.968-45.056 44.544-45.568 24.576-.512 45.056 19.968 45.568 44.544v1.024z" />
</svg>

You just need to link your new icon.svg file in the document head:

<link rel="icon" href="/assets/icon.svg" />

Here's the outcome. You might need to reload the page when switching between light/dark mode UI.

Emoji Favicons Are a Thing Now 🤯🚀

Callum — Tue, 06 Jul 2021 11:49:43 +0000

Emojis are everywhere nowadays. I created perpetual.pizza many years ago now and tend to update it every so often. I never liked the old pizza favicon and decided to try replacing it with an emoji.

SVG favicons are now widely supported and I have been experimenting with the possibilities recently (light/dark mode favicons are awesome). I ended up finding an elegant solution for creating an emoji favicon.

It turns out that you can use emojis inside of SVG text and
use relative units to position and size the emoji correctly. This method also displays the emoji in the format the user is familiar with on their operating system.

Here's the markup for my icon:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100">
  <text y="0.9em" font-size="90">🍕</text>
</svg>

I added it into the document head like a regular SVG icon:

<link rel="icon" href="/assets/icon.svg" />

Here's the outcome: