I've heard variations of this question many times: Is the JavaScript Debugger in NetBeans IDE better than the one in Chrome Developer Tools (CDT)? How do they compare feature by feature? Why should I use the one in NetBeans instead of the JavaScript debugger in CDT?
Apples and Pears
While it is tempting to put together a feature matrix with one column for NetBeans and the other column for CDT, and then compare the number of checkboxes, this comparison would not make much sense. Because it is like comparing apples and pears. No, that's misleading too. It is like comparing a car factory (NetBeans IDE) with a car mechanic (CDT). Both car factory and car mechanic have a very vast and detailed knowledge about cars but they also have a very different focus. A car factory knows what steps there are to build a car from scratch and everything is optimized around this primary function - to build a new car of a certain brand. A car mechanic, on the other hand, is not concerned with most of the aspects of car manufacturing. The primary function of a car mechanic is being able to find what's wrong with a car and fix it. Regardless of the car brand, age, size, and state. You would not ask your local car mechanic workshop to build you a new car, would you? Neither would you drive your Subaru into the Ford factory to get it fixed.
Let's play with this metaphor a little bit more. How does NetBeans help you to build your project from scratch? It tightly integrates many separate tools to work seamlessly and optimizes the daily workflow of a typical developer. It comes with:
- templates for project creation (e.g., Bootstrap, HTML5 Boilerplate, AngularJS Seed, your custom one, etc.)
- support for components and libraries (e.g., CDNJS.com integration)
- support for project version control (e.g., GIT, HG, SVN, local versioning, etc.)
- support for project compilation (e.g., PhoneGap; coming very soon is SASS compiler)
- editor with syntax coloring, semantic features like refactorings, active error recognition, code assist, code navigation, etc. (JavaScript, HTML, CSS, SASS, etc.)
- support for problem diagnostics (e.g., JS debugger, network monitor, etc.)
- server to run your project on
- support for writing, running and debugging of unit tests (e.g., jstestdriver runner)
- support for editing visual part of your project (e.g., CSS styling)
- support for different target browsers (e.g., Chrome, Embedded WebKit, Android, iOS, PhoneGap native apps)
Seamless Integration
The true advantage, though, is in the seamless integration. An example of what I mean: with a few mouse clicks you can create a new project which uses, e.g., the AngularJS Seed project template; press F6 to start an internal server and open the project in a browser; type some JavaScript and save it and the browser will reload your project automatically; debug your JavaScript code directly in the editor in which you authored it - as simple as adding a breakpoint to a line in the editor; open Browser Log window to see a runtime exception in your code and click on the stack trace to go directly to offending line and column of the code using the same JavaScript editor; with a few clicks create a config file for JsTestDriver and debug unit tests just as regular JavaScript files; get outstanding code completion for jQuery and other selected JS libraries; etc.
This kind of integration is hard to achieve when using disparate tools. Not surprisingly, it was also the number one request in a recent FireFox Dev Tools study.
Surgery
Using still the same parallel, where the CDT excels is in the role of a car mechanic of web applications. It does not matter who produced the application, nor how, and it does not matter which languages they used, how small/big/new/old the application is, none of this matters. The CDT is there, ready to help you figure out the problem and repair it. And it comes with a very rich set of features suitable for this surgical task.
Overlaps
Now, obviously, there are features which overlap and which both IDE and CDT need. When writing code from scratch, or fixing code at runtime, you always need a JavaScript debugger and some editor. Similarly, for creating a brand new UI or tweaking an existing UI, you need styling support.
There are also areas which, IMO, distinctly belong to a single party only. For example, fine tuning performance should be done in the browser in which the application will run. Project management aspects, on the other hand, should be left to IDEs to deal with as most of the tasks are browser agnostic.
Conclusion
So to answer the original questions which triggered this article: both NetBeans IDE and CDT meet the needs of editing, styling, and
debugging but they have different strengths and, according to the task at hand, you should pick one or the other and utilize their strengths to your advantage.
On a more idealistic note, I think there is an opportunity for both IDEs and browsers to cooperate more tightly. It's been really great that efforts like the Remote WebKit Debugging protocol has allowed IDEs and other tools to get inside browser internals and build better tooling for developers. To reciprocate, perhaps we should prototype some APIs through which IDE-like tools could share their project context with the browsers. That is, in the CDT case for example, there could be a CDT API callback which CDT could call to retrieve information like: how to map URL to a file in the local filesystem?; where is the source map file for a given production file?; which project files/folders are relevant for the URL being currently opened?; does this file requires compilation? compile the given file; etc. And tools like NetBeans IDE could implement this callback for all NetBeans projects. That way CDT can work better and developers, you and I, will be better off too.
What do you think?