/    Sign up×
Community /Pin to ProfileBookmark

Opinion: Pro’s and Con’s of .JS files

What are some pro’s and con’s of using a extention javascript file for your webpage?

to post a comment
JavaScript

10 Comments(s)

Copy linkTweet thisAlerts:
@SparoHawkJun 01.2010 — Using external files only has one CON which can be taken out of the way.

As you know browsers pipeline a maximum of around 4 simultaneous connections to a sub domain (remember www is a sub domain). Therefore if you have more than 4 external files the browser will have to wait for one of them to finish loading before jumping to the next.

That can be solved by using more sub domains. Just look at the images being loaded in Google Maps and you will see img1.google.com, img2.google.com, img3.google.com, etc.

After that, its only PROs. External files help you to keep your JS, HTML and CSS layers apart from each other increasing code reviewing efficiency and portability (in case you want the same JS on another site). Is sort of like an MVC model.

You can then separate your JS files accordingly and distribute functions among them as needed.
Copy linkTweet thisAlerts:
@tvb2727authorJun 01.2010 — Thanks for the information. How does it affect Bandwidth? I know my .htm file is 19kb and my .JS file is 20kb. Does it download both of them to the clients system or does it go back and forth on the .JS file as the user clicks a button etc?
Copy linkTweet thisAlerts:
@SparoHawkJun 01.2010 — JS files are downloaded and cached by the browser. They will be downloaded once and every time you go back to the page it will pull the JS files from the cache if they are there.

The clicks of a button only call a function within the JS files. It does not have to reload or re-download the JS files.

When you access a web page the browser loads the the source from top to bottom. Since the JS files normally located in the <head> section they will be loaded in the same order they are placed. Static HTML files can be cached by the browser, but that is assuming that nothing ever changes in them.

As for bandwidth, it will depend on how many external JS files you have and how big they are. Browsers can download up to 4 files simultaneously. You can use that to do some math on bandwidth.
Copy linkTweet thisAlerts:
@tvb2727authorJun 01.2010 — Oh I see. I will just have one .JS file as of right now. I should be good. Thanks.
Copy linkTweet thisAlerts:
@Jarrod1937Jun 01.2010 — The main benefit is that if you have correct cache headers sent for a .js file (like an expires header so no 304 response has to be sent), then you're effectively caching all javascript code for your entire site with a single visit. Compare this to if you had it placed directly within the html, every page then would be inflated to the size of the javascript code. So it has that benefit as well as the others mentioned already.

However you still will want to have as few .js files as possible, the more you have the more http requests you'll have for that first page view, and contrary to whats been said its only 2 connections per domain for IE7 and under.

And one quick tip for you, when javascript is loaded as part of the html all is good and well. However if you have javascript in a .js file, then when the browser hits it, it will not load anything else for fear of having to rerender the page if the javascript contained within the .js changes the layout. So when using .js files its always a good idea to place them as low in the document as possible, preferably right before the </body>. That way the browser can load all style elements (like .css files which are good to use for the same reason) and page structure before attempting to load the .js.
Copy linkTweet thisAlerts:
@SparoHawkJun 01.2010 — [B]Jarrod1937[/B], the "only 2 connections per domain for IE7 and under" can be bypassed by using alternate sub-domains. Lots of dynamic web applications make use of this advantage to boost loading times.
Copy linkTweet thisAlerts:
@Jarrod1937Jun 01.2010 — [B]Jarrod1937[/B], the "only 2 connections per domain for IE7 and under" can be bypassed by using alternate sub-domains. Lots of dynamic web applications make use of this advantage to boost loading times.[/QUOTE]
Indeed, i use that trick myself. However, unless i am misreading your post, i was responding to your wording:

"As you know browsers pipeline a maximum of around 4 simultaneous connections to a sub domain"

Which to me says that browsers pipeline a max of around 4 connections per subdomain, which isn't true, most pipe a max of 2. IE8 however is changing that up.

Edit: just occured to me that you may have misread my post. I tend to use subdomain and domain interchangeably, thus what i meant is that browsers IE7 and under are limited to 2 connections per domain and 2 connections per subdomain. I don't make the distinction here since you can also bypass the 2 connections limit by using a cdn that can be an entirely separate domain from yours.
Copy linkTweet thisAlerts:
@SparoHawkJun 02.2010 — I get your post better now.

I did say "around" 4, which meant it could be less or more. Anyway, I think we agree on everything. =)

On a side note, in Firefox you can modify the max pipelines in the about:config. Haven't searched if it is possible on other browsers.
Copy linkTweet thisAlerts:
@Jarrod1937Jun 02.2010 — I get your post better now.

I did say "around" 4, which meant it could be less or more. Anyway, I think we agree on everything. =)

On a side note, in Firefox you can modify the max pipelines in the about:config. Haven't searched if it is possible on other browsers.[/QUOTE]

I believe you can change it for IE by making some registry edits. However i am not sure about others. You can also turn on http pipelining in firefox to even further improve response times for servers that support it. Though sadly support for http pipelining has decreased considerably due to other technical issues.
Copy linkTweet thisAlerts:
@sohguanhJun 02.2010 — My personal take on JavaScript is I will design my application in such a way such that UI related and simple front end validation will be in JS. All other further non-UI related issues I will delegate it to the back-end (PHP,Perl,C++,Java etc) to process it. This is done hoping that the final code size for the JavaScript remain lean and serve the few specific functions well.

But knowing developers habit, most JS developers will take on even functions that is better suited using a server programming language. This could be due to that particular developer leanings but a truly "good" system should be a good mix of client and server languages.

My favorite analogy. When the hole is round, we use a round peg to fit it in easily. If we insist on using a square peg to plug into a round hole, we can expect difficulty and possibly scarring the edges around the hole. We can still force the square peg into a round hole of cuz but this is not how a IT system *should be* implemented from my point of view.
×

Success!

Help @tvb2727 spread the word by sharing this article on Twitter...

Tweet This
Sign in
Forgot password?
Sign in with TwitchSign in with GithubCreate Account
about: ({
version: 0.1.9 BETA 5.28,
whats_new: community page,
up_next: more Davinci•003 tasks,
coming_soon: events calendar,
social: @webDeveloperHQ
});

legal: ({
terms: of use,
privacy: policy
});
changelog: (
version: 0.1.9,
notes: added community page

version: 0.1.8,
notes: added Davinci•003

version: 0.1.7,
notes: upvote answers to bounties

version: 0.1.6,
notes: article editor refresh
)...
recent_tips: (
tipper: @AriseFacilitySolutions09,
tipped: article
amount: 1000 SATS,

tipper: @Yussuf4331,
tipped: article
amount: 1000 SATS,

tipper: @darkwebsites540,
tipped: article
amount: 10 SATS,
)...