DEV Community: Drew Marshall

Why Juice Generates CSS Instead of Owning It

Drew Marshall — Wed, 01 Jul 2026 19:21:27 +0000

One design goal I’ve had for Juice from the beginning is that it shouldn’t try to replace CSS.

CSS already exists.

It’s incredibly capable.

The web doesn’t need another styling language.

Instead, I wanted Juice to answer a different question:

How can a design system express intent while still producing plain CSS?

Configuration Becomes The Source Of Truth

Recently I added support for configuration-driven stylesheet generation.

Instead of shipping every possible style with Juice, the framework consumes a project configuration and generates stylesheets from it.

Think of it as a theme generator.

The configuration defines things like:

Colors
Typography
Spacing
Shadows
Borders
Radius
Animations
Design tokens

Juice then generates the stylesheets those decisions require.

Why This Matters

One concern I have with many frameworks is that applications slowly become dependent on the framework itself for every design decision.

Eventually the framework becomes responsible for everything.

That wasn’t the direction I wanted.

Instead, I wanted the project to own its design language.

Juice simply helps express it.

The Framework Shouldn’t Own Your Brand

Every application has its own identity.

Its own colors.

Its own typography.

Its own spacing.

Those things belong to the project.

Not the framework.

Juice shouldn’t tell you what your design system looks like.

It should help you implement it consistently.

Configuration Is Documentation

An unexpected benefit is that the configuration becomes documentation.

Instead of searching through dozens of CSS files, you can understand an application’s design language by reading a single configuration.

The project becomes easier to reason about.

The styling becomes intentional.

Final Thoughts

I don’t want Juice to become another framework that tries to solve every styling problem.

I want it to become a design system engine.

The project defines the language.

Juice helps enforce it.

That’s a much more sustainable relationship than asking a framework to own every design decision.

Why Juice Generates CSS Instead of Owning It

Drew Marshall — Wed, 01 Jul 2026 19:21:27 +0000

One design goal I’ve had for Juice from the beginning is that it shouldn’t try to replace CSS.

CSS already exists.

It’s incredibly capable.

The web doesn’t need another styling language.

Instead, I wanted Juice to answer a different question:

How can a design system express intent while still producing plain CSS?

Configuration Becomes The Source Of Truth

Recently I added support for configuration-driven stylesheet generation.

Instead of shipping every possible style with Juice, the framework consumes a project configuration and generates stylesheets from it.

Think of it as a theme generator.

The configuration defines things like:

Colors
Typography
Spacing
Shadows
Borders
Radius
Animations
Design tokens

Juice then generates the stylesheets those decisions require.

Why This Matters

One concern I have with many frameworks is that applications slowly become dependent on the framework itself for every design decision.

Eventually the framework becomes responsible for everything.

That wasn’t the direction I wanted.

Instead, I wanted the project to own its design language.

Juice simply helps express it.

The Framework Shouldn’t Own Your Brand

Every application has its own identity.

Its own colors.

Its own typography.

Its own spacing.

Those things belong to the project.

Not the framework.

Juice shouldn’t tell you what your design system looks like.

It should help you implement it consistently.

Configuration Is Documentation

An unexpected benefit is that the configuration becomes documentation.

Instead of searching through dozens of CSS files, you can understand an application’s design language by reading a single configuration.

The project becomes easier to reason about.

The styling becomes intentional.

Final Thoughts

I don’t want Juice to become another framework that tries to solve every styling problem.

I want it to become a design system engine.

The project defines the language.

Juice helps enforce it.

That’s a much more sustainable relationship than asking a framework to own every design decision.

Architecture Doesn’t Care What You Build

Drew Marshall — Tue, 30 Jun 2026 16:00:00 +0000

One of the biggest realizations I’ve had while building KiwiEngine is that architecture doesn’t really care what you’re building.

An authentication system doesn’t know whether it’s protecting an artist website or an accounting platform.

An API doesn’t care whether it’s serving a CRM or a music player.

A routing system doesn’t know if it’s powering an e-commerce store or a game launcher.

Good architecture solves engineering problems.

The domain simply gives those solutions a purpose.

That realization completely changed how I think about KiwiEngine—and more importantly, how I think about the software I want to build.

Architecture Solves Engineering Problems

The longer I’ve worked on KiwiEngine, the more I’ve realized that many of the problems we solve are universal.

Authentication.

Authorization.

Routing.

Caching.

State management.

Content management.

Documentation.

These challenges exist regardless of the application.

A music platform still needs users.

An online store still needs payments.

An artist website still needs content.

A game launcher still needs updates.

The engineering principles don’t suddenly change because the audience does.

Domains Give Architecture Purpose

If architecture doesn’t care about the domain, people certainly do.

For a long time, I assumed that because KiwiEngine could support business applications, I should be the one building them.

CRMs.

Inventory systems.

Scheduling platforms.

SaaS products.

The architecture was capable.

But I slowly realized something important.

Capability and calling aren’t the same thing.

Curiosity Is A Better Compass

Looking back over the projects that energized me, a clear pattern emerged.

I kept returning to creative technology.

Music production.

Artist websites.

Plugins.

Media platforms.

Game development.

Digital publishing.

Those weren’t distractions from KiwiEngine.

They were the best proving ground for it.

Every time I worked on those projects, I naturally discovered improvements to the framework because I genuinely depended on it.

The software wasn’t theoretical anymore.

It became part of my own workflow.

Open Source Changes The Equation

One of the greatest strengths of open source is that it removes the pressure to build everything yourself.

KiwiEngine doesn’t need me to build every CRM.

Or every scheduling platform.

Or every business application.

If someone wants to build those things, I hope KiwiEngine becomes a solid foundation for their work.

My role is to build the engine.

Document the philosophy.

Share the blueprints.

Teach what I’ve learned.

The community can take those ideas in directions I would have never imagined.

The Best Software Comes From Understanding

I’ve come to believe that software improves when its creator genuinely understands the people using it.

I understand creators because I am one.

I write songs.

I produce music.

I mix and master.

I build games.

I design graphics.

I enjoy creating things.

Building software for those communities isn’t narrowing KiwiEngine’s vision.

It’s giving it a better proving ground.

Final Thoughts

KiwiEngine hasn’t changed.

Its architecture hasn’t changed.

Its philosophy hasn’t changed.

What has changed is my understanding of where I create the most value.

Architecture doesn’t care whether you’re building software for musicians, accountants, educators, or game developers.

People do.

And the better you understand the people you’re building for, the better your software becomes.

That’s why I’m no longer chasing every market.

I’m choosing the one I understand best—and letting the architecture do what it was designed to do.

Finding The Customer You Understand

Drew Marshall — Mon, 29 Jun 2026 17:00:00 +0000

One piece of startup advice you'll hear often is:

"Find a problem worth solving."

I agree.

But I think there's another question that's just as important.

Find a customer you genuinely understand.

For a while, I tried thinking about software markets in general.

Small businesses.

SaaS.

Enterprise.

Productivity.

Eventually I realized something.

I wasn't excited because of the market.

I was excited by the work itself.

Music.

Creative software.

Audio engineering.

Game development.

Design.

Those aren't hobbies sitting beside software.

They're the reason I build software.

Your Experience Is An Advantage

Every builder has accumulated years of experience in something.

Mine happens to include music production, songwriting, game development, design, and software architecture.

Ignoring that experience would be like ignoring a built-in competitive advantage.

Instead of trying to become an expert in industries I don't live in, I've decided to build for the communities I already understand.

Not because they're bigger.

Because I can genuinely contribute something valuable there.

You Don't Have To Build Everything Yourself

Drew Marshall — Sun, 28 Jun 2026 15:00:00 +0000

One misconception I had early on was believing that creating a framework meant creating every application that framework could support.

That's impossible.

If KiwiEngine can build hundreds of different kinds of applications, why should one person try to build all of them?

The answer is simple.

They shouldn't.

Open Source Is Multiplication

Open source isn't about creating every solution.

It's about creating more builders.

The framework provides the foundation.

The community provides the imagination.

Some people will build business software.

Others will build education platforms.

Others will build games.

Others will build entirely new ideas I haven't even considered.

That's far more exciting than trying to own every application myself.

Build The Blueprint

I've become increasingly interested in building blueprints rather than finished buildings.

A blueprint enables many buildings.

One application solves one problem.

A blueprint helps solve hundreds.

That's where I think the long-term value lives.

Not in trying to build everything.

But in making it easier for others to build anything.

Burnout Was Trying To Tell Me Something

Drew Marshall — Sat, 27 Jun 2026 12:53:07 +0000

For a long time, I assumed burnout meant I wasn't working hard enough.

Or that I needed better discipline.

Or better time management.

Looking back, I think something else was happening.

Burnout was feedback.

Every time I forced myself toward projects that didn't naturally fit my interests, progress slowed.

Everything became heavier.

Then I'd spend an evening designing a music application, thinking about plugin architecture, composing music, or sketching ideas for Blackwater Sound.

Hours disappeared.

The energy came back.

Passion Is Data

I don't think passion should replace discipline.

But I do think it's worth paying attention to.

If you consistently find yourself energized by one type of work and drained by another, that's information.

Not an excuse.

Information.

It tells you where your curiosity naturally lives.

Alignment Creates Momentum

Today I still believe KiwiEngine can power almost any kind of application.

What has changed is how I'm choosing to use it.

Instead of chasing every possible market, I'm building creative tools that I personally want to use every day.

Ironically, I think that will make KiwiEngine stronger.

Because software improves the most when its creator genuinely depends on it.

Sometimes burnout isn't telling you to stop building.

Sometimes it's telling you to build the right thing.

Why I Stopped Chasing Every Market

Drew Marshall — Sat, 27 Jun 2026 12:46:48 +0000

One of the biggest realizations I've had over the last year wasn't about software.

It was about focus.

When I first started building KiwiEngine, I wanted it to power everything.

Business software.

CRMs.

Inventory systems.

Scheduling platforms.

Accounting tools.

SaaS products.

If someone could build it, I wanted KiwiEngine to support it.

Technically, I still do.

But something changed.

I realized there is a difference between building software that can solve every problem and trying to solve every problem yourself.

Those aren't the same thing.

The Architecture Never Changed

KiwiEngine is still designed to power business applications.

Nothing about the architecture changed.

The modules.

The APIs.

The philosophy.

The engine remains general-purpose.

What changed was my focus.

Build What You Understand

I started asking myself a simple question.

Who do I actually understand?

Not as a developer.

As a creator.

The answer wasn't accountants.

It wasn't HR departments.

It wasn't inventory managers.

The answer was musicians.

Artists.

Game developers.

Creators.

Builders.

Those are the people whose problems I experience every day.

Those are the workflows I naturally understand.

Open Source Changes The Equation

One of the beautiful things about open source is that I don't have to build every application.

I can build the engine.

I can document it.

I can share the philosophy.

Someone else can build the CRM.

Someone else can build the scheduling platform.

Someone else can build the accounting software.

Meanwhile, I can focus on building the creative tools I genuinely want to use.

The Best Proving Ground

Today, KiwiEngine's proving ground is becoming:

Artist websites
EPKs
Music production tools
Digital storefronts
Creative workflows
Game development
Media platforms

Not because they're the only things KiwiEngine can build.

Because they're the things I care deeply enough to refine every day.

And I think that creates better software than chasing every possible market ever could.

The API Design Lesson I Learned From Building Nectarine

Drew Marshall — Fri, 26 Jun 2026 18:00:00 +0000

One of the most surprising lessons I've learned while building software is that APIs are not really about code.

They're about communication.

At first, that sounds strange.

After all, APIs exist so software can talk to software.

But every API is also a conversation between developers.

And like any conversation, clarity matters.

The First Version Is Usually Technical

Most APIs begin from an implementation perspective.

The database exists.

The endpoints exist.

The underlying logic exists.

The API becomes a reflection of those details.

It exposes how the system works internally.

The problem is that users often don't care about internal implementation.

They care about solving problems.

Intent Is Easier To Understand

One idea I've become increasingly interested in is designing around intent.

Instead of asking:

"How should users interact with the implementation?"

I try to ask:

"What are users trying to accomplish?"

The difference seems small.

The results are often significant.

Intent tends to produce simpler APIs.

Clearer workflows.

Better naming.

Better abstractions.

The Database Is Not The Product

One mistake many systems make is exposing internal structures directly.

Tables become endpoints.

Schemas become workflows.

Implementation becomes the interface.

This is understandable.

It's also limiting.

The API should represent the problem domain.

Not necessarily the storage mechanism.

Good APIs Read Like Conversations

The best APIs I've encountered often feel obvious.

Not because they're simplistic.

Because they're expressive.

You can often read the code and understand the intention behind it.

The API communicates purpose.

Not just mechanics.

Real Usage Changes Everything

Just like documentation, abstractions, and frameworks, APIs reveal themselves through usage.

The first version is rarely the final version.

Real projects expose awkward naming.

Unexpected workflows.

Missing concepts.

Confusing assumptions.

The API evolves as understanding evolves.

The Hidden Goal

I used to think API design was primarily about flexibility.

Now I think it's more about reducing misunderstanding.

Every confusing name creates hesitation.

Every unclear workflow creates friction.

Every implementation detail exposed unnecessarily creates cognitive load.

The best APIs reduce those costs.

Final Thoughts

The longer I build software, the less I think about APIs as technical interfaces.

I think about them as communication tools.

A good API helps developers understand a system.

A great API helps developers forget the system exists and focus on solving the problem instead.

That's the lesson I'm continuing to learn while building software.

And it's one that seems to apply far beyond APIs themselves.

Why I Stopped Adding Features and Started Removing Friction

Drew Marshall — Thu, 25 Jun 2026 16:55:37 +0000

Early in a project, adding features feels like progress.

A new capability appears.

A new screen gets built.

A new workflow becomes possible.

Everything feels like forward motion.

For a long time, I assumed that was the primary job of software development.

Build more features.

Solve more problems.

Expand the system.

Over time, I've started to think differently.

Some of the most valuable improvements I've ever made weren't new features.

They were reductions in friction.

Features Create Possibilities

Features matter.

Users need capabilities.

Products need functionality.

Without features, software doesn't solve problems.

The challenge is that every feature introduces complexity.

Every button.

Every setting.

Every workflow.

Every API.

Every configuration option.

The system grows.

Sometimes that's necessary.

Sometimes it's expensive.

Friction Is Easier To Ignore

One reason friction survives so long is because it often looks small.

An extra click.

An extra configuration step.

A confusing name.

A repetitive workflow.

None of these things seem important individually.

But software isn't experienced one interaction at a time.

It's experienced as a whole.

Small friction accumulates.

The User Feels Everything

As builders, we often focus on what software can do.

Users focus on how software feels.

The difference matters.

A powerful feature that creates frustration may deliver less value than a simple workflow that feels effortless.

The experience is part of the product.

Not just the functionality.

Real Projects Expose Friction

One reason I believe strongly in building real projects is because friction becomes impossible to ignore.

Features tend to dominate planning meetings.

Friction dominates daily usage.

You feel it.

Repeatedly.

The same awkward workflow.

The same repetitive task.

The same confusing decision.

Eventually the problem becomes obvious.

Removing Friction Creates Leverage

A feature helps users do something new.

Removing friction helps users do everything faster.

That's a different kind of value.

The improvement compounds.

Every interaction benefits.

Every workflow benefits.

Every future feature benefits.

The Hidden Metric

I've started paying attention to a question that rarely appears on roadmaps:

"How much effort does this require to understand?"

Not implement.

Not maintain.

Understand.

Understanding is one of the most expensive costs in software.

Reducing friction often means reducing the effort required to understand the system.

Final Thoughts

Features are important.

But they're not the only way software improves.

Sometimes the best feature is the removal of a problem users encounter every day.

The longer I build software, the more I find myself asking:

Not "What should we add next?"

But:

"What can we make easier?"

Because removing friction often creates more value than adding another feature ever could.

Why Constraints Create Better Software

Drew Marshall — Tue, 23 Jun 2026 16:00:00 +0000

When developers talk about software design, flexibility is usually treated as an unquestionable good.

More options.

More customization.

More configuration.

More control.

The assumption is simple:

More freedom equals better software.

I'm no longer convinced that's true.

In many cases, the opposite seems to happen.

The most successful systems often become successful because of their constraints.

Every System Has Rules

Whether we acknowledge them or not, every system operates within constraints.

Programming languages have syntax.

Frameworks have conventions.

Databases have schemas.

Operating systems have permissions.

The question isn't whether constraints exist.

The question is whether they're intentional.

Good constraints guide behavior.

Bad constraints create frustration.

Constraints Reduce Decisions

Every decision requires effort.

Every configuration option requires understanding.

Every customization path requires maintenance.

One reason good software feels simple is because it removes unnecessary decisions.

The system makes sensible choices so users can focus on solving problems.

Not configuring tools.

Consistency Creates Trust

One of the hidden benefits of constraints is consistency.

When developers encounter the same patterns repeatedly, they begin building intuition.

The system becomes predictable.

Predictability creates confidence.

Confidence creates speed.

The result is often greater productivity than a completely unrestricted system.

Languages Depend On Constraints

Languages work because of grammar.

Without shared rules, communication becomes difficult.

Frameworks are similar.

The more a framework grows, the more important consistency becomes.

Conventions become vocabulary.

Patterns become expectations.

The system develops a language.

And languages require rules.

Real Projects Reveal Useful Constraints

The best constraints rarely emerge from theory.

They emerge from usage.

A real project exposes confusion.

A real project exposes repetition.

A real project exposes complexity.

Over time, useful constraints begin to emerge naturally.

Not because someone imposed them.

Because reality demanded them.

The Goal Is Progress

I've started thinking about software design differently.

The goal isn't maximum flexibility.

The goal is maximum progress.

Sometimes progress requires freedom.

Sometimes progress requires constraints.

The challenge is knowing the difference.

Final Thoughts

Good constraints aren't limitations.

They're guidance.

They help developers focus on what matters.

They reduce cognitive load.

They create consistency.

They improve communication.

And over time, they help transform a collection of features into a coherent system.

The longer I build software, the more I find myself asking:

Not "What should this allow?"

But:

"What should this encourage?"

Building a Design System Without Recreating CSS

Drew Marshall — Mon, 22 Jun 2026 23:17:44 +0000

One of the easiest traps to fall into when building a design system is accidentally recreating CSS.

At first, it seems harmless.

You add a few utility classes.

Then a few responsive options.

Then a few layout helpers.

Then a few exceptions.

Before long, you've built an entirely new syntax for doing the exact same thing CSS already does.

I've become increasingly interested in a different approach.

Not replacing CSS.

Not hiding CSS.

Creating a layer above CSS that focuses on intent.

The Problem With More Options

Developers love flexibility.

I do too.

The challenge is that flexibility often comes with complexity.

Consider responsive layouts.

Many systems solve this by exposing every possible breakpoint and layout combination.

The result is powerful.

But it's also easy to end up with markup that spends more time describing implementation details than communicating purpose.

The system becomes harder to understand.

Not because it's incapable.

Because it's trying to describe everything.

Intent Versus Implementation

Lately I've been thinking less about how a layout is built and more about what the layout is trying to accomplish.

For example:

<div content adapt="grid" mobile="stack">

This isn't trying to replace CSS.

It's trying to express intent.

The content should adapt as a grid.

On mobile, it should stack.

The implementation details can remain inside the design system.

The goal isn't more abstraction.

The goal is better communication.

Strong Defaults Create Simplicity

One lesson I've learned from building software is that good defaults are often more valuable than endless configuration.

Most layouts follow common patterns.

Most responsive behavior follows common patterns.

Most developers aren't trying to create entirely new layout systems.

They're trying to organize content.

A design system can help by providing thoughtful defaults rather than exposing every possible option.

The Danger Of Recreating CSS

The moment a design system attempts to expose every CSS capability, it starts competing with CSS itself.

That's usually a losing battle.

CSS already exists.

CSS is already powerful.

CSS is already standardized.

The job of a design system isn't to replace CSS.

The job of a design system is to reduce cognitive load.

To create consistency.

To communicate intent.

To make common patterns easier.

Designing For Readability

One question I increasingly ask when designing APIs is:

"Can I understand this six months from now?"

Not:

"Can I configure everything?"

Not:

"Can I support every edge case?"

Simply:

"Can I read this and understand what it is trying to do?"

Readability scales.

Complexity doesn't.

The Goal Isn't Less Power

Sometimes simplicity gets mistaken for limitation.

I don't think that's true.

The goal isn't to remove power.

The goal is to place power where it belongs.

Common workflows should be simple.

Advanced workflows should remain possible.

The design system should help developers move quickly without preventing them from solving unique problems.

Final Thoughts

I've become increasingly convinced that the best design systems don't try to replace CSS.

They try to create a shared language around common design decisions.

A language focused on intent rather than implementation.

A language that helps developers communicate purpose.

Because at the end of the day, most developers aren't trying to build layouts.

They're trying to build products.

The layout is simply one part of the system.

Every Framework Eventually Becomes a Language

Drew Marshall — Sun, 21 Jun 2026 17:00:00 +0000

When most developers think about frameworks, they think about features.

Routing.

Components.

State management.

Authentication.

Data access.

Build tools.

All important things.

But I've started to believe that the longer a framework survives, the less important its features become.

Instead, something else emerges.

A language.

Not a programming language.

A language of ideas.

A language of patterns.

A language of intent.

And once that language forms, it often becomes more valuable than the framework itself.

Frameworks Start As Tools

Most frameworks begin life as solutions to technical problems.

How do we route requests?

How do we manage state?

How do we organize code?

How do we build interfaces?

The early focus is almost entirely mechanical.

The framework exists to make something easier.

The language hasn't formed yet.

At this stage, the framework is mostly a collection of features.

Then Patterns Begin To Appear

Something interesting happens once enough people start using a framework.

Certain approaches become common.

Certain solutions become preferred.

Certain conventions emerge.

Developers start recognizing patterns.

The framework begins teaching its users how to think.

Not just how to code.

How to approach problems.

This is where the framework starts becoming a language.

Good Frameworks Teach More Than APIs

Think about the frameworks and tools that have survived for years.

People don't just learn the APIs.

They learn the philosophy.

They learn the conventions.

They learn the assumptions.

Eventually they start speaking the language of the framework.

You can often tell when someone has spent years working within a particular ecosystem.

Not because of the code they write.

Because of the way they think.

The framework has shaped their mental model.

The Language Matters More Than The Syntax

Most developers assume the syntax is the important part.

I don't think it is.

Syntax changes.

Versions change.

Features change.

The underlying language tends to remain.

The language is what allows developers to communicate ideas efficiently.

Once a shared vocabulary exists, complexity starts shrinking.

A single term can communicate an entire concept.

A single convention can communicate an entire workflow.

The language becomes a form of compression.

Documentation Is Really Language Training

This realization changed how I think about documentation.

Documentation isn't just explaining APIs.

It's teaching vocabulary.

It's teaching concepts.

It's teaching patterns.

Good documentation helps users understand how the framework thinks.

Bad documentation simply lists features.

The difference is significant.

One teaches understanding.

The other teaches memorization.

Real Projects Shape The Language

One reason I believe every library needs a real project is because real projects shape the language.

Features can be designed in isolation.

Languages cannot.

Languages emerge from use.

They emerge from friction.

They emerge from repeated interactions with real problems.

The most useful concepts survive.

The awkward concepts disappear.

Over time the language becomes more refined.

More expressive.

More coherent.

Every Successful System Develops Vocabulary

This isn't unique to software.

Businesses develop language.

Trades develop language.

Music develops language.

Architecture develops language.

Communities develop language.

The larger and more complex a system becomes, the more important shared vocabulary becomes.

Without a common language, collaboration becomes difficult.

With one, entire ideas can be communicated in a few words.

Why This Matters To Builders

The longer I build software, the less interested I become in adding features for the sake of features.

Instead, I find myself asking different questions.

Does this fit the language?

Does this reinforce the philosophy?

Does this make the system easier to understand?

Does this create a more coherent experience?

Those questions often lead to better decisions than simply asking what feature should come next.

Final Thoughts

Most frameworks begin as tools.

Some evolve into ecosystems.

The most successful ones eventually become languages.

They create vocabulary.

They create conventions.

They create ways of thinking.

The APIs matter.

The features matter.

But over time, the language becomes the thing people truly adopt.

And once that happens, the framework is no longer just software.

It's a way of expressing ideas.