Q:

Why Should I Avoid Inline Scripting?

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?

A:

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.

A:

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.

A:

It's generally good to try to keep HTML and JS generally separated.  HTML is for the view, JS is for the application logic.  But in my experience extreme decoupling of html and javascript (for the sake of purity) does not make it more maintainable; it can actually be less maintainable. 
For example, I sometimes use this pattern (borrowed from ASP.net) in setting up event handlers:
<input type="button" id="yourId" onclick="clickYourId()" />

or
<input type="button" id="yourId" onclick="clickYourId(this)" />

There's no mystery what is triggering an event to happen.  The reason is that six months later you can inspect the element (eg, in Chrome) and see immediately what javascript event is triggered.  
On the other hand, imagine you are reading someone's else's code, which is a hundred thousand lines, and you come across a magical element that fires off a javascript event:
<input id="yourId"  />

How can you easily tell me what javascript method this is calling?  Chrome has made this easier, but perhaps the event is bound to the id, or perhaps it's bound to the first child of the container.  Maybe the event is attached to the parent object.  Who knows?  Good luck finding it.  :)
Also, I would argue that hiding javascript completely from the designer may actually increase the likelihood of them breaking it on an update.  If someone edits code for an magically active element, what indication in the code do they have that would let them know this is an active element on the page? 
So in short, best practice is to separate HTML and Javascript. But also understand rules of thumb are sometimes counterproductive when carried to the extreme.  I'd argue for a middle-road approach.  Avoid large amounts of inline js.  If you do use inline, the function signature should be very simple like:
1. emptyFunction()
2. doCallWithThis(this)
3. atTheExtremOnlyPassOneNumber(2)

