burnrate

I'm going to be making more in the future so make sure to subscribe!

that's very kind of you! thank you

Thank you so much, that's very kind of you! Sounds great! Please feel free to provide any feedback or ways I can make it better for you.

Compile times generally take longer with Rust. It's a trade-off you're making when using anything rust related, but in exchange, you get some pretty sweet runtime perf. But with efficient caching of crates you can claw back a lot of time in CI.

That's very kind of you, thank you! Yes the goal is to make it usable in production! It already powers proa.so, ui.proa.so, latency.so, and a few other sites. Let me know when you build it and I can add it to https://proa.so/ecosystem/apps!

> This might be a silly question, but why 2 views for html and markdown?

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.

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!

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!

That's very kind of you, appreciate it man! Thanks!

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

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

A quick thread on it here as well: https://x.com/drewhariri/status/2071843047508488284

I wonder how much a rack like this costs

It’s 100% to prevent citizens from becoming organized. The regime is most fearful of this.

The Aptos blockchain introduces a Passkey Authenticator that enables users to sign transactions with their Passkey

Visualize how prices for office space in the Bay Area and cities like SF and Manhattan has risen in the last year

Our goal at burnrate.fyi is to help you easily estimate your business' financials. On our site, you can choose from close to 50 different products, services, and expense categories and estimate everything from databases, serverless functions, even employee wages and office leasing costs, and more. Getting accurate estimations for your business' burnrate only takes 3 steps (less than 5 minutes) and NO SIGNUP IS REQUIRED. It's like PCPartPicker for businesses! Consider subscribing to our newsletter here ⇢ https://bit.ly/3jZuy44 to stay updated! Cheers!

I’m Andrew, creator of https://burnrate.fyi. Thanks for checking out my product! I'm a bit of a noob to the hackernews scene, but here’s a brief overview of why I’m making this:

Problem

Cloud SaaS products (ie. AWS EC2, GCP, etc.) have very complicated pricing options and are difficult to compare. Because of this, it's also time-consuming to generate quick, relatively accurate burnrate estimations for your business.

Solution

Burnrate.fyi, the PCPartPicker of SaaS products. Imagine being able to estimate your cloud spend in 5 minutes across service providers, products, and stacks. Burnrate.fyi is here to help you do just that. We have a simplified, curated list of products and categories from Relational Databases, Servers, Authentication, and more. You can easily configure your product and add them to your imaginary cart to see a breakdown of how much you'll be spending per month. We also include things like data transfer (data egress) that aren’t usually factored into pricing estimates. We’re working hard on getting many more products and categories on the platform soon!

How it works

1. Pick a category

2. Configure your product and add to cart

3. View your cart!

Some neat features

- Dark mode

- Sortable and filterable pricing tables

- Imaginary cart with expense distribution

- Chart for comparing different services (ie. servers, dbs, serverless)

- Embedded on-hover definitions for technical jargon and pricing overviews

Product hunt link in case you're interested: https://www.producthunt.com/posts/burnrate-fyi.

Thank you in advance!