If the single binary that just serves static files you're better off with a web server that supports https, rules, vhosts, etc and is battle tested. Not to mention that this binary you created will need startup scripts of some sort depending on the platform.
I'm pretty sure the use case of this is more akin to an electron replacement, and not a production web server. So the user would just download and run the binary, and interact with the app from their browser.
Strange how some people are obsessed with hype. I think what raised interest of this article was just word "Rust" in the title. Rust seems to be wet dream of many developers. They heard it's safe, so it will magically solve all their problems. But the usage of Rust in this case is meaningless. You could do the same with python, nodejs, java, just plain nginx or million other (and better) ways. Just first google query returned probably better solution if you like single static binary http://miniweb.sourceforge.net/. It would be two files instead of one miniweb binary and static site compressed as 7z.
How does this thing scale? What about SSL? Do I have to put reverse SSL terminating proxy in front of it? Yes, you say? Ok, why not just use that proxy for serving those static files too (nginx does that) and skip this thing completely. What about performance? Have you tried to httperf on it?
I would appreciate if this did more then just being a single binary. Like Facebook's HipHop compiler of PHP to static executable or something like that. Sorry but this is real bullshit.
There's nothing else to see here, you either like dependency-less binaries or not.
Hell, if anything, I don't see the point of your point, calling static binaries "real bullshit". Depending on the scenario static binaries are either better for you, or worse for you - it's just a tool in a bag of tools. How can that possibly be bullshit? Is a wrench bullshit?
EDIT: I'm not against static binaries per se. Only against this usage of them.
Basically anywhere where reducing difficulty of deployment and asset management outweighs the valid concerns you pointed out. It's really, really handy in my view.
Of course, I've got no plans or desire to run some production documentation site on this. Yet, that problem domain is vastly different than internal tooling, OSS apps, etc.
Just think of a note web app you write. Do you want your users to have to manage css/template/image bundles just to use your note app? Why not just make the binary work with zero configuration/management? Plus, if you wanted - you can of course support both, allowing the user to override css files if they so desire, without having to recompile the binary/etc.
http://miniweb.sourceforge.net/. It would be two files. 20k server binary and 7z with site resources. It would safe me trouble of recompiling binary.
Know any good nginx books or courses?