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.
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. 😉
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.
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.
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!
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.
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 …
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 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.
