1

I have a lot of inline javascript, but nothing more then calls to functions such as:

<form id="some_id" style="x" method="post" onsubmit="return someFunction(this);"></form>

or "onchange", "onkeyup". I also have some scripts (not many) written inside <script> tags in html and all of the rest is external. The inside calls just as explicit above are all called to external script functions.

I opted to do this because found it more practical considering many async calls with element insertion and needed listeners to register those changes. This is, $.on("form onsubmit", function(){ would not apply to new elements appended async without a listener.

I'm building new elements in the server side due to my template structure and append them directly on the ajax callback.

My main file.js (external) is sitting at 1832 lines and and my index file which includes file.js has about ~500, ~350 with inline javascript as shown above.

This said:

  • Would it be considered a huge flaw to leave inline javascript as shown above (yes I know google does that) or could it be considered acceptable even by high standards?

  • Considering "inline javascript is not kept in cache", what does that mean exactly? Each time the user requests the web page he fetches the whole "onsubmit" in the line above? Or am I missing the meaning of this sentence.

Sorry if the question is vague but I'm quite thinking I had most of my service barely done and don't know if I should go over this or not at all :( thank you very much.

Mr Lister
  • 45,515
  • 15
  • 108
  • 150
Fane
  • 1,978
  • 8
  • 30
  • 58
  • [Here](http://stackoverflow.com/questions/138884/when-should-i-use-inline-vs-external-javascript) is an older question that might help. – enjoylife Dec 10 '15 at 23:43
  • @mattclemens: That's a different topic. This is about binding handlers as element attributes. –  Dec 10 '15 at 23:45
  • @squint that's exactly what I'm talking about squint, could we consider `binding handlers as element attributes` as inline javascript? Would it heavily denegrate performance? What do you mean by `I would be surprised if it wasn't optimized to reuse quite a bit of the function since it doesn't change`? – Fane Dec 10 '15 at 23:47
  • @Fane: Wait, *what* is exactly what you're talking about? Now that look at this again, it seems you may be conflating the concept of inline scripts and inline handlers. –  Dec 10 '15 at 23:48
  • @squint yes I am I guess, could you explain to me really fast? I'll aprove your answer, please do... Is the code I show above merely handlers? With `a new function is created for each handler` do you mean everytime a new element comes from an async call it *creates* a new function? Could this give noticeable bad performance to the service or could it be considered normal? – Fane Dec 10 '15 at 23:51
  • fyi, you can have event handlers attach to elements inserted after page load. Use [delegated events](http://api.jquery.com/on/) – enjoylife Dec 10 '15 at 23:52
  • Your inline handlers are adding little more than you'd get when adding a class or some other attribute. It's nothing to worry about. Even short inline scripts aren't bad because the extra HTTP request of an external script has its own cost. The caching issue is for medium to large scripts where if it's embedded in the page, it would need to be fetched every time the page is fetched, whereas an external script is cached (stored in the browser or by a proxy). But again, for short inline handlers it's really not a concern. –  Dec 10 '15 at 23:54
  • @mattclemens I know, but other then developer practicability would it justify changing the handlers to external js or is it a mere formality? – Fane Dec 10 '15 at 23:54
  • And no, don't worry about the function objects. They're very light weight and probably very optimized. Maybe if you had hundreds of thousands you'd want a different approach, otherwise it's not a big deal. –  Dec 10 '15 at 23:56
  • @squint ok squint, thank you so very much for this clarification, I'm more relaxed :)) – Fane Dec 11 '15 at 00:04

2 Answers2

0

It's really hard to define "huge flaw" so let's just stick to pro's and con's of keeping the code "as-is":

Pro's :

  1. Your current code works : No additional work is needed.

Con's :

  1. Harder to debug : you JS is split on many places, a bug will be harder to track using the browser debug tools.Especially for more experienced JS developers who "expect" (or at least hope) the code to be organised following the good practices, like separating HTML, JS and CSS.
  2. Speed : Your clients have to download and parse the additional JS with each query. If you were able to factorize all these methods calls in the main JS file, this would not be needed.
  3. Modularity : all the methods you are calling from the HTML have to sit in the global namespace. The script you have written will be harder to reuse.

So basically, I would keep the code like this if the website is meant to be developed by you only, won't be used by million people and if you do not hope to reuse any of this code on another project.

If any of these condition is not met, I would refactor the code.

Also, refactoring the code, and learning how to correctly bind handler is a very good exercice if you plan on learning some more javascript.

almathie
  • 731
  • 5
  • 22
0

$('body').on('onsubmit', 'form', function(){});

This will deal with any future changes to the DOM.

Mat Taylor
  • 191
  • 10