Javascript/CSS on the fly

[indiansummersky]

Hello monks,

I'm wondering if anyone can give me their opinions on using Perl to dynamically generate CSS and Javascript for use in webpages. Obviously, on the plus side you have more control over code unique to a particular page. However, you lose the advantage of having your CSS and Javascript cached for fast loading. I've found making two more HTTP requests (one for CSS and one for Javascript) can seriously slow down page load times.

What experiences have you had with this technique? Maybe site-generic code should be loaded from a .css or .js file, whilst page-specific code should be generated on the fly? This still wouldn't address the fact that reloading any given page, its unique javascript or css would always need to be reloaded.

[jhourcle]

Why are you varying the CSS or javascript?

If it's to deal with quirks in different web browsers, and you're trying to serve slightly different versions based on the browser, then I'd recommend that instead of generating the CSS or JS dynamically, you instead generate the references to the correct file dynamically, and have the files themselves be static (or not... see below)

As for the caching issues, you can manipulate things using the correct headers, such as 'http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9 Cache-control', you can get around things -- if it's possible that you might send different versions to the same browser (which is not the case when dealing with browser quirks), then you just need to make the URL formatted in such a way that the browser will consider them differently, while still using GET.

Instead of using a URL passing the info in QUERY_STRING:

http://www.example.com/cgi/generator?id

You should instead pass the date in PATH_INFO:

http://www.example.com/cgi/generator/id

With Cache-control, you can insure that the pages will be cached, and with the differing URLs, you can get the browser to treat different versions as seperately identifiable files.

I'd be interested in knowing exactly what it is that you're trying to accomplish -- there may be better solutions (eg, a 'main' css file, and some pages reference the main file + specific modifications for that page)

[McDarren]

This is not directly related to your question, but it may help nevertheless.

If you're serving a lot of dynamic content from an Apache server, then you might want to check out the mod_deflate module. I only became aware of this module the other day (it was suggested by a cow-worker).

This is what happened after I implemented it on one of our servers - which serves almost exclusively dynamic content (look at the big drop in outgoing bandwidth at midnight on Friday night).

Cheers,
Darren :)

[cees]

Unfortunately, it is generally recommended that you do not compress js or css files, since there are browsers out there that do not support it properly (1). They support compressed text/html content, but sometimes mess up with any other text based content that is compressed.

But using mod_deflate (or mod_gzip for Apache 1.3) is definately something that most admins should be looking at.

(1) http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B327286

[belg4mit]

That's only an issue if it isn't inlined. And if it isn't inlined you can allow for caching better by providing some parameter in the URI to tie it to the page or set of pages it was generated for /applies to.

[TedPride]

How much page-specific Javascript / CSS are we talking about, and how much traffic does your site get? I'd personally put global Javascript / CSS in secondary files (as you suggested), and template the page-specific stuff directly into each page. This eliminates the delay of waiting for external files to load, and keeps bandwidth consumption relatively low.

If you're still having server speed / bandwidth problems, get a better hoster.

EDIT: While there might be only three or four generic text sizes (and spacings, and styles, and so on) across a site, each specific page might need to make use of several more, and there's no point putting piles of extra CSS in your primary file. Hopefully this is what he means. If on the other hand he just wants to feed different CSS to different browsers, it would probably be better to make a .css file for each of these browsers and dynamically write just the name of the file.

[kulls]

Hi,
What kind of CSS work, that you have?. moreover, if you are using any templates like HTML::Template, then you can control the CSS (loop_context_vars) at minimal level.
-kulls

[belg4mit]

There are several modules for the JS side including dumpers Data::JavaScript and fancier AJAX stuff. there are appear to be several CSS modules, and of course some color moixing code on CPAN as well... What was your question again?

There's no reason the code needs to be regenerated if you return proper headers for cacheing.

[weixi]

I fully agree with TedPride. Put the global (site-generic) CSS and JavaScript code into seperate files (which can be cached), and inline the dynamically created (page specific) CSS and JavaScript parts directly into your HTML file. By inlining them you avoid extra HTTP requests. There remains only an increase of the HTML file size which should not make such a big difference.

Concerning run-time, dynamically creating CSS/JavaScript does not make much sense. Because of potential caching, it would be better to write a lot of page-specific .css and .js files (put aside the extra HTTP requests).

However, thinking about generating and - more importantly - maintaining the .css and .js files, it can be a huge benefit for the web developer to use dynamically created CSS/JavaScript. Often a simple Perl script can serve as the generator for a wealth of page specific codes. Any changes can be made in this single script. On the other hand, changing dozens of different .css and .js files can be a tedious and error-prone task.

The maintaince aspect is the very reason why I am sometimes using dynamically generated CSS/JavaScript. I think it is a useful technique, and practice didn't prove me wrong, so far.

[pemungkah]

Thinking about it from the CSS side of things, if your selectors are sufficiently generic, the most you'd need to do would be to change the name of the CSS file you're referencing in the <HEAD>. Take a look at the CSS Zen Garden for an example of how far you can go in the way of restyling a page simply by changing which CSS file you link to.

I can't see any real advantage to you the developer of inlining the CSS; if you're reusing the same CSS file, it'll end up cached in the browser; if it's inlined, you'll be transferring it every time you hot a page.