Show HN: Nectar, a Rust-like React that compiles to WebAssembly
Summary
Nectar is a new web framework that compiles Rust-like code to WebAssembly, eliminating JavaScript dependencies with O(1) signal updates and zero-dependency builds.
After a pretty rough gig experience, I wanted to remind myself that I was a vaguely capable developer. I had recently jumped on the Rust train and wanted a Rust equivalent of React that is more performant and easier to work with. I also wondered if I could effectively eject Javascript. This project came from that... Nectar is a programming language that compiles your entire app, logic, state, and rendering, to WebAssembly. JavaScript is reduced to a roughly 10 KB syscall layer that only bridges WASM to the DOM.<p>The origin: I set out to get React-style ergonomics with better performance, and about halfway in I realized I had hit the ceiling of what was possible going through the browser's DOM (Blink/C++) and a diffing step. So I stopped fighting it and built my own signal-driven rendering layer that compiles to WASM and updates exactly the DOM nodes that changed, in O(1), with no virtual DOM and no garbage collector.<p>What it is right now:<p>- One binary. The same compiler does formatting, linting, testing, a dev server, an LSP, and SSR (although SSR is underdeveloped).
- Fine-grained signals. Each binding updates on its own, so there is no diffing pass.
- A Rust-inspired borrow checker for compile-time safety.
- Language-level keywords for the patterns you reach for constantly on the web: component, store, router, form, auth, payment.
- SEO and Screen Readers. It compiles to two DOMs from the same source so the app stays visible to screen readers and crawlers.<p>Honest status, because this is early and it is mostly one person:<p>- The "no JavaScript" line has an asterisk. WASM cannot touch the DOM directly, so there is a small JS bridge (about 10 KB) that as of this moment I cannot overcome on major browsers.
- The numbers on the site (a counter is ~10 KB versus ~387 KB for React plus JS) are real but small examples, not a full-app shootout. I would not read them as more than they are. They are intentionally poorly architected to measure throughput at massive scales. (contrived)
- License is BSL 1.1, so read that before you build anything real on it.<p>Live demo, 10,000 products with a canvas rendering engine, plus a side by side against Svelte 5:
<a href="https://buildnectar.com/app/canvas" rel="nofollow">https://buildnectar.com/app/canvas</a><p>Site: <a href="https://buildnectar.com" rel="nofollow">https://buildnectar.com</a>
Code: <a href="https://github.com/HibiscusConsulting/nectar-lang" rel="nofollow">https://github.com/HibiscusConsulting/nectar-lang</a><p>I would genuinely like it torn apart. If the core bet is wrong, crush my dreams but tell me how we can make it better, please. I still am not completely sure this is even a good idea. I honestly thought this would be a lot easier to build than it has been. If I had known at the start, I would have never built it, but here we are.
View Cached Full Text
Cached at: 07/12/26, 07:51 PM
# Nectar — The Web Without JavaScript
Source: [https://buildnectar.com/](https://buildnectar.com/)
[Nectar](https://buildnectar.com/)## The webneeds JavaScript doesn't\.
Nectar compiles to WebAssembly\. One language, one binary, zero dependencies\. Your entire app — logic, state, rendering — runs in WASM\. JavaScript is reduced to a 10 KB syscall layer\.
Note: The Svelte demo may time out on first load with 10K products\. Try refreshing if it appears blank\.
## Writeless\. Shipfaster\.
// package\.json: 47 dependencies// node\_modules: 1,247 packagesimportReact, \{ useState \}from'react';importReactDOMfrom'react\-dom';functionCounter\(\) \{const\[count, setCount\] =useState\(0\);return\( <div\> <p\>\{count\}</p\> <button onClick=\{\(\) =\> setCount\(c =\> c \+1\)\}\> \+ </button\> </div\> \); \}
// No package\.json\. No node\_modules\.// One file\. Compiles to WASM\.componentCounter\(\) \{let mutcount:i32=0;fnincrement\(&mutself\) \{ self\.count = self\.count \+1; \}render\{ <div\> <p\>\{format\("\{\}", self\.count\)\}</p\> <button on:click=\{self\.increment\}\>"\+"</button\> </div\> \} \}
## Builtdifferent\.
⚙
### Single Binary Compiler
One Rust binary handles everything: compile, format, lint, test, dev server, LSP, package management, SSR\. No toolchain to configure\.
⚡
### Fine\-Grained Signals
O\(1\) updates per binding\. No virtual DOM, no diffing, no reconciliation\. When a signal changes, only the exact DOM node updates\.
🔒
### Compile\-Time Safety
Rust\-inspired borrow checker, type system, and exhaustive pattern matching\. Catch bugs before they ship — not in production\.
📦
### Zero Dependencies
No npm, no node\_modules, no webpack, no bundler\. Your app compiles to a \.wasm binary and a 3 KB runtime\. That's it\.
🌐
### Built\-In Keywords
component, store, router, page, form, auth, payment, upload, db, cache, agent — common web patterns are language primitives, not libraries\.
🚀
### SSR \+ Edge Deploy
The same WASM binary runs on the server via wasmtime\. Built\-in SSR, hydration, and deployment to 29 Cloud Run regions\.
## HowNectarworks
Your \.nectar source compiles to WebAssembly\. The browser loads the \.wasm and a 10 KB syscall layer\. Everything else is WASM\.
Source\.nectar
→
CompilerRust
→
Output\.wasm
→
RuntimeBrowser
JavaScript Runtime10 KB \(DOM syscalls only\)Virtual DOMNone — command bufferState ManagementWASM signals — O\(1\)Borrow CheckerCompile\-time safetynode\_modulesZero\. Deleted\.GC PausesNone — linear memoryXSS AttacksImpossible — no evalAuthHttpOnly cookies by default
## See itrunning\.
10,000 products\. Canvas rendering engine\. Reactive signals\. All running in WebAssembly\. Side\-by\-side with Svelte 5\.
## Building something withNectar?
Kicking the tires, want early access, or just have thoughts? Drop your email and I'll reach out\. It's one person building this, so it comes straight to me\.
Similar Articles
Show HN: Nub – A Bun-like all-in-one toolkit for Node.js
Nub is a fast all-in-one toolkit for Node.js that provides a Bun-like developer experience, including running TypeScript files, managing dependencies, and Node versions, all in one CLI tool written in Rust.
Show HN: Firefox in WebAssembly
Firefox is compiled to run in WebAssembly, using WebGL-based rendering and an experimental JS-to-WASM JIT, with web content proxied through a Puter-hosted Wisp server.
Show HN: Nibble
Nibble is a C-like systems programming language implemented in 3000 lines of C that generates LLVM IR without external dependencies or heap allocations. It supports defer, recursion, various types, structs, pointers, and includes graphical demos.
@huihoo: NASA open-sources an aviation-standard WebAssembly interpreter written in Rust https://github.com/nasa/spacewasm Recently, there have been many open-source projects rewritten or reimplemented in #Rust; hold on tight!
NASA has open-sourced SpaceWasm, a WebAssembly interpreter written in Rust that meets aviation standards, designed for spacecraft onboard environments, supporting streaming decoding and deterministic memory allocation.
@colinhacks: Introducing Nub. The all-in-one JavaScript toolkit that augments Node.js (instead of trying to replace it)
Introducing Nub, an all-in-one JavaScript toolkit that augments Node.js instead of replacing it.