Update: There's a new version of this module that also handles ScriptResource.axd here

A lot have been written about the compression of WebResource.axd over the years, but as far as I know, nobody has come up with a simple solution to it. Miron Abramson does have a very good library for compressing a lot of different file types, but I’ve never been much in favour of third-party libraries.

There are several reasons why you want to compress the WebResource.axd. First of all you want to reduce the size of your website. On this blog ASP.NET inserts two WebResource.axd script with a combined file size of 43.3KB. If I use compression and minify the scripts, the total file size will be 8.1KB. That is a significant gain.

The WebResource.axd is cached in the browser until midnight the same day, so the file size might not be that big a deal. Well, if we can make it expire on a much later date it would be much better since it never changes. So, if the WebResource.axd is minified, compressed and set to live longer in the browsers it really adds up.

Implementation

Download the CompresWebResource.cs file below and put it in your App_Code folder. Then add the following lines to your web.config:

<httpModules>
  <add type="CompressWebResource" name="CompressWebResource" />
</httpModules>
<httpHandlers>
  <add verb="*" path="*js.axd" type="JavaScriptHandler" />
</httpHandlers>

You can use the HttpHandler for all your other .js files as well. Just change the path from /script.js to js.axd?path=/script.js.

Download

CompressWebResource.zip (2,81 kb)

Jakob asked me a question this evening: What is the difference between front-end and back-end developers? Not long after I was on my way home and couldn’t stop thinking about it. I’ve never thought much about it before, yet I am convinced there is a difference. Also, I have a feeling that there must be a different answer for each developer in the world.

Let’s start by looking at some stereotypical differences.

Front-end devs don’t unit test

…whereas back-end devs take pride in their unit tests and test environment. In my experience this is definitely true. Front-end code is very difficult to test and those tests are even worse to maintain. It’s a fulltime job. However, you have always been able to separate most logic from code-behind files and other classes into libraries that are testable. Maybe front-end devs just don’t care as much about testability or are they more realistic in how they spend their time?

Back-end devs are more low-level

Threading and memory pointers are not interesting for most front-end developer. Back-end devs on the other hand knows all about it and how to utilize it to create scalable solutions. Front-end devs don’t like operating on such a low level of abstraction and feels the platform should take care of it, so they don’t have to. Otherwise you’ll never get anything done. Some are extraordinary productive on a low level and some are equally productive but higher on the stack. Does this separate front-end from back-end devs?

Front-end devs make more mistakes

Back-end devs don’t just jump into development, but thoroughly sketch out every detail to avoid unforeseen scenarios. Front-end devs do just the opposite – they need to create and they need their endorphins fast. I’ve heard this many times before and I don’t agree. There are just as many ugly pitfalls by rushing development in the front-end as in the back-end and front-end devs knows this. Still, they need their fast track to the endorphins, but does it collide with the quality?

Back-end devs hates the client-side

If there is one thing back-end devs hate more than Cirque du Soleil, it’s JavaScript, stylesheets and HTML. Valid XHTML only makes sense to back-end devs if they have to parse it as XML. Front-end devs spend hours on end to perfect every pixel and even longer to validate their stylesheet and XHTML even though the average user wouldn’t notice. Say cross-browser to a back-end dev and he shakes his head at the stupidity thinking that you could just have made a table design and there wouldn’t be any problems. Is this a way of thinking about quality?

A likely answer

When I was hired by ZYB, my boss Ole Kristensen asked me if I considered myself as a front-end or a back-end developer. I answered that I thought of myself as a back-end dev but my heart was in the front-end. Maybe the answer has nothing to do with technicalities but is as simple as what you love the most.