Asset Pipeline for Vanilla

mtschirs

Vanilla's current asset handling (mainly css & js) is pretty basic. I'd like to hear your ideas about how this can be improved. For inspiration, see e.g. http://guides.rubyonrails.org/asset_pipeline.html

Minimum requirements: Asset compression, concatenation and fingerprinting ("cache busting")

My thoughts:

• Github splits its javascript into blocking and async (via <script async="async" ...>). Improves page speed.
• A dependency management would also be nice.
• LESS or SASS support?
• There are some ready-made asset managers out there, e.g. https://github.com/vendethiel/Sprockets-PHP. Still, rolling our own solution (picking what we need from other projects) might be favourable (tighter integration with Vanilla / Garden).

hgtonight

SASS.

Bleistivt

For CSS, most of that is already in the core, see c(Garden.CombineAssets) but in an experimental state afaik.

There is also the Consolidate plugin, which is compatible with 2.1x

+1 for async (or defer, which is what I'm currently using as a tweak)

Javascript compression and minification would be a lot easier if the option to include js files conditionally would be removed or discouraged, so that there would only be a single file for all pages.

R_J

In my opinion it would be better if all js/css files would be compressed into one file each, that is loaded on every page (not like now, where you can attach resources to specific controllers). That way it would be 1 request only and that file could be cached.

mtschirs

@Bleistivt schrieb:
For CSS, most of that is already in the core, see c(Garden.CombineAssets) but in an experimental state afaik.

There is a good reason why I stripped that part (Minify) out of my Vanilla fork; you should do the same (merge https://github.com/mtschirs/vanilla/tree/patch-14).

vrijvlinder

@R_J said:
In my opinion it would be better if all js/css files would be compressed into one file each, that is loaded on every page (not like now, where you can attach resources to specific controllers). That way it would be 1 request only and that file could be cached.

I do not like that at all... it has caused major problems, "concatenation" should be used sparingly in my opinion...

mtschirs

@vrijvlinder Could you elaborate on that? Concatenating JS code should not change its semantics. Do you e.g. mean problems in debugging or preprocessing? Most asset pipelines have an option to turn off concatenation and minification for debugging purposes. We should add this to the minimum requirements.

x00

@Bleistivt said:
For CSS, most of that is already in the core, see c(Garden.CombineAssets) but in an experimental state afaik.

There is also the Consolidate plugin, which is compatible with 2.1x

+1 for async (or defer, which is what I'm currently using as a tweak)

Javascript compression and minification would be a lot easier if the option to include js files conditionally would be removed or discouraged, so that there would only be a single file for all pages.

One idea is to have accumulate option which would effectively defer that logic to the client side. Over time it could accumulate files to the same resource pattern rules, but across all pages. It would wrap each script transporting the checksums for "page collections", These checksums could be used to load the individual scripts conditionally.

Possibly it should be done by application as not to muddy it too much.

it would still follow the pattern rules, but you could have as many or as few as you like.

vrijvlinder

@mtschirs said:
vrijvlinder Could you elaborate on that? Concatenating JS code should not change its semantics. Do you e.g. mean problems in debugging or preprocessing? Most asset pipelines have an option to turn off concatenation and minification for debugging purposes. We should add this to the minimum requirements.

In my experience it causes more problems than it helps. Because style sheets might be specific to a single page and only called on that page. When minifying, it is on one long sheet and it adversely affects the style/theme/functions.

The same with JS.

I prefer just calling the code as needed and being able to diagnose what is going on is easier than when concatenated. But that is my opinion , others might see it differently.

Linc

The groundwork is slowly being laid for this. I'd encourage a discussion via GitHub issue(s) to hammer out technicalities if you want to move forward with this before we do. I don't have a clear internal timeline for this yet.