Skip to main content

Why Should I Avoid Inline Scripting? [Resolved]

A knowledgeable friend recently looked at a website I helped launch, and commented something like "very cool site, shame about the inline scripting in the source code".

I'm definitely in a position to remove the inline scripting where it occurs; I'm vaguely aware that it's "a bad thing". My question is: what are the real problems with inline scripting? Is there a significant performance issue, or is it mostly just a matter of good style? Can I justify immediate action on the inline scripting front to my superiors, when there are other things to work on that might have a more obvious impact on the site? If you pulled up to a website, and took a peek at the source code, what factors would lead you to say "hmm, professional work here", and what would cause you to recoil from an obviously amateurish job?

Okay, that question turned into multiple questions in the writing. But basically, inline scripting - what's the deal?


Question Credit: thesunneversets
Question Reference
Asked December 15, 2017
Posted Under: Programming
37 views
10 Answers

I'm not going to be the devil's advocate, but there is no strict relationship between amateurish job and inline JavaScript. Let's see the source code of several most known websites:

  • Google,
  • Wikipedia,
  • Microsoft,
  • Adobe,
  • Dell,
  • IBM.

Every of their home pages use inline JavaScript. Does it mean that all those companies hire amateurish people to create their homepages?


I'm one of those developers who can't put JavaScript code inside HTML. I never do it inside the projects I work on (except probably some calls like <a href="javascript:..."> for the projects where unobtrusive JavaScript was not a requirement from the beginning, and I always remove inline JavaScript when I refactor code of somebody else. But does it worth the effort? Not so sure.

Performance-wise, you don't always have better performances when putting JavaScript in a separate file. Usually, we are tempted to consider that inline JavaScript waste bandwidth, since it cannot be cached (except when you deal with static cacheable HTML). On the opposite, an extern .js file is loaded only once.

In reality, this is just another premature optimization: you may be right thinking that externalizing JavaScript would fasten your website, but you may also be totally wrong:

  • What if most of your users come with an empty cache?
  • Do you considered that with an extern .js file, a request will be made to this file at every page request, if the website is not configured properly (and usually, it's not),
  • Is .js file really cached (with IIS, it may not be so easy)?

So before optimizing prematurely, collect statistics about your visitors, and evaluate the performances with and without inline JavaScript.

Then comes the final argument: you mixed JavaScript and HTML in your source, so you suck. But who said you mixed both? The source code used by the browser is not always the source code you wrote. For example, the source code may be compressed, minified, or several CSS or JS files may be joined into one file, but this doesn't mean that you really named your variables a, b, c ... a1, etc. or that you wrote a huge CSS file without spaces or newlines. In the same way, you can easily have external JavaScript source code injected into HTML at compile time or later through the templates.


To conclude, if you mix JavaScript and HTML in the source code you write, you should consider not doing it in your future projects. But it doesn't mean that if the source code sent to the browser contains inline JavaScript, it's always bad.

  • It may be bad.
  • It may on the opposite be a sign that the website was written by professionals who cared about performance, made specific tests, and determined that it would be faster for their clients to inline parts of JavaScript.
  • Or it may not mean anything at all.

so rather shame on the person who says "very cool site, shame about the inline scripting in the source code" by looking just at the source sent to the browser, without knowing anything about how the website was done.


credit: Arseni Mourzenko
Answered December 15, 2017

what are the real problems with inline scripting? Is there a significant performance issue, or is it mostly just a matter of good style?

The advantages are not performance based, they are (as Michael pointed out in his comment) more to do with separation of the view and the controller. The HTML/CSS file should, ideally, contain only the presentation and separate files should be used for scripts. That makes it easier for you (and your peers) to read and maintain both the visual and functional aspects.

Can I justify immediate action on the inline scripting front to my superiors, when there are other things to work on that might have a more obvious impact on the site?

No, probably not. It can be very hard to convince the powers that be of pure maintenance work, even if it you believe it will save them money in the long run. In this case though, I don't think it is so important that you should stop everything and get rid of your inline scripting. Instead, just make sure that you make a conscious effort to rectify areas as you work on them for other reasons. Refactoring code should be something you do regularly but only a little bit at a time.

If you pulled up to a website, and took a peek at the source code, what factors would lead you to say "hmm, professional work here", and what would cause you to recoil from an obviously amateurish job?

The number one factor that would tell me it is not professional is the overuse of tables or divs. Here is an article explaining why neither should be overused.


credit: Code-Read
Answered December 15, 2017

Here's a few reasons.

  1. Inline script cannot be minified (converted to a shorter version through symbol reduction). Not a concern on broadband but consider a mobile device in a low bandwidth area, or users who are on global data roaming-- every byte may count.

  2. Inline script cannot be cached by the browser unless the page itself is cacheable (which would make for a very dull page). External Javascript files need only be retrieved once, even if the page content changes every time. Can seriously affect performance on low bandwidth connections.

  3. Inline script is harder to debug because the line number associated with any error is meaningless.

  4. Inline script is reputed to interfere with accessibility (508/WAI) considerations, although that does not mean all inline script causes issues. If you end up with a screen reader announcing script content you have a problem! (Never seen this happen though).

  5. Inline script cannot be tested independently of its page; external Javascript files can be run through independent testing, including automated tests.

  6. Inline script can lead to poor separation of concerns (as described by many of the other answers here).


credit: John Wu
Answered December 15, 2017

There are multiple reasons that would justify not including the script inline:

  • First of all, the obvious answer- it makes for code that is cleaner, more concise, easier to understand and read.

  • From a more practical standpoint, you often want to reuse scripts/CSS/etc. all over your website- inlining these parts would mean having to edit every single page every time you do a small change.

  • If you use a SCM for your project, then having your different components well separated will make tracking changes and commits easier for everyone involved.

As far as I know, performance would not be a concern. It would depend on a lot of things related to the nature of your website, the specs of your server, etc. For instance, if your webpage uses a lot of javascript, your browser may cache the scripts, which would result in better performance when the code is separated in multiple files. On the other hand, I'd be tempted to say that some servers might serve a single large file faster than multiple smaller files- in this case one could argue that not separating the code is better performance wise.

I'm not aware of any formal tests in this area, although it's very likely someone has done them.

In the end, I would say that it's a matter of good practices more than anything else, and that the advantages in terms of readability and organization (specifically w.r.t. point 2) make separating the code in distinct files a much better option.


credit: Bitgarden
Answered December 15, 2017

One argument I'm missing here is the possibility of increased protection against cross site scripting attacks.

It's possible to disable the execution of inline JavaScript in modern browser via the Content Security Policy. This reduced the risk of your site falling victim of XSS. This may be a more convincing argument to make to your management to invest in removing inline script.


credit: MvdD
Answered December 15, 2017

One reason NOT to use InLine Javascript (not even onclick="DoThis(this)" on buttons), is if you intend to make your web application a Chrome App. So, if you are planning to port your web app into a Native Chrome App, start by NOT including ANY inline javascript. This is explained right at the beginning of what you will need to change (mandatorily) from your web app if you intend to "Chrome-etize" it.


credit: FraCoinsuy
Answered December 15, 2017
Your Answer
D:\Adnan\Candoerz\CandoProject\vQA