Brian Fernandes
Director of Customer Engagement - Loves technology and almost everything related to computing. Wants to help you write better software. Follow at @brianfernandes.
Posted on Jun 24th 2016

While far from an expert, I’ve been working with JavaScript for ages. I started off using JavaScript for DHTML (anyone remember that term?) when cross-browser meant your site would work with Internet Explorer and Netscape Navigator. I moved on to using JavaScript for desktop widgets and finally, browser extensions for Firefox and Chrome. A big believer in “eating your own dogfood,” ever since I started developing MyEclipse, I’ve been using MyEclipse as my JavaScript IDE for these personal projects as well.

Coming to the Eclipse space, at Genuitec we’ve always been at the forefront of JavaScript tooling; we introduced the first Eclipse based “AJAX” JavaScript debugger way back in ‘06, followed by an in-house JavaScript solution – an alternative to JSDT, a highly customized Tern Java integration for better content assist, and a new, modern JavaScript debugger that allows you to debug both Node JS and Web applications.

We released JSjet about a month ago and I believe this is a game changer for JavaScript support in Eclipse. When I last worked on my Firefox extension, it was with the pre-JSjet version of MyEclipse. With JSjet, there’s almost a night and day difference in terms of the support I get from my IDE and the amount of trust I can place in the tooling. Let’s walk through some of these changes—I’ll be using one of my Firefox extensions as a sample code base.

First Impression

The first thing I noticed when I opened my project in JSjet was how much cooler my code looked. And this isn’t just about pretty code—it’s about improved code readability. Local variables and fields are differently colored, function calls clearly stand out, special keywords are easily distinguishable, etc. Look at these screenshots which show you how the same piece of code looks in JSjet vs Neon.


The syntax coloring even works for embedded JS too.


The preferences are further customizable of course, if you want to distinguish a variable that’s a parameter from other variables, you could enable that setting too—we didn’t want to make it too colorful. 😉

Content Assist

JSjet has a highly customized Tern / Tern Java integration that provides more complete and accurate content assist. The inference engine delves just deep enough into your JavaScript source to bring you the suggestions you actually need. Even the icons clearly indicate what framework or library the suggestions are coming from. In this case I’m returning a type that’s defined in another file—JSjet shows me suggestions from the referenced class.


Note: Neon does have content assist support, it just doesn’t work for all cases, like the one above.

If you use third party libraries (of course you do), you can enable the corresponding module to have the content assist quality stepped up a notch with detailed documentation provided as well.


Code Analysis & Navigation

Now this is my favourite set of JSjet’s features. If the IDE truly understands your code, there are a slew of capabilities that you can now use, and more importantly, trust to give you the right analysis and show you the right details.


The Outline view is a standard in most Eclipse perspectives. If you’re a Java developer, you would have learned to use it to get a quick understanding of how the code you’re looking at is structured. However, as far as JavaScript was concerned, I could never really trust the outline to give me a complete picture. With Neon, I’m afraid the outline has taken a step backwards; have a look at the screenshots below—no other explanation is warranted.


Note: Neon does have an Outline view, but it doesn’t work in all cases – the way I’ve written by FireBible ‘class’ was not Neon friendly, resulting in almost no elements shown in the view.

The outline has been an area of continuous improvement since we released JSjet a month ago, we’ve made several fixes and enhancements to it already. I don’t know if many of you use the quick outline, but it’s my favored method of getting around code—in all languages. It goes without saying that a more accurate and detailed outline allows for more accurate and granular navigation.


Hyperlink Navigation

Unfortunately, this is another area where Neon has taken a step back, either you don’t see the link (underline) or you do … but it takes you nowhere. Thankfully, JSjet is here to save the day. Just like the outline, hyperlink navigation works very well.


Mark occurrences also deserves a mention here—it just works!


Call Hierarchy

The call hierarchy works not only for methods and functions, but it works for variables and fields as well. How did I figure out where a particular variable was being referenced before this? Well, I’d use the File search to be sure and have to sift through quite a few invalid text matches before figuring out what I wanted. I’m sure a lot of you have done the same thing. With the Call Hierarchy on variables, I can quickly see references, even those from other JavaScript source files.


Call Hierarchy showing calls to the initMenuItem method


Call Hierarchy showing references to the pHandler field. Notice that the view refers to pHandler as a method, we’ll correct that shortly.

Type Hierarchy

With my JavaScript code not being very … “OOP like,” I must admit I don’t have much use for a type hierarchy. However, just to show it off, the JSjet type hierarchy works with old school prototype based extensions as well as the newer, ES6, class structures.



When you do need some advanced code analysis, the JavaScript search capability is really handy. Not only does it support searching for different types of constructs, the search in JSjet correctly identifies different types of references. No longer will you get a variable read if you are searching only for writes, or function references if you’re only looking for the declaration. The search also works well with OOP, of course it understands ES6 syntax. You can search within OOP and ES6 classes too, and, at a more fundamental level, it understands the difference between methods and functions, or fields and variables. Observe the search results below which display only the write access to chromeWindow while ignoring two other references to that variable because we limited our search to only the write accesses.


I haven’t differentiated these last three features from JSDT in Neon, because frankly, they were a bit hard to assess. Most, if not all these features failed to work with ES6 code. Several capabilities were also hit and miss; worked perfectly sometimes, worked only half the time/returned an incomplete and sometimes incorrect set of results, or simply did not work at all. As a result, you never really knew when you could use or trust the feature you needed. Searched for all read accesses to the variable “counter”—are you confident you got them all? No? Let’s do a File search just to be sure …

Validation & Linting

If you’ve been dealing with “validation” in JSDT, in the past, I know most devs preferred to just turn it off. To say it was slow and a resource hog would be an understatement—and let’s not get started on false negatives. In comparison, the JSDT validator in Neon is a significant improvement, being both faster and other than a few misses with ES6, it worked pretty well. Let’s come to JSjet though—like all other features, we support ES6 syntax completely. Salient features:
  • It’s fast. In our tests, the JSjet validator was at least four times as fast as the validator in Neon—a big difference when your projects have a metric-ton of JavaScript resources.
  • Error messages are far more precise and no irritating false negatives.
  • Fault tolerant— it won’t just stop at the first error, but show you multiple errors simultaneously.
  • The validator also strives to place error markers at the actual source of the error, so you don’t just know your code is invalid, but you also know where it is invalid. Ever had a single missing brace drive you crazy?


Example 1


Example 2

In these screenshots, observe how the JSjet validator is capable of continuing past an error to continue validation. Also, observe the specificity of the error messages.

I’m a bit embarrassed to admit that I had never used a JavaScript linter for any of my projects so far. Especially in a weakly typed language like JavaScript, a linter will help you catch errors that would only occur at runtime, or in very specific circumstances, without you having to actually run your code. JSjet support several different JavaScript linters like ESLint, JSHint and JSCS, and you can configure them according to your specific needs or preferences or even use settings that your team has been using outside Eclipse.


Just a small section of the linting errors visible after I turned on JSHint, looks like I’ve been quite careless with my null / 0 checks Linting support is another area that we’re working on right now, the next few releases will include usability fixes that make the linters much easier to use.


It’s important to get formatting right, and we’ve integrated esformatter to do the job. Of course, esformatter supports ES6 as well (have I said, “ES6 is supported” far too many times in this article?) and if you’re coming in from outside Eclipse land, you may already have been using esformatter to format and beautify your JavaScript. Esformatter is highly configurable and we’ve made it respect the JavaScript formatting settings in Eclipse too.


JavaScript Debugger

We released the JavaScript debugger as part of Webclipse way before JSjet, and have been continually improving it over the last year. Our debugger supports both Node.js as well as Java EE and Static web application debugging, and it’s so feature-rich that I really can’t do it justice in the small blurb below—so I’ll just mention a few of its key features:
  • One-click debugging for Java EE and Node.js applications.
  • Easily debug applications that are already running or remote sites. No need to launch from the IDE, we’ll intelligently map remote files to workspace files.
  • Script Explorer view allows you to explore and debug scripts that you don’t have in your workspace.
  • Intelligent source map support allows you to debug minified files or TypeScript, CoffeeScript, etc.
  • Great hover support for variables and types—hovering, even over fields during a debug session will show you the current value.
  • Integrated with the new Node.js runtimes available in Neon.
  • A well-integrated debug experience that works just like the Java debugging you are familiar with in Eclipse.


JavaScript Debugger Overview


JavaScript Debugger Example

For more on the debugger, see this article. In contrast, the JavaScript debugger in Neon does allow Node.js debugging (no Java EE debugging yet), but lacks almost all the debugging niceties mentioned above.


We really like where the JSDT development is Eclipse is heading; several areas have been improved significantly, like validation, and the fact that there is some ES6 support as well. There is also cool new integration for Grunt, Gulp and Bower, as well as the Node.js debugger. At the same time, several features have remained unchanged and some have even taken a step backwards, like the outline and navigation, for instance.

JSjet allows you to be productive with JavaScript in Eclipse today, right here, right now—whether you’re using Neon, Mars or even Luna! If you are a MyEclipse user, all JSjet features are included in MyEclipse 2016 already.

“But, JSDT is going to improve, right?” Definitely, and that’s great news for all of us! We’ll make sure you have the best JavaScript experience in Eclipse, and it will be a combination of an enhanced version of JSDT, as well as features that are developed in house. At Genuitec, we’re committed to continually improving our modern web support, so we’re always going to be adding more features—TypeScript and better Angular / Angular 2 support are coming soon, for instance.

You can get JSjet either standalone or as part of the Webclipse suite, which includes a host of other features like Live Preview, REST support, Emmet, usability capabilities, etc. – it’s free up to 8 days a month as part of our “we know, you just do a bit of JavaScript” license, and unlimited for only $29/year. Your time and sanity are worth it!

Let Us Hear from You!

If you have any comments or questions, we would love to hear from you @Webclipse on twitter or via the Webclipse forum. If you’re not already subscribing to our blogs, why not do it today?