Why do you think it is a strength that git is "not bundling the kitchen sink"? I'd like to understand better why other people prefer kitchen sink vs multiple binaries.
I am in two minds when it comes to this. A lot of (server) software I write bundles server, client and tools in the same binary. I also embed the API documentation, the OpenAPI files, the documentation and sometimes related documentation in the binary so that it can be served on an endpoint on the server or extracted.
So you have one binary, statically linked whenever possible, that contains everything you will need. And where everything is the same release as everything else, so there are no chances you'll end up with different versions of client, server, documentation, tooling etc.
The binary size doesn't concern me. I could easily increase the binary size tenfold, and it still wouldn't be a problem for the software I write. I don't think binary size is a big concern today since so much software "splats" files all over your system anyway (which I think is a horrific way to do things), so footprints tend to be somewhat large anyway.
What occasionally does concern me is that this might be confusing to the user. But it is possible to make things confusing for the user even if a piece of software is more focused (ie does "one thing"). One example is CLI utilities that have multiple screenfuls of `--help` output. To me, that's poor usability. Users end up resizing terminal windows, scrolling back and forth (when you deal with related options) and perhaps even resorting to grep or less to find what you are looking for.
I try to mitigate this by always structuring CLI applications with commands and subcommands. Where you can do --help at each level. Quite a few CLI applications do this and I think it helps.
This summer I wrote the first piece of software in perhaps half a decade that has separate binaries for the client and the server. Because I want to share the client code, but not the server code. While the split was unrelated to usability, I've started asking myself if this presents a better user experience. I haven't really been able to conclude.
I am in two minds when it comes to this. A lot of (server) software I write bundles server, client and tools in the same binary. I also embed the API documentation, the OpenAPI files, the documentation and sometimes related documentation in the binary so that it can be served on an endpoint on the server or extracted.
So you have one binary, statically linked whenever possible, that contains everything you will need. And where everything is the same release as everything else, so there are no chances you'll end up with different versions of client, server, documentation, tooling etc.
The binary size doesn't concern me. I could easily increase the binary size tenfold, and it still wouldn't be a problem for the software I write. I don't think binary size is a big concern today since so much software "splats" files all over your system anyway (which I think is a horrific way to do things), so footprints tend to be somewhat large anyway.
What occasionally does concern me is that this might be confusing to the user. But it is possible to make things confusing for the user even if a piece of software is more focused (ie does "one thing"). One example is CLI utilities that have multiple screenfuls of `--help` output. To me, that's poor usability. Users end up resizing terminal windows, scrolling back and forth (when you deal with related options) and perhaps even resorting to grep or less to find what you are looking for.
I try to mitigate this by always structuring CLI applications with commands and subcommands. Where you can do --help at each level. Quite a few CLI applications do this and I think it helps.
This summer I wrote the first piece of software in perhaps half a decade that has separate binaries for the client and the server. Because I want to share the client code, but not the server code. While the split was unrelated to usability, I've started asking myself if this presents a better user experience. I haven't really been able to conclude.