Packing, caching, JS and CSS in PHP that differentiate between development and production environment

Question

I am trying to make development easy and have highly optimized output in production.

The goals of what I am trying to do is:

Answer 1

Still working on exploring the best solution leveraging the resource already available.

CSS-JS-Booster and Turbine so far looks like the best starting point: http://github.com/Schepp/CSS-JS-Booster and http://turbinecss.org/

Other JS/CSS Combiners solutions and articles

• http://code.google.com/p/minify is good but seem a little to hard to configure.
• http://rakaz.nl/code/combine Let you use sintax like this: http://www.creatype.nl/javascript/prototype.js,builder.js,effects.js,dragdrop.js,slider.js (not exactly the best) I also think I saw a patch to this script but I cannot find it now. (example of usage http://brainfart.com.ua/post/code-cache-combine/)
• http://www.ejeliot.com/blog/72 and http://www.ejeliot.com/samples/combine/combine.phps Ed Eliot combine.php solution. It only let you have specify once the file to merge
• http://aciddrop.com/php-speedy/ other solution.
• http://www.artzstudio.com/2008/08/using-modconcat-to-speed-up-render-start/ Use of mod_concat and overview of other solutions
• http://wordpress.org/extend/plugins/w3-total-cache/ That is a WordPress Plugin. It is very interesting but probably to much work to make it independendt from Wordpress.
• http://bakery.cakephp.org/articles/view/combine-your-js-css-files-for-faster-loading CakePHP solution

Resource for JS compression and caching:

• http://code.google.com/p/php-closure/ PHP script that let you combine .js files ancd combile thought the Google Closure REST API. Check timestamps and cache the combined version locally.
• http://dean.edwards.name/download JS packer compressor/obfuscator. I am not sure how long the decompression take. But it was able to shrink the jQuery 1.4.2 compiled/minified with Closure to 50639 bytes from 71946 (almost 30% reduction!) with Base62 Encode on! It would be interesting to compare the gzipped versions. Regarding JS obfuscation Packer optimizer make a little more difficult to tamper in your JS code.
• http://thinkvitamin.com/dev/serving-javascript-fast/ Great discussion about gzip and caching
• http://cjohansen.no/en/ruby/juicer_a_css_and_javascript_packaging_tool Ruby Juicer JS/CSS packaging tool

LESS compilers/tutorials/tools:

• http://designshack.co.uk/articles/css/using-less-js-to-simplify-your-css3 Less.js tutorial/introduction.
• http://net.tutsplus.com/tutorials/html-css-techniques/quick-tip-you-need-to-check-out-less-js Presentation of less.js (useful comments)
• http://fadeyev.net/2010/06/19/lessjs-will-obsolete-css/ and http://github.com/cloudhead/less.js It is a LESS compiler written in JS and can also be added in the browser. Great for development
• http://lesscss.org/ What LESS is. Originally written in Ruby but there are implementation in a lot of different fanguages,
• http://leafo.net/lessphp/ Less compiler written in PHP (it does not seem updated)
• 960 is another way to make it things easier; http://www.webdesignerdepot.com/2010/03/fight-div-itis-and-class-itis-with-the-960-grid-system/
• http://github.com/everzet/sfLESSPlugin LESS in symphony
• http://drupal.org/project/less Drupal CSS Preprocessor
• http://github.com/sunny/csscaffold A PHP parser of something similar to LESS but not quite
• http://code.google.com/p/maven-less-plugin/ maven-less-plugin uses rhino, envjs and less.js to translate the less-code to css during the process-source phase of your maven build. In the end you get a artifact with ready-to-use css code.

At Deployment time options:

• http://phing.info/docs/guide/stable/ Phing is build/deployment system in PHP
• http://www.capify.org/index.php/Capistrano The Ruby solution

Answer 2

Why don't you use a project build system to deploy your application to the production server that does just that? For PHP you might like Phing, since it would allow you to write extra plugins in PHP, that you can execute while deploying. Other options you might want to consider of you take this route are Ant and Capistrano (and there's lots of others), but these require knowledge of other languages (granted, you could start the php parser from them if you really wanted to...).

Answer 3

Great Question!

I've worked with a process with similar requirements, but we took somewhat of a different approach. I realise its maybe not exactly what you're after, but would still make some recommendations:

1. Make the compression/compilation part of the shipping process.(You may already be doing this, but it wasn't clear from the above).
2. Compress/compile it on the development servers too. It might be a hassle for debugging/testing but you want to be able ensure the production version and test versions are as similar as possible. If you have the luxury of multiple development stages, then you could possibly compress on one of them.
3. Only do the compression/compilation if it passes some sort of quality scan (e.g. jslint)
4. Don't combine the modules - keep them separate. The performance benefits you will gain will be so negligible, as to be almost pointless.
5. Don't change the HTML, just change the dependant modules content.

I realise its a bit different from what you were intending, but in my experience it leads to a more robust development promotion model.