I have seen three ways to put Javascript: Can someone tell me the best way to put Javascript? ------------------------------------------------------------------------------------------- <script></script> ------------------------------------------------------------------------------------------- <script> //<![CDATA[ //]]> </script> -------------------------------------------------------------------------------------------- <script> $(document).ready(function (){ } </script> --------------------------------------------------------------------------------------------
Hi Anjana, first method is the most used for HTML/theme/template (calling a script internal or external) second method is used for parse document as XML last is for embedding directly Javascript code inside HTML/theme/template In my opinion, you can pretty use <script></script> then: If you need Javascript ready before the page is completely loaded, put inside <head></head> section If you need Javascript ready at determinate point of loading, consider to put inside <body></body> section where you need If you need Javascript for statistics purpose (like Google Analytics) you put it just before </body> Hope this help.
Generally speaking the BEST approach is "none of the above". All of those are bad practice as they inline scripting in the markup, meaning there's no chance to leverage caching if you have a dynamic page. The only time you should use the first two is if you need to configure variables or manually call functions -- two things well written scripts wouldn't need more than a line or two of code to do. That last one is even worse, since it's jQuery-tard bull -- AND pretty much waits for onload/onready (depending on browser) which if you are doing DOM or layout changes makes the layout 'jump' with a reflow after being displayed once. Worse, none of the above include the required TYPE attribute. Which is why 99.99% of your scripting using 'best practices' should be in an external file loaded thus: <script type="text/javascript" src="yourscript.js"></script> ... and best practice is putting ALL your scripting right before you close </body> in order of dependence. These days I would NOT put scripting inside HEAD, nor really should GOOD scripts even end up anywhere in BODY except right before you close it... though a lot of crappy advertising scripts have to be sleazed onto the page inline with the markup.
Thanks for the replies, carlo & deathshadow. I'm sorry but actually I want to know how to put Javascript for a blog (blogger/wordpress) Suppose if I have an external link like this: <script type="text/javascript" src="yourscript.js"></script>. I could get the code by opening "yourscript.js" with the browser. If I want to put those codes inside a gadget, which is the best option?
I'm not entirely certain I'm grasping your last post -- however the "I could get the code by opening" part makes it sound like you're trying to obfuscate or block user side access to it -- which since JavaScript is a client-side language you really cannot do. It HAS to be decoded and open to even run in the first place. Whenever possible it belongs in a separate file so it can be cached across page-loads. Really though I have no idea what you mean by "inside a gadget"... Also, since this is a scripting question, you might have better luck asking in the JAVASCRIPT part of these forums.
deathshadow, you have an excellent point. However, if I have a bunch of functions (90%) related just to homepage and 10% functions used on other pages, wouldn't it be wise just to place this common 10% in external js file and place those 90% as internal script on the homepage?
It's funny because even google is suggesting that now -- that if you have something only used on the homepage inline it... but... What if someone visits the home-page more than once before the cache expires? When it makes sense to inline scripting and CSS is when most of your traffic is bounce or single visit; if you're retaining visitors or have pages that the same people visit day after day, hour after hour, it makes more sense to put it in an external file. It also makes more sense not to inline it if you are running any sort of content management or server side includes -- because then it is more markup for it to have to process and gzip compress. If you keep it in a separate file it may introduce the overhead of an extra handshake (bad), but that is often paid off many-times-over by server-side cache where it can be gzipped and ready to send. It can also help if people visit pages out of order, or if you know that after your home page they tend to visit other pages that need the scripting. It might increase the first-load time, but it can speed up loading other pages as it's already downloaded and cached. At the same time, you pass more than 48k of scripting for an entire website, you're probably doing something wrong. Same goes for CSS where if an ENTIRE website's CSS is more then 32k, you've probably shtupped the canine somehow. Part of why I think jQuery and nonsense like BootStrap are a bunch of nonsense, as by themselves individually compressed they're half my total target size for an entire page on a site (that's HTML+CSS+SCRIPTS+IMAGES) uncompressed not counting the content. Anyone tells you you need 100k or more of CSS or scripting before you even start writing your semantic markup, they're packing you so full of sand you could change your name to Sahara. If they tell you that jQuery is easier, bootstrap is easier, HTML 5 is easier... well... Somebody call Mandy Patinkin. Generally speaking though -- if you are high bounce, not retaining visitors, serving static pages and not really having people visit lots of different pages stuffing scripting and CSS in the markup will show a benefit. If you are retaining visitors and serving dynamic pages, particularly when your home page content is constantly changing or people are visiting lots of sub-pages -- in other words a healthy website -- then putting it into external files where it can be cached pays higher dividends. Like a lot of things, it's a balancing act. Usually though any site where keeping scripting or CSS in the markup pays dividends, is so low in traffic it wouldn't/shouldn't matter either way. Honestly, crapping large sections of CSS and JS into the markup, combined with bloated outdated markup or even more bloated HTML 5-tardery is why people end up throwing more server resources at things like result caching (like W3 Total Cache) is really just sweeping crappy coding practices under the rug; sites that see a benefit from it would probably see an even higher benefit by splitting things into separate files that can be cached client side, and not sleazing out such massive markup it takes more time for languages like PHP to process it than it does to access the database for the info (or a cached copy of the page). But again, I practice code limits, semantic markup and minimalism -- my ideal total template size is 72k in 16 files or less (HTML + CSS + SCRIPTS + IMAGES) uncompressed, and 144k in 32 files by the time you get content in it. Usually if a page blows past those limits, it's probably poorly written crap. See the stock templates for things like Xenforo, vBull, Turdpress -- where they blow 50 to 150k of markup on delivering single digits of actual content and a half dozen content images; anywhere from 3 to 15 times as much crap as should ever be allowed in the markup of so little content -- and usually the culprit is wrappers for nothing, classes for nothing, outdated markup -- but most importantly static css/scripting inlined in the markup. That extra garbage in the markup if processed by languages like PHP or ASP is just making the server have to work harder; again sometimes to the tune of spending more time parsing the code than it does accessing the database.
Thanks for your thorough reply, it makes sense. After all, placing js in a separate file is the way if I want to separate design and functionality. So yes, I would go with your solution even if I do have a high bounce rate. BTW if you are interested in providing a semantic help I would appreciate your guidance: https://forums.digitalpoint.com/threads/html-semantics-help-and-correct-use-of-css.2717964/