How to use inline JavaScript

Is Inline JavaScript Good Or Bad?


I have currently switched from WordPress to the Yii framework and an external developer is rebuilding my website.

One thing that strikes me is that every time he calls AJAX / jQuery the Yii way, JavaScript inline is embedded in the website. Even though the JavaScript code appears to be placed below the footer, it is still inline.

In general, it seems that JavaScript code is inserted into the web page more frequently. I've always believed that JavaScript scripts should be placed in JavaScript files as much as possible. Is this a coming "new" trend? Or should I try to save JavaScript code in separate files anyway?






Reply:


Inline JavaScript increases the download times for the page, which is not a good thing. When a file is called, these can at least be parallel calls and the download times for content can be shortened. Yes, there are times when it's okay to put JavaScript straight into the HTML. However, it is often better if you outsource this as much as possible.

Note that page load times (i.e. HTML) and not all resource calls affect the metrics that affect ranking (even if it doesn't matter as PageRank or in the SERPs). The point is, it affects a website's performance for SEO however it manifests itself.







On my currency conversion website, most sessions are single pageviews. This is because users can do their currency calculation right on the homepage (all the calculation is done on the client side using JavaScript.)

My page will be downloaded and rendered in about half the time it takes all of the resources (CSS, JS, and even images) on the page. With so few of my users viewing multiple pages, I wouldn't get much benefit from caching some of these resources between page views.

My side is not typical. Most websites have multiple pages per session and large images that would make my technique less applicable. There is no right answer to this question; it depends on the website. You have to measure it yourself against the typical behavior of your users.


Having JavaScript in your HTML file isn't necessarily a bad thing, but you need to make a judgment about it.

It is bad if you are using a large amount of javascript on multiple pages. In this case, the JavaScript should reside in an external, compressed, and cacheable file. If your site has a lot of traffic, consider using a CDN.

However, if you have a small amount of JavaScript, saving the drop to an external file can be ruined by making an additional HTTP request to get that file. In this case, it is more efficient to leave the JavaScript on your page.

If the same little JavaScript snippet is used on multiple pages, it is helpful to place it in an external file to take advantage of caching.

Ultimately, you have to weigh the size of the JavaScript against the overhead of additional HTTP requests. In most cases, just putting it in an external file will probably not make much of a difference to an "average" site.


I am a Yii developer and I can tell you that Yii has nothing to do with it . It lies entirely with the developer whether he or she puts JavaScript code in a separate file and registers it with the method on the HTML page (view) or puts it directly on the HTML page (view) and registers it with the method.

According to your answer, most (professional?) Yii developers strongly support the first approach, which is to keep as much Javascript code as possible in separate files. So that's for sure no new code trend but bad developer practice. At least that's the way it is in the Yii community.

EDIT : I actually forgot the most important argument. Yii (like most other professional PHP frameworks) is based on the MVC design pattern (actually: architecture pattern). And the same pattern can be used in fronted: HTML is the model (data), CSS is the view (decorator) and Javascript is the controller. Put all of them in separate files , and files - minimized, obsfucated, and in the best scenario gzip.

When you build your Yii application, you can break the MVC pattern and keep everything in the same file. The question is - is it worth it, what are the benefits (none?) And where does this take you? You can use the same reasoning when asking whether or not to keep JS code inline.







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

I use a small amount of inline JavaScript, while I prefer external JavaScript files when they are large.

In either case, if the page loads JavaScript, it must be executed first. It is recommended to use external JavaScript so as not to lengthen the page content. This also makes debugging easier.


The answer actually depends on what is being done.

If you notice inline JavaScript that is used across the site (e.g. a widget that appears in the header on all pages of the site), it is appropriate to move it to a "generic" JavaScript file .

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

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

where for some reason it was not possible to move the code to an external JavaScript file (e.g. if the image parameters are from the database) I would leave it inline. However, I would choose third-party plugins that are "nondescript" (or convert them as such).


These answers miss the mark. Take a look at inline caching.

Since Yii is coded in PHP, you will find that developers sometimes write PHP code to dynamically generate Javascript code on the server based on a state, condition, or value known to the server. Then send everything in one batch to the client so that the client can perform the function and skip some of the computation already done by the server.

Instead of sending a whole bunch of generic javascript functions to the client in a .js file that has no context until they are dated (data that may be stored on the server and require a round trip), we can the "bake" context / data as part of the Javascript function. This is economical as you are sending the functions / data together and only sending the functions / data that a client might need at that point, rather than sending the entire app when the first page loads. This also means that you don't have to simply download and reverse engineer your entire app when the first page loads, as you only incorporate a small portion of the functionality that each individual client may need at that point in time. I'm not sure how good this is for SEO, but I'm sure it can be tweaked accordingly.

Imagine an end user writing a page in CMS software with a WYSIWYG editor. How does this user add new functionality to the page if they don't have access to your JS source files on the server? You switch to the HTML tab and use inline Javascript.

Not all inline javascript is bad; sometimes onclick is okay too. Avoid writing inline Javascript in general and you are well on your way to developing good habits.

References:


Usually inline JS code is bad like the others before me said.

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

Imagine a CMS that inserts a JS controlled gallery. The gallery can be created in jQuery. It is identified by an ID attribute that is unique not just on the page but across the site. In this case - I think - inline JS would be better because the JS code is only used on one side and you have no HTTP overhead

We use cookies and other tracking technologies to improve your browsing experience on our website, to show you personalized content and targeted ads, to analyze our website traffic, and to understand where our visitors are coming from.

By continuing, you consent to our use of cookies and other tracking technologies and affirm you're at least 16 years old or have consent from a parent or guardian.

You can read details in our Cookie policy and Privacy policy.