Live data from Hacker News

Web Developer Checklist

webdevchecklist.com

61–70 of 77 posts

Re: Web Developer Checklist

#61
post #58
post #56

A no-www domain might not be the best solution if you ever want a 'Cookie-free Domain' (static.) for images etc. which speeds up your site. If you start with a no-www domain you have to setup a different domain (no subdomain) for it: like sstatic.net for SO, ytimg.com for YT and yimg.com for Yahoo. When the browser makes a request for a static image and sends cookies together with the request, the server doesn't have…

I never considered this before. A great tip, thanks

Bear in mind that making sure requests for static content don't send cookies is pretty far down the front-end optimisation ladder - there are normally a lot of things you can do first that are quicker, easier, and have a bigger impact.

Re: Web Developer Checklist

#62
post #51

sorry but that Remove 'www' subdomain is just harmful. force 'www.' instead. why? shitty URL parsers, marketing people and DDOS attacks, that's why. let's imagine you write a - blog post - blog comment - press release (distributed via free and paid press release services) - mail - word - forum post - ... - ... if you have a non-www URL it's a game of chance, your in text "whatever.tld" domain will get transformed int…

301 redirects.

Re: Web Developer Checklist

#63
post #62
post #51

sorry but that Remove 'www' subdomain is just harmful. force 'www.' instead. why? shitty URL parsers, marketing people and DDOS attacks, that's why. let's imagine you write a - blog post - blog comment - press release (distributed via free and paid press release services) - mail - word - forum post - ... - ... if you have a non-www URL it's a game of chance, your in text "whatever.tld" domain will get transformed int…

301 redirects.

does solve only the annoyance part (wrong www URLs by journalists), not the shitty URL parser & marketing people and DDOS issues.

Re: Web Developer Checklist

#64
post #61
post #58

Earlier quoted context omitted.

I never considered this before. A great tip, thanks

Bear in mind that making sure requests for static content don't send cookies is pretty far down the front-end optimisation ladder - there are normally a lot of things you can do first that are quicker, easier, and have a bigger impact.

Well another thing is that it's easier to setup GEO-ip stuff in a CNAME (so www) instead of the root A records, for now at least in PowerDNS (used by Wikipedia etc.). You're completely right, but if your sites ever scales to something big you're not in the best position with a no-www, in my view having a www record (and no-www redirect) has more benefits that a no-www.

Re: Web Developer Checklist

#65
post #51

sorry but that Remove 'www' subdomain is just harmful. force 'www.' instead. why? shitty URL parsers, marketing people and DDOS attacks, that's why. let's imagine you write a - blog post - blog comment - press release (distributed via free and paid press release services) - mail - word - forum post - ... - ... if you have a non-www URL it's a game of chance, your in text "whatever.tld" domain will get transformed int…

And yet, I find no-www so much cleaner. With 301s it's generally not a problem, and link parsers will look for the protocol anyway. I think the only valid point is mitigating DDOS attacks, but I don't know enough about that subject to comment.

Re: Web Developer Checklist

#66
post #33

It's sad how "Security" there's only one very generalizing item. "Implement best practices". Right. Is the author just ignorant, or am I a fool thinking that if anything it should be "Security" which has the most elaborate items?

Security is much more dependent on the site itself though, it's not as "general". Do you have forms? Then watch out of SQL injection. Do you have user input of any type? Watch for XSS. Admin login page? Consider HTTPS. Something like a favicon can apply to every site, not so much with security practices. The idea of just having a "security checklist" is a bit worrisome in itself. The developer in charge should be familiar with the potential dangers as they program a feature, it shouldn't be an afterthought from a checklist.

Re: Web Developer Checklist

#67
post #51

sorry but that Remove 'www' subdomain is just harmful. force 'www.' instead. why? shitty URL parsers, marketing people and DDOS attacks, that's why. let's imagine you write a - blog post - blog comment - press release (distributed via free and paid press release services) - mail - word - forum post - ... - ... if you have a non-www URL it's a game of chance, your in text "whatever.tld" domain will get transformed int…

And yet, I find no-www so much cleaner. With 301s it's generally not a problem, and link parsers will look for the protocol anyway. I think the only valid point is mitigating DDOS attacks, but I don't know enough about that subject to comment.

but in marketing, as in mails and comments, you or your loyal users do not always write http:// in front of your domain.

i consulted a sh-tload of companies on this question (and yes, i also think i have better things to do), any company that chooses non-www URLs regrets it down the road.

Re: Web Developer Checklist

#69

Liked the favicon part, very often forgotten... Would be nice if this was open sourced so more items could have been added by the community (also framework specific checklists) but I like the concept One thing I would add which is driving me crazy on mobile / tablet sign up pages - make sure your email fields are annotated with type="email" Another common issue is with SSL mixed content waring, so I would also add -…

Protocol relative URLs for stylesheets unfortunately cause a double download (one for both HTTP and HTTPS) in IE 8 and below, which is a damn shame. Paul Irish has a lot of info on this here: http://paulirish.com/2010/the-protocol-relative-url/

Re: Web Developer Checklist

#70

Custom 404 page under usability? hmm. I'm sure just about anyone who has used the web for any length of time has hit the standard apache "Not found" page hundreds of times now and pretty much knows what it means. Custom 404 pages of often quite confusing as they will try to be clever and redirect you to other content that may be interesting. Sometimes these aren't clear and give the impression that the link was not b…

I prefer the 404 pages that something to the effect of "Sorry, that is broken" and then include the results of a site search of the keywords or friendly url that was provided. It's less confusing and keeps people on site.

If you do this (which you should in my opinion), please return the 404 code. For example Facebook used to return 200 on error. Very confusing.
Post reply on HN