Should I completely stop using inline JavaScript?

Question

In a discussion elsewhere on SO, I was informed that "[m]ost browsers will not execute inline javascript... these days." This is news to me, and I have been researching to try to verify this statement, in order to understand if I need to adjust the code on some of the websites I maintain in order to make them compatible with future browsers.

As far as I can tell, the commenter is referring to Content Security Policy, a relatively new proposal that would, if implemented, restrict or totally disable inline scripting.

However, I note:

• This requires the use of a (currently optional) HTTP header or meta-tag equivalent, which I doubt any webserver will ever be able to send out by default.

• The browser support for it is currently limited to the latest & greatest, especially on mobile.

• Nothing in this indicates (to me) that 'most browsers' will not serve inline JavaScript at all, nor that they are planning to implement such a thing in the future.

My question is basically, am I wrong about #3? Is inline JavaScript support likely to be on the way out?

---

Incidentally, I ask this on SO because I think it might be a "practical, answerable problem that is unique to software development." If others believe this is too broad or belongs somewhere else on SE, I would like to hear your suggestions. Thanks in advance!

Answer 1

There are hundreds of millions of web pages out there that would stop working if inline javascript was disabled by default. A browser that does that would have to be very brave.

Backwards compatibility in browsers is a good and a bad thing (just think about IE!). A bad thing, because they could be lighter and quicker if they didn't have to support legacy code, and a good thing, because, otherwise, hundreds of millions of useful webpages that no one maintains any longer would be almost lost.

Think that no browser, even when using HTML5, will enforce strict rules for HTML, so I doubt inline javascript will be disabled. And even if there is introduced a way to do it, you, as a developer, will have a way to disable that option (or even better, not to enable it).

That said, I'd be the first to enable it in my own websites, because I hate inline code. My advice: never use it except if strictly necessary.

Answer 2

Like the comment said, whoever said that is wrong.

However, you should still stop using inline JavaScript (exception, frameworks like Angular) because it's poor practice. Concerns should be separated. For instance:

<someElement onlick="func()">Derp</someElement> // this is bad.
someElement.addEventListener("click",func,false); //this is much better

It's easier to read, and in larger apps, it's much easier to maintain, especially in a separate file.

It will still act the same, yes, but in my experience I have encountered many more problems debugging inline js than I did external scripts.

Answer 3

Browsers will execute inline JavaScript

All browsers will execute inline JavaScript provided they have JavaScript enabled. Whoever told you this was wrong.

Browsers will likely continue to execute inline JavaScript by default.

Inlining JavaScript is the easiest way to make a piece of script occur at a particular point in the page. The internet is democratic. You don't need to be a computer scientist to hack together a renderable HTML page with some blinking text and a dancing penguin. This is how the web is supposed to be.

Also, sometimes it is useful to be able to pass through a content managed JSON object from the HTML to a static script. Any browser that removed this would become instantly less useful, and people would migrate away.

Issues with inline JavaScript (why this is actually a good idea)

Allowing Inline JavaScript makes cross site scripting (XSS) attacks fairly easy. The attacker enters some JavaScript into a web form, perhaps a comments box, and the server then renders that script to the page. The script can then do things like steal login credentials or redirect to another page containing malware.

Currently XSS must be dealt with on a per server basis, and it's actually harder than you might think as there are many ways to execute script. Implementing a simple header element that turns off inline script would be a much easier way to guard against all XSS.

It's best practice not to use inline JavaScript if possible

You should think twice about using inline JavaScript. Separation of concerns (HTML5 for meaning, CSS3 for styling, JavaScript for behavior) remains good practice. It's tidier and easier to maintain. Also, by separating your JavaScript into a separate file, you gain the benefits of caching. The script will not need to be downloaded each time a page on your site is viewed.

Optimising for pure speed

The exception to this is if you are optimising for speed. Placing your script inline at the end of your file will ensure your content is visible as soon as possible. This is a technique that Google are fond of. I don't hold with it personally as it makes your code messy, but it will render the page content slightly faster.