CODEWITHSUNDEEP
javascripthtmlweb-applicationsnode.js
Harry
Harry

Reputation: 54949

Any disadvantages to Javascript inside the page?

In my build (for a complex 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).

Upvotes: 4

Views: 1759

Answers (6)

Chris
Chris

Reputation: 1579

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).

Upvotes: 2

Naraen
Naraen

Reputation: 3250

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

Upvotes: 0

Andrew
Andrew

Reputation: 10033

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.

Upvotes: 7

Marko
Marko

Reputation: 72222

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 combine and compress 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.

Upvotes: 0

tvanfosson
tvanfosson

Reputation: 532465

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.

Upvotes: 1

zellio
zellio

Reputation: 32484

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.

Upvotes: 2

Related Questions