One thing that slowly wore me down over the years of frontend development wasn’t JavaScript.
It wasn’t components.
It wasn’t CSS itself.
It was the increasing amount of visual noise in the markup.
At some point, UI code started feeling less like structure and more like string management.
You’d open a component and see something like:
<div class="flex flex-col items-center justify-between gap-6 rounded-2xl border border-zinc-800 bg-zinc-900/50 p-8 shadow-lg backdrop-blur-md">
And while utility-first systems absolutely solve real problems, I eventually realized something:
I was spending more time parsing styling syntax than understanding the component itself.
That started bothering me.
A lot.
I Wanted the Markup to Read Like Structure Again
Over time, I became increasingly interested in making UI code feel:
- readable
- semantic
- intentional
- composable
- expressive
Not just:
“technically efficient.”
That thinking eventually led me toward building Juice — an attribute-driven UI system I’ve been experimenting with as part of the broader WebEngine ecosystem.
The goal wasn’t:
“replace CSS.”
And it wasn’t:
“reinvent HTML.”
It was:
“make components readable again.”
Here’s an Example
This is a pricing section component written using Juice-style attributes:
<section type="pricing" id="pricing" paddingY="roomy">
<div container>
<div section-header>
<h2>Pricing That Scales With You</h2>
<p>Start free and grow at your own pace. No hidden fees, no surprises.</p>
</div>
<div grid="3x1" gap="comfortable">
<div card="pricing">
Even before reading the implementation details, the structure is understandable.
You can visually identify:
- sections
- layout intent
- spacing
- grouping
- component purpose
without parsing long utility chains.
That distinction matters to me.
Because I think frontend architecture should optimize for human readability just as much as browser rendering.
The Problem Wasn’t Utility Classes
To be clear:
utility-first frameworks solve legitimate problems.
They:
- improve consistency
- reduce CSS sprawl
- accelerate development
- encourage reusable spacing systems
I completely understand why they became popular.
But after building larger systems, I noticed a tradeoff emerging.
The markup itself became increasingly overloaded with implementation detail.
Eventually components started feeling visually dense.
Not structurally expressive.
Structure and Styling Started Blending Together
One thing I kept asking myself was:
“Can I quickly understand the purpose of this component?”
Not:
“Can I understand the CSS?”
But:
“Can I understand the architecture?”
That’s a different question entirely.
Because when UI systems scale, readability becomes incredibly important.
Especially when:
- teams grow
- components evolve
- systems become long-lived
- onboarding matters
- design systems expand
The easier a component is to mentally parse, the easier it becomes to maintain over time.
I Wanted Styling to Feel More Declarative
One thing I love about attributes is that they naturally feel declarative.
Instead of:
<div class="pt-24 pb-24">
You can express intent more directly:
<section paddingY="roomy">
Now the component describes meaning instead of implementation detail.
That subtle difference changes how the code feels to work with.
Components Start Reading More Like Systems
As I kept experimenting with the approach, I noticed something interesting.
The markup started feeling less like:
“a pile of styled divs”
and more like:
“a structured UI language.”
For example:
<div card="pricing" featured>
immediately communicates:
- this is a card
- it’s specifically a pricing card
- it has a featured state
without needing:
- multiple utility chains
- conditional class merging
- long style abstractions
The component becomes easier to reason about visually.
The Goal Was Never “Less CSS”
Ironically, this approach actually made me think more about CSS architecture.
Because now the system itself needs:
- scalable tokens
- predictable patterns
- strong conventions
- reusable layout primitives
- intentional naming
The complexity doesn’t disappear.
It shifts downward into the design system layer instead of living directly in every component.
And personally, I think that’s a healthier separation of concerns.
I Think Modern UI Has a Readability Problem
One thing I rarely hear discussed is how mentally exhausting frontend markup can become at scale.
Not because developers are bad.
Not because frameworks are bad.
But because modern UI systems often optimize heavily for:
- flexibility
- speed
- composability
while readability becomes secondary.
That tradeoff accumulates over time.
Especially in large applications.
This Isn’t About “Winning” Frontend Development
I don’t think there’s one perfect way to build UI.
And I’m not interested in framework tribalism.
Honestly, most frontend ecosystems have good ideas worth learning from.
This is more about exploring:
- readability
- semantic structure
- maintainability
- expressive architecture
and asking:
“What should UI systems feel like five years from now?”
Because I don’t think frontend architecture is finished evolving yet.
Not even close.
Why This Matters to Me
The longer I work on systems like:
- WebEngine
- KiwiPress
- Juice
- Sig.js
the more I care about creating software that:
- scales operationally
- stays understandable
- remains expressive
- reduces hidden complexity
I want components to feel approachable.
I want systems to feel intentional.
And I want markup to communicate structure clearly again.
Final Thoughts
I still appreciate utility-first systems.
I still appreciate modern frontend tooling.
But personally, I’ve found myself increasingly drawn toward UI architectures that emphasize:
- intent
- structure
- readability
- semantics
- declarative design
Because eventually frontend code stops being just implementation.
It becomes part of the language teams use to communicate architecture to each other.
And I think that language matters more than we sometimes realize.