There's something to be said for the social availability that github brings. I'm far more likely to submit a pr for a bugfix to a project on gh than a random self-host site.
You can do your own ci/cd runner system, but you still rely on webhooks or triggers, when you aren't hosting the code.
> There's something to be said for the social availability that github brings. I'm far more likely to submit a pr for a bugfix to a project on gh than a random self-host site.
Yeah, that used to be the single favorable argument for GitHub, nowadays I think it might be the opposite, at least personally. If the contributor can't be arsed to join the community proper (and maybe get a sign-in code to their email, or whatever login you use), I think I prefer life without their drive-by PRs.
It's funny, my first thought with multiple render paths was specifically for htmx integrations... Such as a full render or just a main component render. There are extensions for C#/razor that with really well for this.
Would be cool to do the same with rust. That said, I didn't know how hard that would be with this framework. There are of course a lot of different limitations with ssr vs soa.
I'm really sad about the announcement and that the Deno runtime as it was is going away. I'll definitely be following and likely using an active fork if it presents one.
I've been using Deno a lot for straight shell scripting. Being able to link directly to dependencies and run without a separate install step or node_modules directory is huge. The fact that it's a single binary download and can self update is so nice too.
I'm not sure if these features are similar for Bun or not. I'm just sad about the whole thing.
The et in etc (et cetera) being Latin "and" (in essentially "and so forth"). The ampersand is said to have started as a very stylized "E" and "t" merged together, so it does have an interesting historic appropriateness in &c.
That's a large part of why I lean more and more into just preferring sqlite for applications.
Even in work environments for apps that likely won't have thousands of simultaneous users. Modern SSD drives are so fast that so many apps don't need the advanced features of a full blown rdbms. And I think options like Turso and Cloudflare D1 fill the in between as a hosted option.
I do wish that sqlite had a couple more native types, it works really well as it stands.
All my home server apps are in /apps/app-name/ all have a docker config... All data and configurations are mounts under that directory or to my library. It's really straight forward.
I don't have to hunt for different configuration files, each app has what it needs.
I can spin down, move and get back up in a minute or two. All in a consistent way to the platform.
The overhead for Docker isn't near a full vm, it's maybe 2-3% if that.
>The overhead for Docker isn't near a full vm, it's maybe 2-3% if that.
Interesting, I run audiobookshelf bare metal on my old laptop that only has 8gb of ram. I've considered using a docker container but my experience using rancher for work is that it sits there chewing up 4GB of ram on my company MBP.
Maybe I'm wrong but I've never seen the point in a self hosted app running in a container when it seems much lighter to just run the app?
That's close to my workflow as well... keeping planned areas in TODO.md, done changes in DONE.md, and a non-committed WORKING.md for the current work being done, as well as coordination with sub-agents, so I can view/monitor... have to direct the latter each time to have it done that way.
I spent part of last week, and the weekend, in Claude (Fable) on a documentation project... maybe a waste to use Fable, but been a little obsessed with trying to get the technical details right. I know, from personal history, more than some of the available info easily found on the subject. I let a lot of it just go, and swing for the fences, but in the end, did hand review all the output at each stem.
In my specific case, implementing modern documentation for Remote Imaging Protocol (and old graphics protocol for terminal/bbs usage), and in particular trying to gather what exists of the later version released. The company itself folded, and there wasn't a lot of broad use of the later versions, and only partial information was ever released as a documentation. Claude was able to interrogate the apps, and some available open source, in progress work, and establish a lot of things.
I've still got to direct some edits... I guided a re-flow of the order the documentation was written in, particularly to be consistent between the versions... but it obsessively added verbose summaries to every page/file. All markdown, meant to build a website from, and eventually some compatibility tests, guidelines and a green/open implementation.
reply