Hi, first of all, sorry for chiming in so late. It seems like this has been discussed in May, already, but I didn't follow the discussion back then.
Today the staticfiles contrib app was committed to trunk. This got me wondering: Wasn't there recently a discussion about how "contrib" is a bad idea and all apps should either be in core or live as separate projects? Is staticfiles really a core app? Even if it is a core app, does it do its job well enough to be in contrib? I do agree that such an app is critical for practically all web projects and the documentation even says: """ For small projects, this [static files management] isn't a big deal, because you can just keep the media somewhere your web server can find it. However, in bigger projects -- especially those comprised of multiple apps -- dealing with the multiple sets of static files provided by each application starts to get tricky. """ So like the docs say, staticfiles seems to target "bigger projects". However, what staticfiles does has almost nothing to do with "bigger project" asset management. Just look at the features grid on djangopackages (disclaimer: I'm the author of django-mediagenerator and I maintain that grid): http://djangopackages.com/grids/g/asset-managers/ It's obvious that django-staticfiles has none of the critical features: * It doesn't combine your CSS/JS files. * It doesn't compress them. * It doesn't support CSS compilers like Sass or Less. * It doesn't support versioning of CSS, JS, and images. * Because of the lack of versioning the staticfiles view doesn't (and can't) support proper caching which means for every single visited page the browser will make unnecessary "if-modified-since" roundtrips to the very slow runserver. These unnecessary HTTP roundtrips make it very painful to work even on medium sized projects (unless combined with a local dev http server like Apache). * Finally, staticfiles doesn't auto-regenerate the assets when they are changed. This makes development extremely painful and error-prone because you have to "manage.py collectstatic" every time you make a little change to your JS or CSS code (and that's really easy to forget). >From that point of view, staticfiles is only useful for small hobby projects. So, why was this app added to Django? Most projects are better off using a different solution, anyway. BTW, I noticed a bug in the staticfiles view: It checks for "if settings.DEBUG", but that should be "if not settings.DEBUG". Also, staticfiles doesn't index "media" folders although the admin uses "media" instead of "static". Why not follow the existing scheme? Bye, Waldemar Kornewald -- Django on App Engine, MongoDB, ...? Browser-side Python? It's open-source: http://www.allbuttonspressed.com/blog/django -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
