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.
Related
Possible to set a breakpoint for the code block of javascript like the screenshot below.
How can we use them? VS always ignores.
If Internet Explorer is set as the browser when debugging, Visual Studio is, in theory, able to stop at breakpoints set at client side script. To use the feature, you will need to make sure that "Disable script debugging" is checked in your IE Internet Options, Advanced tab.
However, I have found VS script debugging to be a bit flaky; the breakpoint is not always hit, especially with VS2010 or earlier. My personal experience is that it works best in VS2012 or later.
That being said, if you're using VS as the client-side script debugger and you find that your client-side breakpoints are not getting hit, it is best to insert a "debugger;" line prior to the line you would like to break at to ensure that it is picked up by the VS script debugger.
pennstatephil posted a link above that indeed provides more information on the subject: http://msdn.microsoft.com/en-us/library/7seh8d72.aspx
Edit: I'm not able to add comments, but in response to sb9's comment about why one would use IE, I find debugging in Visual Studio a lot more convenient when investigating script behavior before postbacks occur and server-side behaviors occurring immediately after postbacks. Also, sometimes the VS/IE combination will catch errors that Chrome and Firefox/Firebug reports with a nonsensical error message.
In Visual Studio 2017 there is an option to enable/disable script debugging
Just enable it and you should be good to go.
There are seemingly infinite possibilities to why this happens. I just solved this problem after hours of searching.
My particular issue is that my breakpoints were disabled immediately after my coworker enabled bundling (see description here). I had to go into our BundleConfig.cs file and comment out the line that said:
BundleTable.EnableOptimizations = true;
After I did that, they were hit. You'd want to add that line back in for deployments.
Another scenario for the inability of the debugger to stop at the break point is if one uses bundling.
To debug JavaScript files, we need to remove bundling.
I hope this will help someone.
Yes you can put the break-point on client side page in Visual studio
First Put the debugger in java-script code and run the page in browser
debugger
After that open your page in browser and view the inspect element you see the following view
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.
My goal is to be able to see which javascript functions have executed since the start of an audit. This is most comparable to me placing a breakpoint at the start of every method in every javascript file that's loaded, and then writing down a list of all the functions who have a breakpoint that was hit.
Does this tool exist? If not, why do developers not need it? I find myself looking at a page, seeing 'something' happening, but not being able to get a handle on what is happening. In a large environment I could see this task becoming insurmountable.
Cheers
Yes. Firebug (for Firefox) is the most popular.
http://getfirebug.com/
Also, IE9 and Chrome... press F12 to bring up the developer window.
With all of the tools mentioned here you can set javascript break points, see the stack, and even profile your scripts.
Check out console.log to help you out -
http://getfirebug.com/wiki/index.php/Console_API
Google Chrome's javascript console (which is some nice visual profiling) -
http://blog.chromium.org/2009/06/developer-tools-for-google-chrome.html
I would like to see what the JavaScript interpreter is doing in real-time, which line it is reading and which function it is running, because I would like to make a full debug on every little piece of the JavaScript to make it faster. For this I need some tool to tell me what the interpreter is doing exactly, if it is defining a variable, if it's running a function, if it's in a loop, check the current intervals (defined in setInterval).
As far as I know Firebug can't do that.
Check out the javascript tab in Firebug, it's a full debugger. Set a break point and when your code hits that line you will have full debugging access to variables etc. Chrome has similar functionality in the developer tools which are included in a standard install.
If you're looking to do automated monitoring/analysis of your program, check out Chrome's Debugger Protocol. It provides a programatic API. I believe (but could be wrong) that this is what tools like Web Inspector and node-inspector are built on.
If you want something more than what the standard Firebug/Web Inspector interfaces are built on, you're going to have to either use something like this or start hacking on the internals of the V8 and Gecko JS interpreters.
As the other answer says,if you want to go step by step, setting a debug point is the way to go.
But since you seem interested in improving performance you might want to consider optimizing only the true bottlenecks in your application. To see which functions take the most to run, and other statistics you might want to take a look at console.profile() (available both in firebug and chrome).
Here is an example:
console.profile('myProfile');
//some code you want to know more about
console.profileEnd();
You can also start it manually by clicking the Profile button in the Console panel(in firebug)/ Profile panel (chrome)
In Chrome you might want to also take a look at Heap Snapshots (they tell you about memory usage).
I am developing an application on Facebook. I am running into some vague situation that I want to debug. The problem is that Facebook adds MUCH wrapping code and changes the name, not to mention that it already uses a modified version of JavaScript called FBJS. These things make it almost impossible to use tools like FireBug to debug the code. Does anybody have a suggestion for such cases? I am thinking of some debugging library that traces the code, variables, etc., and show me some results in some other window, or something like that.
You can try adding the line debugger to your javascript where you want to break. Firebug should break point on that line.