Symfony and Asset Management
A bit like jQuery has been obsoleted by the advancement in JavaScript and browser implementations, the same has happened to Assetic. It solves problems in a way that is no longer the de-facto method in the web development circles. Some are even becoming irrelevant, such as concatenating assets to a single file due to HTTP/2:
Concatenation and sprites will have less of an impact than before, but they will still have some impact. The biggest issue with downloading multiple files instead of a single file with HTTP/1 isn't actually an HTTP-side problem, per se: there is some bandwidth-based overhead in requesting each file individually, but it's dwarfed by the time-based overhead of tearing down the TCP/IP session when you're done with one file, then starting up a new one for the next, and repeating this for every file you want to download.
An assortment of Ruby, Python and even Java applications were commonly used to minify and package static assets sent to the browser when Assetic was introduced in 2010. In 2015 JavaScript and Node have emerged as the most common build toolchain that developers use. This is a natural match as JavaScript is the language the browser understands and the language that all web developers should be familiar with.
Tools such as Grunt, Gulp and Webpack are used in projects built with PHP, Java, Scala, Python, Ruby and others. Adding JavaScript to your deployment process does add some initial overhead, but that skillset is transferrable - just like Twig in the PHP world. Learning to use tools written in PHP such as Assetic or Robo are not. In this way Assetic worsens the experience of new devs getting into Symfony2 development.
Symfony3 and Assetic
Just this week the relevancy of Assetic in Symfony3 was questioned on Twitter:
Honest question: is #Assetic still relevant for #Symfony 3.0?
— Fabien Potencier (@fabpot) September 28, 2015
An overwhelming number of respondents felt Assetic is no longer relevant in Symfony3. This quickly lead to a pull request for removing Assetic from the Symfony Standard Edition. There is plenty of good discussion about for and against the removal of Assetic. I recommend everyone interested in the matter to read the comments.
I am all for removing Assetic. Not that it's bad, but it continues to be alien to me and others. So while Assetic remains to be useful in applications built using it, I think we should let go and push it into maintenance for Symfony2/Symfony3 applications.
In fact many have already done so, but in a number of different ways, for example Gulp! Refreshment for Your Frontend Assets. Adopting alternative tools in Symfony3 requires clear documentation and a standard directory structure (Resources/private in Bundles?) to place the front end assets' source material.
JavaScript build tools together with the Asset Component introduced in Symfony 2.7 is the way forward...
Should Symfony3 adopt Puli?
...or is it? Puli is an interesting intiative to package assets in PHP. It aims to unify management of resources for projects built with PHP. It supports resources such as Twig templates, CSS, JavaScript and more to a virtual directory layout.
So Puli aims to be more than just a replacement for Assetic and build tools written in JavaScript, Ruby, etc. In fact Puli integrates with Gulp using a plugin to avoid duplicating behaviour that is already done very well by other tools. I feel this is a great approach. Symfony has a history of rapidly adopting new technolologies, such as PSR-7. Maybe Puli should be one of them?