(Declarative UI + Imperative Logic = The Sweet Spot)
Most HTML‑first frameworks hit a hard boundary the moment your UI logic becomes procedural, multi‑step, or algorithmic. Cross‑field validation, async inventory checks, dynamic pricing rules — these are not things you should try to express inside declarative attributes.
But here’s the part people miss:
State.js was never designed to replace JavaScript.
It was designed to replace DOM code.
And when you pair standard JavaScript for the heavy logic with State.js for the visual reactions, something magical happens:
- No DOM manipulation
- No class toggling
- No template re-rendering
- No hydration
- No virtual DOM
- No framework lifecycle overhead
Just pure logic → pure UI, with the browser doing the rendering work natively.
This hybrid model is not a workaround.
It’s the ideal architecture for State.js.
🟢 Why This Hybrid Model Works So Well
1. True Separation of Concerns
Your JavaScript does nothing but compute data.
No querySelector.
No classList.add.
No “toggle this element when that element changes.”
Your HTML/CSS does nothing but react to state.
This is the cleanest separation you can get on the web.
2. Zero Framework Lock‑In
If a developer knows JavaScript, they can write the logic.
If they know HTML/CSS, they can build the UI.
There are no lifecycle hooks, no component trees, no hydration rules, no custom syntax to learn.
3. Native Performance
When you do:
formEl.state.valid = true;
State.js updates:
- attributes
- CSS variables
- text bindings
…all using the browser’s native rendering pipeline.
No diffing.
No reconciliation.
No memory churn.
Just instant paint.
🟢 A Real E‑Commerce Example (The Live Pattern)
Here’s what a real checkout validation flow looks like using the hybrid model.
1. The HTML (Clean & Semantic)
<div id="checkout-form" data-state data-shipping-cost="0" data-valid="false">
<input type="text" id="zipcode" placeholder="Enter Zip Code">
<div data-state-condition="valid == false" class="error-msg">
Please enter a valid shipping address.
</div>
<div data-state-condition="valid == true" class="success-msg">
Shipping calculated! Cost: £<span data-state-display="shipping-cost"></span>
</div>
</div>
No JS logic.
No DOM manipulation.
Just declarative UI.
2. The JavaScript (Pure Logic)
const formEl = document.getElementById('checkout-form');
const zipInput = document.getElementById('zipcode');
zipInput.addEventListener('input', async (e) => {
const zip = e.target.value;
if (zip.length === 5) {
const response = await fetch(`/api/shipping?zip=${zip}`);
const data = await response.json();
formEl.state.shippingCost = data.cost;
formEl.state.valid = true;
} else {
formEl.state.valid = false;
}
});
No DOM updates.
No class toggles.
No template re-renders.
Just data → state → UI.
🟢 Why This Matters for E‑Commerce
E‑commerce is 90% UI state:
- cart drawer open/close
- variant switching
- “free shipping” progress bars
- quantity selectors
- error/success messages
- loading states
- stock indicators
- modal popups
- mobile menus
State.js handles all of this declaratively and instantly.
The remaining 10% — the business logic — belongs in JavaScript or the backend.
And that’s exactly how it should be.
🟢 The Final Architecture (The One That Actually Scales)
State.js handles:
- UI state
- visual state
- layout state
- animations
- transitions
- toggles
- progress bars
- variant switching
- micro‑interactions
JavaScript handles:
- validation
- pricing rules
- async workflows
- inventory checks
- checkout logic
Together:
You get a system that is:
- simpler than React
- cleaner than Alpine
- more expressive than HTMX
- more native than Stimulus
- more flexible than Web Components
This is the architecture that makes State.js “unstoppable.”
Top comments (0)