django-static works by maintaining a global dictionary variable that whenever you render the template it maps a filename (e.g. "/js/foo.js") to an "optimized" filename (e.g. "/js/foo.123513563.js")
Only the first time does it need to do the necessary symlinking and whitespace compression so there is some extremely tiny overhead for each rendering.
django-compressor, last time I checked, doesn't support sorting out the images inside the CSS files automatically. That's where most images are and those need to get the best filename rewrites to get the best setup.
Looks pretty cool! I'm currently using django-compressor, which operates in a similar way (using templatetags). The downside of this approach is that a fair bit of processing (at the very least, parsing of HTML and some filesystem mtime checks) has to be done on each and every request to a Django page, even in the best-case scenario when no static files have been modified.
Because there's no comprehensive list of "files to be served" in any one location, there's no way to provide a "build step" that you run once when you deploy changes, and thereafter let the code trust that nothing has changed.
I used to use django-compress which forces you to define all your media assets in the settings file, thus allowing it to provide a run-once build step.
On the whole, I think this is a relatively fair tradeoff for the super-convenient templatetag system; I much prefer not having to change settings whenever I add a media file.
Right; it doesn't need to slim or write the files unless something has changed, but it does need to parse the HTML inside the template tags and check whether anything needs updated. This is the same as django-compressor. I agree that that overhead isn't a big concern.
django-compressor does already find and rewrite image links in CSS to make them absolute; would be easy to have it also tag them with a querystring for cache-busting at the same step. Guess I've never needed that because we use the Compass CSS framework, so image links in our CSS are already tagged that way before they ever get to the deploy step.
Comment
django-static works by maintaining a global dictionary variable that whenever you render the template it maps a filename (e.g. "/js/foo.js") to an "optimized" filename (e.g. "/js/foo.123513563.js")
Only the first time does it need to do the necessary symlinking and whitespace compression so there is some extremely tiny overhead for each rendering.
django-compressor, last time I checked, doesn't support sorting out the images inside the CSS files automatically. That's where most images are and those need to get the best filename rewrites to get the best setup.
Parent comment
Looks pretty cool! I'm currently using django-compressor, which operates in a similar way (using templatetags). The downside of this approach is that a fair bit of processing (at the very least, parsing of HTML and some filesystem mtime checks) has to be done on each and every request to a Django page, even in the best-case scenario when no static files have been modified. Because there's no comprehensive list of "files to be served" in any one location, there's no way to provide a "build step" that you run once when you deploy changes, and thereafter let the code trust that nothing has changed. I used to use django-compress which forces you to define all your media assets in the settings file, thus allowing it to provide a run-once build step. On the whole, I think this is a relatively fair tradeoff for the super-convenient templatetag system; I much prefer not having to change settings whenever I add a media file.
Replies
Right; it doesn't need to slim or write the files unless something has changed, but it does need to parse the HTML inside the template tags and check whether anything needs updated. This is the same as django-compressor. I agree that that overhead isn't a big concern.
django-compressor does already find and rewrite image links in CSS to make them absolute; would be easy to have it also tag them with a querystring for cache-busting at the same step. Guess I've never needed that because we use the Compass CSS framework, so image links in our CSS are already tagged that way before they ever get to the deploy step.