I'll push a new release with the license — always forget this!
Thank you for all your observations. Two things: 1) floats were originally purposefully not allowed, for simplicity, but I might change that and 2) multiple groups with the same name are indeed not allowed, but you raise a good point: it should be possible to reference all groups with a common label if the only difference between them is an attached timestamp.
And yes, will definitely push Win/Linux releases soon!
The processor considers monthly income when calculating your projections. It'll sum all credit and debit operations (from all flows) and calculate from there.
> In my mind the simplest form of budgeting is so-called "Envelope Accounting", where you have physical envelopes full of money where you pull money out when you spend it.
Just wanted to give 2 cents on the rationale behind this:
Most people don't budget at all.
Most people live paycheck to paycheck. I have lived paycheck to paycheck for a long time. When your finances are in distress, and you have no planning, the least helpful thing you can do is trying a fully featured app, or even worse, a spreadsheet. It requires a lot of attention to details and they can get overwhelming and confusing to manage — not everyone is fluent in spreadsheet formulas, as basic as they may be, to the point of getting the setup right, and most template spreadsheets available pack a lot of unnecessary things and customizing them becomes a project of its own. There's also the feeling of despair realizing you're not even close to even having that much data or assets to put in. This is not only my opinion — this is what I've gathered asking friends and family on the topic.
So this is a way to keep things simple. Extremely simple. No integration to banks, no mental overhead, just a smart replacement for a piece of paper where you write down your income and your expenses. There is a lot of people that still use a physical notebook to keep track of their finances, in this day and age, out of sheer choice — it's a way to maintain focus on the big picture, and not miss any detail.
It's a way to express your finances in a portable, human-readable format that is essentially computable plain text. You can express your finances at a 10,000-feet level, know what your savings will look like, for motivation, and know where your money is going. This is it. Surely it will be too simple for many, but perhaps just about right for some.
You're also not vendor locked, your data is plain text and you can use the CLI (free and open source) to process it. I myself use the CLI and manage my sheets from Sublime Text. Yep :)
Thank you so much for the feedback — this is a very early iteration.
I've been using it for several years and wanted to get it into an app. I've been getting a lot of suggestions and requests from early adopters. I will definitely take yours into consideration. There's a lot of room for improvements.
Re: GUI limitation, there's a CLI which is open source and free:
It's just part of the starter template, through unocss.
unocss goes beyond what Tailwind does. it's general CSS processing engine and provides quick access to some rather essential goodies, like an icon set. I think it's a worthy addition to the starter template, but easy to remove. Literally remove one import and a vite.config.js plugin entry.
You can think of it as a potential replacement for Nuxt.js, Next.js, SvelteKit, Remix etc, if you're running a live Node server and prefer structuring your app as a Fastify application first.
Nothing, RSS is alive and well. I got to this HN post in a RSS reader. But yeah, if it were up to the BigCos it would be dead already. It's kind of funny to think so many companies sponsored the development of both the RSS2 and Atom specs 15+ years ago, and suddenly they must have realized, "Oopsie, we shouldn't have come anywhere near this thing, EVERYONE BACK AWAY SLOWLY".
Yeah, SSR is pretty much a misnomer in this context, but it's still the term most heavily used to describe server-side rendering JavaScript apps. Like others have said, we're lacking a term for non-JavaScript dependent SSR now.
Nice, I missed that. I'll consider making it PTA-compatible!
Only issue I have is with the indentation-based subitems.
I'd rather keep it restricted to top-level groups for clarity.