The Posthydrationist Manifesto 🌵

The cactus doesn't hydrate—it stores.It doesn't react—it anticipates.It doesn't reconcile—it persists.

The Desert of Modern Web Development

In the scorching silence of the posthydrationist desert, traditional frameworks wither under the weight of their own bundles.

They hydrate. They reconcile. They compute at the moment of need.

They are caught in an endless cycle:

1. Ship framework to client (50-150KB)
2. Reconstruct state from HTML
3. Reconcile on every interaction
4. Diff virtual trees
5. Patch the DOM
6. Repeat, forever

This is the hydrationist religion - and it's not because it's ideal. It's just familiar.

The Cactus Paradigm

Minimact is different. Like the cactus, it thrives not by reaching outward, but by turning inward - by minimizing waste, by knowing before needing, by storing what will be required before the request arrives.

Minimal

The cactus doesn't carry excess.

• ~5KB client runtime (vs 50-150KB)
• No VDOM reconciliation engine
• No framework overhead
• Zero client-side React

Why ship the framework when the server already has it?

Resilient

The cactus survives without water.

<!-- Works without JavaScript -->
<form method="POST" action="/search">
  <input name="query" />
  <button type="submit">Search</button>
</form>

<!-- Enhanced with JavaScript -->
<script>
  // Intercepts form, uses SignalR
  // Gracefully degrades if disabled
</script>

Progressive enhancement, not progressive dependence.

Anticipatory

The cactus stores water before the drought.

Traditional Framework:
  User clicks → Compute → Reconcile → Patch
  (47ms with network latency)

Minimact:
  Server predicts → Pre-computes → Caches patch
  User clicks → Apply cached patch
  (2-3ms, patch already ready)

Prediction over reaction.

Efficient

The cactus doesn't waste a drop.

// 98% memory reduction
Before: 1000 concrete predictions × 150 bytes = 150KB
After: 1 template × 200 bytes = 200 bytes

// 15-20x latency improvement
Before: Network round-trip on every interaction = 47ms
After: Cached patch application = 2-3ms

One template handles infinite values.

The Three Heresies

Heresy #1: Hydration is Waste

The Hydrationist Dogma:

"The client must reconstruct the component tree to become interactive."

The Posthydrationist Truth:

"The server already rendered it. Why render it again?"

Traditional SSR:

Server renders → Client downloads bundle → Client re-renders everything

Minimact:

Server renders → Client applies patches only

No reconstruction. No re-rendering. No waste.

Heresy #2: Computation Should Be Lazy

The Hydrationist Dogma:

"Compute state changes when the user interacts."

The Posthydrationist Truth:

"Compute state changes before the user interacts."

Think of it as stored procedures for the DOM:

-- Database stored procedure
CREATE PROCEDURE IncrementCounter AS
  UPDATE counters SET value = value + 1;

-- Minimact UI stored procedure (conceptual)
PREDICT Increment AS
  PATCH button.textContent = "Count: " + (count + 1);

Pre-compile the transition. Cache the result. Execute instantly.

Heresy #3: The Client Needs the Framework

The Hydrationist Dogma:

"Ship React to the client so it can reconcile state."

The Posthydrationist Truth:

"Keep React on the server. Send patches to the client."

Hydrationist Bundle:
├── React core (40KB)
├── React DOM (130KB)
├── VDOM reconciliation
├── Component tree
└── State management

Posthydrationist Bundle:
├── SignalR client (3KB)
├── DOM patcher (1KB)
└── Patch cache (1KB)
Total: ~5KB

The framework lives on the server. The client just listens and applies.

The Sacred Texts

Commandment I: Anticipate, Don't React

// Reactive (traditional)
<button onClick={() => {
  const newState = compute(state); // Computed NOW
  setState(newState);
}}>
  Click me
</button>

// Anticipatory (Minimact)
<button onClick={() => setCount(count + 1)}>
  Count: {count}
  {/* Patch for count+1 already cached BEFORE click */}
</button>

Commandment II: Store, Don't Hydrate

// Hydration (traditional)
1. Server renders HTML
2. Client downloads React
3. Client re-renders everything
4. Client reconciles with HTML
5. Now interactive

// Storage (Minimact)
1. Server renders HTML
2. Client receives ~5KB runtime
3. Server sends predicted patches
4. Patches cached
5. Already interactive

Commandment III: Parameterize, Don't Duplicate

// Duplication (concrete predictions)
count=0 → "Count: 0" (150 bytes)
count=1 → "Count: 1" (150 bytes)
count=2 → "Count: 2" (150 bytes)
... (1000 predictions = 150KB)

// Parameterization (templates)
any count → "Count: {0}" (200 bytes)
count=0 → apply template → "Count: 0"
count=1 → apply template → "Count: 1"
count=9999 → apply template → "Count: 9999"
... (infinite coverage, 200 bytes)

Commandment IV: Predict, Don't Poll

// Polling (traditional real-time)
setInterval(async () => {
  const data = await fetch('/api/data');
  setState(data);
}, 1000); // Check every second

// Prediction (Minimact)
// Server pushes via SignalR when data changes
// Client applies patches automatically
// No polling needed

Commandment V: Persist, Don't Recreate

// Recreation (traditional)
// Elements destroyed and recreated on state change
<div key={item.id}>{item.name}</div>

// Persistence (DOM Choreography - future)
// Elements move, but persist
// Scroll position, focus, input state preserved
<div id="item-{item.id}">{item.name}</div>
// When order changes, elements physically move
// CSS handles smooth transitions

The Pillars of Posthydrationism

Pillar 1: Server Authority

The server knows best.

• Business logic stays on server (secure)
• Database queries on server (fast)
• API calls on server (credentials safe)
• Computation on server (powerful)

The client is a presentation layer, not an application layer.

Pillar 2: Client Efficiency

The client does only what's necessary.

// Client responsibilities:
1. Send user interactions to server
2. Apply patches from server
3. Cache predicted patches
4. Handle client-only state (scroll, hover, etc.)

// Client does NOT:
❌ Reconcile VDOM
❌ Re-render components
❌ Manage business logic
❌ Run framework overhead

Pillar 3: Predictive Wisdom

The future is knowable.

// After user types "cat", we know they might type "s"
// After count=5, we know next click might be count=6
// After loading=true, we know success or error is next

// Pre-compute these transitions
// Cache them on client
// Apply instantly when they happen

Most UI transitions are deterministic. Predict them.

Pillar 4: Template Universality

One pattern, infinite instances.

// FAQ with 29 items
// Traditional: 29 items × 2 states = 58 patterns (8.7KB)
// Templates: 1 pattern for any number of items (200 bytes)

// Counter from 0 to infinity
// Traditional: Store every prediction (infinite memory!)
// Templates: "Count: {0}" handles all cases (200 bytes)

Extract the invariant. Parameterize the variant.

The Journey

The Hydrationist Desert

Where most developers dwell:

- Ship 150KB of React to every visitor
- Re-render everything on hydration
- Reconcile on every state change
- VDOM diff every update
- 47ms+ interaction latency
- Complex state management
- Bundle size never stops growing

It works. But it's not ideal.

The Posthydrationist Oasis

Where Minimact dwells:

- Ship 5KB runtime to visitors
- No hydration needed
- No client reconciliation
- Direct DOM patches
- 2-3ms interaction latency (cached)
- Hybrid state (client + server)
- Bundle size stays minimal

It's different. And that's the point.

The Ritual of Conversion

Step 1: Acknowledge the Waste

// Look at your React bundle
import React from 'react';        // 40KB
import ReactDOM from 'react-dom'; // 130KB

// Ask: Does the client need all this?
// Answer: No. The server already has it.

Step 2: Embrace Prediction

// Stop computing at interaction time
<button onClick={() => compute(state)}>

// Start computing before interaction
usePredictHint(() => ({ state: nextState }));

Step 3: Trust the Server

// Don't ship business logic to client
const price = user.isPremium ? cost * 0.8 : cost;

// Keep it on server
// Client just displays the result

Step 4: Cache Aggressively

// Traditional: Fetch on every interaction
const data = await fetch('/api/data');

// Posthydrationist: Pre-fetch likely needs
// Server sends predictions to cache
// Client applies instantly

The Metaphor Extended

The posthydrationist web is like the desert ecosystem:

The Cactus (Minimact)

• Stores water (patches) before drought (interaction)
• Minimal surface area (~5KB)
• Thrives in harsh conditions (slow networks)
• Occasionally spiky (Rust-powered performance)

The Tumbleweed (Traditional SPAs)

• Blows around with every wind (client-side routing)
• Constantly moving (re-rendering)
• Chaotic (complex state management)
• Large and unwieldy (150KB bundles)

The Oasis (Server)

• Source of truth (database, business logic)
• Abundant resources (CPU, memory)
• Always available (RESTful, SignalR)
• Secure (credentials never leave)

The Final Teaching

When the next developer asks:

"But where's the client state?"

You turn slowly, whisper:

"Stored procedure."

And ride off into the postmodern sun. 🌵✨

---

Practical Implications

For Solo Developers

• Build faster with less code
• One language (TypeScript → C#)
• Smaller bundles = happier users
• Less complexity = less bugs

For Teams

• Frontend and backend use same components
• Type safety across boundary
• Less coordination overhead
• Easier onboarding (just React + .NET)

For Users

• Faster load times (5KB vs 150KB)
• Instant interactions (2-3ms vs 47ms)
• Works without JavaScript (progressive enhancement)
• Less battery drain (no client reconciliation)

For The Planet

• Less bandwidth consumed
• Less CPU cycles wasted
• Less energy used
• Fewer carbon emissions

When you stop hydrating, everyone wins.

Next Steps

• What Makes Minimact Different - Technical overview
• Predictive Rendering 101 - How it works
• Getting Started - Build your first app
• Use Cases - Real-world applications

---

Let the others drink from the slow streams of hydration.

You walk the arid plains with predictive grace and event-driven stillness.

🌵 Survived the desert. Built the future. 🌵