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).

The Coni WASM Revolution

One of the most exciting aspects of the Coni language is its seamless compilation to WebAssembly (WASM). To put this capability to the ultimate test, I recently built a Multi-City Flight Search App entirely in Coni.

Instead of writing vanilla JavaScript or pulling in massive NPM frameworks, this app uses a custom, lightweight port of the famous re-frame state management pattern—written purely in Coni!

Why re-frame in Coni?

If you’re familiar with ClojureScript, you already know the elegance of re-frame. It provides a unidirectional data flow and highly predictable state management. Bringing this pattern to Coni means we can write UI applications using:

One of the great things about building your own language and tooling is the ability to rethink how operations are performed. In our latest commits, we decided to tackle a major bottleneck in our build process: downloading Maven dependencies.

The Problem with Platform-Specific Scripts

Previously, the download-url-to-file function in Coni relied on shelling out to platform-specific tools:

• On Linux/macOS, it spawned a curl process.
• On Windows, it invoked a massive powershell command using System.Net.WebClient.

While this worked, it had several drawbacks. First, shelling out to external processes is slow and resource-intensive. Second, the dependency on external tools meant that subtle differences in curl versions or Windows security protocols could cause unexpected failures. Most importantly, downloading artifacts sequentially using these shell commands meant that resolving a large Maven project would take entirely too long.

One of the greatest strengths of the Coni language is its portability. We designed it so that the core interpreter and standard libraries are shipped as a single, static binary. You don’t need a bloated installation process; you just download the executable and you’re good to go.

However, as the ecosystem grew—like the addition of our Android build pipeline—we found ourselves with a minor workflow annoyance. To invoke the Android APK builder, you had to run the script via its absolute path: