To the extent that I'm interested in webassembly, it's with the idea of being able to run a desktop app in a web browser.

One of the nice things with YNAB is the ability to see multiple months at once - in effect a spreadsheet view where categories are rows, and the columns are months. And changing the budgeted amount in one category cascades a balance forward across the months.

One of my key goals with my app design is to do those calculations client side (on the desktop/phone/browser) and not on a central server (which causes scalability issues when lots of people try to budget at the start of a month.)

The number of transactions entered is actually small - the number of calculations required to determine category balances for a month's view are much higher.

Another goal for me is supporting multiple devices per budget (both myself and my wife using our phones) and offline operation (so I can enter a transaction while in a big warehouse store with poor data reception.) So devices are a source of transactions, but balances are never stored (except in a local device cache) and are discarded when transactions from other devices arrive.

I'm also working to design transactions to represent the creation of categories (accounts in your perspective) and their ordering, renaming, hiding, etc. These are in addition to the journal transactions you're describing above. I also have budget transactions, which represent the movement of budget values between categories. So each category has two balances within a period, one's the sum of the budget transactions, and the other's the sum of actual transactions.

A further distinction for me is that journal transactions have 2 dates, one is the date the transaction took place, the other represents the budget period (the column in the view) in which the transaction applies.