DEV Community: Naveen R

Min-Mozhi: the first Tamil-rooted, safe-by-default hardware description language

Naveen R — Thu, 25 Jun 2026 08:00:00 +0000

I built Min-Mozhi (மின்மொழி — "language of electricity"): a modern HDL that
reads like Go/TypeScript, is safe like Rust, and speaks English, Tanglish, and
Tamil over one grammar. It compiles to synthesizable Verilog and ships its own
event-driven simulator. v0.1.0 is out today. 432 passing tests, MIT + Apache-2.0.

Here's a counter:

module Counter(WIDTH: int = 8) {
  clock clk
  reset rst
  out count: bits[WIDTH]
  reg value: bits[WIDTH] = 0
  on rise(clk) {
    value <- value +% 1
  }
  count = value
}

The same module in Tanglish — same grammar, only the keywords change:

thoguthi Counter(WIDTH: int = 8) {
  thudippu clk
  meettamai rst
  veliyeedu count: bits[WIDTH]
  pathivedu value: bits[WIDTH] = 0
  pothu yetram(clk) {
    value <- value +% 1
  }
  count = value
}

Quick start

cargo build
mimz check   examples/english/counter.mimz
mimz compile examples/english/counter.mimz -o counter.v --emit-testbench
mimz sim     demo/cpu.mimz --cycles 8 -o demo/cpu.vcd

Release v0.1.0: https://github.com/Naveen2070/min-mozhi/releases/tag/v0.1.0
Repo: https://github.com/Naveen2070/min-mozhi
Site: https://mimz.naveenr.in

What would you build if you could write hardware in your own language?

Stop Building Boring Interfaces for Cool Systems

Naveen R — Thu, 25 Jun 2026 06:53:03 +0000

Why developer tools deserve a design language of their own - and how I built one for my own corner of the web

Somewhere along the line, we collectively agreed that "functional" had to mean "boring."

Open almost any developer tool, internal dashboard, or technical log and you'll find the same thing: a sterile corporate wiki. Grey on white. The same SaaS design system everyone copied from the same three component libraries. Rounded cards, a sans-serif font, a faint drop shadow. It works. It's also completely forgettable.

But here's the thing nobody says out loud: when you're building for engineers - or building your own space on the web - you are under no obligation to follow the standard playbook.

The intersection of system design and visual identity is one of the most under-explored areas in frontend architecture. We obsess over latency, bundle size, and runtime dependencies, then slap a default theme on top and call it done. The backend gets all the craft. The interface gets a template.

I wanted to do the opposite.

Building VOID_PROTOCOL
When I put together my own developer log - https://blog.naveenr.in - I deliberately stepped away from the standard minimalist tech blog. Instead, I built out a full design system I call the VOID_PROTOCOL × Manga Editorial Design System: dark-only, type-driven, built on Astro 6, Tailwind 4 (CSS-first @theme tokens), and React 19 islands.

The name isn't decoration. VOID_PROTOCOL started on my https://naveenr.in portfolio, which runs in two modes. There's a minimal version, and there's an immersive one - and in immersive mode the background is a real-time 3D simulation of a sentinel entity. It's not a looping video; it actually responds to your movement, clicks, and scroll. When you leave it alone long enough, it sleeps. And when it sleeps, it dreams - it dreams my initials. (Yes, really. It started as a joke and I kept it.)

That entity is the soul of the whole identity: black, empty, void-like space and a cool blue palette, a deep-space console you've wandered into rather than a page you're reading. The blog inherits that DNA and pushes it somewhere more printed and tactile by mashing up three references that have no business sharing a page:

A cyberpunk terminal HUD. The VOID_PROTOCOL layer, carried straight over from that immersive portfolio mode - near-black canvas (the surface ladder runs void → surface-4, roughly #07080c upward), sky-blue accent (#38bdf8), square 4px scrollbars, and a voice to match. The UI doesn't say "search" and "comments"; it says QUERY_, VOID_PROTOCOL CONNECTED, Transmissions_, Frequency_Stable. Terminal slang as chrome.

A printed manga / zine page. This is where it stops being just another dark tech site. Every panel is a double-lined manga frame with crop marks in the corners, like registration marks on a printed page. Headings are set in Bangers (the comic-stamp face); halftone dot fields, speed lines, and a giant 96px chapter watermark sit behind the hero. Posts are literally framed as issues - // ISSUE #04 - CURRENTLY READING.

A tactile sticker / sketchbook layer. Handwritten annotations and pull-quotes in Caveat, rotated a half-degree so they feel scribbled in by hand. Ink underlines. The logo badge is clipped like a sticker peeling off its sheet. Pagination corners fold up like paper when you hover them. And clicking spawns floating handwritten sound effects - SYNC, SHIP, LOG - that change depending on what you're reading.

The connective tissue is something I call the mood system: every post's first tag picks an accent color, and a single CSS class recolors the entire page - borders, headings, halftones, even the sound-effect vocabulary - without swapping a single component. A dev-log post glows blue; an architecture post burns orange; the experimental "hive" category goes industrial red.

That last detail is the whole point, and it's why this isn't just "I made it look cool." Because the system is built on CSS-first @theme tokens with React islands only where real interactivity is needed, the visual identity isn't paint on a template - it's wired into the architecture. The design system is the stack.

The real argument: design should follow use and place
Here's where I want to push the original idea a bit further, because "make it look cool" is the lazy version of this.

The reason VOID_PROTOCOL works isn't that it's edgy. It's that the design is fit to its context - its use and its place. That's the actual principle worth defending.

A developer log is a personal, opinionated, low-stakes space. It's read by people who are comfortable with terminals, schematics, and dense information. A terminal-HUD-meets-manga-zine aesthetic isn't just decoration there - it signals who this is for and what kind of reading to expect. The form matches the function and the audience. The very mashup that makes it work - cold cyberpunk HUD, loud manga page, handwritten sticker layer - would be pure noise in a context that demanded restraint.
And that's the test.

That same design language would be wrong almost anywhere else. A medical records dashboard, a tax-filing flow, a tool used by exhausted on-call engineers at 3 a.m. - those demand calm, legibility, and zero friction, not halftone patterns and paper peel-corners. The minimalist SaaS look that I'm complaining about exists for a reason: it's a safe default that rarely actively hurts.

So the takeaway isn't "abandon the corporate wiki for manga panels." It's this:

Aesthetic choices are engineering choices. They should be derived from who uses the thing, where it lives, and what it's for - not inherited by default and not chosen purely to look striking.

When you control the entire stack - backend infrastructure down to the exact runtime dependencies on the frontend - you get to dictate the vibe deliberately. That's a privilege most engineers waste. You aren't just pushing pixels; you're crafting an environment, and an environment communicates before anyone reads a word of your content.

My portfolio is the cleanest example of this I can give you. Same content, two designs: a minimal mode for someone who just wants to read my work and leave, and an immersive mode with the living 3D entity for someone who wants to poke around. I didn't build two modes to show off - I built them because the reader's intent changes what the right interface is, and I'd rather serve both than force everyone through one. That's the principle in miniature.

For my log, the right answer happened to be loud, dark, and tactile. For your tool, the right answer might be the quietest, most invisible interface imaginable. Both are good design if they're reasoned from use and place rather than copied from a starter template.

Aesthetics matter in engineering

A tool that looks engaging and feels tactile is one that developers actually want to use and read. A tool that's calm and frictionless is one they can rely on under pressure. Neither happens by accident, and neither happens by default.

Stop inheriting your interface. Start deriving it.

What's the most visually striking developer tool or documentation site you've come across recently? Drop them below - bonus points if you can articulate why the design fits what the thing is for.

Crucible v1.1.0 — Generate UI components you actually own (React/Vue/Angular)

Naveen R — Sat, 06 Jun 2026 08:49:36 +0000

Crucible v1.1.0 — The App-Building Kit Release 🚀

Most component libraries give you a black box: install a package, fight its API, and inherit a runtime dependency you can't fully control.

Crucible takes the opposite approach — it generates the source code for components directly into your project.

No runtime. You own every file.

v1.1.0 is the App-Building Kit release.

What's new

14 new components, bringing the library to 25 — Label, Separator, Badge, Skeleton, Avatar, Textarea, Checkbox, Switch, Alert, Progress (linear + circular), Breadcrumb, RadioGroup, Accordion, and a floating-ui DropdownMenu.
Enough to scaffold a minimal SaaS app, web app, form, or marketing site.
A plug-and-play plugin architecture — add your own components by dropping a manifest + templates into .crucible/plugins/, with no changes to the engine.

Every component ships across React / Vue / Angular × CSS / SCSS / Tailwind, is token-backed, and is accessible by default.

Try it

npm i -D @cruciblelab/crucible
npx crucible init
npx crucible add Button Card Dialog Accordion

The generated files land in your project as plain, readable source — edit them like code you wrote yourself.

Why "you own it" matters

No version-lock to a library's release cadence
No fighting an opinionated API — change the markup directly
No runtime footprint shipped to users

📦 npm: @cruciblelab/crucible
📖 Docs: https://crucible-docs.naveenr.in

What would you want generated next? Drop ideas in the comments 👇

Crucible v1.0 — generate React, Vue, and Angular components that you actually own

Naveen R — Sun, 29 Mar 2026 18:02:01 +0000

I shipped Crucible v1.0 today. It's a code generation engine — you run a CLI command, it writes production-ready component source files into your project, and then it disappears. Zero runtime footprint. You own every line.

npx crucible add Button
# writes Button/Button.tsx, Button/Button.module.css,
# Button/Button.types.ts, Button/README.md
# into your project. yours forever.

I built it because I kept running into the ceiling of what component libraries let you do — and I wanted to see what the "no library, just code" model looked like taken further than copy-paste snippets.

Here's how it works.

The five-layer pipeline

crucible.config.json
  → Config Layer      read + validate with ajv
  → Token Resolver    CSS custom props + OKLCH dark mode derivation
  → Component Model   normalised IR for templates
  → Template Engine   Handlebars, strictly logic-free
  → File Writer       hash protection + Prettier formatting

The IR (intermediate representation) layer is the decision I'm happiest with. Without it, templates become conditional nightmares — {{#if angular}}, {{#if dark}}, {{#if compoundComponents}}. With it, all that logic lives in TypeScript where it can be typed and tested. Templates become pure interpolation.

Templates are audited on every build. Comparisons, ternaries, and else-if chains are prohibited at the .hbs level. npm run audit:templates runs as a prebuild hook and fails the build on any violation.

Token resolution

Tokens deep-merge with your chosen preset. Set only what you want to change:

{
  "theme": "minimal",
  "tokens": {
    "color": { "primary": "#FF6B6B" }
  }
}

Only primary changes. The rest of the minimal preset — radius, typography, backgrounds — is untouched.

Everything resolves to CSS custom properties. No mode ever hard-codes a hex value:

:root {
  --color-primary: #FF6B6B;
  --radius-md: 8px;
  --spacing-unit: 4px;
}

OKLCH dark mode

Dark tokens are derived in OKLCH, not HSL.

HSL lightness shifts change perceived hue — blue can drift toward cyan, purple toward gray-purple. OKLCH is perceptually uniform: lightness changes without hue drift.

{ "darkMode": { "strategy": "auto" } }

That's the whole config. Crucible derives the full dark palette automatically and emits it as [data-theme="dark"] CSS vars alongside the light :root block.

Manual override is also supported for specific tokens.

Framework output

Three frameworks, three style systems — parallel template folders, no {{#if framework}} anywhere in the templates themselves:

Framework	Patterns used
React 18+	Hooks, CSS Modules, compound components (static property pattern)
Vue 3.4+	Composition API, `<script setup>`, named slots
Angular 17+	Standalone components, `@if`/`@for`, `ng-content`

Style systems: css (CSS Modules), scss (SCSS Modules), tailwind (Tailwind v4 with CSS variable arbitrary values).

Adding a new framework means adding a template folder — nothing in the engine changes.

Hash-based overwrite protection

Every generated file gets a content hash stored in .crucible/manifest.json. On re-generation:

Hash matches → overwrite (file is unchanged from generated output)
Hash differs → warn and skip (you've edited it; Crucible leaves it alone)
--force → overwrite regardless
--dry-run → print what would happen, write nothing

The manifest key includes the component subfolder name (Button/Button.tsx) to prevent collisions across components.

CLI

crucible init              # scaffold crucible.config.json
crucible add Button        # generate one component
crucible add -a            # generate all components
crucible add Button --stories  # with Storybook stories
crucible eject             # copy preset tokens into config for full manual control
crucible tokens            # regenerate tokens.css only
crucible doctor            # check Node version, config validity, framework install
crucible config            # print resolved config
crucible clean             # remove generated files

All commands have short aliases: a, i, d, t, e, l, c, cfg.

Components in v1.0

Button · Input · Card · Dialog · Select

Each one: full variant/size/state matrix, TypeScript types, compound components (React) / named slots (Vue) / ng-content (Angular), WCAG 2.1 AA accessibility, auto-generated README.

Test coverage

230 unit tests, 24 test files, 19 E2E phases.

E2E phases cover every framework × style-system combination (React/Vue/Angular × CSS/SCSS/Tailwind = 9 phases), plus write protection scenarios, batch generation, theme presets, custom output directories, and all CLI commands. Each phase runs in an isolated temp directory.

Repo

github.com/Naveen2070/project_crucible — MIT, open from day one.

Good first contributions: Textarea, Badge, Checkbox. The pattern is: add to src/registry/manifests/defaults.ts, create template files in the right framework folders, run the test suite. The engine discovers new components automatically.

Happy to go deep on any of the architecture decisions in the comments.