Show HN: Proa – A Rust web framework with fast SSR and multi-target rendering
proa.soVideo on multi-target rendering: https://youtu.be/pJx84jdBDKU?si=HRRd6dgUWXiqeWhq
Benchmarks: https://github.com/Proa-Labs/proa-benchmarks
By default, WebContext composes RenderBuffer (but it can be overriden via generics) which uses fixed-size 4 KiB pages. When a page runs out of room, it adds another page without moving the HTML already written. This avoids copying the accumulated output during growth! Its designed to be a performance improvement over Vec<u8>
For context, the problem with Vec<u8> is that every time a vector reaches maximum capacity, it has to reallocate a new area of memory (typically 2x larger than the previous allocation) and then copy everything into that new buffer. This adds a ton of overhead, especially if you're writing large pages.
Checkout https://github.com/Proa-Labs/proa/blob/384136f87fc9f91747477... if you're curious about RenderBuffer's design
One nit: Forgive me if I'm missing something but why do you have pro components? Won't people vibe-code clones anyway? I'd rather have a donate button these days.
PLus you're missing the licensing aspect, part of this is AGPL if you use the free version, lots of places are happy to throw down money to get a commercial license rather than hem and haw over AGPL.
Since I don't believe the maintenance challenges of a non-unified model are particularly high-friction in the LLM era (even if they may be error-prone, since that is usually solved with CI/CD or TDD), the nominal utility of this angle of architectural enhancement is considered dubious.
With regard to speed, there is no hardware shortage at present for any of these simple rendering tasks.
Overall, a nice efficient codebase but suffering a bit from NIH syndrome solving no particularly acute problem. Unless a community forms rapidly, this will probably die.
I'd like to see the benchmark compared to, eg. static files served with binserve.
Also, I think it's exciting to see so many rust web frameworks popping up but I'm in total decision paralysis. If I want to build something with rust now there are at least 3 complete frameworks: loco, topcoat and now proa... plus actix, rocket, axum, and ...more?
No such thing as silly questions! Yes there are cases where it can be inferred from one to the other, but in many cases you may want to be very specific about how you author the markdown view. I'll give you a few examples:
1. Custom components: For example, let's say you have a carousel component. It's not really straightforward to infer the markdown from this. But you probably want the carousel to render as a series of markdown image tags. A custom view would be helpful for this. Same goes for Calendars, SVG charts, Diagrams, form inputs, tabs, popovers, and more.
2. Information omission: Agents don't need all of the information on your page. For example, a dark/light button... probably doesn't need a markdown equivalent. But a button that is an anchor tag that links to another page, probably you should keep. So having the ability to custom author the markdown render target based on the data it's rendering is helpful.
One of the unique aspects of Proa's authoring model is that it supports composability of Markdown components, just like JSX, which is I think one of its standout features. And you can embed native control flow (if, loops, match, etc.) directly in the md!{} macro just like you could with JSX. https://www.youtube.com/watch?v=pJx84jdBDKU&t=21s explains it quite well if you're interested. Makes the readability and code ergonomics much much better.
> it's exciting to see so many rust web frameworks popping up but I'm in total decision paralysis.
I am a bit biased here but I think Proa is the most complete framework currently for building a production web application in Rust. I know its newer and doesn't have as many stars, but maybe I can point you to three things to see if it gives you more confidence:
1. Data loading: https://proa.so/docs/framework/data-loading 2. Browser interactivity: https://proa.so/docs/rsjs/signals (all in rust btw) 3. Security: https://proa.so/docs/framework/security-headers
Proa, Proa UI, latency.so, and a few other sites are all using Proa in production. It's the fastest SSR framework in production (https://github.com/Proa-Labs/proa-benchmarks) and supports streaming SSR (checkout the streaming SSR benchmark), suspense, etc. And it's server framework agnostic so you can use it with actix, axum, and other frameworks if you want.
Would be cool to do the same with rust. That said, I didn't know how hard that would be with this framework. There are of course a lot of different limitations with ssr vs soa.
I could drop the react ecosystem given considerable improvement over it at the deployment part
Especially since years of experience with frameworks doesnt matter anymore and won’t matter with recruitment soon
doesnt that determine runtime performance for web apps, unless the browser is running rust natively or maybe wasm, I don’t see how javascript for example would be more performant just because I configured it in rust
And then this shows up.
https://github.com/rust-lang/rust/issues/164348#issuecomment...
A bug as careless as can be. Relying wantonly on hashing for equality checking, without even wondering about the specific hash's collision probability.