Static Sites Without the Bloat: Quesby’s Approach to Modern Web Dev

Published: 6 days ago (December 12, 2025 at 09:00 AM EST)

4 min read

Source: Dev.to

The problem with modern tooling

Most developers start a simple website, open their tooling of choice, and suddenly they’re dealing with bundlers, configs, dependencies, and features that aren’t relevant to the project.
Nothing is wrong with those tools—they’re built for ambitious apps—but when you’re only generating HTML pages the ecosystem can become unnecessary overhead.

Quesby’s philosophy

Quesby takes a different angle: use only what serves a static site well, keep the workflow predictable, and avoid carrying tools that won’t be used.

Core ideas

Built on Eleventy – its philosophy fits static sites: generate HTML from templates, nothing more unless asked.
No runtime attached – no front‑end framework assumptions.
No unnecessary tools – analytics, external fonts, and client‑side libraries are omitted by default.
Don’t ship or maintain what you don’t use – the goal isn’t aesthetic minimalism but practical reduction of bloat.
Transparent layers – content, templates, SEO, and assets live in places you can inspect and customize.

SEO made simple

Front matter becomes a single source for meta tags, OpenGraph, Twitter Cards, JSON‑LD, canonical URLs, and language alternates. Instead of juggling separate plugins, Quesby consolidates the logic into a predictable module.

---
title: "Static Sites Without the Bloat"
description: "How Quesby trims modern tooling down to what static sites actually need."
image: "/assets/images/posts/static-sites-without-the-bloat/cover.jpg"
---

Quesby turns that into consistent markup:

Static Sites Without the Bloat | Example Site

Image handling

Eleventy Image is powerful but noisy. Quesby wraps it with sensible defaults that handle WebP/AVIF output, fallbacks, modern markup, lazy‑loading, and deterministic filenames. You get the good parts without the friction.

A typical image in a template looks like this (Nunjucks syntax):

{% image "src/assets/images/posts/static-sites/cover.jpg", "Cover image for the article", "article-cover" %}

Quesby automatically adds responsive sources, modern formats, and attributes such as loading="lazy".

Content workflow

Quesby provides structured content directories, automatic slugs, ULID‑based IDs, predefined collections, and simple front‑matter rules. Adding a new article is as straightforward as creating a file:

src/content/posts/01HXYZABCD1234567890--my-first-post/index.md
---
id: 01HXYZABCD1234567890
title: "My First Post"
slug: "my-first-post"
description: "Short summary used for meta tags and previews."
date: "2025-12-09T10:00:00.000Z"
image: "/assets/images/posts/my-first-post/cover.jpg"
category: "guide"
tags: ["static-site", "eleventy", "seo"]
---

Your Markdown content starts after the front matter.
If you prefer a shortcut, launch the helper:

npx quesby new post "title-of-the-article"

Directory structure

The layout is intentionally boring and easy to understand:

src/
├─ _data/
│  └─ site.json
├─ _includes/
│  ├─ layouts/
│  └─ partials/
├─ assets/
│  ├─ css/
│  ├─ js/
│  └─ images/
├─ config/
│  ├─ collections.js
│  └─ taxonomies.js
├─ content/
│  ├─ media/
│  └─ posts/
└─ themes/
   └─ quesby-core-theme/

No hidden pipelines, no magic directories—open the repo six months later and it still makes sense.

Performance and privacy

Zero unwanted JavaScript
Minimal CSS
Optimized images
No cookies
No external requests unless you add them

Performance isn’t a selling point; it’s a natural consequence of the lean setup. Quesby ships with zero third‑party integrations, which means fewer external calls, fewer legal requirements, fewer performance penalties, and fewer surprises during audits. Add analytics or embeds only when you explicitly need them.

Developer experience

Quesby avoids two extremes:

Sprawling configs – everything is modular and predictable.
“One‑command magic” that hides everything – you see and control each layer.

You get:

A stable, understandable codebase
Modular configs
Predictable build behavior
Freedom to extend without digging through abstractions

DX should support development, not add ceremony around it.

Who should use Quesby

Developers building static or content‑driven sites
Those who prefer explicit structure over convention‑heavy automation
Teams that want SEO and image handling solved without a maze of plugins
Eleventy fans looking for an ecosystem around it
Anyone who wants a workflow they can audit and override

If you’re building a full web app, you’ll likely need a different stack. For a website, Quesby feels more natural.

Getting started

When the balance feels right for your next project, bootstrap a new site with:

npm create quesby@latest

Conclusion

Static sites don’t need complicated tooling, but they do benefit from structure and good defaults. Quesby sits in that middle ground: lightweight, stable, and focused on solving the recurring problems of static‑site development without dragging in an entire ecosystem built for different use cases. It doesn’t try to redefine web development—it just tries to make building websites feel sane again.