Develop Reference

Debugging and checking what variables are equal to in production

So I've been coding for a while now in school, and I'm having my first introduction into a real working code base at my new job. When it comes to debugging, like if I want to find out what a certain variable is equal to, I'll often just console.log() things out and hope that something useful comes out of it.
It seems really inefficient considering how many moving parts there are in the code. Most of the time, it works eventually, but it feels so barbaric just editing the code over and over and looking at the browser's console until something useful comes out, and it feels like there has to be a better way to debug in a production environment. I am specifically using Ember.JS, but this question would apply to any framework like React or Angular or Node.

There are many tools out there to debug JS, the most "basic" being the debugger in your browser. Some tools go further also, for example VSCode has a slew of extensions that open and control the browsers debugger.
Chrome: https://developers.google.com/web/tools/chrome-devtools/javascript/
Firefox: https://developer.mozilla.org/en-US/docs/Tools/Debugger
Edge: https://learn.microsoft.com/en-us/microsoft-edge/devtools-guide/debugger
Safari also has one in the develop menu but there is no site describing it in detail - it is located in the sources pane

If you use VS Code, you can run Node apps in debug mode then select Node.js.

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.

How to deal with IE when writing Javascript

This is kind of a two-part question.
Why does IE require so much special treatment when handling Javascript? And are there any tricks, resources, and/or systems you have picked up for making your js IE-compatible, besides Firebug lite?

Using standardised libraries like J-query so you don't have to jump through all the hoops yourself works on the javascript side!
Also Yahoo User Interface (YUI) is good for making websites look extremely similar over different browsers. Their Grids library works really well.

Could you please elaborate little what you're referring to?
JavaScript in it's core is have mainly been the same the last 10 years. If you're worried about older IE versions (IE6-7) you can remain calm. IE6 was released with JavaScript 1.5 support so all JS code should run fine. Mozilla has a very good JS ref document at their MDC site. At the bottom of each page there's usually a list of what version of each browser that supports that specific function.
However the difference between browser usually lies in the DOM implementation or event handling. Where properties may have different names, at the top of my head these properties mainly are related to element/scroll positions.
To find the correct property to use, check in the developer tool (Firebug in IE, Developer Tools in Webkit or Developer Toolbar in IE) for that browser to find what you are looking for. If you're unsure set at JavaScript breakpoint in your code using the debugger;keyword or send something to the console using console.log(). In IE Developer Toolbar is available from IE8+ (I think).
Most of these problems are already resolved in the major JavaScript frameworks like jQuery, MonoTools and so on.

The two main "special treatment" things that come to mind are:
Events. Including assignment of event handlers, the way the event object is made available to the handler function, and some of the properties of the event object. See this page for more info: http://www.quirksmode.org/js/introevents.html
Ajax. Use of XMLHttpRequest versus ActiveXObject("Microsoft.XMLHTTP").
Most everything else should be fine.
You can write yourself some (relatively) simple helper functions to get around these issues, or use a library like jQuery that normalises the differences for you. If you do write it yourself, be sure to test for feature support rather than try to test for which browser - see this (long) article for an explanation: http://jibbering.com/faq/notes/detect-browser/ (I'm sure there are shorter explanations around but I can't be bothered finding one.)

If you using jquery in your page then you can check for ie with this code
if ($.browser.msie && $.browser.version == '6.0') {
//do IE specific code
}
This code will only run when the user browser will be IE 6.0 or you leave this condition

Is it possible to profile built-in JavaScript functions with Firebug?

I'm building a graphics-intensive site in HTML5 that makes heavy use of the canvas context's drawImage() function. In IE9 on Windows 7, performance is smooth, but in Firefox 4, things get choppy. I'm trying to isolate bottlenecks so I can start optimizing.
If I use the JavaScript performance profiling feature of Firebug 1.7.0, I can see statistics for my own functions, but I'd like to see calls to the built-in JavaScript functions as well. Is there any way to do this in Firebug or some other tool?
As a workaround, I suppose I could make the profiling granularity finer by breaking things down into lots of tiny functions, but I'd rather my design not be driven by how easy it is to profile.
Update: Looking back at this question, it occurs to me that the built-in functions in question are not truly JavaScript functions but functions provided by the host. In this case, they're DOM objects from the browser. Just thought I'd clarify that technical detail.

Last I used it Firebug doesn't give you the ability to profile native code.
What you can do is make your own function that just calls the native piece you want to call. As in turn the code:
ctx.fillRect(50,50,50,50);`
Into:
// wrap in function
function fillR() {
ctx.fillRect(50,50,50,50);
};
// call it immediately afterwards
fillR();
Then you can get the stats for fillR. Not the best fix, but it may useful enough.

You might try playing around with Venkman, Mozilla's JS debugger. At the moment the version on addons.mozilla.org is broken in Firefox 4.0.
You can get the most recent version via mercurial, which does work with Firefox 4.0:
hg clone http://hg.mozilla.org/venkman/
cd venkman/xpi
./makexpi.py
firefox venkman-0.9.88.1.xpi

After contemplating this on and off for a couple of days, I came up with a new solution and wrote a blog post about it:
http://andrewtwest.com/2011/03/26/profiling-built-in-javascript-functions-with-firebug/
This method does the following:
Checks to see if the Firebug console
is open.
Does a combination of overriding and
wrapping native functions with
user-defined functions.
These steps combined provide a way to profile DOM functions that doesn't affect your original script code unless you're debugging.

Interactive Javascript console (preferably integrated with Firebug)

I'm looking for a way to have an interactive JIT debugger, preferably integrated with Firebug.
I got the idea from PHPEd, which has an "Immediate" debug tab where you can just type in PHP code and modify objects on the fly. This makes debugging a breeze as you can re-assign variables multiple times, re-execute functions, etc without leaving the program.
Here's what I think would be superb:
- set a breakpoint in Firebug
- arrive to breakpoint
- have an Execute JS tab where one could enter JS code, similar to what I described above
Does anything like this exist already?
TIA.

You can already do this in Firebug. Just get to a break point, then go to the "console" tab, and type your commands into the command line at the bottom (where there's the ">>>").

If I understand the question correctly, I think can do that already in firebug.
Set a breakpoint (or use the debugger
keyword)
Click the console tab
the bottom line allows you to enter a
javascript command.
if you need more space click the icon
that looks like an upside down v in
the bottom right part of the browser.
You might also like the JS execute extension.

Actually, Firebug can do this and it's only a matter of a little investigation on their website to find out how to do this best :) Good luck!

Agree with parents that Firebug is the best choice. Another option that requires a good deal of configuration would be Aptana. For folks using the Eclipse IDE, Aptana is a solid editor for Javascript work. The plus with Aptana is that it's tied more to a code editing environment.