Tuesday Mar 26, 2013

What works better for you? NetBeans IDE or Chrome Developer Tools?

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.


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.


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.


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?

Sunday Mar 24, 2013

Network Monitor for REST and WebSockets communication

One of the features which we have not managed to finish for NetBeans 7.3 was a Network Monitor. When developing an application which talks to a server all sorts of problems can happen. Server may not respond and simply abort communication; server may send different data than expected; the data which our application sent to a server were not processed on the server as expected; etc. In times like that it is invaluable to be able to analyse what exactly is being exchanged between the server and our application. Did our application used the right URL? did it set right request headers? what exact data are being send to server? what exact data has server responded with? in what format the data are? These and other questions can now be answered with help of the Network Monitor. The feature just landed into nightly builds of next NetBeans release. It is not completely finished, the UI needs to be polished but it is good enough for a first round of review.

Let's look at what it does. When running a project in "Chrome with NetBeans Integration" browser or "Embedded WebKit" browser the Network Monitor monitor window will open automatically similarly to the Browser Log window or debugging session windows:

As I said the UI is preliminary. Trigger a REST or WebSocket communication in your browser application and you will notice network requests to start appearing in the Network Monitor UI. As mentioned on the previous screenshot not all network requests are monitored. The focus of NetBeans network monitoring is to help resolve common problems which happen during development of applications which are using REST and WebSocket communication. Network requests like loading of static resources (ie. images, css, etc.) are automatically filtered out. If you need to see those you can analyse them directly using your browser tooling for example in Chrome Developer Tools. However, any network request which fails is logged and brought to attention regardless of whether it is REST, WebSocket or plain static resource request.

Let's look how network requests are presented:

Above screenshot shows three network requests recorded. First one failed and is therefore shown in red color. The last one is a call to the Twitter Search REST API and shows request and response headers. Switch to Response tab to see data received from the service:

The response from server in this case is JSONP (notice that content-type in the response headers in previous screenshot was "application/javascript") and IDE automatically extracted JSON data from the javascript response and reformatted the single line JSON stream into a more readable form. If it is desirable to see data as they came from the service just tick "Raw Data Response" checkbox at the right bottom corner. In this instance the outcome is:

The last tab shows callstack which triggered this network request and links allow you to quickly dive into your application's code:

For monitoring WebSocket communication the UI is similar but instead of response data you get to see list of textual frames as they happen:

Blue color indicates that WebSocket request is still open and more data frames may be received/sent.

When a network request fails the Network Monitor shows server's status code in the Headers panel, for example "404 - Not Found". There is one error case which the Network Monitor is distinguishing and trying to provide more help than that. It is the case of REST service call which your browser aborted due to Same Origin Policy:

This can happen for example if you are developing REST service and deploying it to a GlassFish server (which by default runs on port 8080) and at the same time you are trying to access this REST service from your HTML5 project which runs on NetBeans lightweight web server (which by default runs on port 8383). In this scenario browser's Same Origin Policy stops your JavaScript code from accessing REST service because the policy says that JavaScript can access only resources on the same server, using the same port and the same protocol.

There are few options how to resolve this. You could run both projects on single server. Or you could enhance your REST service to support JSONP and use JSONP from your JavaScript which would workaround the Same Origin Security policy. However, if you plan to make your REST service publicly accessible then the best approach is to utilize Cross-Origin Resource Sharing (CORS) and amend your REST service to tell browser that it can be called from different domains. For REST services developed in the NetBeans using Jersey this can be as simple as following the "Jersey Cross-Origin Resource Sharing Filter" wizard (in the Web Services category) to create subclass of Jersey's ContainerResponseFilter SPI and provide all necessary CORS headers:

 public class NewCrossOriginResourceSharingFilter
              implements ContainerResponseFilter {
    public ContainerResponse filter(ContainerRequest request, 
                                    ContainerResponse response) {
            "Access-Control-Allow-Origin", "*");
            "Access-Control-Allow-Methods", "GET, POST, PUT, DELETE");
            "Access-Control-Allow-Headers", "content-type");
        return response;

The wizard automatically registered the filter in web.xml for you.

Hope you find this feature helpful! Any feedback or suggestions are appreciated.


This is the blog of the NetBeans client-side web team, which develops the support for HTML5 applications in the NetBeans IDE.


« March 2013 »