juicerblog demo

About this site

2026-05-27T22:46:01.552523561Z

This site exists for one reason: to be a realistic-looking blog so we can iterate on the juicerblog theme without reaching for stock-photo content. Every post here is a real-ish essay about a topic the credited author cares about; nothing is filler, but nothing has to be defended at length either.

What it exercises

Tagging — most posts carry one or two tags, with meta deliberately overloaded (used by three posts) and life used exactly once, so the tag cloud has visible weight differences.
Series — the Reading on screens posts are a three-part series by Alice. The series sidebar lists all three; the prev/next buttons step through chronological order across all posts, regardless of series.
Multiple authors — Ed, Alice, and Ben each have author records under [[authors]] in site.toml. One post (Why static sites still win) has co-authors.
Date archives — dateArchives = true in site.toml, so /2024/, /2024/07/, /2024/08/, etc., land as their own pages.
Aliases — Why static sites still win declares two old URLs that resolve via meta-refresh.
Permalinks — [permalinks] posts = ":year/:month/:slug/" — every post lives under its date, so the URL survives a re-tagging.
Atom feeds — /feed.xml aggregates everything; per-section feeds drop in too.

Why a third demo blog

Two reasons. First, a theme is only as good as the content you can iterate on, and stock-Lorem-ipsum hides exactly the design problems that show up in real text — tag cloud imbalance, series sidebars with awkward title lengths, multi-author bylines that need to wrap, posts with figures vs. without. Second, every Phase-2 engine feature ships with a layout in juicerblog, and a layout that has no demo content is a layout that breaks at the next refactor without anybody noticing.

How a “page” is different from a “post”

This page declares static: true in its frontmatter, which tells the juicerblog theme to drop the post chrome (date line, reading time, tags, series sidebar, prev/next nav) and render the body as a clean long-form essay. The signal is purely a theme convention — the engine still treats this file like any other content — but it means an about / colophon / contact page can live alongside the post archive without looking like part of it.

Source for the demo lives at examples/blog-site/ in the juicer repo. Pull requests welcome.

Why static sites still win

2024-12-04T00:00:00Z

A static site generator turns markdown + templates into HTML at build time. No runtime database, no app server, no per-request rendering — the bytes are just there, ready to be served by any file host that knows what a directory looks like.

The boring case

It’s hard to overstate how good this story is in 2024. CDNs are everywhere; the marginal cost of serving a request from cache is essentially zero. There’s no scaling story to plan for, no failover to design, no security patches to chase down at 3 AM because some CMS plugin opened a hole.

You write markdown, you push to git, the site updates. That’s the whole deployment story.

The ageing case

A WordPress install from 2014 is a forensic exercise in 2024. A static HTML directory from 2014 still serves its content. The format is the format; browsers haven’t lost the ability to render <h1>.

When the next paradigm shift hits — and there will be one — your static site keeps working. That’s not nothing.

A whirlwind tour of Scala 3

2024-11-18T00:00:00Z

Scala 3 cleans up a decade of accreted complexity. Five things land squarely:

Significant indentation

class Box[T](var value: T):
  def map[U](f: T => U): Box[U] =
    Box(f(value))

Curly braces are still legal, but most code reads better without them. The compiler accepts both styles — pick what fits.

Enums are first-class

enum Json:
  case Obj(fields: Map[String, Json])
  case Arr(elements: List[Json])
  case Str(value: String)
  case Num(value: BigDecimal)
  case Bool(value: Boolean)
  case Null

A real algebraic-data-type syntax. Pattern matching gets exhaustiveness checking automatically.

Given / using replaces implicit

trait Show[T]:
  def show(t: T): String

given Show[Int] with
  def show(n: Int): String = n.toString

def render[T](t: T)(using s: Show[T]): String = s.show(t)

The intent reads off the page now: given introduces an instance, using consumes one.

Extension methods

extension (s: String)
  def shout: String = s.toUpperCase + "!"

Cleaner than the implicit-class song-and-dance Scala 2 made you do.

Match types and inline

The advanced features (match types, transparent inline, capture checking) round out a language that finally fits in your head.

Markdown is enough

2024-10-30T00:00:00Z

Twenty years of WYSIWYG editors lost to a syntax invented for read-this-as-text emails. The lesson, in retrospect, is obvious: text is the universal interchange format, and markdown is the smallest possible layer of structure on top of it.

Why markdown won

A specification readable by ten-year-olds. A toolchain that runs in any language. Diffs that highlight prose, not bracket-soup.

You can read a markdown file as plain text and never miss a thing. You can also render it to HTML, PDF, an EPUB, a man page. The format encodes intent (# Heading, **bold**) without committing to a presentation.

What it isn’t

Not a layout language. Use HTML or CSS for that.
Not a programming language. No conditionals, no loops, no data flow.
Not WYSIWYG. The preview is downstream of the source.

These limits are what makes markdown durable. Add a third comma and you get reST; add a fourth and you get TeX. Each step toward power is a step away from “anyone can author this on a phone.”

Typography 101 for site builders

2024-09-22T00:00:00Z

Most sites get type wrong by default — too cramped, too small, too many faces fighting for attention. The fixes are mostly free.

Pick two

One serif, one sans. That’s it. A monospace for code if there is code. The discipline of “two faces, two roles” eliminates 90% of typographic clutter.

Set a generous measure

Reading prose at 100 characters per line is exhausting; 60–75 is comfortable. Set max-width: 38rem on the column and stop fighting your eyes.

Line-height is doing more than you think

Body text wants line-height: 1.6 to 1.75. Headings want closer to 1.15. Buttons and labels want 1.0. The vertical rhythm of a page comes from these ratios more than from any specific font.

Trust system stacks

font-family: "Iowan Old Style", Charter, Georgia, serif;

The web safe stack of 2010 still works in 2024. You don’t need to ship a 200KB webfont to look professional.

A short note on file naming

2024-09-03T00:00:00Z

Kebab-case. Lowercase. No dates in the filename — that’s what frontmatter is for. Never use a space, never use a colon (Windows hates you back), and treat anything past 50 characters as a smell. The slug is the URL is the canonical handle for the rest of the post’s life; pick something a stranger could reasonably guess.

Five years of regret distilled into one paragraph.

On coffee rituals

2024-08-15T00:00:00Z

The water comes to a boil while the beans grind. The grinder is loud, then quiet; the kettle is quiet, then quiet differently. The shape of the morning condenses around 30 seconds of sound and 4 minutes of waiting.

The ritual

Bloom: 30 grams of grounds, 60 grams of water, 30 seconds of stirring while the puck off-gasses. Pour to 200, then 350, then 500. Stop the bed from collapsing. Wait. Drink.

The coffee almost doesn’t matter at this point. The ritual is the thing.

Why morning

The first hour after waking is where most days are won or lost. A practice that demands attention — even a low-stakes one — anchors the rest. Easier to focus on something hard at 9 AM if you’ve already focused on something deliberate at 7.

Reading on screens, part 3: long-form reading patterns

2024-08-05T00:00:00Z

Eye-tracking studies on long-form web reading converge on the same boring conclusion: the first thing your reader does is scan. They glance at the title, fall to the first paragraph, jump down to scan headings, scroll the bar to gauge length, scroll back up, and only then commit to reading.

If your article doesn’t survive that scan, it doesn’t get read. The encouraging news is that “surviving the scan” is mostly a structural problem, not a writing one.

1. Front-load the thesis

The first sentence is the only sentence you can guarantee gets read. It should answer: what is this article about, and why should I keep going? Burying the lede past a paragraph of throat-clearing is the single most common failure mode of essays that “didn’t take off.”

Compare:

I’ve been thinking about how people read on screens lately, ever since I noticed that…

vs.

People scan first and read second. The article that survives that first scan is the one that gets read.

The second version costs you the warm-up. It buys you the reader.

2. Scannable headings

Your headings should make sense read in isolation. A reader scrolling past should be able to reconstruct the article’s argument from the headings alone. “A note on history” is decorative; “Why the Greek alphabet won” is structural.

The test: copy your article’s headings into a new document. Do they form a coherent outline?

3. The 38-rem column

Comfortable reading hits 60–75 characters per line. At a body font size of 17–18 px, that’s 38–42 rem. Wider columns force the eye to track too far horizontally and lose the line break; narrower columns produce too many line breaks per minute and the eye fatigues.

The web’s instinct to fill the viewport horizontally is a UI-design instinct, not a reading instinct. Reading wants the column to be small.

4. Small inline contrast

Italic and bold are the two pieces of structural emphasis that survive the scan. They mark this is a definition, this is the key word, this is the contradiction I’m flagging.

Use them sparingly. A page with five bolded phrases pulls the eye to all five and the eye trusts none of them. A page with one bolded phrase per scroll-screen makes that phrase the load-bearing claim.

5. Lists for parallel structure

Lists are good when items are parallel:

Subject parallel. “Three things designers get wrong about color.”
Form parallel. Each item begins with a verb in the same tense.
Length parallel. Items don’t vary by 10x in word count.

Lists are bad when forced. If your three “items” are really one big idea broken into three sentences, write the sentences. The reader will follow.

6. Code blocks as visual anchors

Even a non-programmer reader uses code blocks as scroll waypoints. The reader scrolls, sees a code block, registers “technical content here,” and may or may not stop. Make sure the prose around your code block stands on its own — readers who skip code should still come away with the argument.

This means: no “as you can see in the code above” phrasing. Restate the point in prose immediately after.

7. Pull quotes earn their keep

A pull quote that just repeats a sentence from the body is decorative. A pull quote that isolates a claim and gives the eye a place to land while scrolling is structural.

The unspoken floor for “comfortable long-form reading” is closer to 8–13:1 contrast — well above WCAG AA.

That’s a pull quote. It commits to a claim, in language that survives being lifted out of context.

8. End with a turn

The final paragraph should turn the article into a question, a recommendation, or a stake. Don’t summarize what you just said — the reader was there. Move the conversation forward.

This series ran three parts: the substrate (subpixels and hinting), the chemistry (color and dark mode), and the choreography (how the eye moves through long-form). The next move, for any one essay, is yours: open the document and look at it for thirty seconds without reading it. What did your eye do? That’s what your reader is doing too.

Reading on screens, part 2: color, contrast, and dark mode

2024-07-22T00:00:00Z

The default body color of every browser is #000000 on #ffffff. Maximum contrast, right? That’s actually the problem.

Pure black is a glare problem

Sunlight hitting paper bounces back diffusely; sunlight (or backlight) coming through a screen punches into your eye directly. When the brightest part of the screen is pure white and the darkest is pure black, the dynamic range your eye is asked to process is roughly the same as standing in a snowfield staring at a wet rock. Reduce both ends and the eye relaxes.

Most production type uses near-white background (#fcfcfa, #f8f7f4, the famous #fdfcf8 of paperback novels) and near-black foreground (#1f1f1f, #1c1917):

Pure black on pure white
The default. Notice how your eye flickers around the edges as it tries to settle on the column.

Warm cream on deep ink
Same letterforms; the eye lands and stays. The contrast ratio is still 13:1 — well above WCAG AAA.

Same words, two palettes. Read each side for thirty seconds and you'll feel the difference.

WCAG ratios are necessary but not sufficient

WCAG AA wants 4.5:1 for body text; AAA wants 7:1. Hit those, and you’ve cleared the accessibility bar. You have not necessarily produced text that’s pleasant to read for an hour.

The unspoken floor for “comfortable long-form reading” is closer to 8–13:1 with off-white backgrounds:

Foreground	Background	Ratio	Verdict
`#000`	`#fff`	21.0	Glare-prone
`#1c1917`	`#fdfcf8`	16.7	Cream-paper feel
`#44403c`	`#fdfcf8`	8.9	Pleasant for body
`#78716c`	`#fdfcf8`	4.7	Edge of legibility

The 4.7 row meets WCAG AA. Don’t put your body text there.

Dark mode is its own problem

Inverting the colors does not, in fact, give you a dark mode. You have to redesign:

Reduce, don’t invert. A dark background fights pure white text just as hard as a white background fights black. Pull both toward grey.
Desaturate accent colors. The #c2410c amber that anchors a light theme will burn in a dark one. Use a lighter, slightly cooler tone (#fb923c).
Watch your borders. A 1px hairline that read as “subtle separator” on cream paper will vanish on a dark background. Either make it lighter relative to the bg, or replace it with negative space.
Think about your shadows. They mostly stop working. Borders or elevation tokens replace them.

Pure white on pure black
Fonts visibly bleed into the background. The accent color burns.

Off-white on warm ink
Your eye relaxes. The accent reads as warm, not neon.

Same idea, dark side. Notice how the right column doesn't shimmer.

Contrast for code

Code blocks are often where dark-mode design falls apart, because syntax highlighting was designed for light backgrounds. Pull the comment-grey up, the keyword color toward warmer tones, and the background slightly darker than the body so the block reads as a distinct surface:

```css: root[data-theme=”dark”] {

–code-bg: #161412; /* darker than body’s #1c1917 / –code-text: #e5e5e5; –syn-keyword: #fb923c; / warm, not neon / –syn-string: #84cc16; / lime, not pure green / –syn-comment: #78716c; / up from #57534e */ }


Final part: long-form reading patterns. How people actually move through 2,000 words.

Reading on screens, part 1: display fundamentals

2024-07-08T00:00:00Z

Before we can reason about line-height or letter-spacing, we need to be honest about what we’re rendering into. A “pixel” is a triplet of red-green-blue subpixels arranged in a known geometry, and most operating systems exploit that geometry to triple horizontal resolution at the cost of color fringing.

RGB stripe vs. PenTile vs. nothing

Desktop monitors are overwhelmingly RGB stripe — three vertical bars per logical pixel:

[R][G][B]   [R][G][B]   [R][G][B]
[R][G][B]   [R][G][B]   [R][G][B]

OLED phones often use PenTile layouts where greens outnumber reds and blues. The “300 PPI iPhone display” and the “300 PPI laptop display” do not have the same effective resolution for thin vertical strokes, and your fonts will look subtly different on each.

When the OS draws a glyph, it can target subpixel positions:

fn draw_stem(x: f32, y: f32, height: f32) {
    // x is fractional in physical pixels — 0.33 lights the green
    // sub-pixel only; 0.67 lights blue. Whole numbers light all three.
    rasterize(x, y, /*width=*/1.0, height);
}

The catch: subpixel rendering only works when you know the subpixel layout. Rotate the display 90° and the technique inverts; on a phone in landscape it usually disables itself.

Anti-aliasing

A glyph’s edge rarely lands on a pixel boundary. Anti-aliasing samples the glyph’s coverage of each pixel and renders accordingly:

Coverage	Pixel value
0%	background
25%	0.75 background + 0.25 ink
50%	0.50 / 0.50
75%	0.25 / 0.75
100%	ink

The “fuzziness” people complain about with non-Retina displays is anti-aliased coverage doing exactly what it’s supposed to do, just at a resolution where 25% coverage is half a millimetre wide and your eye notices.

Hinting

Hinting is the font’s attempt to round its outlines to the pixel grid so that a stem ends exactly at a pixel boundary. Done well, hinting makes 12px Verdana look like a deliberate design choice instead of a bitmap accident. Done badly — or skipped entirely on a Mac, which doesn’t hint — it’s the difference between text that “snaps” into shape at small sizes and text that visibly blurs.

Most modern setups have given up on hinting because Retina-class densities (>200 PPI) make pixel-level snapping invisible. Outside that regime — every CRT, every old laptop, every projector — hinting is still load-bearing, and your designer-mac-rendered comp will not match.

What it means for the CSS you write

You don’t get to control any of this. You can decide whether to hide it or design with it in mind:

Choose a body font that ships well-hinted (Charter, Source Serif, Inter) over one that doesn’t (most decorative serifs).
Avoid 1px-wide vertical lines next to text — they alias differently than the glyph stems do.
Test on a non-Retina monitor at least once. The rendering you see is what 30% of your audience sees.

Next part: color, contrast, and the dark-mode rabbit hole.