DEV Community: Quesby

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

Quesby — Fri, 12 Dec 2025 14:00:00 +0000

Modern web tooling is powerful—sometimes too powerful for what most projects actually need.

Frameworks today are engineered to handle broad, complex use cases: dynamic apps, interactive dashboards, real-time data, entire design systems running in the browser.

Static sites sit on the opposite end of the spectrum.

They rarely need that level of machinery, yet developers still feel the weight of choices designed for far larger problems.

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.

1. Why Quesby Exists

Most developers have lived this scenario: you start a simple website, open your tooling of choice, and suddenly you’re dealing with bundlers, configs, dependencies, and features that aren’t relevant to your project.

Nothing wrong with those tools—they're built for ambitious apps.

But when you're generating HTML pages, that ecosystem can become unnecessary overhead.

Quesby focuses on the common needs of static sites:

predictable structure
clean templates
good SEO
image optimization
no hidden integrations
no configuration sprawl

It doesn't try to be a universal solution.

It tries to be a good one for a specific class of projects.

2. Design Principles

Three core ideas shape Quesby:

2.1 Use the Right Tool for the Job

Quesby builds on Eleventy because its philosophy fits the nature of static sites: generate HTML from templates, nothing more unless asked.

No runtime attached.

No front-end framework assumptions.

2.2 Keep the Surface Area Small

Tools that don’t add value aren’t included.

No analytics by default.

No external fonts.

No client-side libraries unless you opt in.

The goal isn’t “minimalism for aesthetic reasons”.

It’s “don’t ship or maintain what you don’t use”.

2.3 Make Everything Observable and Replaceable

Quesby avoids black boxes.

Every layer—content, templates, SEO, assets—lives in a place you can inspect and customize.

If you want to extend it, nothing fights you.

3. What Quesby Adds on Top of Eleventy

Quesby doesn’t reinvent the Eleventy workflow.

It refines it for real-world use.

3.1 Centralized SEO

Front matter becomes a single source for:

meta tags
OpenGraph
Twitter Cards
JSON-LD
canonical URLs
language alternates

Instead of juggling separate plugins, Quesby consolidates the logic into a predictable module.

You define SEO once in front matter:

---
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:

<title>Static Sites Without the Bloat | Example Site</title>
<meta name="description" content="How Quesby trims modern tooling down to what static sites actually need.">
<meta property="og:title" content="Static Sites Without the Bloat">
<meta property="og:image" content="https://example.com/assets/images/posts/static-sites-without-the-bloat/cover.jpg">
<!-- ...additional structured data... -->

3.2 Image Handling That Makes Sense

Eleventy Image is powerful but noisy.

Quesby wraps it with defaults that handle:

WebP/AVIF output
fallbacks
modern markup
lazy-loading
deterministic filenames

You get the good parts without the friction.

A typical image in a template might look like:

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

Quesby handles responsive sources, formats, and attributes like loading="lazy" for you.

3.3 A Clean Content Workflow

Markdown should stay Markdown.

Quesby provides:

structured content directories
automatic slugs
ULID-based IDs
predefined collections
simple front matter rules

Nothing exotic. A workflow that doesn't collapse the moment you add pages.

3.4 Adding a new article made easy

Creating a new article is as simple as adding a file like:

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 here.

And it can be even easier by launching the helper:

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

3.5 A Boilerplate That Doesn’t Dictate Design

The starter includes a neutral, accessible layout system you can extend or scrap entirely.

It works out of the box for:

blogs
landing pages
docs sections
mixed content sites

But you’re never locked into its visual identity.

4. Architecture: Predictable by Design

The directory structure is intentionally boring:

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.

If you open the repo six months later, it still makes sense.

5. Performance: Not a Contest, Just Good Defaults

Static sites are fast by default.

Quesby ensures you don’t accidentally sabotage that:

no unwanted JS
minimal CSS
optimized images
zero cookies
no external requests unless you add them

Performance isn’t a selling point—it’s a consequence.

6. Privacy by Default

Quesby ships with zero third-party integrations.

fewer external calls
fewer legal requirements
fewer performance penalties
fewer surprises during audits

Add analytics or embeds only when needed, not because the template assumed them.

7. Developer Experience: Stability Over Flashiness

Quesby’s DX avoids two extremes:

no sprawling configs, no “one-command magic” that hides everything.

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.

8. Who Quesby Is For

Quesby fits developers who:

build static or content-driven sites
prefer explicit structure over convention-heavy automation
want SEO and images solved without plugins everywhere
like Eleventy but want an ecosystem around it
want a workflow they can audit and override

If you’re building a full web app, you’ll want something else.

If you’re building a website, this will probably feel more natural.

9. Closing Thoughts

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.

If that sounds like the right balance for your next project:

npm create quesby@latest

Quesby doesn’t try to redefine web development.

It just tries to make building websites feel sane again.

Markdown Style Guide: Best Practices for Content Creation

Quesby — Tue, 09 Dec 2025 13:00:00 +0000

Markdown has become the de facto standard for content creation in modern web development. Whether you're writing documentation, blog posts, or technical articles, understanding Markdown best practices ensures your content is readable, accessible, and maintainable.

This style guide covers everything from basic formatting to advanced techniques, helping you create content that works seamlessly across different platforms and devices.

Basic Text Formatting

Headers and Structure

Use header hierarchy to create clear content structure:

# Main Title (H1)
## Section Title (H2)
### Subsection (H3)
#### Minor Heading (H4)
##### Small Heading (H5)
###### Tiny Heading (H6)

Best Practice: Use only one H1 per document and maintain logical hierarchy. Don't skip heading levels.

Emphasis and Strong Text

*This text is italic*
_This text is also italic_

**This text is bold**
__This text is also bold__

***This text is both bold and italic***
___This text is also both___

Accessibility Tip: Use emphasis sparingly. Screen readers announce emphasis, so overuse can be distracting.

Lists and Organization

Unordered Lists

- First item
- Second item
  - Nested item
  - Another nested item
- Third item

Ordered Lists

1. First step
2. Second step
   1. Sub-step
   2. Another sub-step
3. Third step

Task Lists

- [x] Completed task
- [ ] Pending task
- [ ] Another pending task

Links and References

Basic Links

[Link text](https://example.com)
[Link with title](https://example.com "Optional title")

Reference Links

[Link text][reference-id]

[reference-id]: https://example.com "Optional title"

Email Links

[Contact us](mailto:hello@example.com)

Best Practice: Use descriptive link text. Avoid "click here" or "read more" as they don't provide context when read out of context.

Images and Media

Basic Image Syntax

![Alt text](image.jpg)
![Alt text](image.jpg "Optional title")

Responsive Images

![Alt text](image.jpg "Title")
![Alt text](image-320.jpg "Title" width="320")
![Alt text](image-640.jpg "Title" width="640")

Accessibility: Always provide meaningful alt text. If an image is decorative, use empty alt text: ![](image.jpg)

Code and Technical Content

Inline Code

Use `console.log()` to output data to the browser console.

Code Blocks

function greetUser(name) {
  console.log(`Hello, ${name}!`);
}

Syntax Highlighting

<div class="container">
  <h1>Welcome</h1>
</div>

.container {
  max-width: 1200px;
  margin: 0 auto;
}

npm install package-name

Fenced Code Blocks with Language

{
  "name": "project",
  "version": "1.0.0",
  "dependencies": {
    "react": "^18.0.0"
  }
}

Tables and Data

Basic Table

| Column 1 | Column 2 | Column 3 |
|----------|----------|----------|
| Row 1    | Data 1   | Data 2   |
| Row 2    | Data 3   | Data 4   |

Aligned Table

| Left Aligned | Center Aligned | Right Aligned |
|:-------------|:--------------:|--------------:|
| Left         | Center         | Right         |
| Data         | Data           | Data          |

Complex Table

| Feature | Status | Notes |
|:--------|:------:|:------|
| Basic Auth | ✅ Complete | Works with all providers |
| OAuth 2.0 | 🚧 In Progress | Expected Q2 2024 |
| SSO | ❌ Planned | Not yet started |

Blockquotes and Callouts

Basic Blockquotes

> This is a blockquote.
> It can span multiple lines.
> 
> And include multiple paragraphs.

Nested Blockquotes

> This is a blockquote.
> 
> > This is a nested blockquote.
> > It can be useful for replies or comments.

Blockquotes with Attribution

> The best way to predict the future is to create it.
> 
> — Peter Drucker

Horizontal Rules and Separators

---

***

___

- - -

* * *

Best Practice: Use horizontal rules sparingly to avoid visual clutter. They work best for major section breaks.

Advanced Markdown Features

Strikethrough

~~This text is crossed out~~

Superscript and Subscript

H~2~O (subscript)
2^10^ = 1024 (superscript)

Highlighting

==This text is highlighted==

Footnotes

This is a sentence with a footnote[^1].

[^1]: This is the footnote content.

Content Structure Best Practices

1. Use Descriptive Headers

❌ Bad
## Stuff

✅ Good
## User Authentication Methods

2. Keep Paragraphs Short

Break up long paragraphs into digestible chunks. Aim for 2-3 sentences per paragraph on mobile devices.

3. Use Lists for Scannable Content

❌ Bad
The application supports multiple features including user authentication, data validation, error handling, and logging.

✅ Good
The application supports multiple features:
- User authentication
- Data validation  
- Error handling
- Logging

4. Include Table of Contents

For longer documents, consider adding a table of contents:

## Table of Contents
- [Introduction](#introduction)
- [Getting Started](#getting-started)
- [Configuration](#configuration)
- [Advanced Usage](#advanced-usage)
- [Troubleshooting](#troubleshooting)

Accessibility Guidelines

1. Meaningful Alt Text

❌ Bad
![image](photo.jpg)

✅ Good
![Screenshot of the login form showing username and password fields](login-form.jpg)

2. Descriptive Link Text

❌ Bad
[Click here](https://example.com) for more information.

✅ Good
[Read our complete installation guide](https://example.com) for detailed setup instructions.

3. Proper Heading Hierarchy

# Main Title
## Section 1
### Subsection 1.1
### Subsection 1.2
## Section 2
### Subsection 2.1

Platform-Specific Considerations

GitHub Flavored Markdown

Supports task lists: - [x] Completed task
Supports tables with alignment
Supports strikethrough: ~~text~~
Supports syntax highlighting in code blocks

CommonMark

More standardized than GitHub Flavored Markdown
Better cross-platform compatibility
Supports most basic Markdown features

Static Site Generators

Many support front matter (YAML, TOML, JSON)
Some support custom shortcodes or components
Consider your target platform's specific features

Tools and Resources

Markdown Editors

VS Code: Built-in preview and extensions
Typora: WYSIWYG Markdown editor
Mark Text: Real-time preview editor
Obsidian: Note-taking with Markdown support

Validation Tools

markdownlint: Lint Markdown files
markdown-link-check: Check for broken links
textlint: Advanced text linting

Online Tools

Dillinger: Online Markdown editor
StackEdit: Advanced online editor
Markdown Live Preview: Real-time preview

Common Mistakes to Avoid

1. Inconsistent Formatting

❌ Bad
- Item 1
* Item 2
- Item 3

✅ Good
- Item 1
- Item 2
- Item 3

2. Missing Alt Text

❌ Bad
![Screenshot](image.jpg)

✅ Good
![Screenshot of the dashboard showing user statistics](dashboard.jpg)

3. Poor Link Text

❌ Bad
[Here](https://example.com) is the documentation.

✅ Good
[Complete API documentation](https://example.com) is available online.

4. Inconsistent Header Usage

❌ Bad
# Title
### Subtitle
## Another Section

✅ Good
# Title
## Subtitle
## Another Section

Conclusion

Mastering Markdown is about more than just syntax—it's about creating content that is accessible, maintainable, and user-friendly. By following these best practices, you'll create documentation and content that serves your users well across all platforms and devices.

Remember:

Consistency is key to maintainable content
Accessibility should be considered from the start
Structure helps both humans and machines understand your content
Testing your Markdown across different platforms ensures compatibility

Start implementing these practices in your next piece of content, and you'll see immediate improvements in readability and maintainability.

Why Eleventy Still Matters in 2026 (and Why Quesby Builds on It)

Quesby — Fri, 05 Dec 2025 20:16:14 +0000

Over the last few years, the web development ecosystem has gone through a predictable cycle:
a shiny new JavaScript meta-framework appears, becomes the “new standard,” grows in complexity, and often ends up forcing developers into migrations they didn’t ask for.

Yet one tool has remained consistently fast, stable, and free from bloat: Eleventy.

In 2026, with more developers reconsidering their stacks, Eleventy isn’t just relevant — it’s strategically important. And it’s the foundation of Quesby for a reason.

1. For Many Sites, the Web Didn’t Need More JavaScript — It Possibly Needed Less

Many modern frameworks promise DX, then — especially for content-driven sites — bury you under:

massive dependency trees
bundlers, dev servers, compilers
countless edge runtimes
plugin ecosystems that break with every release
lock-in designed to keep you on their platform

Eleventy takes a different path for these cases: no client-side framework, no hydration ceremony, no runtime tax.

Just HTML, templates, Markdown, and a build pipeline that stays out of your way.

Less to debug. Less to update. Less to break — particularly when your site is mostly content.

This feels closer to Web Development 101 than to yet another reinvention.

2. Static Sites Are Not “Old School” — They’re the Performance Baseline

Static sites age well.

They’re cache-friendly, CDN-first, stable, and require almost no infrastructure.

In a world where Core Web Vitals dictate traffic, static HTML isn’t nostalgia — it’s often a competitive advantage for a large class of sites.

Eleventy excels because:

it outputs plain HTML
it avoids unnecessary client-side JS
it gives you full control over markup
it integrates perfectly with modern CDNs and edge deployments

If performance matters and your site is mostly content, static is often one of the simplest ways to win.

3. Eleventy’s Flexibility Makes It a Strong Foundation Compared to Many Meta-Frameworks

Most frameworks force you into one paradigm.

Eleventy doesn’t care how you work.

You can structure your site with:

Nunjucks
Markdown
Liquid
JavaScript templates
11ty Data Cascade
custom content generators
arbitrary folder structures

This flexibility is why Quesby builds on Eleventy instead of reinventing the wheel.

Quesby simply adds:

opinionated conventions
predictable content structures
a fully wired documentation system
soft-defaults for SEO, images, metadata, and accessibility
a zero-noise build pipeline
clear extension points

Eleventy is the engine.

Quesby is the chassis that makes it production-ready from day one.

4. Stability Beats Churn (Especially in 2026)

Framework churn is a tax:

new major versions every year
breaking changes
migration guides
refactoring half your codebase just to stay compatible

Eleventy largely sidesteps this problem in day-to-day work.

Its release cycle is slow, conservative, and stable.

Quesby builds on that foundation to give you something you can rely on long-term — without spending your life migrating configs.

5. Eleventy Is a Great Fit for Content-Centric Sites

Not every site needs React.

Not every site needs hydration.

Not every site needs a client-side application.

But every site needs content.

Eleventy shines for:

blogs
documentation portals
landing pages
marketing sites
knowledge bases
simple product sites

Quesby builds on this strength by providing a ready-made environment for:

Markdown-based content
auto-generated sitemaps and feeds
automatic metadata + JSON-LD
documentation layouts and navigation
responsive images and inline SVG helpers

It removes the overhead so the developer can focus on building — not configuring.

6. A Framework Should Be Invisible, Not the Star of the Show

The best tool is the one that gets out of your way.

Eleventy’s simplicity makes it one of the few modern SSGs that doesn’t try to own your workflow.

Quesby’s philosophy is identical:

no proprietary ecosystem
no vendor lock-in
no magic that hides what’s really happening
no external dependencies
no bundle
no JS-heavy boilerplate

Just clean, predictable output.

Here I'll include an example of a live website made exclusively in Quesby.
Real-world performance: quesby.dev achieves Lighthouse 94 with minimal JavaScript (12.2 KB) and near-zero external dependencies (3.14 KB third-party). This is what 'no bundle' and 'no external dependencies' look like in practice.

Conclusion: Eleventy Hasn’t Just Survived — It’s Become a Benchmark

The web doesn’t need more heavy frameworks.

It needs tools that:

respect the platform
build fast
ship fast
age well
don’t hijack your architecture

Eleventy fits that role better in 2026 than ever before.

And Quesby builds on it because the goal isn’t to reinvent the stack — it’s to deliver a clean, efficient, production-ready way to use the best parts of the web as they already are.

If you’re tired of the noise, the churn, and the complexity, Eleventy remains the most sensible foundation.

Quesby just makes it easier to use.

Quick Start: Eleventy Shortcodes for Responsive Images & Inline SVG

Quesby — Wed, 03 Dec 2025 19:00:00 +0000

This guide shows how to add two production-ready shortcodes to Eleventy (ESM): a responsive image helper using @11ty/eleventy-img and an inline SVG helper that lets you inject CSS classes.

Here’s the final output generated in the DOM (fully handled by the shortcode):

<picture>
  <source type="image/avif" srcset="/img/hero_320.avif 320w, ..." />
  <source type="image/webp" srcset="/img/hero_320.webp 320w, ..." />
  <img src="/img/hero_original.webp" alt="Site cover image" loading="lazy" />
</picture>

Quick Start

Follow these steps to get ready-to-use shortcodes in minutes:

Install dependency

   npm i @11ty/eleventy-img

Create the shortcodes module at eleventy/shortcodes/media.js (see below)
Register it in eleventy.config.js and rebuild
Use {% image %} for responsive images and {% svg %} for inline SVG in your Nunjucks templates

What you get

The {% image %} shortcode outputs a <picture> element with AVIF/WebP sources, responsive widths, lazy loading, and decoding hints—all preconfigured for production use.

Prerequisites

Eleventy v2+ or v3 with ESM config.
Nunjucks templates (examples use {% %} tags).
Project layout with assets under src/.

Example folders:

src/
  assets/
    images/
    icons/

Install

npm i @11ty/eleventy-img

Shortcodes module

Create eleventy/shortcodes/media.js:

import path from "node:path";
import fs from "node:fs";
import Image from "@11ty/eleventy-img";

/** Responsive image (async) */
async function imageShortcode(src, alt, sizes = "100vw") {
  if (!alt) throw new Error(`Missing alt for ${src}`);

  // Normalize to src/assets/images/
  const normalized = src.replace(/^\/?src\/assets\/images\/?/, "");
  const resolved = path.resolve("src/assets/images", normalized);

  const metadata = await Image(resolved, {
    widths: [320, 640, 960, 1280, null],  // null => original width
    formats: ["avif", "webp"],            // add "jpeg" if you want a fallback
    outputDir: "./_site/img/",
    urlPath: "/img/",
  });

  return `<figure>${Image.generateHTML(metadata, {
    alt,
    sizes,
    loading: "lazy",
    decoding: "async",
  })}</figure>`;
}

/** Inline SVG with optional class */
function svgShortcode(svgPath, className = "") {
  const rel = svgPath.replace(/^\/?src\/?/, ""); // keep paths under src/
  const fullPath = path.join(process.cwd(), "src", rel);
  const svg = fs.readFileSync(fullPath, "utf8");

  if (!className) return svg;

  // Append or set class on the opening <svg ...>
  const hasClass = /<svg([^>]*?)\sclass="([^"]*)"/i.test(svg);
  if (hasClass) {
    return svg.replace(
      /<svg([^>]*?)\sclass="([^"]*)"([^>]*)>/i,
      (_m, pre, cls, post) => `<svg${pre} class="${cls} ${className}"${post}>`
    );
  }
  return svg.replace(/<svg([^>]*)>/i, `<svg$1 class="${className}">`);
}

export default (cfg) => {
  cfg.addNunjucksAsyncShortcode("image", imageShortcode);
  cfg.addNunjucksShortcode("svg", svgShortcode);
};

Register in Eleventy config

In eleventy.config.js (ESM):

import mediaShortcodes from "./eleventy/shortcodes/media.js";

export default function(eleventyConfig) {
  eleventyConfig.addPlugin(mediaShortcodes);
}

Usage in Nunjucks

Responsive image (async shortcode):

{% image "hero/cover.jpg", "Site cover image", "(min-width: 768px) 75vw, 100vw" %}

Inline SVG with a custom class:

{% svg "assets/icons/github.svg", "icon-lg text-neutral-700" %}

Alternative: expression style

If you prefer {{ ... }} output for SVG, also register:

// in the plugin function
cfg.addShortcode("svg", svgShortcode);

Then:

{{ svg("assets/icons/github.svg", "icon-lg") | safe }}

Troubleshooting and notes

“Unable to call ‘svg’…” means you registered with addShortcode but used {% svg %}. Use addNunjucksShortcode for tag syntax.
Paths: keep inputs relative to src/…. The module normalizes src/assets/images/... automatically for images and src/... for SVGs.
Accessibility: alt is required. Use empty alt only for decorative images.
Fallbacks: if you need a bitmap fallback, add "jpeg" to formats.
Caching: @11ty/eleventy-img caches processed assets. Commit the cache if you want stable builds in CI.

Additional tips:

ESM vs CJS configs: This example assumes ESM. If you are on CommonJS, adapt imports/exports accordingly.
Windows paths: Prefer path.resolve and avoid hardcoded backslashes. The provided code handles normalization.
External URLs: The shortcode expects local files. For remote images, download them during build or provide a local copy.

Minimal CSS example

.icon-lg { width: 1.5rem; height: 1.5rem; display: inline-block; }

Commit message template

feat(shortcodes): add responsive image and inline SVG helpers (Nunjucks, ESM)

How Quesby Handles SEO (Without Plugins, Frameworks, or Runtime Code)

Quesby — Tue, 02 Dec 2025 13:00:00 +0000

Automatic Metadata, Open Graph, and JSON-LD — Eleventy Style

Most Eleventy setups start the same way: every project re-implements SEO from scratch.

Another base.njk, another batch of <meta> tags, another copy-pasted JSON-LD snippet from schema.org.

It’s boring, error-prone, and inconsistent across projects.

Quesby solves this the only sane way: one SEO model, one source of truth, generated at build time.

No plugins.

No runtime.

No React components disguised as SEO helpers.

This is how it works.

The Idea in 10 Seconds

Quesby takes:

site.json + frontmatter → SEO model → complete <head> + JSON-LD

Everything happens during the Eleventy build.

Templates stay clean.

SEO stays consistent.

In base.njk, it looks like this:

{%- set seoModel = page | seoModel(site, pageData) -%}
{{ seoModel | seoHeadHtml(site) | safe }}
{{ seoModel | seoJsonLd(site) | safe }}

That’s the entire integration surface.

Site-Level Defaults (One File)

Global SEO config lives in:

src/_data/site.json

Example:

{
  "name": "Quesby",
  "url": "https://quesby.dev",
  "description": "A modern Eleventy boilerplate",
  "socialImage": "/assets/images/og-default.jpg",
  "twitter": "@quesby",
  "language": "en-US"
}

Quesby uses this for:

default description
default Open Graph image
canonical URL generation
Twitter Card data
JSON-LD publisher info

You define it once.

Every page inherits it automatically.

Frontmatter: Minimal When You Want, Detailed When You Need

Simple page:

---
title: "My Page"
description: "Short summary."
---

Full blog post:

---
title: "How to Build Better Websites"
seoTitle: "Complete Guide to Modern Web Development"
description: "Learn the principles behind fast, accessible websites."
image: "/assets/images/cover.jpg"
postType: "article"
author: "John Doe"
date: "2024-01-15"
---

Quesby applies fallback rules:

Title: `seoTitle` → `title` → `site.name`
Description: `description` → `site.description`
Image: `image` → `site.socialImage`

You don’t repeat yourself.

Pages don’t need boilerplate.

Automatic Head Metadata

From the SEO model, Quesby generates:

Basic SEO

<title>
<meta name="description">
<link rel="canonical">
<meta name="robots"> (with noindex support)

Open Graph

og:type
og:title
og:description
og:url
og:image

Twitter Cards

`twitter:card` (`summary_large_image`)
`twitter:site`
`twitter:title`
`twitter:description`
`twitter:image`

No manual tags.

No plugin configuration.

No React component SEO helper nonsense.

JSON-LD Structured Data

Quesby also outputs JSON-LD for:

Blog posts (`BlogPosting`)

headline
description
image
author
publisher
datePublished
dateModified

Site (`WebSite`)

name
url
description
publisher

Rendered via:

{{ seoModel | seoJsonLd(site) | safe }}

Again: static, not runtime.

Sitemap, Robots, and Noindex Integration

Quesby integrates SEO beyond the <head>:

Sitemap generated from the `sitemap` collection
Pages with `noindex` or `eleventyExcludeFromCollections` are auto-excluded
`robots.txt` generated automatically and linked to the sitemap

Everything stays consistent with the same SEO model.

Opt-Out When Needed

For special pages:

---
seoDisableCoreHead: true
seoDisableCoreJsonLd: true
---

You can disable core SEO on a per-page basis and write your own tags.

No lock-in.

Why This Matters for Eleventy Developers

If you build Eleventy sites regularly, you already know the pain:

copy-pasting head tags
rewriting JSON-LD
fixing Open Graph mismatches
forgetting canonical URLs
duplicating logic across pages

Quesby removes all of that.

One config file
One model
One consistent output
Zero runtime JavaScript
Zero framework dependencies

HTML-first, static-first, and boring in all the right ways.

Final Thoughts

If you like Eleventy but don’t want to rebuild SEO infrastructure for every project, Quesby gives you:

strong defaults
static, predictable output
extensibility when needed
zero client-side bloat

It’s a lightweight alternative to plugin-heavy or framework-heavy approaches, built specifically for people who prefer clean HTML and simple pipelines.

More info:

https://quesby.dev

Stop Using @import: How to Prepare for Dart Sass 3.0 (Full Migration Guide)

Quesby — Thu, 27 Nov 2025 05:00:04 +0000

What’s Changing in Dart Sass 3.0

The Sass team announced that Dart Sass 3.0 will arrive no earlier than two years after version 1.80.0. When it ships, several features will be removed completely:

@import → Removed. Replaced by @use and @forward.
Global built-in functions (e.g. map-get, nth, call) → Removed. You must import functions from the relevant module (sass:map, sass:list, etc.).
Legacy global color functions → Replaced by namespaced versions from sass:color.

Right now these features still work, but trigger deprecation warnings. With 3.0 they will fail with errors.

Preparing for Dart Sass 3.0: Goodbye `@import`, Hello `@use`

Dart Sass is moving forward. The next major release, Dart Sass 3.0, will remove long-deprecated features such as the @import rule and global functions like map-get. If your stylesheets still depend on them, it’s time to update.

In this post we’ll cover what’s changing, why it matters, and how you can migrate smoothly.

Why `@import` Had to Go

The old @import rule had serious issues:

It pollutes the global scope with variables and mixins.
Order of imports changes the outcome, often leading to brittle code.
Performance suffers because the same file can be compiled multiple times.

@use and @forward fix these problems by introducing explicit scoping. Code is loaded once, names are controlled, and dependencies are easier to reason about.

Migrating from `@import` to `@use`

Before

// skin.scss
@import "@quesby/core/sass/_reset";
@import "_theme-variables";
@import "@quesby/core/sass/_mixins";
@import "_base";

After

// skin.scss
@use "@quesby/core/sass/reset";
@use "theme-variables" as *; // optional: expose variables without prefix
@use "@quesby/core/sass/mixins" as *;
@use "base";

Notice how each dependency is namespaced. If you omit as *, you’ll need to prefix variables or mixins with the module name:

.container {
  max-width: mixins.container-width(laptop);
}

This explicitness avoids collisions and makes code more predictable.

Migrating Global Functions

Before

max-width: map-get($container-max-widths, tablet);

After

@use "sass:map";

max-width: map.get($container-max-widths, tablet);

The pattern is always the same: import the right built-in module and call the function with dot notation.

Quick Reference Table

Old Syntax (Deprecated)	New Syntax (Supported)
`@import "file";`	`@use "file";` or `@forward "file";`
`map-get($map, $key)`	`map.get($map, $key)`
`nth($list, $n)`	`list.nth($list, $n)`
`adjust-color($c, $args...)`	`color.adjust($c, $args...)`
`lighten($c, $amount)`	`color.scale($c, $lightness: $amount)`

Keep this table handy when refactoring your codebase.

Step-by-Step Migration Strategy

Inventory your imports. Find all @import rules in your codebase.
Convert shared variable/mixin files. Use @forward in an index file to re-export what other files need.
Update your main entry files (skin.scss, etc.) to use @use instead of @import.
Replace global functions with their module equivalents (map.get, list.nth, color.adjust, etc.).
Run your build in verbose mode to catch any leftover deprecations.

When Should You Migrate?

You still have time: Dart Sass 3.0 is at least two years away. But the safest approach is to migrate now:

No more noisy warnings during builds.
Cleaner, more modular Sass code.
Zero risk of breakage when 3.0 drops.

If you’re starting a new project today, don’t use @import at all—begin with @use and @forward.

Final Thoughts

Sass 3.0 will be the cleanest, most predictable version of Sass yet. By dropping legacy features, the team is ensuring a simpler, more robust future for stylesheet authoring.

Don’t wait until the last minute. Begin the migration today and your projects will be future-proof by the time Dart Sass 3.0 arrives.

Meet Quesby: A Privacy-First Eleventy Starter That Stays Out of Your Way

Quesby — Fri, 21 Nov 2025 05:44:02 +0000

I've always loved static site generators.

But every time I wanted to spin up a small, focused site, I kept hitting the same problems:

Boilerplates full of stuff I didn't ask for
Too many external dependencies
Complex setups just to publish a few pages or blog posts

So I ended up building my own starter – and that's how Quesby was born.

Quesby is the boilerplate that powers my own site at quesby.dev, and now it's open for you to use too.

What Quesby Is

Quesby is a modern Eleventy boilerplate with a privacy-first mindset, Decap CMS integration, and a tiny core you can actually understand.

It's a clean starting point for content-driven sites where you still stay in control.

Who Quesby Is For

Why I Built It

I wanted a starter that:

Respects visitors – no tracking pixels, no analytics you didn't explicitly add
Respects developers – no 20 layers of abstraction just to render a page
Respects content creators – a simple CMS flow instead of “open a Markdown file and hope you don’t break the front matter”

Under the hood, Quesby uses a reusable core (@quesby/core) so the project logic isn't scattered everywhere.

That means you can reuse the same core across multiple sites and keep things consistent.

What You Actually Get

Out of the box, Quesby ships with:

Eleventy 3.0 for static site generation
A small CLI, for example:

npx quesby new post "My First Quesby Post"

Generates a properly structured post with front matter, date, and a sane folder name.
A modular theme system (comes with a couple of themes you can swap or customize)
SEO basics (sitemap, meta tags, etc.)
Privacy-first defaults – nothing gets injected behind your back
Optional CMS integration (Decap)

But the most important part: the codebase is meant to be readable.

If you like to open files, understand what's going on, and tweak things, Quesby is on your side.

How to Try It

The fastest way to play with it:

npx create-quesby my-site

cd my-site

Install dependencies (uses pnpm under the hood):

npm install -g pnpm@9

pnpm install

Launch the server with auto-reload:

pnpm serve

Then open http://localhost:8080 and start tweaking.

If you prefer details and alternative setups (Corepack, etc.), they're all in the repository README.