Good point! We use a database (SQLite or Postgres) to enable more advanced features like versioning, collaboration, and access control, which aren't easily managed with static files alone. The database also allows us to scale better for teams with frequent updates.
While it does limit deployment to platforms like GitHub Pages, Kalmia is designed for teams that need more than just static documentation—think of it as a middle ground between static site generators and fully dynamic CMS solutions. For purely static sites, there are other great options out there, but Kalmia focuses on more interactive, collaborative documentation.
That said, we’re actually interested in providing an option for users to export and deploy it to platforms like GitHub Pages or similar, so stay tuned for future updates on that!
You could look into frontmatter to store metadata within the files, and just load it all into memory on startup. Even for huge projects, that probably won’t hurt anyway.
We already load all the documentation assets into memory whenever something changes. Even with large projects spanning hundreds of pages and page groups, it remains very fast—under 1 second in our testing.
That being said, there are some cases where a database is necessary. For example, handling multiple people editing the same document simultaneously wouldn’t work well with just flat files. Also, where would we store user emails/passwords for authentication? Another feature Kalmia supports is private documentation, where users need to log in to access certain docs (there's a simple toggle to enable authentication).
That said, adding an "export to zip" or "push to git" button is totally feasible, and it's something we've had a lot of requests for. While we don't personally use it, we'll be adding it so people can host their docs on static file platforms without needing Kalmia as the backend.
The nice thing about flat files represented in memory would really be maximum performance, no external data store necessary, and easy portability. I definitely understand that sorting out concurrency by using a DBMS is easier, however.
> Also, where would we store user emails/passwords for authentication?
For this kind of application, I’d strongly recommend (and request from anything I buy) OAuth signin via my existing identity provider. That means I don’t have yet another location for accounts, and you don’t have to worry about storing them securely.
Slightly tangential: if you are hacking on PDFs, manually or otherwise, this is an incredibly useful tool: https://pdfcpu.io/ (not the author, just a user)
Whatever the merits of this project -- and it does seem to be useful -- they should be a little clearer about the fact that it's not actually part of the "official" svelte framework.
I'm sure they consider it a tribute but it fees a little deceptive that they're cloning the svelte docs look and feel without any kind of "who we are" statement.
Moreover, it was made by one of the folks who brought TypeScript support to Svelte (https://github.com/halfnelson/svelte2tsx), so although it may not be explicitly pushed by the core team, it was still made by a significant core contributor.
I'll note that React is the only web renderer that gives official blessing to a native framework, and that's because it's also the only web renderer that built one themselves rather than leaving it to the community.
E.g. your dog would recognize an object that smells like the part of her that you rubbed. Your dog would also notice that it is a static scent, with an age of 1-2 minutes, that continues to fade. Your dog would also recognize your scent (you held the mirror), the scent of the mirror and perhaps some other scents in the air.
Right now my dog is completely numb to mirrors. I'm curious what would make her at least to show some attention. So perhaps there should be a scent dispenser behind the mirror?
Note that we are numb to fire hydrants. I guess we could smell them, but it would’t tell us much.
Meanwhile a sniff of a fire hydrant tells your dog how many other dogs have marked it, how long ago, where did they come from, how old were they, what were they eating, were they healthy, etc.
I don’t plan to sniff fire hydrants though; and for the same reason your dog won’t be interested in mirrors.
Unless they are actually using sight; e.g.: if you’re silent, scent is not a factor (very difficult to achieve), your position is unknown to the dog and someone has placed a mirror so that your dog sees your reflection in that mirror, and you wave - then your dog might spot you and go investigate.
It seems like learned positional encodings would still prevent you from doing fine tuning on a larger context size, though, so maybe using alibi is still relevant (although I have not read that paper).
You've said that twice on this thread. I honestly don't remember; is there a story somewhere? Wasn't there another company (Treo) also building hardware with Palm OS?
