2

This is a piece of code which is normally used by the majority of programmers:

<input type="text" id="myID" onchange="myFunction()" />
<script>
     function myFunction (){
          //DO THIS
     }
</script>

But in my case I prefer to create a file with .js extension that contains only Javascript and .html that contains only HTML. So in my index.html I have this line:

<input type="text" id="myID"/>

And in main.js I have this line:

function myFunction (id){
      $(id).change({
           //DO THIS
      });
 }

 myFunction("#myID");

The two methods are the same and do the same thing, but what is the best? What is the best performance between inline Javascript code and pure Javascript code?

Mustapha Aoussar
  • 5,833
  • 15
  • 62
  • 107
  • 1
    *normally used by the majority of programmers* - do you know this? Or is this just your assertion? – random_user_name May 22 '14 at 16:04
  • No matter how you do it, your computer is bored and does it equally fast. The question is, how can you work best with that code. The only real difference is, when having JS in an extra script, there is a second HTTP request with some overhead. But you can cache it np. – Daniel W. May 22 '14 at 16:05
  • You seem to be asking about two different things. duplicate if you're asking about difference between adding a handler inline vs as property: http://stackoverflow.com/questions/6348494/addeventlistener-vs-onclick – linstantnoodles May 22 '14 at 16:06
  • @linstantnoodles - not a duplicate of that question – EkoostikMartin May 22 '14 at 16:07
  • Sorry is just my assertion. But I've worked in a company IT where my senior colleagues used the first method. – Mustapha Aoussar May 22 '14 at 16:07
  • @EkoostikMartin part of it is. There's two things he's asking about. One is whether it's faster to use external js. The other is the difference between attaching handler inline vs as property (via jquery). I'm calling duplicate on the latter. – linstantnoodles May 22 '14 at 16:08
  • Look at the benchmarks: http://jsperf.com/jquery-selector-benchmark – Daniel W. May 22 '14 at 16:08
  • 1
    I think the question would be improved by removing the jQuery reference in the external code - that is confusing an interesting discussion. – pherris May 22 '14 at 16:13
  • 1
    The best way would be `document.getElementById(id).addEventListener("change", function() {})` -- No jQuery, lol – ndugger May 22 '14 at 16:14
  • @NickDugger The `.change()` and `document.getElementById(id).addEventListener("change", function() {})` are the same and in my opinion jQuery is faster than Javascript. – Mustapha Aoussar May 22 '14 at 16:19
  • 1
    Do you mean jQuery is faster to type, or do you actually think that jQuery runs faster than native JS? Because you'd be wrong on the second one. – ndugger May 22 '14 at 16:20
  • Mine was an opinion, but I'm wrong, you're right. And I see a test here: http://jsperf.com/jquery-vs-javascript-performance-comparison – Mustapha Aoussar May 22 '14 at 16:23
  • You can't really have an opinion about fact. That's like saying that, "In my opinion, the sky is red, and consists of mashed potatoes and cream-cheese". – ndugger May 22 '14 at 16:26

4 Answers4

1

for performance script should be external because for maintenance & performance. Its better because if the code is separate, it can easly be cached by browsers.

yahoo rules https://developer.yahoo.com/performance/rules.html#external

nolawi
  • 4,439
  • 6
  • 22
  • 45
1

At first, jQuery isn't pure JS.

If consider these snippets only and disregard the timeouts on HTTP requests, page loading and function calls overhead, the second would be slower than the first one.

Why?

$(id).change({
    //DO THIS
});

There we have a jQuery selector. Selector can be heavy (as you know, jQuery and document.querySelector accept CSS-like selectors) and thus negatively impact the performance. But in your case if this just IDs, jQuery might use built-in function document.getElementById which be faster than CSS-like query, but people say it still slow.

If talk in general, you won't see this little difference if

  • external JS is cached on client-side, low-weight and ping to your server is low (even a request that tell you that JS isn't modified takes time);
  • you're not dealing with a page with huge DOM and don't have to do this many times in a loop (100K and more iterations)

Of course, you should load JS asynchronously, place <script> tags to the bottom of the page to avoid possible loading/parsing lags and show content first, but in general you won't see the difference.

So I prefer place bindings to onclick or in <script> depending on what I need, where I need it, how fast I need it and how it would be hard to maintain it considering framework I'm using to build the site.

Community
  • 1
  • 1
efpies
  • 3,625
  • 6
  • 34
  • 45
0

The external script has to be loaded by an additional HTTP request. From Google (https://developers.google.com/speed/docs/best-practices/rtt?hl=fr-FR#CombineExternalJS):

most browsers prevent the rest of the page from from being loaded while a JavaScript file is being downloaded and parsed

Once the code is loaded the speed is probably the same, but since you have to make that extra HTTP request it would seem that the external JS will load slightly slower (approximately the length of time it takes to make that extra HTTP request).

pherris
  • 17,195
  • 8
  • 42
  • 58
0

Please check this post Does the <script> tag position in HTML affects performance of the webpage?.

In case of performance comparison, they had a good analysis with the following case:

QUOTED

it does affect the performance of the web page.

The problem with JavaScript is that is blocks the execution/loading of the rest of the page. If you have something that takes a long time in your JavaScript then it will prevent the rest of the page from loading:

See these examples:

 Script at top, blocks whole page: `http://jsfiddle.net/jonathon/wcQqn/`
> Script in the middle, blocks bottom:
> `http://jsfiddle.net/jonathon/wcQqn/1` Script at bottom, blocks nothing:
> `http://jsfiddle.net/jonathon/wcQqn/3/` You can see the effect the alert
> has on the rendering of the rest of the pag

e. Any JavaScript that you

put into the top of your page will have the same effect. In general, it is better to put anything critical to the layout of your page (i.e. menu plugins or something). Anything that requires a user interaction (popup handlers) or doesn't involve the user at all (Google Analytics) should go to the bottom of the page.

You can get lazy loaders that will inject your script tags into your code. Since the code isn't on the HTML, you can be sure that your whole page has rendered correctly and that the JS you're including will not block anything

Community
  • 1
  • 1
Memin
  • 3,788
  • 30
  • 31