I am working on a very complex web site which is wizard based and have many JavaScript files included.
Now problem is if I pass through many step and at some later stage I find a JavaScript problem, as I fix it I have to load the page again and as I load the page again the Wizard will be started from step one again.
What I want is if I make JavaScript change in a file, there should be a possibility to refresh the JavaScript file through Firebug or something like it.
Thanks a lot.
No, not really. You could try to change the <script>'s src attribute to something like /your/script.js?timestamp=1234567890, but this doesn't give a reliable guarantee that the script will be loaded again.
You could add another script element into the DOM, but then you'd have two very similar scripts loaded at the same time, which may be problematic.
Related
I'm having a (simple) issue, but I have no idea how to fix it. Essentially, every tutorial I have come across for Babylon puts all of the Javascript code inside < script > tags in the main HTML page.
However, I would like to have all of my Javascript code inside a separate file. I have tried every way of loading it as I could think of, though I am a novice at Javascript (I am decent at C++, and I can see the similarities); yet I was unable to make it load. (It works fine when called from the HTML page itself).
Does anyone know what (if anything) I can do in order to be able to load my scripts from external files, and still get everything to work? Thanks in advance!
2 options:
register to the DOMContentLoaded event in your external JS file
reference your JS file with the tag at the end of the HTML page
You can find a sample in one of my tutorials here: http://blogs.msdn.com/b/davrous/archive/2014/11/18/understanding-collisions-amp-physics-by-building-a-cool-webgl-babylon-js-demo-with-oimo-js.aspx
Enjoy and thanks for using Babylon.js! :)
David
The reason I don't want to use ajax to do this is because the part I want to refresh is actually a commenting plugin implemented by other. I just put a snippet of script they provided in my html code and it shows a commenting part under my articles. As it's not a live commenting one, I want to add a refresh button next to it to enable users to just refresh the commenting part to get the latest comments without need for reloading the whole page.
Therefore, I think maybe iframe is an option for me. But the problem is I need to specify the src attribute of iframe. I don't know what value I should use because all I have is just a snippet of script. Can someone give me any idea on this?
By the way, the code snippet is as follows:
<div id="uyan_frame"></div>
<script type="text/javascript" id="UYScript" src="http://v1.uyan.cc/js/iframe.js?UYUserId=1674366" async=""></script>
Just create a html page with the script you talked inside about and use this file in the iframe src attribute.
You can put the snippet above in an html file like this
<!DOCTYPE html>
<html>
<body>
<div id="uyan_frame"></div>
<script type="text/javascript" id="UYScript" src="http://v1.uyan.cc/js/iframe.js?UYUserId=1674366" async=""></script>
</body>
</html>
And then use that file as the src of your iFrame, which you can refresh using javascript.
That said, just because you can do something doesn't mean you should do something. This is a really hacky way of doing what you're trying to do. A few alternative options:
Understand what the script you're using is doing, and work with it. Judging by the name of the script and div in the snippet, it may be creating an iframe to begin with. If thats the case, why not just figure out what that iFrame is called using your browsers debug it and refresh it manually, or modify the script to do so?
Use a live updating framework- This may not be possible for you, I don't know your constraints, but there are plenty of great commenting frameworks out there that do live updates. For instance Disqus comes to mind. Other examples are facebook comments or you could embed a reference to an external site like branch
Use Ajax - I'm a bit unclear on whether this is your script that you're writing, or a 3rd party script. If it is your script, then use the generally accepted methods for doing this type of work, unless you have a really great reason not too. You'll get better support from others, you'll gain more generally applicable experience, and for the most part, best practices gain that name for a reason. People use "ajax" methods for live updating pages because its effective and useful. Frames have become much less common on the web because they're clunky and make it difficult for different parts of the page to interact. If you don't have a great reason not to use the common practice, its usually your best bet.
You could do this :
var iframe = document.getElementById('your_frame_id');
iframe.src = iframe.src;
set the iframe src to its value again, this will cause the frame to refresh, and will work with cross domain frames
I see that Javascript code is normally in heading part of HTML code.
<head>
<script type="text/javascript" language="javascript" src="core.js"></script>
...
</head>
Is it OK to put the Javascript code in a body part of HTML code? I tested it, but it seems to work.
<body>
<script type="text/javascript" language="javascript" src="core.js"></script>
...
</body>
If so, why the examples of Javascript books put the javascript code in heading part?
If not, what's the difference between putting the javascript code in body/heading part?
Not only is it OK, it's actually better, since it lets the content come first.
If your viewers have a slow (eg, mobile) connection, it's better to send the actual content first, so that they can read it while the browser downloads the Javascript.
All the people saying it is better only applies if you are talking about at the bottom of the page (and that is an up for debate thing) from a code quality point of view, it is NOT ok to sprinkle script tags through your html. All references to javascript should be in a single place on the page, either the head (where they should be), or the very bottom (as a perf optimization)
Edit:
Basically, a web page is made up of 3 pieces; style (css), structure (html), and behavior (javascript). These pieces are all very distinct, so it makes sense to keep them as separate as possible. That way if you need to change some javascript, it is all in one place. If it is sprinkled through the file, it becomes much more difficult to find the code you are looking for, and that code basically becomes noise when you are just looking at structure.
It is the same arguments as why not sprinkle db access code all over your page. It has nothing to do with technical reasons, purely an architectural/design decision. Code that does different things should be kept separate for readability, maintainability, and by extension, refactorability (not sure if that last one is actually a word...)
You can do it, and people often do.
For example, people like to put their script tags just before the closing </body> to make web pages render quicker.
Also, if you do a script block after an element is created, you don't need to wait for DOM ready.
Be warned though, don't add, or remove an element from an unclosed ancestor in the markup tree (not including the script block's immediate parent element), or you will get the dreaded Operation Aborted error in IE.
Just something to add on:
I have preference of putting Javascript file right before </body>. My reasons being that:
Content can load and be shown first. If you load huge Javascript files first, which most are meaningless until the page is loaded, the user won't be able to see anything until the JS files are loaded.
Most Javascript code require to work with the UI can only run after the UI has been loaded. Placing the codes at the end of the html file reduces the need to use the onload event handler.
It is very bad habit to place Javascript snippets all over the HTML file. Placing all at the back of the HTML file allows you to manage your Javascript more efficiently.
It is legal according to the spec.
Most examples use them in the header as the headers come first and the browser will be able to parse the reference and download the JS files faster.
Additionally, these are links and are not part of the display, so traditionally, put in the header.
It is perfectly legal but there seem to be some differing opinions about it. Those who say to put all the javascript references in the head argue that the script is downloaded before the rest of the page become visible and dependent on it. So your user will not see an object on screen, attempt to interact with it and get an error because the javascript code is not yet loaded.
On the other hand, the argument goes that it takes longer to load all the script before the user sees the page and that can have a negative impact on perceived speed of your site.
JavaScripts inside body will be executed immediately while the page loads into the browser
Placing javascript at the end of the body will defer javascript load (ie: the page will render faster), but remember that any javascript function used for an event should be loaded before the event declaration, it is mainly because users may be able to fire an event before the page is completely loaded (so before the function is loaded)!
I used to put it in the head, then I've heard that it takes longer for the page to load so I started placing the scripts at the very bottom. However, I found out the most 'clean' way to do it is to place it in the head BUT you place the script inside a document.ready function. This way you have the best of both worlds. It is cleaner because it is in the head and it is not loaded before the content has been loaded, so there aren't any problems performance wise either.
With jQuery for instance, you can do it like this:
$(document).ready(function() {
alert('test');
});
The alert will only popup when the page has been fully loaded, even though the script is in the head.
I have partial control of a web page where by I can enter snippets of code at various places, but I cannot remove any preexisting code.
There is a script reference midway through the page
<script src="/unwanted.js" type="text/javascript"></script>
but I do not want the script to load. I cannot access the unwanted.js file. Is there anyway I can use javascript executing above this refernce to cause the unwanted.js file not to load?
Edit: To answer the comments asking what and why:
I'm setting up a Stack Exchange site and the WMD* js file loads halfway down the page. SE will allow you to insert HTML in various parts of the page - so you can have your custom header and footer etc. I want to override the standard WMD code with my own version of it.
I can get around the problem by just loading javascript after the original WMD script loads and replacing the functions with my own - but it would be nice not to have such a large chunk of JS load needlessly.
*WMD = the mark down editor used here at SO, and on the SE sites.
In short, you can't. Even if there is a hack, it would heavily depend on the way browsers parse the HTML and load the scripts and hence wouldn't be compatible with all browsers.
Please tell us exactly what you can and cannot do, and (preferably; this sounds fascinating) why.
If you can, try inserting <!-- before the script include and --> afterwards to comment it out.
Alternatively, look through the script file and see if there's any way that you could break it or nullify its effects. (this would depend entirely on the script itself; if you want more specific advice, please post more details, or preferably, the script itself.
Could you start an HTML comment above it and end below it in another block?
What does the contents of unwanted.js look like?
You can remove a script from the DOM after it is called by using something simple such as:
s = document.getElementById ("my_script");
s.parentNode.removeChild(s);
This will stop all functions of the script but will not take it out of user's cache. However like you wanted it can't be used.
Basically you can't unless you have access to the page content before you render it.
If you can manipulate the HTML before you send it off to the browser, you can write a regular expression that will match the desired piece of code, and remove it.
I was just using the plugin "Yslow" for Mozilla Firefox, and it told me that I should put JavaScript at the bottom. I have heard this before but haven't really thought about it too much. Is there really an advantage in putting JavaScript at the bottom of a web page compared to the top?
It'll allow the web page to load visibly before executing JavaScript, which makes sense for things like Google Analytics, which don't need to happen before the page loads.
You may also want to look into things like jQuery, prototype, etc and attach to the "ready" handler, which executes JavaScript code after the DOM has been fully loaded, which is an appropriate place for much JavaScript code.
Assuming you aren't running on a CDN or aren't serving your JS from a separate sub-domain or server, it will load synchronously and force your HTML content to wait until it has downloaded the files. By placing the JS at the bottom of your page before the closing </body> tag, you are allowing the HTML to be parsed prior to loading the javascript. This gives the effect of faster page load times.
If you have static html content and a lot of javascript, it can make a difference in perceived page load time since the html will load first giving the user something to look at. If you don't have much javascript, or the existing page content relies on the javascript to be useful, then this is not as useful practically-speaking.
I want to bring update to this topic, google has recently introduced async snipped http://support.google.com/analytics/bin/answer.py?hl=en&answer=1008080&rd=1 which can be added for your site to bring e.g. google statistics support. It should be placed bottom of the <head> section for best performance. The point is that this increases likely hood of tracking beacon to be sent before user leaves the page.
Also it should be located there if you want to verify your site in google webmaster tools using your google analytics.
Other than that, same rules still applies basically - javascript at bottom for "fast" loading of the page. I used quotes because I dont count page fully loaded until javascript finishes ;-)
Yes, the page will load the content and render it before loading and executing javascript, and the page will, as a result, load faster.
TOP
When you put your JavaScript at the top of the page, the browser will start loading your JS files before the markup, images and text. And since browsers load JavaScript synchronously, nothing else will load while the JavaScript is loading. So there will be a timeframe of a few seconds where the user will see a blank page, while the JavaScript is loading.
BOTTOM
On the other hand, if you place your JavaScript at the bottom of the page, the user will see the page loading first, and after that the JavaScript will load in the background. So if, for example, your CSS & HTML takes 5 seconds to load, and your JavaScript takes another 5 seconds, putting our JavaScript on the top of the page will give the user a “perceived” loading time of 10 seconds, and putting it on the bottom will give a “perceived” loading time of 5 seconds.
Taken from Demian Labs.
It allows all the DOM elements to fully load before loading the Javascript which addresses them. This standard is also part of Visual Studio.
Placing scripts at the bottom of the element improves the display speed, because script compilation slows down the display.
Yes including the javascript at the bottom of the page really quickens the loading of the page. Since browser executes things synchronously it impacts the page loading if it is placed at the top of the page. If it is placed at the bottom of the page, the page would have loaded the entire markup by then when the browser starts loading the javascript giving a better experience to the user.
It's advisable to put all inline scripts at the end to improve performance, you don't want your users to be staring at a blank white screen while the script renders. You can use defer attribute eg. to prevent link scripts from delaying your html rendering.