Redbean is just 155Kb without the need for alpine or any other dependency. You just copy the Redbean binary and your static assets, no complicated build steps and hundred MB download necessary. Check it out: https://github.com/kissgyorgy/redbean-docker
I believe the best chance we have of [building binaries "to stand the test of time with minimal toil"], is by gluing together the binary interfaces that've already achieved a decades-long consensus, and ignoring the APIs. . . . Platforms can't break them without breaking themselves.
The term 'battle tested' has nothing to do with amount of features, it's about how proven the stability and/or security of the included features included are. The term also usually carries a heavy weight towards older systems that have been used in production for a long time since those have had more time to weather bugs that are only caught in real-world use.
Yes but it's nice to have the SSL built-in for when you want it. Web servers like Varnish and thttpd take a really hard stance on the issue, where they don't want to touch the crypto at all. Honestly, I don't blame them because implementing SSL is prodigiously technical and emotional. One of the things I do is I offer a file called redbean-unsecure.com that has zero-security baked-in so that folks who love redbean but want to handle the security separately themselves can do so. But like I said when we don't have strong opinions on separation of concerns, having a fast snappy tiny zero config SSL is nice.
"Battle tested" typically means that the code has been running for a long time, bugs found, bugs squashed, and a stability has been attained for a long time. It's usage predates the "information wars", back when we really didn't think about security that much because nothing was connected to anything else that went outside the companies, so there were no hackers or security battles back then. So I suspect this is the authors frame of reference.
