views:

97

answers:

2

As many of you know, most jQuery (or javascript, for that matter) plugins you find these days can be downloaded as either regularly formatted code, minified version, or both. For development purposes, I like to use the non-minified versions of the plugins, in case I need to set a Firebug breakpoint or look through it for any reason.

Now when I package my app and deploy it, I'd rather switch to the minified versions of the plugins, for efficiency's sake. The only way I know to do this is to have both versions on hand, then manually change all the references in my Views (I use MVC) to point to the minified versions, then package and deploy. Ideally I'll be minifying (and maybe obfuscating) my own javascript files as well.

Does anyone know of a better, more efficient way of developing with non-minified plugins (for readability) and deploying with minified versions (for efficiency)? Any articles you could point me to that talk about it? I'm pretty new to how to handle javascript deployment, and could probably brush up on best practices.

Thanks.

+3  A: 

I tend to always use the minified versions of 3th party JSs unless I specifically need to look into it... In any case, you could write an html helper that inserts the correct script name based on some configuration (can be debug vs release)...

You would end up with something like:

<%= Html.IncludeJQuery() %>

or if all your scripts follow the same convention ( .min.js for minified version) do a helper that inserts the '.min' on the script that you pass is when in release

<%= Html.IncludeCorrectVersionOfScript("jquery-1.4.2.js") %>

Update:

Html helpers, are extension methods to Mvc's HtmlHelper class that you can use to emit the ActionLink, BeginForm, EditorFor, etc. You basically attach a new method (albiet static only) to that object so you can do Html.MyMethod.... A helper for this would be some like:

public static class ScriptIncludeHelper
{
    public static MvcHtmlString IncludeCorrectVersionOfScript(this HtmlHelper html, string script)
    {
        if (!html.ViewContext.HttpContext.IsDebuggingEnabled)
            script = script.Replace(".js", ".min.js");
        var tag = string.Format("<script type=\"text/javascript\" src=\"{0}\"></script>", script);

        return MvcHtmlString.Create(tag);
    }
}

Note that this is very simplified version (no validation of the string, etc.etc.etc.)

Now you could use the IsDebuggingEnabled or a configuration in your web.config or a static configuration to define if you want to include the minimized version of the debug version...

Hop this helps

Jaime
I'm intrigued. I've read a little about HTML helpers, but I'm not completely clear. What exactly would the helper do? Check for debug vs. release compilation symbols, and include the correct files then? How would it know which files to include? Maybe you could elaborate a bit in your answer...
Mega Matt
+1  A: 

This is an example of how Rails handles it. It may or may not be a best practice, but eliminates the load from the developer completely.

A config file containing settings for each environment:

# resources.yml
# example config file

development:
    jquery_url: http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.js

test:
    jquery_url: http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js

production:
    jquery_url: http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js

Parse the resources depending on the current environment into a variable that gets referenced everywhere on application startup.

RESOURCES = YAML::parse('resources.yml')[CURRENT_ENVIRONMENT]

Then use a base layout or template that gets included in all pages, instead of having each view or page specify it's own settings. The <%= yield %> indicates that output from child views or pages goes there.

# application.html.erb

<!DOCTYPE html>
<html
<head>
    <script src="<%= RESOURCES['jquery_url'] %>"</script>
</head>
<body> <% yield %> </body>
</html>

Then you simply have to change one key - CURRENT_ENVIRONMENT (development, test or production) to trigger everything. It is also useful for API keys and all other types of dependencies that already do or could potentially change between environments.

Anurag