Develop Reference

Dojo mysteriously, persistently blanked on page

We use the dojo framework on our websites. A client has called in a panic saying their sales from users of Microsoft Edge have completely dropped off. I've found that in that browser, intermittently, the dojo variable is null after page load. So of course no interaction works for those users, so of course no sales.
But in the course of testing I found this astonishing thing in devtools:
I don't even know how I would do that if I wanted to do it. So I want to track this down but I have no clue what to look for. I might've suspected some weird, recurring setInterval code, but I would not have thought that could get between the two statements on that last console line.
There's a script line just before the </body> tag where I'm able to put a breakpoint. At that point, dojo is set as the framework as expected. So some code that loads after page load is doing it.
(EDIT: I'd be willing to do iterative, brute force breakpoints if I could. But I only have access to Edge via BrowserStack, and trying to set useful breakpoints in minified code is very difficult in Edge's dev tools.)
Does anyone have a suggestion what sort of thing I should look for?
How to debug for this? Is there a client-exposed variable where you can see the functions set to the document's onload, or a way I can put breakpoints in them?
I attempted using a watch() shim in console to watch for the dojo object being changed, but didn't have much luck with that. (but might have done it incorrectly, so if this is an idea, I might need help with proper implementation).
EDIT: There's also this, if this helps make any sense of it. After I delete dojo, setting it works as expected.

Well, I don't know what the specific problem is, but someone has at least given me a way in which this is possible:
window.__defineGetter__('dojo', function(){ return null })
This doesn't exist in the original code, but at least now I see how it's possible at all. The person who gave me this suggests that the code might be trying to get and protect its own copy of dojo, but something about it goes wrong in Edge.

Authoritative JavaScript validation to a standard

I am trying to validate the JavaScript on my website. The scripts do not throw any errors and run fine on Chrome and Firefox (latest stable version). However, the animated parts absolutely do not work on IE (9)[*1][*solved]. I have used jQuery and jQueryUI for the animation and had hoped that it would be cross browser compatible.
Usually I would not have cared abut IE users, but liked the idea of folks at anybrowser.org and thought of sticking to a standard instead of using the lowest common denominator and leave the graceful degradation to the browsers / JS engines. My page is HTML5 compliant according to the w3c validator and I wanted to do the same with JavaScript, but could not find an acceptable way to do it.
Why JSLint did not work -
It will not take the page and check it like w3c validator.
So there is no way to check jQuery referenced script. (There are a few SO posts on this).
I did find an ECMA-264 test page that would check the browser, but not my JavaScript.
The question after all the preamble is: How do I validate the Javascript on my webpage? Is there an authoritative validator for JavaScript?
*1 Added: The minification has nothing to do with the script not working on IE9. Even the unminified version does not work.
*Solved: The problem with the specific page was solved by this comment.
This started as "What is Javascript?" got closed here and migrated to Programmers. Thanks to YannisRizos for helping me to split the original question to something that was acceptable between Programmers and SO.

A test suite. No really.
If you want to ensure your javascript runs perfectly in every target environment, then you write a test suite for your code and make sure it passes in all your target environments.
A test suite helps find where your code breaks when run on different platforms. And therefore helps you fix it.
But assuming you want something that is less work, http://www.jshint.com/ is your best bet.
Or http://www.jslint.com/ if you like getting yelled at.
But honestly, no validator will ever be able to ensure that your code runs without error and exactly how you expect everywhere. Simply because your code follows best practices correctly, that doesn't mean it will work in an old version of IE.
Standards evolve, but an old browser that never updates get stuck with whatever standard was out at the time that the browser maker may or may not have even implemented successfully or accurately.
Testing, automated or manual, is the only way to ensure things work universally.

Advice for experienced developer trying Javascript for the first time

I'm very experienced in C/C++/Objective-C and over the last few days have been trying my hand at html/css/JS and am finding it very frustrating.
Time and time and time again I've been caught out as I've a syntax error or undeclared variable due to copying / pasting etc. with the consequence being that the code suddenly stops working then I have to scratch my head and figure out why.
The most painful thing is resorting to sprinkling alerts in the code everything something fails in order to track down the reason. I know there is the new console object for logging but it doesn't seem to work with Komodoedit or jsFiddle? Which is what I've been using.
Is there a way of using these tool, or alternative tools where I can step through the code line by line in a debugger like I can with other languages? Or any tricks for easy detection of problems with the code before executing it in addition to jslint?
[I don't want to use any libraries that might have built-in support for logging etc. as I'm finding they (well JQuery/JQuery mobile is) are drastically slowing down loading times on an iPhone so want to concentrate on pure JS.]
[My target browser is just iOS, but am using Komodoedit with Chrome most of the time and every few hours try it on an iPhone]
Thanks

You need several tools.
First, get yourself a real debugger. I use the one built into Chrome. There's a similar one built into Safari and Firebug available as an add-on for Firefox. This will allow you to set breakpoints and step through your code and see exactly what is happening.
Second, get very used to running your code through jsLint. This will show you many obvious typos and encourage you to write robust code from day one.
Third, start writing in strict mode. This will again prevent some obvious typos and force you to start some good habits.
Fourth, use console.log() when needed. Once you have a debugger, it's output will show in the debug console of the debugger for any page in your browser, including jsFiddle pages. You will have to invoke the debugger on the right frame in jsFiddle and then it will work fine. I use both a regular debugger and console.log() all the time with jsFiddle. It takes a little figuring in jsFiddle and the debugger to find where your own code is to set breakpoints, but once you find it, it's easy to use.
Fifth, javascript is simply not C++. While the syntax will seem quite familiar, the way you do things with anonymous functions and closures and objects and prototypes is very different. As one who programmed in C++ for many, many years before learning javascript, I very much appreciate what I can do now in javascript that was a lot more work in C++, but it took awhile to get my brain into a new mode of thinking. I spent too much time in my first years of javascript development trying to emulate C++ techniques rather than just learning the better way to accomplish the goal in javascript.
Sixth, you will have to change how you write and test code because of the lack of a compiler that finds errors for you. I remember in the days of C++, when I needed to refactor something, I could make a bunch of changes and then let the compiler find all the other places I need to fix the syntax. You can't do that with javascript. When you make mass changes, you can run through jsLint to find some issues and then you literally need to execute every path to make sure everything works. It is a bit of a pain.
Seventh, find a strategy/tools for unit testing. Once a project gets more than a few functions long, you will benefit greatly from building unit tests that you can run anytime you make significant changes. They will both find issues for you in a lot less time than without the unit tests and they will give you the courage to refactor and clean up your code when you see the need for that because you know the unit tests will tell you if everything is working again. It's extra work up front that pays dividends many times over down the road.

Firefox has an add-on called FireBug that is very helpful for debugging CSS/javascript, and yes, it does have the ability to step through a script as well as a command line where you can try out various javascript expressions. I'm pretty sure Chrome has a similar feature.

Here is the article in which you get a list of tools to debug the javascript
advance-javascript-debugging-techniques

Since you're using Chrome, you just need to open the developer console (spanner -> tools -> javascript console, or Ctrl+Alt+J (at a guess)). Instead of sprinkling your code with alerts, use console.log, console.error, and console.info to print to it. All of those are variadic, so you can pass as much to one call as you need.
In addition to this, you can use the console to test and modify parts of your code on the fly, or to just try out a few snippets to see if they work. It's a fully functional REPL that also works with the current document.
In the sources tab of the developer console, you are able to set breakpoints and step through your code, analysing state at each point. This page goes into some detail about it: http://chromedevtools.googlecode.com/svn-history/r421/trunk/tutorials/breapoints/index.html
In the elements tab, you are able to set breakpoints on changes to elements in the DOM, including changes to attributes and child nodes. Right click a node and select the option you want. This will come in handy when debugging code that is asynchronous and plays with the document (eg. AJAX calls inserting new content).
In addition to this, you can scroll to the bottom of the styles pane to the right, and open the event listeners section. Here, you can inspect all the events bound to the selected DOM node.
You can enter debugger (without a semicolon) into your code, and it will open the sources tab at that point so you can inspect the code further. I think this may be Chrome specific.
Finally, tools like JSlint will help you spot undeclared variables as you code, as well as cases where the formatting of your code creates unexpected errors, and some might even go as far as using syntax highlighting to make you notice variables that are undefined.
This is also just scraping the surface. Your editor and JSlint can make your code look right and parse without error, but the browser and its console is where you will spend most of your time.

What is the most effective JavaScript syntax checking solution?

I am developing an AJAX application and in the process of doing this I am creating many small JS files that will eventually be concatenated and minified in the production release. However in development I will be working with the individual uniminified files.
The issue I have is that I am using Kate in Ubuntu as my editor and when I make small errors like an extra comma in a JSON structure, or an extra parenthesis, colon, semi-colon, or other simple syntax error I have no way of knowing until I see it in Firebug or IE Developer Toolbar (run in a VM). Unfortunately Firebug isn't very good at identifying which line has the syntax error and only IE complains about extra commas. If I could see these mistakes in real-time like a good modern IDE it would be awesome. However, I'll settle for any syntax checking solution that doesn't require me to copy and paste each file from my local machine into a text area.
Also, JSLint goes a bit overboard with it's checking. Half of the things it complains about I do intentionally.
What are my options?

jshint ( http://www.jshint.com/ )is one of the descendants of jslint after several people had also such problems with jslint (being too opinionated).
You could do similar things I guess with jshint as well as it is done by jslint here: http://sergioserra.posterous.com/using-jslint-with-kate
Personally, I used vim with jslint (with a much more permissible configuration than the default), which was checking syntax live.
Another alternative is Closure Linter from Google: https://developers.google.com/closure/utilities/

Why some javascript error only comes in IE not in firefox? how to know where is code creating problem?

Why some javascript error only comes in IE not in firefox? should i solve all IE javascript errors, if my site is working fine with it ?

You should definitely seek to fix any JS errors you are getting in IE. What shows up in your IE as a little yellow icon, will show up in other IE browsers as a popup letting the user know there was an error.
One way you can minimize problems is by using one of the many JavaScript framework/libraries like jQuery, MooTools, etc that seek to minimize browser differences. Then, when you get specific errors, they can often be fixed by added a missing ; or adding an if statement in the correct place.
You should never knowingly leave code unfixed that is known to break in modern browsers.

should i solve all IE javascript
errors, if my site is working fine
with it ?
I'd say, yes absolutely. Under certain circumstances, IE throws Javascript errors right into the user's face with a big fat dialog. I think it's very embarrassing for a visitor (who may not even know what JS is, and even less the intricacies of cross-browser scripting) to get a error message as their first impression of you.

they have slightly different implementations of javascript, dom, css, etc.... should you fix the errors? if no major functionality is impacted, then it would probably be a very low priority... and depending on your userbase (say its a corporate intranet) you could simply say Firefox is your preferred browser. all depends on the requirements. Prioritizing tasks will help ensure the most important objectives are met.

Yes, you should fix the Javascript errors being reported in IE, because it can be unclear how the errors manifest themselves in your application. For instance, it can cause menu navigation to not work, or incorrect behavior of buttons.
As for actually detecting where the problem came from and how to fix it, you can try our Browsera service, which will detect and log the Javascript errors for you that occur in the browser, and use the Script Editor, which comes with MS Office
Or, if you dont have OFfice, use the free Microsoft Script Debugger, which works, but is less powerful.

if you are working with ajax than you can use $.getJason using jQuery, instead you get data from ajax and then use JSON.parse();