JavaScript tracing, debugging, profiling - filling in spaces
For years, I used Chrome DevTools, Firebug, and even Opera Dragonfly to debug, trace, and profile my JavaScript code. I note that I used these wonderful tools not only for working with JavaScript, but also for tracking network events, debugging CSS, working with the DOM.
However, sometimes I fell into certain exclusion zones, in which the above tools could not help me for certain reasons, but I would like to.
It so happens that I often look at JavaScript code, with which I am not very familiar, if at all. For example, I’m just studying third-party code for general development, trying to understand how some kind of jQuery extension doesn’t want to work, so I assumed, fix bugs, get acquainted with the MVC code of the framework that I want to understand better, look at the code of project colleagues, sometimes even my own code that forgot how it works (I hope I'm not the only one). It so happens that even finding a place with which your fascinating journey into this code (broken into many files, sometimes minified, often confused) is a puzzle.
After a quick inspection and the realization that the humble contemplation of kilobytes of source code is not particularly productive, I run the code. I enthusiastically set a breakpoint in some familiar place, I lose heart a little when I once again get into the debugger in minified jQuery (and who doesn’t lose heart?), I get annoyed when I once again step through the debugger through the necessary piece of code, violently jump the cycles so that do not get stuck there for a thousand iterations, while breathing, I set conditional breakpoints, I apathetically press F11 again and again in fear of missing something important. Sounds familiar?
In certain cases, console also comes to the rescue, but everyone probably remembers that “magic” feeling when you forget to delete console.log (or, God forgive me, alert) before committing. Fortunately, jshint also comes to the rescue for some, which unobtrusively reminds. It’s worse, you think that console comes to the rescue, but you get a soulless “console is undefined”. If you did not have this, then you are either lucky or a beginner.
What about the crazy Heisenbug ? The bug is running, F12 is pressed, the breakpoints are placed with unmistakable accuracy and the cool calculation of a professional hunter, the described steps are completed, but the bug has never happened?
I don’t even want to start a sad song about errors reproduced only in certain browsers / devices / platforms where there are no saving DevTools. No, sometimes (though not always) alternatives are available, often no longer supported, heavy, difficult to install and use, not having exactly the functionality that you need. Yes old versions of IE, I'm looking at you . In fairness, despite the fact that witch-hunting is always fun, not only older versions of IE are sinful. Creating an environment for debugging on mobile devices is no less sad (specific platform requirements, simulators, additional software, SDK, device configuration, etc.) - Androind , iPnone .
Finally, performance profiling. Using the excellent JsPerf service, you can see strangers for different browsers or drive your optimization ideas, this is when there are ideas. In Chrome DevTools and Firebug has a built-in profilers, taking the exact figures of respectively engines V8 and SpiderMonkey, but I have never been easy to use interface, where the figures presented do not like the fact that profiling should always include and you can not just turn once and to always have it turned on by default, the insert of console.profile / console.time into the code (and especially forgetting to remove them) was never fun either.
In view of the foregoing, one day I was visited by the thought - it would be nice to have a tool that solves at least part of the above problems and:
If the above problems and suggestions for solving them are not close to you, then you can probably not read further, as there will be what can be called advertising (albeit free at the moment) of the product.
I am glad if I have not lost you after the advertising disclaimer. Like most of my colleagues, I was cast on the old programmer spell “write tulsum kotorus nemogus findlus”therefore, please welcome spy-js - a new tool for working with JavaScript, designed to fill in the gaps of existing tools, look at debugging, profiling, tracing from a different angle. The project is in beta, but the beta version already can do most of the wish list voiced above. The general direction of development is not to replace the capabilities of existing DevTools / Firebug, but to provide an alternative solution to problems and fill in the possible gaps of these tools.
By spontaneously obeying Atwood's law that everything that can be written in JavaScript will be written in it, spy-js is mainly written in the language for which it is written (ek, wrapped).
Architecturally spy-js is a nodejs web applicationand browser client. How it works: the browser in which the page with the scripts to be traced will be loaded is configured to use a proxy server (a web application on nodejs). The web application proxies requests and, if the requested resource is a JavaScript file, modifies it before sending it back to the browser. A file modification is an insert of instrumental instructions . When the changed code is executed in the browser, information about its execution is sent back to the server, which after processing becomes available in the spy-js user interface, where you can watch events in real time.
A project would never have been completed without using great open source projects such as: nodejs, esprima, express, grunt, socket.io, jQuery, knockout.js, underscore, ace, bootstrap. Not all used projects are listed.
The free beta version of spy-js is currently available for download at http://spy-js.com . The source code of the project itself is not open. Documentation, configuration examples, the ability to start bugs, ask questions and so on, is currently carried out using the open github repository. Questions can also be asked on stack overflow with the spy-js tag.
At this stage, my financial investments in the project are not so large, I work on it most of my free time. My plan is to use reviews from those who find the tool useful to continue its development to the stage when / if I can offer paid licenses and invest more time / support / finance in the product.
I am sincerely grateful for any support, suggestions, feedback, dissemination of information about the project. It really inspires and helps me do what I do. I hope with your help I can contribute to the development of JavaScript tools.
However, sometimes I fell into certain exclusion zones, in which the above tools could not help me for certain reasons, but I would like to.
It so happens that I often look at JavaScript code, with which I am not very familiar, if at all. For example, I’m just studying third-party code for general development, trying to understand how some kind of jQuery extension doesn’t want to work, so I assumed, fix bugs, get acquainted with the MVC code of the framework that I want to understand better, look at the code of project colleagues, sometimes even my own code that forgot how it works (I hope I'm not the only one). It so happens that even finding a place with which your fascinating journey into this code (broken into many files, sometimes minified, often confused) is a puzzle.
After a quick inspection and the realization that the humble contemplation of kilobytes of source code is not particularly productive, I run the code. I enthusiastically set a breakpoint in some familiar place, I lose heart a little when I once again get into the debugger in minified jQuery (and who doesn’t lose heart?), I get annoyed when I once again step through the debugger through the necessary piece of code, violently jump the cycles so that do not get stuck there for a thousand iterations, while breathing, I set conditional breakpoints, I apathetically press F11 again and again in fear of missing something important. Sounds familiar?
In certain cases, console also comes to the rescue, but everyone probably remembers that “magic” feeling when you forget to delete console.log (or, God forgive me, alert) before committing. Fortunately, jshint also comes to the rescue for some, which unobtrusively reminds. It’s worse, you think that console comes to the rescue, but you get a soulless “console is undefined”. If you did not have this, then you are either lucky or a beginner.
What about the crazy Heisenbug ? The bug is running, F12 is pressed, the breakpoints are placed with unmistakable accuracy and the cool calculation of a professional hunter, the described steps are completed, but the bug has never happened?
I don’t even want to start a sad song about errors reproduced only in certain browsers / devices / platforms where there are no saving DevTools. No, sometimes (though not always) alternatives are available, often no longer supported, heavy, difficult to install and use, not having exactly the functionality that you need. Yes old versions of IE, I'm looking at you . In fairness, despite the fact that witch-hunting is always fun, not only older versions of IE are sinful. Creating an environment for debugging on mobile devices is no less sad (specific platform requirements, simulators, additional software, SDK, device configuration, etc.) - Androind , iPnone .
Finally, performance profiling. Using the excellent JsPerf service, you can see strangers for different browsers or drive your optimization ideas, this is when there are ideas. In Chrome DevTools and Firebug has a built-in profilers, taking the exact figures of respectively engines V8 and SpiderMonkey, but I have never been easy to use interface, where the figures presented do not like the fact that profiling should always include and you can not just turn once and to always have it turned on by default, the insert of console.profile / console.time into the code (and especially forgetting to remove them) was never fun either.
In view of the foregoing, one day I was visited by the thought - it would be nice to have a tool that solves at least part of the above problems and:
- allows you to see what events are happening in the code right now, open the call tree and highlighted code execution path
- allows you to filter scripts and events and monitor only what is interesting to me at the moment
- allows you to execute certain scripts in the application and then analyze what happened, including access to data at runtime
- allows you to trace, debug, profile code in any browser / device / platform
- it allows you to quickly, conveniently and constantly see the performance of functions, immediately see which of the recently added functions can drain performance, also to support decision-making, what exactly can you try to optimize
- allows you to see highlighted let execution of a specific scenario
- allows you to learn unfamiliar code, analyzing the process of its execution
If the above problems and suggestions for solving them are not close to you, then you can probably not read further, as there will be what can be called advertising (albeit free at the moment) of the product.
I am glad if I have not lost you after the advertising disclaimer. Like most of my colleagues, I was cast on the old programmer spell “write tulsum kotorus nemogus findlus”therefore, please welcome spy-js - a new tool for working with JavaScript, designed to fill in the gaps of existing tools, look at debugging, profiling, tracing from a different angle. The project is in beta, but the beta version already can do most of the wish list voiced above. The general direction of development is not to replace the capabilities of existing DevTools / Firebug, but to provide an alternative solution to problems and fill in the possible gaps of these tools.
By spontaneously obeying Atwood's law that everything that can be written in JavaScript will be written in it, spy-js is mainly written in the language for which it is written (ek, wrapped).
Architecturally spy-js is a nodejs web applicationand browser client. How it works: the browser in which the page with the scripts to be traced will be loaded is configured to use a proxy server (a web application on nodejs). The web application proxies requests and, if the requested resource is a JavaScript file, modifies it before sending it back to the browser. A file modification is an insert of instrumental instructions . When the changed code is executed in the browser, information about its execution is sent back to the server, which after processing becomes available in the spy-js user interface, where you can watch events in real time.
A project would never have been completed without using great open source projects such as: nodejs, esprima, express, grunt, socket.io, jQuery, knockout.js, underscore, ace, bootstrap. Not all used projects are listed.
The free beta version of spy-js is currently available for download at http://spy-js.com . The source code of the project itself is not open. Documentation, configuration examples, the ability to start bugs, ask questions and so on, is currently carried out using the open github repository. Questions can also be asked on stack overflow with the spy-js tag.
At this stage, my financial investments in the project are not so large, I work on it most of my free time. My plan is to use reviews from those who find the tool useful to continue its development to the stage when / if I can offer paid licenses and invest more time / support / finance in the product.
I am sincerely grateful for any support, suggestions, feedback, dissemination of information about the project. It really inspires and helps me do what I do. I hope with your help I can contribute to the development of JavaScript tools.