I Built A Browser Audio Visualizer Without A Frontend Framework Because I Wanted To Build The Damn Thing

I wanted momentum more than framework philosophy

The original goal was simple: get sound into the browser, analyze it, throw motion on screen, and see whether the thing had any life in it. That required momentum more than architecture discourse.

I did not want to burn two weeks learning the blessed way to express state, lifecycle, routing, hydration, composition, or any other framework-shaped worldview before the product had earned that complexity. I wanted the product to shape the code, not the other way around.

So I kept the stack brutally direct: vanilla JS, HTML templates, CSS, Web Audio, WebGL, Canvas, and a willingness to break things in public until they started feeling right.

What I actually cared about in the early phase:

• fast feedback loops
• getting audio metrics on screen quickly
• testing visual ideas before they got overexplained
• shipping something with taste before polishing the soul out of it

Creative browser work rewards speed more than ceremony

An audio visualizer is not a CRUD app wearing LED lights. A lot of the work is feel. Motion. Timing. Whether the beat hit feels satisfying. Whether the brightness breathes or strobes. Whether the whole thing feels alive or just technically reactive.

You do not get those answers from a framework tutorial. You get them by running the visual, staring at it, hating it, changing three lines, rerunning it, and repeating that loop until the scene stops embarrassing you.

That is why I wanted the shortest possible distance between an idea and a visible result. If I had to constantly stop and translate instinct into framework ceremony, I was going to lose the thread.

The loop I wanted was:

1. plug in audio
2. watch the visual misbehave
3. change the code immediately
4. repeat until it starts to slap

Vanilla JS let me move like a gremlin

If I wanted to add a metric, tweak a render path, swap visual behavior, wire a new control, or try some cursed idea at 1:30 in the morning, I could just do it. No component tree therapy session required.

That mattered because so much of VVavy was discovered through iteration. The useful abstractions were not obvious at the start. They showed up after enough experimentation made the repeating patterns undeniable.

That is a much better way for me to build this kind of product than forcing a perfectly organized app structure onto a thing that is still actively revealing what it wants to be.

Things I did not miss:

• asking whether this should be a hook
• hunting for the correct place to put state just to animate some pixels
• reading another opinionated thread about how to think properly
• mistaking framework compliance for actual product progress

Future me is absolutely going to roast present me

I am not romantic about the tradeoff. Skipping a framework does not magically make complexity disappear. It just means I own more of the discipline myself.

There are definitely parts of this codebase that future me is going to open, squint at, and say, who let this happen. The terrible part is that I will already know the answer.

But future regret is easier to negotiate with than present paralysis. I would rather deal with some cleanup later than spend the whole early stage preparing for scale before there is even a real thing to scale.

Shipping beat purity

Early on, the bottleneck was not maintainability theater. It was courage, taste, and velocity. I needed enough real product in the world to learn what was good, what was fake, and what deserved more structure later.

A lot of planning-for-scale advice is valid. A lot of it is also fear in a nice shirt. If I had optimized too hard for future elegance, I probably would have ended up with a beautifully reasoned system and a weaker actual product.

Instead I got to iterate fast as fuck, get a taste out to the world, and let the real experience teach me what needed to harden next.

This does not have to scale if there is only ever one hand in the cookie jar

This does not have to scale if there is only ever one hand in the cookie jar. That sentence is doing real work for me.

I am the one in here. I know where the cursed parts are, where the clean parts are, and which corners I cut on purpose because getting the thing alive mattered more than earning architecture points from people who were not building it.

Would I make different choices for a big team? Obviously. Would I probably regret parts of this later? Also obviously. But I was able to move insanely fast, get a taste out into the world, and learn from the actual product instead of a fantasy version of it. That trade was worth it.

Keep exploring

Common questions