HN Explorer

Show HN: Nectar, a Rust-like React that compiles to WebAssembly (buildnectar.com)

2 points by blakeburnette ↗ HN
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.

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.

What it is right now:

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

Honest status, because this is early and it is mostly one person:

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

Live demo, 10,000 products with a canvas rendering engine, plus a side by side against Svelte 5: https://buildnectar.com/app/canvas

Site: https://buildnectar.com Code: https://github.com/HibiscusConsulting/nectar-lang

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.

17 comments

[ 3.8 ms ] story [ 44.1 ms ] thread
debdattabasu
This is genuinely very useful. In rust all you have is egui which is amazing but no proper ergonomic setup. Floem is a serious contender here but you went with a different approach. Watching this closely because I have some requirement where I need same codebase to work in desktop without electron and on wasm single binary single canvas.

How is your system different from floem? Are you doing pure immediate mode or retained mode partially? What are you using for 2d? Is this portable between webgl and webgpu? Do you need help? I am happy to drive this along if this is useful.

cyberclimb
Nice! Heads up that unfortunately the demos don't appear to scroll on mobile
blakeburnette
Mobile and scroll. Yeah. I have been struggling with these.

I need to add some love into those two areas for sure. As well as Safari and edge cases, etc. If anyone wants to contribute...

barefootford
Demos dead on iOS on iPhone 16 pro.
LoganDark
Safari on my Mac can't run it either, but Chrome can.

In Safari, the page seems to render once, and if I resize the window, it just stretches the canvas? The thing seems to die after rendering one frame.

Tistron
Demo does not work in Fx on android
cush
Wow that demo is slow on iOS
josephg
How is this different / better than Leptos or Dioxus?

https://leptos.dev/

https://dioxuslabs.com/

tekacs
I have the same question, but it doesn't look like this is actually Rust code; it's just a compiler for their custom... syntax (?) written in Rust.
blakeburnette
Largely the difference, as I am aware of those two options. They build on the traditional DOM. I took this approach, and as I was attempting to speed processes up I was consistently running into issues where I was beholden to C++ and Blink. The more I tried to beat Svelte, it seemed that I was hitting limitations with traditional web architectures, javascript and the DOM itself. They are fantastic options. I support writing Rust everywhere. But I was kind of over the many issues with JS (security, performance limitations, etc...). I had a vague curiosity about the ability to abandon the traditional DOM, thoughts on WASM and long story short I went for it. So what you are seeing is not a traditional DOM, inspect the demo page and compare it to the Svelte demo. I built my own DOM, but when you compile Nectar it automatically gets picked up as a traditional DOM by screen readers and SEO (this still needs some love). Initial loads, I am still really struggling with, but sorts and filters are quite performant.
kin
This is neat. It's like a framework and language in one. Congrats on the launch! The tooling for it feels quite novel. I get the allure of having zero dependencies but... the reason why I have dependencies in the first place is because the ecosystem provides tons of functionality out of the box. Do you want the language/framework to provide all the functionality?

The landing page's main value prop is removing the dependency on JS. Thing is... I don't hate JS. Typescript has quite a lot of fans.

I feel like you should demonstrate performance metrics or app size or just some other value prop other than hating on Javascript.

opem
Demos are not usable on android/chromium. Can't scroll or interact with the elements, clicking the buttons works but only sometimes and the rest of the time flashes a skyblue overlay.
ricardobeat
The Svelte demo (which does work on mobile, unlike the nectar version) seems a bit misleading. You won’t be rendering and filtering 10000 items on the screen, and if you do for some kind of UI, there are more performant ways to do it. A less biased benchmark would make a better case.
blakeburnette
I totally get the benchmark is arbitrary for most usecases. I have gone back and forth on how to benchmark this, what's repeatable, what's fair, etc... What you see is largely me building something that lets me test performance, and rendering 10k rows with no virtualization is deliberately the dumbest possible case, it's a stress test, not a recommendation.
dcsommer
What is the binary size comparison including wasm + js?
blakeburnette
Since this is still in development, it fluctuates slightly, but the floor is effectively

WASM - 374KB Raw || 148KB gzipped

JS and HTML - 31KB Raw || 8KB gzipped

Total - 404KB Raw || TLDR; 156KB for the end user

blakeburnette
I appreciate all of your feedback so far. It is incredibly helpful. Everyone in this room is so much smarter than I am so thank you for helping point me in the right direction. And of course if anyone wants to contribute, I would love nothing more than that.