As part of my session, I will share the technical details of transforming JavaScript code into GPU instructions without changing semantics or adding new language features. This allows existing IDEs and tooling to analyze the code, e.g., the TypeScript language server. Expect a deep-dive into transpilation, handling differences between the source language (JavaScript) and the target language (WGSL), and how to embed fake type information into plain objects. I will go through every TypeScript hack necessary to achieve end-to-end type safety between code running on the CPU, and code running on the GPU, as well as the limitations I encountered along the way. But why transpile JavaScript to run on the GPU in the first place?

Adding 3D content to a website is trivial thanks to Three.js, but when trying to build something custom or more lightweight, developers are left to use low-level APIs like WebGL or WebGPU. This led to many bespoke abstractions and libraries that are incompatible with each other. Furthermore, with local inference of AI models in the browser becoming more feasible, utilities that could be shared are reimplemented per use-case. My team and I felt like there's a missing layer, the connective tissue between GPU libraries, so we built it!

TypeGPU is a library for advanced TypeScript & WebGPU interoperability. It provides primitives that can be either incrementally adopted into existing apps, or used to build something from the ground up. Our latest frontier is allowing developers to write shaders in JavaScript. When combined with TypeGPU's primitives for I/O, the IDE can suggest and auto-complete code across the CPU and GPU (similarly to how tRPC or Convex allow for end-to-end inference across the Client and Server boundary). Although transpiling JavaScript to run on the GPU is by far the most complex part of TypeGPU, the patterns it introduces make GPU-driven web apps easier to build and maintain. Exciting roads ahead!