Ibexend

Ibexend is a suite of spatial computing tools built for developers who think of the browser as a computation medium rather than a document renderer. I co-founded the company and serve as CTO, leading engineering and architecture from Sri Lanka.

What we're building

The core thesis behind Ibexend is simple: the browser is the most widely distributed runtime in the world, and WebGL + WebGPU have made it a capable compute environment. But the tooling hasn't caught up. Most web developers still think in terms of pages and components, not shaders and compute pipelines.

We build tools that bridge that gap. Shader authoring environments. GPU-accelerated data visualization libraries. Real-time 3D interface frameworks that treat the DOM as one layer in a multi-surface rendering system rather than the entire interface.

Architecture decisions

Every Ibexend product shares a few architectural principles:

GPU-first, CPU-second. Anything that can run on the GPU should. The CPU coordinates; the GPU executes. This means our data flow is inverted from typical web apps: instead of CPU processing → GPU rendering, we go GPU processing → CPU coordination → GPU output.

Shader pipeline as the core abstraction. Every visual element passes through a configurable shader pipeline: vertex transform → geometry generation → fragment shading → post-processing. This is overkill for a button. It is necessary for a real-time data visualization with a million data points.

TypeScript from day one. GPU code (GLSL, WGSL) is untyped in practice — shader compilers vary by vendor and error messages are often cryptic. The JavaScript side must be rock-solid to compensate. Everything that touches the GPU has strict TypeScript types, and shader inputs/outputs are validated at the TypeScript boundary.

Current products

The suite currently includes:

• Shader Forge — a browser-based GLSL/WGSL authoring environment with live preview, error diagnostics, and a library of common patterns (SDF primitives, noise functions, color spaces)
• Spatial Kit — a React component library for 3D interfaces, built on Three.js with custom shader backends for performance-critical paths
• Compute Grid — a WebGPU compute orchestration layer that manages buffer allocation, synchronization, and result readout across multiple compute passes

Technical challenges

The hardest problem we've faced is cross-vendor shader compatibility. A GLSL shader that runs perfectly on an NVIDIA GPU through ANGLE might produce subtle artifacts on an Apple Silicon GPU through Metal. The differences are often in floating-point precision, derivative computation, and loop unrolling behavior.

Our solution is an automated shader validation pipeline: every shader is tested against a matrix of GPU vendors, browser versions, and operating systems before it ships. The test renders the shader to an offscreen buffer and compares the output to a reference image, flagging deviations larger than a tolerance threshold. This isn't glamorous work, but it's what makes the difference between a tool that works on the developer's machine and a tool that works everywhere.

What's next

The near-term roadmap includes WebGPU compute shader support for Compute Grid, a visual node-graph editor for Shader Forge, and better interop between Spatial Kit components and CSS layout. The long-term vision is a set of tools that make GPU programming on the web as accessible as React made component-based UI development.

If that sounds like something you want to build, we're hiring.