4 ms·

> You should use www because today you have a small web site, and tomorrow you want a big web site. Really big. So Twitter, Pocket, Github, Trello...are all do

> You should use www because today you have a small web site, and tomorrow you want a big web site. Really big. So Twitter, Pocket, Github, Trello...are all doing it wrong? I really don't think this matters more, and I think that the non-www version makes a web address so much more readable.

ymse 11y ago
It only matters if you intend (or require) to CNAME your main site off to some other DNS name. If you're serving your entire site from S3 for example, you can't just alias yoursite.com to your-bucket.s3.amazonaws.com, but you can CNAME www.yoursite.com and have a small server sitting on yoursite.com sending a 301 redirect for every request. Github and Twitter are large enough to not care. And if you're using something like Cloudflare, they can just take over your IP address with BGP, no DNS trickery needed. I've worked a sysadmin for more than 10 years now, and never realized that it's not possible to CNAME the domain root. It's good to keep in mind, but in most cases there are other workarounds. This is also why "naked domains" set up a whole other domain for static files rather than "static.yoursite.com", to avoid the "top-level" cookie (megacookie?) being sent with every request.
- developer2 11y ago
  By the way, even the CNAME on root domain is no longer a concern if you are already using AWS. Route 53 has supported CNAME on root domain for quite some time now: https://aws.amazon.com/blogs/aws/root-domain-website-hosting-for-amazon-s3/ https://aws.amazon.com/blogs/aws/root-domain-website-hosting...
  - treve 11y ago
    It's not a true CNAME, but rather a sort of server-side translator to make it behave as a CNAME while really just returning A/AAAA records. It's more like the 'ALIAS' record.
- elithrar 11y ago
  > I've worked a sysadmin for more than 10 years now, and never realized that it's not possible to CNAME the domain root. It's good to keep in mind, but in most cases there are other workarounds. The common approach is called CNAME flattening, where you can specify a CNAME at the root and your DNS provider 'flattens' that by resolving the A/AAAA record at the end of the CNAME chain. e.g. CloudFlare's approach: https://support.cloudflare.com/hc/en-us/articles/200169056-CNAME-Flattening-RFC-compliant-support-for-CNAME-at-the-root https://support.cloudflare.com/hc/en-us/articles/200169056-C...
- lucaspiller 11y ago
  > And if you're using something like Cloudflare, they can just take over your IP address with BGP, no DNS trickery needed. Why can't Heroku and such say 'put this IP as an A record' and do the same if they have issues with that particular server?
- skrause 11y ago
  > If you're serving your entire site from S3 for example, you can't just alias yoursite.com to your-bucket.s3.amazonaws.com You can if you also use Amazon's Route 53 service which can resolve the A record of your naked domain directly to a S3 bucket or CloudFront endpoint. They call it an Alias record: http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/res...
gavinpc 11y ago
Not to mention archive.org. If they don't care about archival URL's, I'm not sure who does. Edit: the answer is probably http://longbets.org/ http://longbets.org/
developer2 11y ago
The advice being given by the OP is outdated. The only relevant point is the CNAME for load balancing which, unless you are on AWS which permits CNAMEs on root domains, can be a restriction. Everything else is advice from someone who still thinks it's 1995. The norm now is for naked domains. www is a concept that has vanished from the "real world" that most of us live in here in 2016. It's natural to hang onto things that you grew up with, and the "I should use www" is one of those things. It used to be the norm. This is no longer the case, and there are few arguments to support keeping it other than "it's what I originally learned to use".
- wfunction 11y ago
  > The advice being given by the OP is outdated. The only relevant point is the CNAME for load balancing > Everything else is advice from someone who still thinks it's 1995 What about the part about cookies and static content? Why do you consider that inapplicable nowadays?
  - developer2 11y ago
    Cookies are broken down into two possible situations: 1. Serving of static content from a CDN on a separate hostname than the web servers. First of all, 99% of companies do not fall under the umbrella where saving the few bytes of the cookie request header is going to save you many Mbps/Gbps/packets of bandwidth. For most of us, having our example.com cookies unnecessarily sent to static.example.com isn't a big deal. Secondly, this is remedied by using a separate domain name for your CDN rather than a subdomain. Example: Facebook uses fbcdn.net rather than a subdomain on facebook.com - even though they do still use the www prefix. 2. You want separate "sections" to your website, akin to Google's mail.google.com, news.google.com, images.google.com, maps.google.com, etc. Maybe you want the cookies for your root domain to only be sent to that root domain and not all your subdomains. This is not completely ignorable, but I have personally not seen a situation where cookies on the root domain or www cannot/should not be able to be shared across subdomains. I just find it odd that www is still considered a convention by some. If you're redirecting the root to www anyway, there is no reason to use www. You may as well use hi.example.com as your primary domain and just redirect example.com to hi.example.com. www has no intrinsic meaning, it's just a regular subdomain with DNS records like any other subdomain.

ymse 11y ago

It only matters if you intend (or require) to CNAME your main site off to some other DNS name. If you're serving your entire site from S3 for example, you can't just alias yoursite.com to your-bucket.s3.amazonaws.com, but you can CNAME www.yoursite.com and have a small server sitting on yoursite.com sending a 301 redirect for every request. Github and Twitter are large enough to not care. And if you're using something like Cloudflare, they can just take over your IP address with BGP, no DNS trickery needed. I've worked a sysadmin for more than 10 years now, and never realized that it's not possible to CNAME the domain root. It's good to keep in mind, but in most cases there are other workarounds. This is also why "naked domains" set up a whole other domain for static files rather than "static.yoursite.com", to avoid the "top-level" cookie (megacookie?) being sent with every request.

developer2 11y ago
By the way, even the CNAME on root domain is no longer a concern if you are already using AWS. Route 53 has supported CNAME on root domain for quite some time now: https://aws.amazon.com/blogs/aws/root-domain-website-hosting-for-amazon-s3/ https://aws.amazon.com/blogs/aws/root-domain-website-hosting...
- treve 11y ago
  It's not a true CNAME, but rather a sort of server-side translator to make it behave as a CNAME while really just returning A/AAAA records. It's more like the 'ALIAS' record.
elithrar 11y ago
> I've worked a sysadmin for more than 10 years now, and never realized that it's not possible to CNAME the domain root. It's good to keep in mind, but in most cases there are other workarounds. The common approach is called CNAME flattening, where you can specify a CNAME at the root and your DNS provider 'flattens' that by resolving the A/AAAA record at the end of the CNAME chain. e.g. CloudFlare's approach: https://support.cloudflare.com/hc/en-us/articles/200169056-CNAME-Flattening-RFC-compliant-support-for-CNAME-at-the-root https://support.cloudflare.com/hc/en-us/articles/200169056-C...
lucaspiller 11y ago
> And if you're using something like Cloudflare, they can just take over your IP address with BGP, no DNS trickery needed. Why can't Heroku and such say 'put this IP as an A record' and do the same if they have issues with that particular server?
skrause 11y ago
> If you're serving your entire site from S3 for example, you can't just alias yoursite.com to your-bucket.s3.amazonaws.com You can if you also use Amazon's Route 53 service which can resolve the A record of your naked domain directly to a S3 bucket or CloudFront endpoint. They call it an Alias record: http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/res...

gavinpc 11y ago

Not to mention archive.org. If they don't care about archival URL's, I'm not sure who does. Edit: the answer is probably http://longbets.org/ http://longbets.org/

developer2 11y ago

The advice being given by the OP is outdated. The only relevant point is the CNAME for load balancing which, unless you are on AWS which permits CNAMEs on root domains, can be a restriction. Everything else is advice from someone who still thinks it's 1995. The norm now is for naked domains. www is a concept that has vanished from the "real world" that most of us live in here in 2016. It's natural to hang onto things that you grew up with, and the "I should use www" is one of those things. It used to be the norm. This is no longer the case, and there are few arguments to support keeping it other than "it's what I originally learned to use".

wfunction 11y ago
> The advice being given by the OP is outdated. The only relevant point is the CNAME for load balancing > Everything else is advice from someone who still thinks it's 1995 What about the part about cookies and static content? Why do you consider that inapplicable nowadays?
- developer2 11y ago
  Cookies are broken down into two possible situations: 1. Serving of static content from a CDN on a separate hostname than the web servers. First of all, 99% of companies do not fall under the umbrella where saving the few bytes of the cookie request header is going to save you many Mbps/Gbps/packets of bandwidth. For most of us, having our example.com cookies unnecessarily sent to static.example.com isn't a big deal. Secondly, this is remedied by using a separate domain name for your CDN rather than a subdomain. Example: Facebook uses fbcdn.net rather than a subdomain on facebook.com - even though they do still use the www prefix. 2. You want separate "sections" to your website, akin to Google's mail.google.com, news.google.com, images.google.com, maps.google.com, etc. Maybe you want the cookies for your root domain to only be sent to that root domain and not all your subdomains. This is not completely ignorable, but I have personally not seen a situation where cookies on the root domain or www cannot/should not be able to be shared across subdomains. I just find it odd that www is still considered a convention by some. If you're redirecting the root to www anyway, there is no reason to use www. You may as well use hi.example.com as your primary domain and just redirect example.com to hi.example.com. www has no intrinsic meaning, it's just a regular subdomain with DNS records like any other subdomain.