6

I've recently started embedding JavaScript and CSS files into our common library DLLs to make deployment and versioning a lot simpler. I was just wondering if there is any reason one might want to do the same thing with a web application, or if it's always best to just leave them as regular files in the web application, and only use embedded resources for shared components?

Would there be any advantage to embedding them?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Max Schmeling
  • 12,363
  • 14
  • 66
  • 109

6 Answers6

4

I had to make this same decision once. The reason I chose to embed my JavaScript/CSS resources into my DLL was to prevent tampering of these files (by curious end users who've purchased my web application) once the application's deployed.

I doubting and questioning the validity of Easement's comment about how browsers download JavaScript files. I'm pretty sure that the embedded JavaScript/CSS files are recreated temporarily by ASP.NET before the page is sent to the browser in order for the browser to be able to download and use them. I'm curious about this and I'm going to run my own tests. I'll let you know how it goes....

-Frinny

Frinavale
  • 3,908
  • 10
  • 44
  • 74
3

Of course if anyone who knew what they were doing could use the assembly Reflector and extract the JS or CSS. But that would be a heck of a lot more work than just using something like FireBug to get at this information. A regular end user is unlikely to have the desire to go to all of this trouble just to mess with the resources. Anyone who's interested in this type of thing is likely to be a malicious user, not the end user. You have probably got a lot of other problems with regards to security if a user is able to use a tool like the assembly reflector on your DLL because by that point your server's already been compromised. Security was not the factor in my decision for embedding the resources.

The point was to keep users from doing something silly with these resources, like delete them thinking they aren't needed or otherwise tamper with them.

It's also a lot easier to package the application for deployment purposes because there are less files involved.

It's true that the DLL (class library) used by the pages is bigger, but this does not make the pages any bigger. ASP.NET generates the content that needs to be sent down to the client (the browser). There is no more content being sent to the client than what is needed for the page to work. I do not see how the class library helping to serve these pages will have any effect on the size of data being sent between the client and server.

However, Rjlopes has a point, it might be true that the browser is not able to cache embedded JavaScript/CSS resources. I'll have to check it out but I suspect that Rjlopes is correct: the JavaScript/CSS files will have to be downloaded each time a full-page postback is made to the server. If this proves to be true, this performance hit should be a factor in your decision.

I still haven't been able to test the performance differences between using embedded resources, resex, and single files because I've been busy with my on endeavors. Hopefully I'll get to it later today because I am very curious about this and the browser caching point Rjlopes has raised.

Frinavale
  • 3,908
  • 10
  • 44
  • 74
  • 1
    I'm very interested in the cache issue. I can't imagine that they wouldn't use consistent URLs to allow the browser to cache the file. – Max Schmeling Jul 28 '09 at 15:44
  • 2
    Embedded JS files rendered through a ScriptManager are indeed cached, and use consistent URLs across the whole application. We're using it quite successfully on a couple of client sites. – Zhaph - Ben Duguid Jul 28 '09 at 21:41
  • Thank you for the update Zhaph. Do you happen to know if the same thing applies to the Page.ClientScript.GetWebResourceUrl method? – Frinavale Jul 29 '09 at 13:16
  • Embedding is nice for updates/versioning - less to upload to the client. – oldwizard Feb 16 '11 at 09:46
  • Embedding is nice for updates/versioning since you have less files to upload to the client. There are some problems though. * You need to recompile the project to see changes in css/javascript. That makes development painfully slow. * If you support Themes and have many projects with embedded resources things becomes hard to maintain since when you add a theme you need to add resources to every project and recompile them instead of just adding the required resources to the App_Themes folder in a single project and compile/distribute that. – oldwizard Feb 16 '11 at 09:53
1

Reason for embedding: Browsers don't download JavaScript files in parallel. You have a locking condition until the file is downloaded.

Reason against embedding: You may not need all of the JavaScript code. So you could be increasing the bandwidth/processing unnecessarily.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
easement
  • 6,119
  • 3
  • 29
  • 36
  • cuzillion ( http://stevesouders.com/cuzillion/ ) can show you how each inline/embedded choice and placement on the page can affect the overall page load times. – easement Jul 27 '09 at 20:17
  • @easement, that's an interesting page, but it seems a bit contrived. Adding an external stylesheet, it tells you that it's going to add a 2 second delay, which seems arbitrary. And it doesn't seem to address the idea of embedded resources. – Robert Harvey Jul 27 '09 at 20:22
  • 1
    Some browsers do retrieve in parallel, don't they? Or at least I think you can tell Firefox to do so. When you embed them, does it only have one link no matter how many files you embed? if not i wouldn't think that would make much difference. – Max Schmeling Jul 27 '09 at 21:04
  • @Robert Harvey- Yeah, it's a little contrived, but the principles hold water. @Max Schmeling - FF makes a blocker as well. You can see in the Firebug NET panel. That being said, I came across some JS that you can add to make them go in parallel. I haven't tested it. http://piecesofrakesh.blogspot.com/2009/03/downloading-javascript-files-in.html – easement Jul 27 '09 at 21:21
  • Here's a video Google's lsets make the web faster series: http://code.google.com/speed/articles/include-scripts-properly.html – easement Jul 27 '09 at 21:23
1

Regarding the browser cache, as far as I've noticed, response on WebRecource.axd says "304 not modified". So, I guess, they've been taken from cache.

Arthur
  • 2,601
  • 1
  • 22
  • 19
1

I had to make this same decision once. The reason I chose to embed my JavaScript/CSS resources into my DLL was to prevent tampering of these files (by curious end users who've purchased my web application) once the application's deployed. Reason against embedding: You may not need all of the JavaScript code. So you could be increasing the bandwidth/processing unnecessarily.

user2721863
  • 11
  • 1
-2

You know that if somebody wants to tamper your JS or CSS they just have to open the assembly with Reflector, go to the Resources and edit what they want (probably takes a lot more work if the assemblies are signed).

If you embed the js and css on the page you make the page bigger (more KB to download on each request) and the browser can't cache the JS and CSS for next requests. The good news is that you have fewer requests (at least 2 if you are like me and combine multiple js and css and one), plus javascripts have the problem of beeing downloaded serially.

rjlopes
  • 2,430
  • 4
  • 21
  • 23