In the last 24 hours alone, we’ve pushed the boundaries of the Coni WebAssembly ecosystem to produce an entire suite of procedural audiovisual web experiences. By combining the Coni macro system with raw WebGL and the WebAudio API, we successfully scaffolded, compiled, and deployed complex graphical and musical systems natively in the browser—with absolutely zero external asset dependencies.

Let’s take a look at the five new applications we’ve built. You can experience them all natively in your browser on the Coni WASM Gallery.

Mental health and focus are paramount in today’s fast-paced digital world. Following the success of our brainwave entrainment applications, we decided to tackle another facet of well-being: conscious breathing.

We are excited to unveil our latest Coni WASM application: the WebGL Breathing App, a visual and auditory experience built from scratch to guide you through a calming 6-2-6 breathing exercise (6 seconds inhale, 2 seconds hold, 6 seconds exhale).

Creating a Living UI

Unlike traditional breathing timers that simply show a growing circle, we wanted to build something that feels alive. We designed an interactive menu where you can set your Mood—choosing from Calm (Cyan), Warm (Orange), or Focus (Purple).

Conimo is the official full-stack web framework for Coni. It brings together the blazing-fast WASM frontend capabilities and the robust backend server environment into a cohesive, streamlined developer experience.

Recently, we’ve vastly improved the developer experience by embedding the core Conimo CLI scripts directly into the bin directory of the conimo library. This means you don’t need external setup scripts—everything is powered by native Coni code.

In this guide, we’ll walk through scaffolding a new application, running the local development server, and quickly building a minimal Content Management System (CMS) utilizing the powerful patom database.

When you’re building high-performance applications in the browser, JavaScript’s generic Number type often isn’t enough. You need raw, contiguous memory arrays. In Coni WASM, we rely heavily on native WebAssembly float32 arrays for our most mathematically intensive applications.

Where is Float32 actually used in Coni?

Native float32 arrays (make-float32-array, f32-set!, f32-get) are the absolute backbone of Coni’s performance layer. You’ll find them powering:

1. WebGL Geometry: In our deep-focus-webgl app, we use float32 arrays to mathematically sculpt an 80,000-vertex brain matrix (240,000 floats!) natively, before shipping it to the GPU in a single shot via js/float32-buffer.
2. Game Engine Particle Systems: For games like flappy-bird or neon-boids, parallel float32 arrays keep track of thousands of X/Y coordinates, velocities, and lifetimes without garbage collection pauses.
3. Raw DSP Audio: Our sound-nodes synthesizer calculates complex impulse responses and noise waveforms natively using float32 arrays before mapping them into WebAudio channels.

The Bug: Type Coercion and f64.reinterpret_i64

Because of how critical these arrays are, any bug in them is catastrophic. Recently, we discovered an issue where passing an exact integer (like 150) into f32-set! would mysteriously yield 0.0.

WebAssembly in the browser has always promised incredible performance, but bridging it smoothly with Web APIs like WebAudio and WebGL can sometimes feel like solving a puzzle. Today, we’re thrilled to showcase how the Coni ecosystem elegantly solves this by introducing two brand-new web apps designed for cognitive focus.

These two applications generate a 40Hz gamma frequency—a specific brain wave frequency associated with deep focus, memory recall, and cognitive enhancement—using binaural beats. But the real magic lies under the hood: they are both written entirely in Coni WASM.

In our previous post, we showcased the raw power of Coni WASM by orchestrating an 80,000 particle WebGL matrix. But there was always one lingering annoyance in the WebGL pipeline: the shaders themselves.

If you’ve ever written WebGL code, you know the drill. You end up writing your Vertex and Fragment shaders as massive, messy string literals concatenated across your codebase. You lose syntax highlighting, formatting, and—most tragically for Lisp hackers—you lose structural editing (Paredit/Slurp/Barf).