[jrockway]

I feel like x.example.com is preferred over example.com/x because it is simpler to move the files around (when you want the same app/bundle of static files to be y.example.com). Browsers by default will make <a href="/foo/bar.html"> into x.example.com/foo/bar.html when served from x.example.com, but it won't make it into example.com/x/foo/bar.html when served from example.com/x/; something else has to make sure the URLs are correct. The options available to make links work are to generate correct links in the first place (CGI back in the day provided enough information to make this possible, but modern reverse proxies have no way to convey this), never use absolute paths in links (restrictive), or to have some machinery intercept the document, parse the HTML, and rewrite links (super flaky). If you are always going to be at exmaple.com/x/ and never need to change the base URL, you can make it work. If you are making something reusable that people download and self-host, you will pull all your hair out making the /x/ case work well. Therefore, people tend to prefer the subdomain approach. It's just easier, because of an implicit base URL assumed by browsers (and even things like grpc clients). When you try to override defaults, it's like rolling a stone up an infinitely long hill. This is that, I think.

For your blog, it doesn't matter. You can hard-code the entire URL in every link and it will probably never go wrong. Applications are harder. Applications that various people are going to self-host are hardest.

[wbl]

Reverse proxies do pass the host header which is all you need.

[jrockway]

I'm talking about the case where your application is being served at, say, localhost:1234 but the reverse proxy thinks it's example.com/some/sub/path; as far as I know there is no header that says "add /some/sub/path to every URL you generate". (Yes, Host tells you the base is example.com.)