Where should I keep JS and CSS code — inline or in an external file

Hamlet’s great question (“To be or not to be“), turns in web development and mobile world into Javascript (or CSS stylesheet) asking the developer: “To be inline or not to be”. In other words: what is better — to put code inline of HTML page or to put it in an external file? I was more than sure, that the answer is pretty straightforward — external file is always better. And I keep myself with this answer. However, I found a few arguments, that my sound interesting at first, but must be answered.

There is this question and my answer to it. But the most important part in this blog post is put in my comments spread around other answers (my comments were magically removed, so you can’t read them now). But, let’s first deal with some undoubted facts.

External files

Key advantages of using Javascript code and CSS stylesheets kept in an external files are:

1. It is faster. The .js and .css files can be minified, obsfucated and sometimes even gzipped. They can be put to CDN-like solution or network (serves files from location geographically closest to user location). Browsers can use parallelization to start loading both files in the same time etc.,
2. Code is reusable. Code kept in one file can be shared by many HTML pages.
3. Your page can be build upon MVC architectural pattern. Where HTML code is the model (data), CSS is the view (decorator) and Javascript is the controller.

Inline code

Now, to name counter arguments — developers prefering using inline Javascript code points out following advantages of it:

1. Inline code is actually faster to download. That’s because, connection times are usually ten to even hundred times bigger than real data exchange time. In other words, overall process of downloading Javascript code is slower. In other words, downloading two separate files (HTML page and Javascript code) is faster (thanks to parallelization, if browser fully supports it) only in terms of real data exchange. But, time saved on this (and even much, much more) is wasted on mentioned connection-lag point.
2. Inline code is easier to debug.

Let’s deal with these two arguments, shall we?

1. Most pages are build (designed) with assumption, that files will be read from server only once or few times, cached in browser’s cache, and for the rest of times — read from that cache. If you compare speed of reading file from browser cache, for inline code and external file, you’ll get very the same times. But, for inline code, you’re loosing every possible benefit from code reusabillity.
2. That is not a real argument, rather a huge misunderstanding, so, there’s not much to deal with. We’re talking about production code, that will be placed on production server. It should be minified, obsfucated, gzipped and made as small as possible in any other ways. Which means — it will be made as less readable as possible. Debugging has nothing to do with the fact, whether you keep your code inline or in a separate file. You do not debug production code. It is assumed, that it is produced after debugging and after marking it as perfect. Any developer can have whatever he or she wants in his/her debugging environment, but that has nothing to do with the production code. Amen.

Bind, bind and bind again!

Other inline Javascript / CSS supporters points out, that a tiny small Javascript code, should be placed inline, because it fails on loading (connection) time problem (mentioned above — we’re going back to roots). Even if my above counter argument (about caching) doesn’t convince you, then let me put it this way: What do you mean by “tiny” code? Even small one-line event listeners should be kept together in one file, for clarity of reading (unless you want to keep them inline on development machine and then put back together for production code, but that’s a complete madness).

If you’re using any framework, like Zepto or jQuery, you should put them all (along with all other, non-method code) to $(function (){}); and you should register events with .bind(), .live(), .on() or any other similar approach.

If you write in pure Javascript, do the same , by declaring event listeners as simple functions (function buttonOnClick()) or object methods (app.buttonOnClick: function()) and bind them directly in HTML (<button onclick="buttonOnClick"> or </button><button onclick="app.buttonOnClick">). That is the only inline code you should use. Period. Amen.

Summary

I must admit, that I got a little bit “choked” on that connection-lag argument, but as you can see, I found a good counter argument (the “easier debugging” argument made me just laughing). On, the other hand, I don’t reserve myself a right to be an oracle.

The general conlusion from mentioned question and all its answers is, that you should carefully measure, how your page is being used, consider different scenarios (for example, take a look at this one) and then match the proper strategy.

I must again admit, that I haven’t found any situation, project or scenario yet, that would convinced me to use inline code over external files. But, that doesn’t mean, that I won’t find such in a future and, that I won’t change my mind on this subject.