html - Any disadvantages to Javascript inside the page? - Stack Overflow

admin管理员组

文章数量:1289901

In my build (for a plex webapp), I've aggregated all the javascript into 1 file, which I'm loading as script.js

I thought I might go even further and just print all the js into html. Are there any reasons I should not do that? My thinking is... why not just save the request?

The only downsides I'm aware of are: I understand that since the js is pretty huge, the initial page load might get slowed down.

I'm not very concerned about that since the page is empty anyway without javascript.

Also the script.js could be cached. If I wanted to cache the script within the html, I would have to use varnish or the like.

What are some reasons why I should not do this? Thanks.

Edit: I forgot to mention that this is a 1 page javascript app, so every single page has the same javascript (and html).

In my build (for a plex webapp), I've aggregated all the javascript into 1 file, which I'm loading as script.js

I thought I might go even further and just print all the js into html. Are there any reasons I should not do that? My thinking is... why not just save the request?

The only downsides I'm aware of are: I understand that since the js is pretty huge, the initial page load might get slowed down.

I'm not very concerned about that since the page is empty anyway without javascript.

Also the script.js could be cached. If I wanted to cache the script within the html, I would have to use varnish or the like.

What are some reasons why I should not do this? Thanks.

Edit: I forgot to mention that this is a 1 page javascript app, so every single page has the same javascript (and html).

• javascript
• html
• web-applications
• node.js

Share Improve this question Follow edited Mar 24, 2011 at 0:18 Harry asked Mar 23, 2011 at 23:58 HarryHarry 55k7676 gold badges185185 silver badges270270 bronze badges 8

• 2 "I'm not very concerned about that since the page is empty anyway without javascript." - well I'd be concerned about the people with JavaScript disabled. – Czechnology Commented Mar 24, 2011 at 0:01
• @Czechnology if you have javascript disabled you can't use the app anyway, I don't see any need to serve those people. – Harry Commented Mar 24, 2011 at 0:05
• 1 @Harry - that's not a very nice way to think about the blind and low-vision users who are restricted to using screen readers to navigate the web. – tvanfosson Commented Mar 24, 2011 at 0:07
• 2 @Raynos - plex apps can and are used by low vision users. Our campus course management system has a gold rating from the National Federation for the Blind. It's not necessarily easy but it can be done. In some cases you could be violating the law by not having your web sites be accessible, at least in the US. And, while they may not have maps (most blind people aren't driving, I hope), they do have accessible search: labs.google./accessible – tvanfosson Commented Mar 24, 2011 at 0:19
• 1 Sites that aren't (yet) legally mandated to ply with accessibility guidelines are now starting to be sued by groups such as the National Federation for the Blind. We're reaching the point where you are taking a financial risk when you decide to blow off accessibility. – Stephen P Commented Mar 24, 2011 at 0:53

 |  Show 3 more ments

6 Answers 6

Sorted by: Reset to default 7

I use one single minified external js file. As a seperate file it can be cached nicely, although an extra HTTP request is needed.

If you put your java script inline then it wont be cached as simply and you will have duplication of code on every page if you are reusing methods that are inline.

Give the credit to Andi - this is what they meant, if I may be so presumptuous.

It's better form to have the file external because it simplifies caching. Allows it to be easily minified for lighter transport and makes maintaining the JavaScript it self easier.

There are many reasons to separate javascript code from HTML (if not just for "best practice" purposes), but there is one big one that is very important in this situation.

Caching. When it is in another file (such as "script.js"), that file will be cached after the first page load and will, therefore, not be read from the server until the cache expires. If you put it into the HTML, the javascript will be reloaded every single time. Varnish is simply an HTTP accelerator on the server-side. It does not modify the cache of the client at all, so all the data will still be sent. Varnish will just not reparse the data on the server (server scripting (PHP/ASP/etc), not client scripting (javascript)). This is the biggest point to learn about this issue. All the code will continually be resent to the client, which will greatly hinder the load time.

In addition, it is really only important to split them up among different files if: A) One file will be changed a lot more frequently than the others (caching reasons again) B) If you plan to use some functions on some pages (and not all on every page). It is unnecessary to make the javascript interpret the function headers (only really the function headers due to lazy execution) of functions that it never uses on that page. C) It is easier for organizational purposes.

Finally, browsers actually load multiple pages concurrently. If you have an "index.html" page and a "script.js" page, they will both being loading concurrently and, therefore, begin execution faster. If you split "script.js" into three files (lets say "script1.js", "script2.js", and "script3.js"), the browser will load these pages concurrently and, thus, begin execution even faster than just one script.js file. Most browsers have a default concurrent page loading value of "3", meaning it will only load 3 pages concurrently, so it does not make sense to split something into tons of files instead of just a couple.

I hope I have made it clear why you should separate your javascript from your HTML (especially if you are making a large webapp in javascript).

This might work pretty well for a single page web site, but it's not going to work very well if you need to share that code among several web pages or in an app with several url endpoints.

All scripts that are necessary to run before the body loads should be placed in the <head> section. Furthermore, scripts that need to run AFTER the body loads should also be placed in the <head> section but inside a document.onload wrapper. Having this wrapper will ensure that you have access to the elements on the page since it will run after the body is rendered.

If you need to run scripts which need to execute as the body loads, you can place inline <script> tags inside the body, as they will execute while the page is rendering. This is useful in scenarios where you need to adjust widht/heights on some elements but don't want to have the jump that would happen if you placed it inside the document.onload wrapper.

Don't forget to bine and press all scripts that are in the <head> section since this will ensure a faster page load and it will also get cached by the browser.

Is client-side caching of your JavaScript file desired in your case? If so I'd lean towards a separate file.

本文标签： htmlAny disadvantages to Javascript inside the pageStack Overflow