20

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?

Improve this question
11
  • What exactly do you mean by it inserts JavaScript inline in the web page?
    – Salman A
    May 14, 2014 at 10:08
  • 3
    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, 2014 at 3:34
  • 1
    @user1066946 t.co/j1RpJgwoku :-)
    – Kos
    May 15, 2014 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, 2014 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).
    – MrWhite
    May 19, 2014 at 11:04

8 Answers 8

Reset to default
32

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.

Improve this answer
0
15

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.

Improve this answer
9
  • 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, 2014 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, 2014 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, 2014 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, 2014 at 15:59
  • 3
    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, 2014 at 17:10
14

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.

Improve this answer
0
5

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?

Improve this answer
5
  • Ok. The developer seems to use 3rd party widgets for everything; Autocomplete, ajax image uploads etc. All this adds inline js.
    – Steven
    May 14, 2014 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, 2014 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, 2014 at 13:17
  • Ok, thanks for the feedback. Besides Stackoverflow, where can I find a good Yii community?
    – Steven
    May 14, 2014 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, 2014 at 13:23
3

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.

Improve this answer
0
2

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

Improve this answer
2

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:

Improve this answer
0

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

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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