Publishing CSS or JS as Multimedia Components?

Let me start by saying that I am a strong believer that handling, uploading or publishing CSS or JS files as Multimedia Components is bad practice. At the same time I was recently surprised that opinions are actually quite different on the topic. There are people who don't always agree with me, shocker!!!

So I guess the point of this post is just to present the advantages/disadvantages of the two methods and see which you like best. Make that one best practice :)

Multimedia Components

In this approach, CSS or JS files are uploaded into Tridion as MMComponents based on a MMSchema. This is the default way the Dreamweaver mediator handles references to CSS or JS from an HTML (.dwt) document.

Advantages:

• speed - easy to upload into Tridion, without having to create additional items like Schemas, Components, CTs, PTs, Pages;
• easy to understand - developers with little Tridion experience understand this approach easier;
• out-of-the-box - this is the default way the Dreamweaver mediator handles references to CSS or JS;
• published automatically - when the referencing PT is published, all these MMComponents are published too automatically;

Disadvantages:

• not elegant - treating text documents as binaries is an improper solution (binaries are treated like a black box, read-only, cannot be modified, need to be added as Multimedia Types, then added as allowed types in a MMSchema);
• difficult to modify - MMComponents cannot be edited in Tridion, so you have to download them, modify them in an external editor, then upload them back into Tridion (note that you are forced into using _some_ external editor);
• no version comparison - Tridion cannot compare MMComponent binaries;
• overhead in publishing - whenever the referencing PT is publshed, all these MMComponents are published too, which can have bad consequences to publishing performance;

I think this is bad practice because it does not use the Tridion methodology of publishing text documents. In this approach, Tridion is nothing more than an FTP tool backed by a binary repository.

Components, CTs, PTs and Pages

In this approach, CSS and JS files are stored inside a Component text field (multi-line, no RTF). An embedded Component Template on the same Schema is used to output the text field. A Page Template specifies the file extension and outputs all Component Presentations. For each CSS and JS Components, you need a Page using the respective PT and on it, you place the Component with the Component Template.

Advantages:

• control - this approach gives full control over the CSS and JS, e.g. by allowing image references to be resolved and published from within the CSS;
• verison compare - possible to use because we are now dealing with textual representation;
• publishing performance - CSS and JS are not published automatically when the referencing PT is published, therefore there is no performance degradation due to this fact;
• editing capability - CSS and JS Components can be edited inside Tridion GUI (no external tool is needed);
• follows Tridion methodology - this is the proper way of publishing things from Tridion (i.e. from Schema to Component to templates to Page);
• elegant - this approach is clean, architecturally elegant, and it implements Tridion properly without cutting shortcuts into development;

Disadvantages:

• slower development - this approach is not the default way the Dreamweaver mediator is using and more Tridion items are needed (e.g. Schema, Components, CTs, PTs, Pages);
• not published automatically - when a referencing PT is published, the CSS and JS it not automatically published, rather a manual publish is needed;

This approach is the best practice.