Take the 2-minute tour ×
Webmasters Stack Exchange is a question and answer site for pro webmasters. It's 100% free, no registration required.

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 / jQuery the Yii way, it embeds inserts JavaScript inline in the web page. Although it seems the JavaScript code is placed below the footer, it's still inline.

In general, it seems that JavaScript code is more frequently being put inside the webpage. I've always been thought that JavaScript scripts should, as much as possible, be placed in JavaScript files. Is this a coming "new" trend? Or should I still try to keep JavaScript code in separate files?

share|improve this question
    
What exactly do you mean by it inserts JavaScript inline in the web page? –  Salman A May 14 at 10:08
2  
For the sake of others who find this question and are thinking of things like <a onClick="function(){/* do stuff */} ">Click Here</a> This, I understand, is considered VERY bad and one should seperate their code from their HTML See: This article –  TecBrat May 15 at 3:34
1  
@user1066946 t.co/j1RpJgwoku :-) –  Kos May 15 at 13:34
1  
@user1066946 I really like using Angular, I just observed that the "semantic web" has made a circle (in terms of keeping some glue code next to the DOM) –  Kos May 15 at 15:11
1  
"Although it seems the JavaScript code is placed below the footer, it's still inline." - It sounds as if you are referring to embedded JavaScript, rather than "inline" JavaScript (which TecBrat refers to). –  w3d May 19 at 11:04
show 6 more comments

7 Answers 7

up vote 9 down vote accepted

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.

share|improve this answer
7  
Negotiating a second connection to a presumably same host to download the same amount of data is faster than within the active stream? usually if you get, say, 50Kbps on a file to a host, starting a second session may cut it so that both are now 25Kbps. Unless the host is throttling per connection for some reason. –  EkriirkE May 14 at 6:46
    
There is a con to external files though. If not done properly, you create DOMblocking code, ie the doc.ready trigger is slower, which affects percieved speed. But if properly done, external is the way to go –  Martijn May 14 at 9:38
4  
.js files are better for caching, it does not make sense that two connections to the same host would magically make your download speed larger. –  user29263 May 14 at 14:00
    
The thought of dividing the bandwidth, while I understand your logic and it is not entirely wrong, is a bit misleading. The HTML is smaller taking less time and any subsequent call can actually wait. –  closetnoc May 14 at 15:59
2  
if you are loking for time, you are wrong to look at bandwidth. look at profiler at loading times: normally connection times are 10-100x BIGGER than real data exchange time. this mean that FRAGMENTATION is a real problem, and using an external, dedicated, file for really small js may be worst that inline. Inline is better on browser that does not do real parallelization –  lesto May 14 at 17:10
show 3 more comments

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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?

share|improve this answer
    
Ok. The developer seems to use 3rd party widgets for everything; Autocomplete, ajax image uploads etc. All this adds inline js. –  Steven May 14 at 13:11
    
No, I can't agree. I'm using Twitter Bootstrap in my Yii applications (probably Yii's biggest extension and huge set of widgets) as well as many other Yii's extensions and none of them uses inline JS. Your developer would have to be really lucky to find widgets and extensions, that uses only inline Javascript. You have to be quite experienced in Yii to start writing own extensions (with exception of those few, really poorly written) and even semi-experienced Yii developer uses inline code as last of options, if everything else fails. –  trejder May 14 at 13:16
    
Using 3rd party extensions and widgets in Yii is a great idea (you don't have to invent the wheel again). But, using inline JS code in Yii application or extension really is a bad attitude. So either force your developer to write better code / use better extensions and widgets or... get a better developer! :] –  trejder May 14 at 13:17
    
Ok, thanks for the feedback. Besides Stackoverflow, where can I find a good Yii community? –  Steven May 14 at 13:18
    
At Yii forum. Most pages are freely accessible. Some require to register an account and login. Most Yii developers at Stack Overflow have own accounts at the forum. After nearly six years of existing, Yii framework has earned a large community of developers, so if you look carefully, you should be able to find few Yii developers in your local community or even neighborhood. Good luck. –  trejder May 14 at 13:23
add comment

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.

share|improve this answer
add comment

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).

share|improve this answer
add comment

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

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.