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
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. 😉
In this case I’m returning a type that’s defined in another file—JSjet shows me suggestions from the referenced class.
Note: Neon doeshave 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.
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!
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.
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:
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?
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.
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.
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.
For more on the debugger, see this article.
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.
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?