Comments URL: https://news.ycombinator.com/item?id=50132526

Points: 2

# Comments: 0

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.

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

For context, the problem with Vec 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

Video on multi-target rendering: https://youtu.be/pJx84jdBDKU?si=HRRd6dgUWXiqeWhq

Benchmarks: https://github.com/Proa-Labs/proa-benchmarks

Comments URL: https://news.ycombinator.com/item?id=50105467

Points: 107

# Comments: 36

Comments URL: https://news.ycombinator.com/item?id=48729153

Points: 1

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=48009819

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=45638892

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=44357722

Points: 15

# Comments: 6