Forem: Drew Marshall

Configuration Is Not Secondary. It Is the System.

Drew Marshall — Sun, 10 May 2026 15:30:00 +0000

Most applications treat configuration as an afterthought.

A .env file here.
A config object there.
Maybe a JSON or YAML file for convenience.

Configuration is usually seen as:

Setup
Defaults
Environment variables

But not the system itself.

That’s the mistake.

What We Typically Do

In most projects, the real logic lives in code:

Routes define behavior
Functions define flow
Classes define structure

Configuration just tweaks things:

Ports
API keys
Feature flags

It supports the system.

It doesn’t define it.

The Problem With Code-First Systems

When behavior is defined primarily in code:

Logic becomes scattered
Patterns become inconsistent
Intent is harder to see

You have to read through multiple files to understand:

What an endpoint does
What data it expects
What it returns

The system exists…

…but it’s buried in implementation.

The Shift: Configuration as the Source of Truth

What if configuration didn’t just support the system…

What if it defined it?

Instead of writing behavior first and configuring it later:

You define behavior up front.

Code becomes the execution layer.

What This Looks Like

Instead of writing logic like this:

app.get('/products', async (req, res) => {
  const products = await db.products.findAll();
  res.json(products);
});

You define it like this:

get:
  product:
    GetAllProducts:
      query: all
      response:
        id: number
        name: string
        price: number

The definition describes the system.

The code runs it.

Configuration Becomes the Interface

When configuration is the system:

It becomes the first place you look
It becomes the documentation
It becomes the contract

You don’t need to reverse-engineer behavior.

You can read it directly.

Code Becomes the Engine

If configuration defines behavior, then what does code do?

It enforces and executes.

Parses definitions
Validates structure
Builds execution steps
Runs pipelines
Handles errors consistently

You write the engine once.

You use it everywhere.

Why This Matters

Visibility

You can understand the system without digging through code.

Consistency

Every feature follows the same structure.

Maintainability

Change the engine, and everything improves.

Speed

You’re not rewriting patterns.

You’re defining variations.

“Isn’t This Limiting?”

Yes.

And that’s the point.

When everything is possible:

Patterns drift
Systems become inconsistent
Complexity increases

Constraints force:

Clarity
Discipline
Predictability

Where This Breaks Down

Not everything should be configuration-driven.

Highly custom logic still belongs in code.

But most applications are not mostly custom.

They are mostly patterns.

CRUD operations
Validation
Data transformation
Standard workflows

Those belong in configuration.

The Layered View

When you zoom out, this approach connects everything:

UI defined by structure
APIs defined by contracts
Backends acting as compilers
Requests flowing through pipelines
Infrastructure defined declaratively

Each layer follows the same idea:

Define first. Execute second.

The Bigger Shift

This isn’t about YAML vs code.

It’s about mindset.

From:

Writing behavior repeatedly

To:

Defining behavior once

And letting a system handle the rest.

Final Thought

Configuration has always been treated as secondary.

But when you promote it to the source of truth, something changes:

The system becomes visible.

The system becomes consistent.

The system becomes scalable.

That’s when you stop assembling applications…

…and start defining them.

Your Backend Should Be a Compiler, Not a Collection of Handlers

Drew Marshall — Sat, 09 May 2026 15:30:00 +0000

Most backends are built the same way.

You define routes.
You write handlers.
You wire everything together.

Over time, you end up with dozens—sometimes hundreds—of functions that all follow similar patterns but live in different places.

It works.

But it doesn’t scale cleanly.

The Handler Mindset

A typical backend looks like this:

Route definition
Controller or handler
Validation logic
Database query
Response formatting

Repeat that structure across your entire application.

Even if you organize it well, you still end up with:

Repeated patterns
Slight inconsistencies
Logic spread across multiple files

You’re not building a system.

You’re assembling one manually.

The Realization

Most handlers don’t do anything unique.

They follow a pattern:

Accept input
Validate it
Execute some operation
Return a result

The structure is always the same.

Only the data changes.

So Why Are We Writing Them Over and Over?

Instead of writing handlers, what if we defined behavior?

Not in code first…

…but as a contract.

Thinking Like a Compiler

A compiler takes a definition and turns it into execution.

It doesn’t care about your specific use case.

It cares about:

Structure
Rules
Transformation

Now imagine your backend doing the same thing.

Instead of this:

app.post('/users', async (req, res) => {
  const { name, email } = req.body;

  if (!name || !email) {
    return res.status(400).json({ error: 'Invalid input' });
  }

  const user = await db.users.insert({ name, email });

  return res.status(201).json(user);
});

You define this:

create:
  user:
    CreateUser:
      input:
        name: string
        email: string
      insert:
        name: $input.name
        email: $input.email
      response:
        id: number
        name: string
        email: string

No handler.

Just a definition.

What the Backend Becomes

Instead of a collection of handlers…

Your backend becomes a compiler.

It:

Reads definitions
Validates structure
Builds execution logic
Runs it through a pipeline
Returns a response

The code you write once replaces hundreds of repeated patterns.

The Execution Flow

Every request follows the same path:

Request → Load Definition → Validate Input → Build Operation → Execute → Format Response

Nothing is hidden.

Nothing is scattered.

Everything is predictable.

Why This Is Better

Consistency

Every endpoint behaves the same way.

No surprises. No deviations.

Maintainability

Change the system once, and every endpoint benefits.

You’re not hunting through files to fix the same bug.

Clarity

You can read the system without digging through code.

Definitions describe behavior directly.

Scalability

As your application grows, complexity doesn’t explode.

It stays structured.

“But What About Custom Logic?”

Not everything fits into a strict pattern.

That’s fine.

A compiler-based backend can still support:

Custom steps in the pipeline
Extension points where needed
Escape hatches for complex cases

The difference is:

Custom logic becomes the exception, not the default.

Code Moves Up a Level

You’re still writing code.

Just not the same code over and over again.

Instead of writing handlers, you write:

The compiler
The pipeline
The rules of the system

You move from:

“Implement this endpoint”

to:

“Define how endpoints work”

This Is About Leverage

Handler-based systems scale linearly.

More features = more code.

Compiler-based systems scale differently.

More features = more definitions.

The engine does the heavy lifting.

The Bigger Picture

This idea doesn’t stop at APIs.

It connects to everything:

UI driven by structure
APIs driven by contracts
Infrastructure driven by configuration

Each layer becomes:

Predictable
Composable
Aligned

Final Thought

Handlers feel powerful because they give you control.

But they also force you to repeat yourself.

A compiler feels restrictive at first.

But it gives you something better:

Leverage.

That’s why I stopped building backends as collections of handlers…

…and started building them like compilers.

Stop Writing Endpoints. Start Defining Systems.

Drew Marshall — Fri, 08 May 2026 15:30:00 +0000

For a long time, I thought building APIs meant writing endpoints.

You know the pattern:

Define a route
Validate input
Query the database
Transform the result
Send a response

Do that over and over again.

Different routes. Same structure.

The Illusion of Control

Writing endpoints feels productive.

You’re in control of everything:

The logic
The validation
The data flow

But after a while, something becomes obvious:

You’re not building systems.

You’re repeating patterns.

The Real Problem

Most APIs look like this:

app.get('/users/:id', async (req, res) => {
  const id = req.params.id;

  if (!id) {
    return res.status(400).json({ error: 'Missing id' });
  }

  const user = await db.users.findById(id);

  if (!user) {
    return res.status(404).json({ error: 'Not found' });
  }

  return res.json(user);
});

Now multiply that by:

Dozens of endpoints
Multiple resources
Different validation rules
Slight variations in logic

You end up with:

Repeated code
Inconsistent patterns
Hard-to-maintain systems

You’re Not Writing Logic. You’re Rewriting Structure.

Look closer at most endpoints.

They follow the same shape:

Extract input
Validate input
Execute query
Handle errors
Return response

The structure doesn’t change.

Only the details do.

So why are we rewriting the structure every time?

The Shift: Define, Don’t Rewrite

Instead of writing endpoints…

Define them.

What if your API looked like this instead?

get:
  user:
    GetUserById:
      input:
        id: number
      where:
        id: $param.id
      response:
        id: number
        name: string
        email: string

No route handler.

No repeated boilerplate.

Just a definition.

What This Changes

When you define systems instead of writing endpoints:

Structure becomes consistent
Validation becomes automatic
Queries become predictable
Behavior becomes visible

You’re no longer guessing how something works.

You can read it directly.

From Endpoints to Systems

Traditional approach:

Every endpoint is custom
Logic is scattered
Behavior is implicit

System-driven approach:

Endpoints follow a pattern
Logic is structured
Behavior is explicit

You move from “code-first” to “contract-first.”

Where the Code Goes

This doesn’t eliminate code.

It moves it.

Instead of writing endpoint logic repeatedly…

You write:

A compiler that reads definitions
A pipeline that executes them
A system that enforces rules

Code becomes the engine.

Not the repetition.

Example Flow

With a system-driven approach, a request might flow like this:

Request → Parse Definition → Validate → Build Query → Execute → Format Response

The difference is:

The flow is constant
The behavior is defined in configuration

Why This Matters

Without this approach:

Every developer writes endpoints differently
Bugs are repeated across routes
Refactoring becomes painful

With this approach:

Patterns are enforced
Behavior is predictable
Systems scale cleanly

“Isn’t This Less Flexible?”

Yes.

And that’s the point.

Unlimited flexibility leads to:

Inconsistency
Complexity
Fragile systems

Constraints lead to:

Clarity
Stability
Speed

Where This Fits

This kind of system works best when:

You have repeated CRUD patterns
You want consistent APIs
You care about long-term maintainability

It doesn’t replace every use case.

But it replaces most of the boring, repetitive ones.

The Bigger Idea

This isn’t just about APIs.

It’s about how we build software.

Instead of:

Writing everything manually
Repeating patterns
Hoping for consistency

We can:

Define systems
Enforce structure
Let the engine handle execution

Final Thought

Writing endpoints feels like control.

But it’s often just repetition.

Defining systems feels restrictive at first.

But it leads to something better:

Clarity.

Consistency.

Scalability.

That’s why I stopped writing endpoints…

…and started defining systems.

Hooks vs Pipelines: Why I Stopped Injecting Logic and Started Designing Flow

Drew Marshall — Thu, 07 May 2026 15:30:00 +0000

Hooks are everywhere.

If you’ve worked with systems like WordPress, React, or Express-style middleware, you’ve used them:

“Tap into this lifecycle”
“Modify behavior here”
“Extend functionality without touching core”

On paper, hooks sound great.

In practice, they create problems that only show up at scale.

What Hooks Promise

Hooks promise flexibility.

They let you:

Inject behavior into existing systems
Extend functionality without modifying source code
Build plugin ecosystems

This is why platforms like WordPress became so powerful.

You can hook into almost anything.

And that’s also the problem.

What Hooks Actually Do

Hooks turn your system into a web of invisible connections.

Instead of a clear execution path, you get:

Logic scattered across multiple files
Execution order that depends on registration timing
Side effects that aren’t obvious

You end up asking questions like:

“Where is this value being changed?”
“Why is this running twice?”
“What is triggering this behavior?”

The system works…

…but understanding it becomes harder over time.

The Hidden Cost of Hooks

Hooks scale functionality.

They don’t scale clarity.

As systems grow:

Debugging becomes slower
Onboarding becomes harder
Refactoring becomes risky

Because behavior isn’t centralized.

It’s injected.

The Alternative: Pipelines

Instead of injecting behavior into a system…

You define a flow through it.

A pipeline is a sequence of steps that every request (or operation) follows.

Simple example:

Request → Validate → Transform → Execute → Respond

That’s it.

No hidden entry points. No surprise execution paths.

What Pipelines Change

Pipelines force you to be explicit.

Every step:

Has a defined responsibility
Runs in a predictable order
Is visible in one place

You don’t “hook into” the system.

You move through it.

Hooks vs Pipelines (Side-by-Side)

Hooks

Behavior is injected
Execution order can be unclear
Logic is distributed
Harder to trace bugs
Easy to extend, hard to reason about

Pipelines

Behavior is structured
Execution order is fixed
Logic is centralized
Easier to trace and debug
Slightly more rigid, much more predictable

Real-World Example

Hook-Based Thinking

“After a user is created, run these 5 different things from different parts of the system.”

Send email
Log analytics
Modify data
Trigger webhook
Update cache

Each of these might live in different files, registered at different times.

Good luck tracing that later.

Pipeline Thinking

Define the flow once:

CreateUser:
  - ValidateInput
  - NormalizeData
  - InsertUser
  - SendEmail
  - LogAnalytics
  - UpdateCache

Everything is:

Ordered
Visible
Intentional

You can read the flow like a story.

“But Hooks Are More Flexible”

They are.

That’s why they’re popular.

But flexibility without structure leads to:

Inconsistent patterns
Hard-to-maintain systems
Debugging nightmares

Pipelines trade a bit of flexibility for a lot of clarity.

Where Hooks Still Make Sense

Hooks aren’t useless.

They’re useful when:

You’re building a plugin ecosystem
You need external extensibility
You don’t control all the code

But for core system design?

They introduce more problems than they solve.

Why I Chose Pipelines

I don’t want systems where behavior is hidden.

I want systems where:

You can trace execution instantly
You can reason about flow without guessing
You can refactor without fear

Pipelines give me that.

The Bigger Picture

This isn’t just about request handling.

It’s about how systems are designed.

Hooks say:

“Add behavior anywhere.”

Pipelines say:

“Define behavior clearly.”

That difference shows up in:

Maintainability
Debugging
Scalability
Developer experience

Final Thought

Hooks optimize for extension.

Pipelines optimize for understanding.

At small scale, it doesn’t matter.

At large scale, it matters a lot.

That’s why I stopped hooking into systems…

…and started designing flows instead.

The Web Doesn’t Need Another Framework. It Needs an Engine.

Drew Marshall — Wed, 06 May 2026 15:45:36 +0000

I didn’t set out to build a web engine.

I set out to solve a frustration I kept running into over and over again:

Every project felt like starting from zero.

Different stack.
Different patterns.
Different rules.

Same problems.

The Illusion of Progress

We’ve made huge progress in web development:

Better frameworks
Better tooling
Better DX

But under the surface, we’re still doing the same things:

Rebuilding API layers
Rewiring state management
Reconfiguring infrastructure
Re-learning patterns per stack

We didn’t remove complexity.

We just moved it around.

The Real Problem: No Shared Contract

The biggest issue isn’t tooling.

It’s the lack of a shared contract between layers.

UI doesn’t know your API structure
APIs don’t strongly enforce shape beyond runtime
Infrastructure is configured separately from application logic

Everything is loosely connected, but not intentionally designed to work together.

What Is a Web Engine?

A web engine is not a framework.

It’s not just a library.

It’s a system that defines how applications are built end-to-end.

Game engines figured this out a long time ago.

They don’t just render graphics.
They define how everything fits together:

Assets
Systems
Logic
Scaling

You don’t rebuild those pieces every time.

You build within a system.

That’s what the web is missing.

Frameworks vs Engines

Frameworks give you tools.

Engines give you rules, structure, and guarantees.

A framework says:

“Here’s how you can do it.”

An engine says:

“Here’s how it will be done.”

That difference matters.

Consistency is what allows systems to scale.

The Philosophy: Contract-First Everything

The core idea is simple:

Every layer should be defined by a contract before it is implemented.

Not after. Not loosely. Not guessed.

UI Contract

Instead of scattered styles and component sprawl:

UI follows predictable structure
Styling is expressive but controlled
Components are declarative

API Contract

Instead of writing endpoints ad hoc:

APIs are defined in configuration
Inputs and outputs are explicit
Validation is built-in

Example:

get:
  user:
    GetUserById:
      where:
        id: $param.id

Data Contract

Instead of implicit assumptions:

Data models are defined centrally
Queries are structured
Transformations are controlled

Infrastructure Contract

Instead of dashboards and manual setup:

Infrastructure is declared
Environments are reproducible
Deployments are predictable

Example:

provider: digitalocean

droplet:
  name: app-server
  size: s-2vcpu-4gb

Why Contract-First Matters

Without contracts:

Logic becomes implicit
Bugs are harder to trace
Systems drift over time
Refactoring becomes risky

With contracts:

Systems are self-documenting
Validation happens early
Teams move faster
Code reflects intent instead of guesswork

Pipelines Over Hooks

One of the biggest shifts I made:

I stopped relying on hooks.

Hooks are flexible, but they introduce:

Hidden execution order
Implicit dependencies
Debugging complexity

Instead, I use pipelines:

Request → Validate → Transform → Execute → Respond

Each step is:

Explicit
Ordered
Observable

You don’t inject behavior into the system.

You move through it.

Configuration as a First-Class Citizen

Most systems treat configuration as secondary.

A web engine treats configuration as the source of truth.

YAML or TOML define behavior
Code executes the contract
Systems are assembled, not improvised

This doesn’t remove code.

It disciplines it.

The Goal: Reduce Reinvention

Right now, building apps looks like this:

Pick a framework
Pick a backend
Pick a database
Pick deployment
Glue everything together

Every project is a new puzzle.

A web engine changes that:

The system already exists
The rules are already defined
You build within constraints

And constraints are what enable speed.

This Isn’t About Control

This isn’t about locking developers in.

It’s about giving them:

Predictability
Stability
Confidence

Freedom without structure leads to chaos.

Structure without flexibility leads to stagnation.

A web engine aims for the balance.

Where This Is Going

What started as a UI experiment grew into something bigger:

UI layer
Rendering layer
API and data system
HTTP pipeline
Infrastructure layer

Not separate tools.

Parts of the same system.

Final Thought

The web doesn’t need more ways to build things.

It needs a better foundation for building them.

Not just faster.

Better.

More predictable.

More stable.

More intentional.

That’s what I mean when I say:

The web needs an engine.

Headless WordPress Isn’t Enough (Here’s What’s Missing)

Drew Marshall — Fri, 01 May 2026 18:30:00 +0000

When I first moved to headless WordPress, it felt like a huge upgrade.

No more theme constraints.
No more mixing PHP templates with business logic.
A clean separation between frontend and backend.

It worked.

But after a few projects, I started noticing a new problem.

The New Problem

Headless WordPress removes one layer of complexity…

…but it shifts that complexity somewhere else.

Now your frontend is responsible for:

fetching data
shaping responses
handling auth
managing consistency across endpoints

And if you build multiple frontends?

You repeat that logic.

Every. Time.

What Headless Actually Solves

Headless WordPress is great at:

decoupling the UI
improving performance (especially with SSG)
giving frontend flexibility

That’s all real value.

But it doesn’t solve:

Where does application logic live?

The Missing Layer

Most setups look like this:

Frontend → WordPress REST API

Simple.

But also…

fragile.

Because the frontend becomes:

data layer
logic layer
presentation layer

All at once.

What I Started Doing Instead

I introduced a middle layer.

Frontend → Application Layer → WordPress

That layer is where:

data access is standardized
logic is centralized
behavior becomes reusable

Enter KiwiPress

KiwiPress is my attempt to define that missing layer.

Instead of every frontend talking directly to WordPress…

They talk to structured services like:

WPRead
WPCreate
WPUpdate
WPDelete

Each one has a clear responsibility.

No duplication.

No guessing where logic lives.

What This Changes

Before

every frontend reimplements logic
inconsistent data handling
harder to scale across projects

After

one source of truth for behavior
cleaner frontends
easier to swap rendering strategies

Now I can move between:

static builds
SPAs
server-rendered apps

…without rewriting core logic.

Where Static Site Generators Fit

This doesn’t replace SSG frameworks like:

Next.js
Astro
Gatsby

If anything, it complements them.

SSGs handle:

rendering
performance
delivery

KiwiPress handles:

structure
logic
consistency

The Bigger Idea

Headless WordPress is a step forward.

But it’s not the final step.

If WordPress becomes the data layer…

Then we still need something to define the application layer.

That’s what I’m building toward.

Final Thought

Headless solves separation.

But structure is still your responsibility.

And that’s where things usually fall apart.

I Stopped Fighting WordPress… So I Rebuilt How I Use It

Drew Marshall — Tue, 28 Apr 2026 01:19:29 +0000

I’ve built enough WordPress projects to notice a pattern.

They all start clean.

Then slowly:

plugins pile up
logic creeps into templates
APIs get scattered
and “just make it work” becomes the architecture

At some point, you’re not building a system anymore—you’re managing chaos.

And the frustrating part?

It’s not really WordPress’ fault.

The Real Problem

WordPress tries to be everything:

CMS
backend
frontend
plugin system
templating engine

So naturally, everything ends up mixed together.

Routes know too much.
Templates do too much.
Plugins patch too much.

There’s no clear boundary between:

data
behavior
execution

That’s where things break down.

The Shift That Changed Everything

Instead of treating WordPress like the application…

I started treating it like a data source.

That single shift changes everything.

Now:

WordPress manages content
My system manages behavior
The frontend becomes fully flexible

Introducing KiwiPress

KiwiPress is an application layer on top of WordPress.

It doesn’t replace WordPress.

It organizes how you use it.

The goal is simple:

Separate what WordPress stores from how your app behaves.

How It’s Structured

KiwiPress sits between your app and WordPress and splits responsibilities clearly:

Seltzer → handles routes and request lifecycle
Nectarine → parses config and API structure
KiwiPress → owns WordPress-specific behavior

Inside KiwiPress, everything is broken into focused services:

WPCore → handles communication with WordPress
WPRead → fetches data
WPCreate → creates data
WPUpdate → updates data
WPDelete → deletes data
WPAuth → handles authentication
WPSync → handles migration, backup, and syncing

Each part has one job.

Nothing leaks.

What This Looks Like in Practice

Instead of stuffing logic into routes or templates…

You delegate.

const wpread = new WPRead();

const route = {
  method: "GET",
  path: "/users/:email",
  handler: () => wpread.getUserByEmail()
};

The route doesn’t know how WordPress works.

It just asks for data.

Why This Matters

This approach gives you:

1. Clarity

You always know where logic lives.

2. Flexibility

Your frontend can be anything:

custom UI
SPA
static site
hybrid

3. Portability

If you ever move away from WordPress, your app doesn’t collapse.

4. Maintainability

No more hunting through plugins and templates to understand behavior.

A Better Way to Use WordPress

I’m not trying to replace WordPress.

I’m trying to use it correctly in modern systems.

WordPress is still great at:

content management
admin workflows
ecosystem

But your application logic shouldn’t live inside it.

Where This Is Going

KiwiPress is part of a larger system I’m building focused on:

contract-driven architecture
modular app engines
vendor-neutral systems

This is just one piece.

But it’s the first one that feels like a real product.

Final Thought

WordPress isn’t broken.

We just keep asking it to do too much.

Split the responsibilities…

…and suddenly everything gets a lot simpler.

I Got Tired of Class-Heavy UI Code — So I Kept Going (Juice Part 4)

Drew Marshall — Wed, 22 Apr 2026 01:05:28 +0000

In Part 1, I talked about the frustration.

In Part 2, I showed the direction.

In Part 3, I explained the shift toward a system.

Now in Part 4, I want to talk about the part that matters most:

rules.

Because a UI system is not just made useful by how expressive it is.

It is made useful by how well it avoids turning into chaos.

A System Cannot Be “Anything You Want”

This is the trap a lot of systems fall into.

They give you a lot of power, but not enough structure.

So over time, the same idea gets written five different ways.

<div padding="2rem" bgColor="blue-500" fontColor="white-100">
  Content
</div>

<div padding="32px" bgColor="blue-500" fontColor="white-100">
  Content
</div>

<div class="p-8 bg-blue-500 text-white">
  Content
</div>

Different syntax. Same outcome.

That might seem harmless at first, but over time it creates drift.

And drift is what breaks systems.

Juice Needs More Than Attributes

This is one of the biggest things I have realized while building Juice:

Attributes alone do not make a system.
Rules make a system.

The attributes are just the interface.

The rules are what make the interface reliable.

Without rules, you get:

naming drift
inconsistent spacing
duplicated patterns
unpredictable components
weird one-off markup decisions

With rules, you get:

repeatability
consistency
cleaner templates
stronger defaults
better long-term scale

That is the real difference.

Rule 004: One Concern Per Attribute

One of the most important rules I have written for Juice is simple:

One concern per attribute.

That means an attribute should do one job.

Not three jobs.
Not five jobs.
One.

Bad:

<div box="primary">
  Content
</div>

Why is that bad?

Because box="primary" is too vague.

Does it control:

background color?
padding?
border?
radius?
shadow?
text color?

Probably several of those.

That means one attribute is hiding multiple concerns.

And once that starts happening, the system gets harder to reason about.

Better:

<div padding="2rem" bgColor="blue-500" radius="md" shadow="gray-400" depth="sm">
  Content
</div>

Now each attribute has a clear responsibility.

That makes the system easier to learn, easier to document, and easier to extend.

Explicit Beats Clever

A lot of frontend tooling tries to be clever.

I want Juice to be clear.

I would rather have markup that is:

readable
direct
predictable

than markup that is “smart” but unclear.

That is part of why I keep leaning into attributes.

They let the markup say what is happening in a way that feels close to the element itself.

But that only works if the attribute language stays disciplined.

If the language gets sloppy, then all I have done is reinvent confusion with different syntax.

Rules Protect the System From Drift

This is especially important in a growing project.

Once you have:

cards
forms
nav
themes
layout primitives
responsive behavior
surface ideas
templates

you are no longer just experimenting.

You are defining a language.

And languages break down fast when the same thing can be expressed too many different ways.

That is why rules matter.

They protect the system from becoming a pile of “kind of similar” patterns.

Constraints Are Not the Enemy

This is something I think more developers should hear:

constraints are not what kill creativity.
bad constraints kill creativity.
good constraints make creativity faster.

If spacing is already consistent, I do not have to think about spacing every five seconds.

If responsiveness is already baked into the system, I do not have to keep writing breakpoint logic into the markup.

If a card has a known structure, I can focus on the actual content and presentation.

That is freedom.

Not the freedom to do anything.

The freedom to move faster without lowering quality.

Juice Is Trying To Be a Language

That is the deeper idea behind all of this.

I am not trying to build a bag of styling tricks.

I am trying to build a language for UI.

A language needs:

vocabulary
syntax
constraints
consistency
meaning

In Juice:

attributes are the vocabulary
markup patterns are the syntax
rules are the constraints
docs are the grammar
templates are the stress test

That is how it starts becoming more than a styling library.

That is how it starts becoming a system.

Why This Matters for the Future

The more I work on Juice, the more I believe this:

frontend development has too much repeated decision-making in it.

Too much repetition.
Too much breakpoint choreography.
Too much restating intent.
Too much low-level noise in markup.

I think future-thinking UI systems should take more responsibility.

They should:

understand layout better
handle responsiveness better
provide stronger structure
reduce repeated authoring work
let developers think more about pages and products

That is the direction I want Juice to move in.

Not less control.

Better defaults.
Better structure.
Better language.

The Goal

The goal is not to remove thought from UI development.

The goal is to remove unnecessary thought.

I should be thinking about:

the page
the product
the experience
the content
the flow

I should not have to keep fighting the markup just to maintain consistency.

That is what the rules are for.

They make the language trustworthy.

Final Thought

Juice does not get stronger by adding endless attributes.

It gets stronger by making the attribute language more disciplined.

Because the real power of a UI system is not how much it can do.

It is how consistently it helps people do the same things well.

That is where I am pushing Juice next.

Not just toward more features.

Toward stronger rules.

Part 5 will go deeper into themes, surfaces, and how Juice starts moving from a styling system into something that feels more like an engine.

I Got Tired of Class-Heavy UI Code — So I Kept Going (Juice Part 3)

Drew Marshall — Mon, 20 Apr 2026 22:40:42 +0000

In Part 1, I talked about the frustration.

In Part 2, I showed the direction.

Now in Part 3, we’re going deeper into what Juice is actually becoming.

Because at this point…

This isn’t just about styling anymore.

The Real Problem Was Never Classes

Classes were just the symptom.

The real problem?

We’ve been writing UI in a way that separates what something is from how it behaves.

<div class="flex items-center justify-between p-4 bg-gray-900 text-white rounded-lg shadow-md">
</div>

This doesn’t describe intent.

It describes implementation.

Juice Is About Intent

With Juice, I’m not trying to replace Tailwind.

I’m trying to replace how we think about UI.

<div layout="row space-between center" padding="4" surface="dark" text="white" radius="lg" elevation="md">
</div>

Now we’re talking.

layout → structure
padding → spacing
surface → semantic background
text → semantic color
radius → shape
elevation → depth

This is no longer a pile of utilities.

This is a language.

From Styling → System Design

Here’s the shift that changed everything for me:

Juice isn’t a CSS library. It’s a UI protocol.

That means:

Defined attributes
Predictable behavior
Shared contracts across components
Extensible rules

Sound familiar?

That’s because it mirrors how we already think about:

APIs
Schemas
Infrastructure

So why doesn’t UI get the same treatment?

The Missing Layer in Frontend

We have:

Frameworks (React, Vue, etc.)
Styling systems (Tailwind, CSS Modules)
Component libraries (MUI, Chakra)

But we don’t have a standardized way to describe UI itself.

Juice is aiming to sit right there:

[ App Logic ]
      ↓
[ UI Description Layer (Juice) ]
      ↓
[ Render Layer (DOM / Canvas / WebGL) ]

That middle layer?

That’s the gap.

Attributes > Classes Isn’t the Point

Let’s be clear:

This isn’t about:

“attributes are better than classes”

That’s shallow.

The real win is:

Attributes let you define rules and contracts more naturally.

Example:

<button variant="primary" size="lg" state="loading">
</button>

Now imagine:

variant ties into your design system
size scales consistently everywhere
state drives behavior + visuals

This becomes a shared interface, not just styling.

Composability Without Chaos

One of the biggest issues with utility-first systems:

They scale visually but not conceptually.

You end up with:

<div class="flex gap-2 p-3 sm:p-4 md:p-6 bg-neutral-800 hover:bg-neutral-700 transition-all duration-200">
</div>

Multiply that across an app…

Now try to refactor it.

Good luck.

With Juice:

<div layout="row gap-2" padding="responsive" surface="neutral-800" interaction="hover-surface" transition="fast">
</div>

Now:

Behavior is abstracted
Patterns are reusable
Refactoring becomes changing rules, not hunting classes

This Is Where It Gets Interesting

Once UI becomes declarative like this…

You unlock things like:

1. Theming at a System Level

<app theme="corporate-dark">
</app>

Everything adapts.

No class overrides.
No specificity wars.

2. Dynamic UI Generation

Now your UI can be generated from:

JSON
YAML
APIs
AI (👀)

Because it's structured.

3. Cross-Platform Rendering

Same UI definition could target:

DOM
Canvas
WebGL
Native

Because Juice isn’t tied to one renderer.

Juice + The Bigger Picture

This is where Juice connects to everything else I’m building.

Sig → rendering & reactivity
Nectarine → data & APIs
Seltzer → HTTP layer
GrapeVine → infrastructure

Juice becomes:

The way UI is defined across the entire system.

Not just styled.

Where This Is Going

Right now, Juice is still evolving.

I’m documenting rules.
Defining protocols.
Figuring out where flexibility ends and standards begin.

But the direction is clear:

UI should be declarative, structured, and system-driven.

Not just styled with strings.

Final Thought

I didn’t start building Juice because I hated CSS.

I started building it because I realized:

We’ve been missing a layer.

And once you see it…

You can’t unsee it.

Part 4 is where things start getting real.

We’ll talk about:

Rules & constraints
How Juice avoids becoming chaos
And how this turns into an actual engine

Stay tuned.

I Got Tired of Class-Heavy UI Code… So I Kept Going (Juice Part 2)

Drew Marshall — Sun, 19 Apr 2026 11:54:00 +0000

In my last post, I talked about why I started building Juice—mainly out of frustration with class-heavy UI code and how messy things can get as projects scale.

If you haven’t read that yet, here it is:
👉 https://dev.to/stinklewinks/i-got-tired-of-class-heavy-ui-code-so-i-started-building-juice-4ocg

This post is about what came next.

Not just what Juice is, but what I’m actually trying to build with it.

⚠️ The Problem Isn’t Just Classes

After stepping back, I realized something:

The issue wasn’t just Tailwind-style class overload.

It was bigger than that.

Most UI systems today:

Push styling into long class strings
Mix structure, intent, and design into one place
Become harder to read as complexity increases
Don’t feel like they scale conceptually

You can make them work—but you’re constantly managing them.

And that’s where things started to feel off to me.

💡 What If UI Was More Declarative?

Instead of this:

<div class="flex items-center justify-between p-4 bg-white rounded-lg shadow-md">

What if you could express intent more directly?

<div row centered gap="1" padding="4rem" card>

Not just shorter—but more meaningful.

That’s the direction Juice is going.

🧃 The Core Idea Behind Juice

Juice is built around one simple idea:

UI should describe intent, not implementation.

Instead of:

Writing long class lists
Remembering utility combinations
Repeating patterns across files

You define:

Layout
Spacing
Surfaces
Behavior

Using attributes that map to a design system.

🧱 Attributes Over Classes

Classes are flexible, but they come with trade-offs:

No structure
Easy to overuse
Hard to standardize across teams

Attributes, on the other hand:

Encourage consistency
Create a natural design language
Are easier to read at a glance

Example:

<div grid="2" gap="4">
  <div card>A</div>
  <div card>B</div>
</div>

You immediately understand:

Layout: grid with 2 columns
Spacing: gap of 4
Surface: reusable card style

No mental decoding required.

🎯 Not Just Styling — A System

Juice isn’t just about styling elements.

It’s about creating a cohesive UI system that includes:

🎨 Design tokens (colors, spacing, typography)
🧩 Components (cards, nav, sections)
⚡ Interactions (animations, states)
📱 Responsiveness (built-in, not bolted on)

The goal is to make UI:

Faster to build
Easier to read
More consistent

⚡ Where This Is Going

Right now, Juice is still early.

But the direction is clear:

A fully expressive attribute-based UI system
Designed to work standalone or alongside other frameworks
Built to integrate directly into WebEngine

And eventually:

A system where developers and non-developers can both build interfaces without fighting the code.

🧠 What I’m Exploring Next

Some of the things I’m actively thinking through:

How far can attributes go before they become noisy?
How should responsiveness be handled without clutter?
What’s the right balance between flexibility and structure?
How can this integrate with things like WebGL and dynamic UI?

🚀 Why This Matters (To Me)

At the end of the day, this isn’t just about CSS.

It’s about reducing friction when building ideas.

Because when UI becomes easier to reason about:

You build faster
You experiment more
You ship more

And that’s the real goal.

🤝 Let’s Build This Together

This is still evolving, and I’m learning as I go.

If you’ve run into similar frustrations—or have thoughts on this approach—I’d love to hear them.

Repo here:
👉 https://github.com/citrusworx/webengine/tree/master/libraries/juice

Next up, I’ll probably dive deeper into:

How Juice handles responsiveness
Or how it compares directly to existing frameworks in real-world use

Appreciate you reading 🙏

I got tired of class-heavy UI code, so I started building Juice

Drew Marshall — Tue, 14 Apr 2026 22:34:31 +0000

At some point, my markup started feeling… heavy.

Not slow. Not broken. Just hard to look at.

At some point, it stopped feeling like I was writing UI…
and started feeling like I was managing class strings.

The Problem

Modern CSS tooling solves a lot of problems.

But it also introduces some friction—especially at scale.

Verbosity

You end up stacking utilities:

<div class="flex flex-col items-center justify-center h-screen bg-gradient-to-r from-purple-400 to-pink-500">

It works. It’s powerful. But it’s a lot to parse.

Readability

When everything is a class:

layout
spacing
color
behavior

…it all blends together.

You stop seeing intent and start reading implementation.

Scaling UI Systems

As projects grow, this turns into:

long, unreadable markup
repeated patterns everywhere
small changes requiring multiple class edits

It works—but it starts to feel messy.

The Idea

What if UI wasn’t driven by long class strings?

What if it looked more like this:

<div flex="col" height="full" grad="candy-grape" centered>

Instead of stacking utilities, each attribute describes intent directly:

flex="col" centered → layout
height="full" → sizing
grad="candy-grape" → styling

Example

Here’s a simple comparison.

Tailwind-style

<div class="flex flex-col items-center justify-center h-screen bg-gradient-to-r from-purple-400 to-pink-500">
  <h1 class="text-2xl font-bold text-white">Hello</h1>
  <button class="mt-4 px-4 py-2 bg-black text-white rounded-md">Click me</button>
</div>

Juice

<div flex="col" height="full" grad="candy-grape" centered>
  <h1 fontSize="xl" fontColor="white">Hello</h1>
  <button margin-top="4rem" padding="x-4 y-2" bgColor="black" fontColor="white" rounded="md">
    Click me
  </button>
</div>

The difference isn’t just shorter code.

Each attribute expresses intent directly, instead of stacking utilities together.

Interactions & Animations

This pattern extends beyond layout and styling.

<button hover="scale-up" motion="fade-in">
  Click me
</button>

Interactions and animations follow the same idea:

attributes describe behavior
not just appearance

What Juice Is

Juice is an attribute-based UI system.

It’s designed to make UI code more:

expressive
readable
scalable

Core Ideas

Layout via attributes
Styling via attributes
Animations via attributes
Works standalone or with frameworks
Optional JS control when needed

Why I Built It

I wasn’t trying to replace existing tools.

I was trying to solve a personal problem:

I wanted my UI code to feel as clean as my logic.

I like systems.
I like consistency.

And I didn’t like how styling started to feel like a wall of strings.

So I started experimenting with attributes.

That turned into patterns.
Then conventions.
Then a system.

Who This Is For

Juice is probably a good fit if you:

build apps or dashboards
use Tailwind (or similar) but feel the verbosity
care about readability as your project grows

It’s probably not for you if you prefer:

strict class-based systems
or fully abstracted component libraries

Current State

Juice is currently in alpha.

That means:

things will change
APIs may evolve
ideas are still being refined

But the core concept is solid enough to start sharing.

Try It / Feedback

This is still early, and I’m actively shaping it.

If you’ve ever felt the pain of class-heavy UI code, I’d love your feedback:

Does this feel clearer or just different?
Would you actually use this in a project?

Repo:
👉 Juice

This isn’t meant to replace everything.

It’s just another way to think about UI—and I’m curious if it clicks for anyone else the way it did for me.

📚 Reading With Intention as a Builder

Drew Marshall — Sun, 12 Apr 2026 12:52:10 +0000

Lately I’ve been trying to be more intentional about what I read—not just consuming information, but actually learning things I can apply while building.

Here’s the current list I’ve been working through:

✅ Finished

Zero to One
The Cold Start Problem
The Lean Startup

📖 In Progress / Up Next

High Output Management
Platform Revolution
Obviously Awesome
Redeeming Science
Financial Intelligence for Entrepreneurs

🧠 What I’m Starting to Notice

Even though these books come from different angles—startups, product, management, finance—they keep pointing to the same ideas:

Building something “cool” isn’t enough
Growth is designed, not accidental
Positioning determines whether people care
Simplicity and clarity win over complexity
And understanding business is just as important as writing code

⚙️ Applying This in Real Time

I’m not reading these passively—I’m trying to apply them across the things I’m building right now.

Whether that’s:

Thinking about distribution before development
Designing systems instead of one-off solutions
Or being more intentional about how ideas are positioned

The goal is simple:

Build things that actually work in the real world—not just in theory.

🤝 Always Learning

If you’ve read any of these, I’d love to hear what stuck with you—or what I should add next.

I’m always looking to sharpen both the technical and business side of building.