It is always recommended to avoid inline Javascript codes by putting all codes in a JS
file, which is included in all pages. I wonder, if this does not cause pe
Making js inline to all pages make the application heavy so we should go with external js which includes to require pages that will help us to utilization of js code to each functionality.
there are variuos case that needs to be keep in mind while placing js code.
For inline :
there is no need to navigate to an external file if you need to change something quickly, so its better in locality
if you are using AJAX in some elements of your page you may loose all the dom element onclick etc for that section, that obviously depends on how you binded them. for ex you can use live or delegate in case your using jQuery to avoid above said problem... but i find that if js is small enough it is preferable to just put it inline.
Now there other theory for ex
Externalizing javascript is one of the yahoo performance rules:
http://developer.yahoo.com/performance/rules.html#external
Inline styles/script gets muddled with html content and can get hard to differentiate. One of the the keys to having maintainable code in web development is writing code that is easily readable by someone who didn't write it. Mixing script tags into your html can make it very hard to find a function that is affecting the rest of you code. Putting Javascript in .js files and Styles in CSS files makes code cleaner more readable.
It's not recommended to inline static resources (in your case, the inline javascript) since you can't cache them.
Caching a static resource reduces the size of page loads – thus increasing the page load speed – for returning visitors. However it comes at the cost of an additional HTTP request which should be avoided.
Whenever the static resource is so small that the additional size is negligible in comparison to a HTTP request, then it's actually recommended to keep that resource inline.
It's usually a good idea to keep javascript libraries in external (cacheable) documents, while keeping small amounts of scripts inline.
So, in response to your headline – inline javascript isn't bad per-se. It's a balance whether or not it's worth a HTTP request to cache the resource.
Avoiding inline js is not performance based...but its more about maintainability and separating the presentation layer(html) from the controller layer(js).
Having inline js on different pages will make it difficult to maintain for you and others as the project scale increases.
Moreover using separate js files you can encourage reusability and modular code design.
keeps your html clean and you know where to look when any js error occurs instead of multiple templates.
It's possible that running unnecessary JavaScript on a page will cause that page to be slow to load. It depends on the JavaScript being run.
You could test your example code by timing it, and seeing how long it takes for JavaScript to run getElementsByClassName
repeatedly.
(I'd bet it doesn't take very long at all, even if you've got 26 functions looking for elements with different class names, but with performance, always measure first.)
If execution time is a problem, you could write your JavaScript so that it's mostly in one file, but expose functions that you run from inline JavaScript on the pages it's required on, instead of running it via onload
events in your JavaScript file.
It's worth remembering everything that has to happen when a page is loaded though:
Although you certainly can write JavaScript that runs slowly, it's likely that it's better overall to have your JavaScript in an external file, and therefore in the user's browser's cache, rather than having it increasing page size by being inline. Network, in general, tends to be much slower than JavaScript parsing/execution.
But, and I'm saying this again because it's the most important point, this will all be different depending on your code. If you want to keep your performance good, your first and last act must be to measure it.