<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Rust WebAssembly on Atharva Pandey</title><link>https://atharva.page/series/rust-webassembly/</link><description>Recent content in Rust WebAssembly on Atharva Pandey</description><generator>Hugo</generator><language>en-us</language><copyright>Copyright ©</copyright><lastBuildDate>Fri, 18 Jul 2025 10:41:09 +0000</lastBuildDate><atom:link href="https://atharva.page/series/rust-webassembly/index.xml" rel="self" type="application/rss+xml"/><item><title>Lesson 8: The Component Model — Composable WASM modules</title><link>https://atharva.page/post/rust/rust-wasm-component-model/</link><pubDate>Fri, 18 Jul 2025 10:41:09 +0000</pubDate><guid>https://atharva.page/post/rust/rust-wasm-component-model/</guid><description>&lt;p&gt;Here&amp;rsquo;s a scenario that actually happened to me: I had a data validation library written in Rust, a business logic layer in Go, and a reporting module that a client had written in Python. Three languages, three teams, three deployment stories. Traditionally, this means three services talking over HTTP with serialization overhead, network latency, and a distributed systems headache.&lt;/p&gt;
&lt;p&gt;With the Component Model, I compiled all three to WASM components, composed them into a single module, and ran the whole pipeline in one process. No network calls, no serialization, no containers. Function calls across language boundaries, at native speed.&lt;/p&gt;</description></item><item><title>Lesson 7: WASI — WebAssembly beyond the browser</title><link>https://atharva.page/post/rust/rust-wasm-wasi/</link><pubDate>Tue, 15 Jul 2025 19:22:41 +0000</pubDate><guid>https://atharva.page/post/rust/rust-wasm-wasi/</guid><description>&lt;p&gt;About a year ago, I deployed a Rust function as a Cloudflare Worker using WASM. Cold start: 0.5ms. Compare that to a Lambda function in any other language — 50-500ms on a cold start. That&amp;rsquo;s when I realized WASI isn&amp;rsquo;t some academic curiosity. It&amp;rsquo;s the future of server-side compute.&lt;/p&gt;
&lt;p&gt;Solomon Hykes — the guy who created Docker — tweeted this back in 2019: &amp;ldquo;If WASM+WASI existed in 2008, we wouldn&amp;rsquo;t have needed to create Docker.&amp;rdquo; He wasn&amp;rsquo;t being hyperbolic. WASI gives you true sandboxing, near-native performance, cross-platform portability, and sub-millisecond startup. It&amp;rsquo;s what containers promised, but at a fundamentally lower level.&lt;/p&gt;</description></item><item><title>Lesson 6: Multi-Threaded WASM — SharedArrayBuffer and atomics</title><link>https://atharva.page/post/rust/rust-wasm-threads/</link><pubDate>Sun, 13 Jul 2025 07:55:18 +0000</pubDate><guid>https://atharva.page/post/rust/rust-wasm-threads/</guid><description>&lt;p&gt;I got a 4.2x speedup on a real-time audio processing pipeline by adding threads to my WASM module. Four threads, 4.2x faster — nearly linear scaling. That almost never happens in practice, but WASM threading hits a sweet spot: the workloads that justify WASM in the first place (heavy computation, large data) are exactly the workloads that parallelize well.&lt;/p&gt;
&lt;p&gt;The bad news? Getting threads working in WASM is more involved than &lt;code&gt;std::thread::spawn&lt;/code&gt;. There are browser security requirements, Web Worker coordination, shared memory semantics, and a whole build pipeline to figure out. Let me walk you through all of it.&lt;/p&gt;</description></item><item><title>Lesson 5: WASM Performance — When it beats JavaScript</title><link>https://atharva.page/post/rust/rust-wasm-performance/</link><pubDate>Thu, 10 Jul 2025 16:08:51 +0000</pubDate><guid>https://atharva.page/post/rust/rust-wasm-performance/</guid><description>&lt;p&gt;&amp;ldquo;WASM is faster than JavaScript.&amp;rdquo; I&amp;rsquo;ve heard this so many times, and it drives me nuts — not because it&amp;rsquo;s wrong, but because it&amp;rsquo;s incomplete. WASM &lt;em&gt;can&lt;/em&gt; be faster than JavaScript. It can also be slower. The difference depends on what you&amp;rsquo;re doing, how you&amp;rsquo;re crossing the JS↔WASM boundary, and whether you&amp;rsquo;ve hit the specific scenarios where WASM&amp;rsquo;s architecture actually gives you an advantage.&lt;/p&gt;
&lt;p&gt;I ran benchmarks for months to figure out where the real boundaries are. Let me show you the data.&lt;/p&gt;</description></item><item><title>Lesson 4: Leptos, Yew, Dioxus — Full-stack Rust</title><link>https://atharva.page/post/rust/rust-wasm-web-frameworks/</link><pubDate>Mon, 07 Jul 2025 09:17:33 +0000</pubDate><guid>https://atharva.page/post/rust/rust-wasm-web-frameworks/</guid><description>&lt;p&gt;After building that todo list with raw &lt;code&gt;web-sys&lt;/code&gt; in Lesson 3, I think we can all agree: manually managing DOM nodes, closures wrapped in &lt;code&gt;Rc&amp;lt;RefCell&amp;lt;Option&amp;lt;Closure&amp;lt;dyn FnMut()&amp;gt;&amp;gt;&amp;gt;&amp;gt;&lt;/code&gt;, and string-based style attributes isn&amp;rsquo;t how anyone wants to build a real application. That&amp;rsquo;s where Rust frontend frameworks come in. And we&amp;rsquo;ve got three serious contenders — each with a different philosophy about how to build web UIs.&lt;/p&gt;
&lt;p&gt;I&amp;rsquo;ve built side projects with all three. Let me tell you what actually matters when choosing between them.&lt;/p&gt;</description></item><item><title>Lesson 3: Manipulating the DOM from Rust — Web without JavaScript</title><link>https://atharva.page/post/rust/rust-wasm-dom/</link><pubDate>Sat, 05 Jul 2025 11:33:47 +0000</pubDate><guid>https://atharva.page/post/rust/rust-wasm-dom/</guid><description>&lt;p&gt;There&amp;rsquo;s something deeply satisfying about writing &lt;code&gt;document.create_element(&amp;quot;div&amp;quot;)&lt;/code&gt; in Rust and watching it actually work in a browser. It&amp;rsquo;s also, if I&amp;rsquo;m being honest, kind of painful — because &lt;code&gt;web-sys&lt;/code&gt; wraps every single Web API call in &lt;code&gt;Result&lt;/code&gt; types, and you end up with &lt;code&gt;.unwrap()&lt;/code&gt; chains that would make any Rustacean cringe. But once you build the right abstractions on top, it becomes surprisingly pleasant. Let me show you how I got there.&lt;/p&gt;</description></item><item><title>Lesson 2: wasm-bindgen — Bridging Rust and JavaScript</title><link>https://atharva.page/post/rust/rust-wasm-bindgen/</link><pubDate>Thu, 03 Jul 2025 14:12:05 +0000</pubDate><guid>https://atharva.page/post/rust/rust-wasm-bindgen/</guid><description>&lt;p&gt;The first time I looked at what &lt;code&gt;#[wasm_bindgen]&lt;/code&gt; actually generates, I was equal parts impressed and horrified. Impressed because it seamlessly bridges two fundamentally different type systems. Horrified because the generated code is a labyrinth of pointer arithmetic, descriptor tables, and heap management. But here&amp;rsquo;s the thing — you don&amp;rsquo;t need to understand every line of generated code. You do need to understand the &lt;em&gt;model&lt;/em&gt;, because when things go wrong (and they will), the model is what helps you debug.&lt;/p&gt;</description></item><item><title>Lesson 1: Rust to WebAssembly — Why and how</title><link>https://atharva.page/post/rust/rust-wasm-intro/</link><pubDate>Tue, 01 Jul 2025 08:45:22 +0000</pubDate><guid>https://atharva.page/post/rust/rust-wasm-intro/</guid><description>&lt;p&gt;I was optimizing a client-side image processing pipeline last year — think heavy convolutions, histogram equalization, color space conversions. The JavaScript implementation was doing about 12 frames per second. I rewrote the core loops in Rust, compiled to WebAssembly, and hit 55 fps. Same browser. Same machine. That&amp;rsquo;s the moment WebAssembly stopped being a curiosity and became a tool I actually reach for.&lt;/p&gt;
&lt;p&gt;But let me be real: getting there wasn&amp;rsquo;t a straight line. The tooling has rough edges, the mental model is different from writing server-side Rust, and half the blog posts out there show you how to add two numbers in WASM and call it a tutorial. That&amp;rsquo;s not what we&amp;rsquo;re doing here.&lt;/p&gt;</description></item></channel></rss>