This might be a silly question, but why 2 views for html and markdown? isn't there a broad base of cases where one can just be inferred from the other?
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?
I highly recommend! I've been writing Rust professionally for 5 years now. Compile times are slow but I love the language. https://cheats.rs/ is a resource i go back to often in case you're interested in learning more. Especially since as you get more into it, Rust has a lot of weird types like RefCell and Cell and OnceCell and disambiguating between them is a chore sometimes. Hope it helps!
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.
Hey! Author of Proa here, thanks for checking it out! The idea is to just accelerate the time it takes to create components, similar to Shadcn or other component libraries. You can create a new component and modify them however you like. It’s nice because they have both the WebRender and MdRender trait implemented, and saves you a bit of time. Also for slightly more complex components like Calendar, we’ve crafted the component with all the JS interactivity required to do things like switch months, select start and end date, etc
This looks really cool! I’ve been really appreciating the revival of old-school server side rendering and foundational web components, but with modern tools or approaches.
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.
This looks amazing, really appreciate your minimal JavaScript approach. I’ll definitely try it out, could see myself potentially doing pro version in future.
Hey great question! WebContext owns an output buffer (i.e., RenderBuffer) that components write HTML into directly, avoiding intermediate allocations and copying. It needs to be mutable for this reason. This is one of the key ways we're able to make Proa the fastest server-side rendering engine on the market.
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.
I can't speak for the others as I am not as familiar with how they're engineered, but with Proa I spent a painstaking amount of time to try and move as much of the work to compile time as possible and being really careful about how memory is allocated. And a lot of those small improvements add up over time!
This might be a silly question, but why 2 views for html and markdown? isn't there a broad base of cases where one can just be inferred from the other?
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?
I would be mostly curious about CI/CD and build and deployment times on underpowered compute instances
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
Damn, projects like these really spark my curiosity about Rust. I guess it's time to try it out, fomo is getting too big haha
I highly recommend! I've been writing Rust professionally for 5 years now. Compile times are slow but I love the language. https://cheats.rs/ is a resource i go back to often in case you're interested in learning more. Especially since as you get more into it, Rust has a lot of weird types like RefCell and Cell and OnceCell and disambiguating between them is a chore sometimes. Hope it helps!
Very cool idea, I'm going to test this!
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.
Hey! Author of Proa here, thanks for checking it out! The idea is to just accelerate the time it takes to create components, similar to Shadcn or other component libraries. You can create a new component and modify them however you like. It’s nice because they have both the WebRender and MdRender trait implemented, and saves you a bit of time. Also for slightly more complex components like Calendar, we’ve crafted the component with all the JS interactivity required to do things like switch months, select start and end date, etc
This looks really cool! I’ve been really appreciating the revival of old-school server side rendering and foundational web components, but with modern tools or approaches.
That's very kind of you, appreciate it man! Thanks!
So... Multi-target = {chat, web, markdown}; Audience = {human, bot}; USPs = {speed, unified model}
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.
This looks amazing, really appreciate your minimal JavaScript approach. I’ll definitely try it out, could see myself potentially doing pro version in future.
Why does `fn render` need to borrow WebContext mutably?
Hey great question! WebContext owns an output buffer (i.e., RenderBuffer) that components write HTML into directly, avoiding intermediate allocations and copying. It needs to be mutable for this reason. This is one of the key ways we're able to make Proa the fastest server-side rendering engine on the market.
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
Can I get a TLDR of why Proa is seemingly so much faster tha existing Rust web frameworks (Dioxus, Leptos, Topcoat)?
I can't speak for the others as I am not as familiar with how they're engineered, but with Proa I spent a painstaking amount of time to try and move as much of the work to compile time as possible and being really careful about how memory is allocated. And a lot of those small improvements add up over time!