subdomain vs. subdirectory in web programming

Question

Besides the fact that from a security standpoint it is a bit easier to isolate an app within a subdomain, I will just comment on what I think is the biggest difference between the two.

Pro's for subdomains:

• You can isolate configuration (for for example apache) per-domain.
• It will be easier to migrate parts of your application to other machines. Sub-directories won't really give you this flexibility.
• Instead of having to use a $baseUri variable in every html template, you can just assume the root of the app is always /.

Cons:

• It will be much more annoying to quickly setup staging or temporary development environments. For every 'app' you will now need DNS of hosts-file entries and webserver configuration. With subdirectories you could drop the app in a directory, and go!
• If you do ever have the requirement to deploy your application on a different system where using / is because of some odd policy not possible, some rewriting might be in order.

My advice:

Make sure you can always do both, which will give you the best of both worlds. Every part of your app should have a configurable base uri that is always respected. As long as you make sure you can always go both ways, then who cares what you do? it's just a url and it can always be changed.

• In terms of code organization: The differences are nil, as you can map subdomains to any directory.
• In terms of browser security: JavaScript access across subdomains is possible but has obstacles (see document.domain and consorts). I do not know of anything on the JavaScript side that is completely impossible when working with different sub-domains.

Opinion:

I personally tend towards directories and against subdomains for public addresses. The general public have become used to web addresses beginning with "www." and it creates unnecessary confusion to break this pattern. You will notice that very often people, when given a subdomain to type into the address bar, will automatically start typing in "www." and they will be surprised to learn that an address can be without.

To me, the only good way to use subdomains is for internal purposes to facilitate, or prepare for, the use of different servers (e.g. static.example.com, images.example.com etc.)

Personally, I prefer using a subdomain for each application, and then the sub-dirs (whether they are actually sub-directories or not -- preferably they are just re-routed to /index.php by a .htaccess) to denote different states of that application. For example:

admin.blah.com/users/1234/bob,
admin.blah.com/pages/4321/title,
blog.blah.com/archives/2007/5678/title, etc.

The subdomain tells you where you are, and the sub-directories tell you what you're doing.

• You can easily 'do' virtual servers on subdomains.
• You can separate out subdomains to different cookies.

You'd be best off recognizing that subdomains are a "major" separation in Web space, and subdirectories a "minor" one. Subdomains are for, well, different domains; you could have different people running different applications on different subdomains. Subdirectories are partitions of a single (sub)domain, separating perhaps different applications by the same user.

Web standards are intentionally very open, but the more you abuse them to create strange hierarchies, the more that will bite you in the end.

One of the major advantages of sub-domains is the files they point to can be contained anywhere -- even on another server. My most common usage of a sub-domain is on going development of a live project. For example, you could create the sub-domain:

dev.example.com

and make a copy of your live site, including the entire directory structure. Drop in an .htaccess file to refuse connections from anyone but you and your client's IP, and use this to make changes until the updates are ready to be pushed live.

There have been excellent answers already, so you could check out these links anytime.

• Subdomains and subdirectories

• Sub Domain Vs Sub Directory