As long as you ignore the extra bandwidth from downloading both the non-retina and retina versions with this script, yes, it's pretty easy. Actually serving retina images only for devices that need them, in an efficient and backwards-compatible way is a much harder problem.
We load a normal (non-retina) page the first time we see a visitor, and then we set a cookie if the devicePixelRatio is high. After that, pages are rendered with retina images directly in the src attributes.
Imperfect, but that seemed like our best compromise. I suppose we could also do this on the first page load, but that felt like diminishing returns.
You could give Pixtulate a try (http://www.pixtulate.com). Detecting the client's properties (pixel density, screen size, etc) would still have to be done via JavaScript on the client, but then just append those properties as query parameters on the img's src attribute and the image will get converted on the fly to whatever your visitor needs. Not only do you not have to pre crop or scale your images, every image is specifically tailored to your visitor...not just a simple 1x vs 2x.
That's very useful, but cropping/resizing the images is not the hard part. If you change the image src after the page is loaded, the first request is already underway, so you end up downloading two images, just as happens with the OP. You need to send device profiles to the server and somehow keep them up-to-date, or create images on the client - and then serve a different version to crawlers... there are plenty of proposals (image-set, srcset) to handle this in HTML5/CSS but none has become standard yet.
Wouldn't this be resolved by setting a data-1x property (leaving the src/background-image property blank)and then running javascript to substitute the data-1x property for non-retina devices and data-2x property for retina devices?
Not that simple. That would be fine for a client-side app, but not for a public-facing site:
1) no javascript = no images. crawlers/bots/archival services won't see them - google might even penalize you for broken image sources. one error in your main js file and all images are toast. needs other workarounds.
2) longer page load times unless you use inline scripts
4) extensions like readability, pinboard, weheartit, etc, might break
If you are going to use this, you should use querySelectorAll('[data-2x]') to select the nodes, rather than getElementsByTagName('*') and then check if each node has a data-2x as is done in the article, for performance reasons[1] and to make your code simpler.
> "If you’re reading this on any desktop monitor that exists in 2013, you’re on a legacy display (72 pixels per inch)"
The 22.2" IBM T221 (http://en.wikipedia.org/wiki/IBM_T220/T221_LCD_monitors) 'becomes retina' when you are 17" away from it, compared to the Apple Macbook Pro Retina 15", which 'becomes retina' when you are 16" away from it. The former has a PPI of 203.98, the later 220.53. (all calculations done by http://isthisretina.com/)
High DPI monitors prior to 2013 have also existed for years for use in hospitals, though admittedly most consumers have probably never used one of those.
The author has posted a follow up here -- http://drew.roon.io/responsive-retinas-strike-back -- that offers some alternatives for getting around the extra download issue (which a number of people brought up, including @ricardobeat in the comments).
