: Is inline JavaScript good or bad? I've currently switched from WordPress to Yii framework and an external developer is rebuilding my site. One thing I notice is that each time he invokes AJAX

@Gretchen104

These answers miss the mark. Have a look at Inline caching.

Since Yii is coded in PHP, a common (or perhaps uncommon) PHP pattern you'll find is that developers will sometimes write PHP code to generate Javascript code dynamically at the server - based on some state, condition or value known by the server - and then send it all to the client in one batch, allowing the client to execute the function and skip some of the computation that has already been done by the server.

Instead of sending a whole bunch of generic Javascript functions in a .js file to the client which have no context until provided with data (data which may be sitting on the server and require a round trip), we can "bake-in" the context/data as part of the Javascript function. This is thrifty because it means you're sending the functionality/data together, and only sending the functionality/data that a client may need at the time, instead of sending the whole app on the first page load. It also means you don't have to expose your entire app to being easily downloaded and reverse-engineered on the first page load because you are only injecting small portions of functionality that each individual client may need at the time. Not sure how well that bodes for SEO, but I'm sure it can be optimized accordingly. Reducing the number of HTTP requests by having some inline Javascript can be useful, it just depends.

Consider the case of an end-user writing a page in some CMS software using a WYSIWYG editor. How is this user going to add new functionality to the page when they don't have access to your source .js files on the server? They switch to the HTML tab and use inline Javascript.

Not all inline Javascript is bad; sometimes onclick is fine too. As a general recommendation, avoid writing inline Javascript and you'll be on your way to building good habits.

References:


Inline caching
Optimizing dynamic JavaScript with inline caches
Explaining JavaScript VMs in JavaScript - Inline Caches
Why Should I Avoid Inline Scripting? (see MainMa's & user1389596's answer)

Vote Up Vote Down

@Mendez628

Normally inline JS code is bad, as the others said before me.

But I think of a use case where inline JS is better.

Think of a CMS which inserts a JS driven gallery. The gallery maybe done in jQuery. It is identified by an id attribute, which is not only unique on the page, but also unique throughout the whole site. In this case—I think—inline JS would be better, because the JS code is used only on one page and you have no HTTP overhead

Vote Up Vote Down

@Jennifer507

The answer actually depends on what is being done.

If you notice inline JavaScript that is used across the website (e.g. a widget that shows inside the header on all pages of the website) then it would be appropriate to move it to a "common" JavaScript file.

In fact, I would move as much JavaScript to a common JavaScript file as possible even if it were used on a single page. I would configure the server to send strong caching and compression headers for JavaScript files; which reduces the size of page(s) but not increase the size of JavaScript file by much.

On the other hand, if the JavaScript is simply a bunch of configuration options/initialization e.g.:

$(function () {
myplugin({
images: ["img1", "img2", "img3"]
});
});


where for some reason it was not possible to move the code to external JavaScript file (e.g. when the image parameters are coming from database) I would keep it in inline. Having said that, I would choose third party plugins that are "unobtrusive" (or convert them as such).

Vote Up Vote Down

@Pierce454

I'm a Yii developer and I can tell you, that Yii has nothing to do with this. It is completely on developer side, whether he or she put Javascript code to a separate file and register it with HTML (view) page with CClientScript::registerScriptFile method or put it directly to view (HTML) code and register it using CClientScript::registerScript method.

As per your answer, most (professional?) Yii developers strongly vote for first approach, that is -- keeping as much Javascript code in separate files as possible. So, this is most certainly not a new trend of coding, but rather a bad developer practice. At least, that's how it is seen in Yii community.

EDIT: Actually, I forgot about most important argument. Yii (as well as most other professional PHP frameworks) is build upon MVC design pattern (actually: architectural pattern). And the same pattern can be used in fronted: HTML code is the model (data), CSS is the view (decorator) and Javascript is the controller. All of them put into separate files, .js and .css files -- minified, obsfucated and gzipped in the best scenario.

When you build up your Yii application, you can break the MVC pattern and keep everything in the same file. The question is -- is it worth doing so, what are the benefits (none?) and where will that lead you? You can use the same argumentation, when asking, whether to keep JS code inline or not?

Vote Up Vote Down

@RJPawlick198

It actually depends on the purpose of the webpage you are developing:

I use a small amount of inline JavaScript, whereas I prefer to go for external JavaScript files if it's big.

Either way, when the page loads JavaScript, it has to be executed first. The best practice is to use external JavaScript so it doesn't lengthen your page content. It also makes debugging easier.

Vote Up Vote Down

@Heady270

On my currency conversion site, the majority of sessions are single page views. This is because users can do their currency calculation directly on the landing page (all the calculation is handled client side with JavaScript.)

My page downloads and renders in about half the time when all resources (css, js, and even images) are inline in the page. Because so few of my users view multiple pages, I wouldn't benefit much from some of these resources being cached between page views.

My site is not typical. Most sites have multiple pages per session and large images that would make my technique less applicable. There is no one correct solution to this question; it depends on the site. You need to measure it yourself based on the typical behavior of your users.

Vote Up Vote Down

@Nickens628

It's not necessarily bad to have JavaScript within your HTML file but you must make a judgement call on it.

It is bad if you have a large amount of JavaScript being used across multiple pages. In that case, the JavaScript should be in an external, compressed, and cachable file and if your site has very heavy traffic you should make use of a CDN.

However, if you have a small amount of JavaScript the saving of putting it in an external file might be negated by the fact you need to make an additional HTTP request to retrieve it. In this instance it would be more efficient to keep the JavaScript in your page.

Then again, if this same small snippet of JavaScript is used on multiple pages it would be beneficial to place it in an external file to take advantage of caching.

Ultimately you must weigh up the size of the JavaScript against the overhead of making additional HTTP requests. For the most part, for an 'average' site, it probably isn't going to make a whole lot of difference just putting it in an external file.

Vote Up Vote Down

@Becky754

Inline JavaScript increases download times for the page, which is not good. With a call to a .js file, at least these can be parallel calls and content download times decreased. Yes there are times where it is okay to put JavaScript directly in the HTML code, but you are often better off off-loading this as much as possible.

Keep in mind that page download times (that is, the HTML) and not all the resource calls affect the metrics that affect ranking (albeit as PageRank or in the SERPs it does not matter). The point is, it affects a sites performance for SEO however it manifests.

Vote Up Vote Down