I built a hardware-inspired UI component library in pure Vanilla JS — here's how

Arvin Prince — Mon, 08 Jun 2026 23:24:30 +0000

Most UI components feel like UI components.

You click a toggle and it moves. Fine. It works. But it doesn't feel like anything.

I wanted to change that.

The idea

I've always been drawn to physical interfaces — the satisfying click of a mechanical switch, the weight of a hardware knob, the way a button depresses when you press it.

Web UI almost never captures that. Everything is flat, instant, weightless.

So I started building components that feel like they exist in the real world. Not skeuomorphic in the old iOS 6 sense — but tactile. Depth. Shadow. Resistance.

That became Aetheric UI.

Why Vanilla JS

No React. No Tailwind. No build step.

Not because frameworks are bad — they're great for what they do. But a toggle component shouldn't require a package.json. It should be a file you drop in and it works.

Every component in Aetheric UI is a single file. You copy it in, it runs. That's it.

Wave 1: Toggles and a Button

The first drop is five components:

Depression Toggle — a circular switch that sits pressed into the surface. When it's on, a small amber dot glows at the center. The whole thing feels sunken.

Half-Pill Toggle — a pill-shaped switch split into two halves. One side is always recessed, the other raised. It mimics the feel of a physical rocker switch.

Sliding Toggle — the most dramatic of the three. An ambient amber glow bleeds out from the left when it's active. The knob itself casts a hard shadow.

Toggle Pack — all three together, bundled.

Hardware Button — a pill-shaped container with a pressable button on the right. Press it and it fires its action. The label is fully customizable — the demo shows a text change on press, but what it does is entirely up to you.

What makes them different

The depth is all CSS — layered box shadows, carefully tuned inset values, subtle gradients. No images, no SVGs, no canvas.

The interactions are pure JS state. Toggle on, toggle off. The animations are CSS transitions triggered by a class swap.

Every component is under 10KB. Most are closer to 4KB.

This is just Wave 1

Navbars are next. Then input fields. Then cards.

Each wave drops on Fridays.

If you want to follow along, I'm building this in public on X and LinkedIn as Aetheric Labs.

And if you want the components themselves — they're available now at aethericlabs.lemonsqueezy.com

Built with zero dependencies. Designed to feel real.

Why I built a framework-free e-commerce boilerplate in 2026

Arvin Prince — Fri, 05 Jun 2026 14:18:46 +0000

Every e-commerce starter I found came with the same problem.
400MB of node_modules before I wrote a single line. Build pipelines to configure. Framework versions to manage. Hydration bugs to debug.
I just wanted to ship a clean storefront fast.
So I built one without any of it.
What I built
Aetheric Food Pantry Boilerplate is a production-ready headless e-commerce starter kit built with:

Pure Vanilla HTML/CSS/JS — no build step, no bundler, sub-second load times
Python backend — clean, predictable, no framework overhead
Headless Shopify Storefront API — full product sync, cart, and checkout
Context-aware AI shopping assistant — built in, not bolted on

Zero npm dependencies in production. Drops into any stack.
Why Vanilla JS in 2026
The web platform is genuinely powerful now. CSS Grid, Custom Properties, Fetch API, Web Components — you don't need React to build something fast and clean anymore.
For a food and grocery storefront specifically, the performance difference is real. Vanilla JS loads instantly. Customers don't wait.
The AI assistant
The shopping assistant uses retrieval over the product catalog to answer real questions — not just a chatbot wrapper. Ask it "what's gluten free" or "show me under $5" and it actually responds intelligently.
Where to find it
GitHub: https://github.com/DeusExspiravit/aetheric-food-pantry-boilerplate
Get it: [https://aethericlabs.lemonsqueezy.com/checkout/buy/125b4c80-01ad-4bef-9c88-aba27a91ad31]
Would love feedback from the dev.to community — especially on the no-framework approach. Is this something you'd use in a client project?