How far did DevExpress get with Javascript refactoring?

Question

Over a year ago, I remember watching one of DevExpress evangelists previewing or at least promoting rich Javascript refactoring (beyond just limited intellisense) within the Visual Studio shell, I recall part of CodeRush/DevExpress product line. I was excited.

On checking today (lmgtfy) I can find only very very limited reference to it, just one small italtic line about beta in product description, no videos, no blog posts, no community buzz. Was it dropped? Vapourware? Poor implementation that they dont even promote it?

With Javascript arguably the most popular programming language ever and with a VM for it on practically every machine in last 10 years, why is editor support so poor? (Compared with those for Java and C#)? You see the likes of ScottGu bragging we now have jQuery intellisense but compare this to richness of C# support in the IDE it is a joke.

Someone once said since there are many style of writing Javascript a rich IDE (beyond intellisense) with refactoring support is difficult, but if several engines can interpret/compile JS with same result surely it should be hard to analysis it to support stuff like rename variable, extract method, move to another namespace (or JS minic of it), etc.. Am I wrong?

Answer 1

CodeRush supports fifty-two JavaScript refactorings:

• Add Block Delimiters
• Add Parameter
• Break Apart Arguments
• Break Apart Parameters
• Case to Conditional
• Combine Conditionals (nested)
• Combine Conditionals (parallel)
• Compress Assignment
• Compress to Ternary Expression
• Concatenate Strings
• Conditional to Case
• Create Multi-variable Declaration
• Create Overload
• Create Setter Method
• Create With Statement
• Expand Assignment
• Expand Ternary Expression
• Extract Method
• Flatten Conditional
• For to ForEach
• ForEach to For
• Initialize Conditionally
• Inline Recent Assignment
• Inline Result
• Inline Temp
• Inline With Statement
• Introduce Local
• Introduce Local (replace all)
• Introduce Result Variable
• Line-up Arguments
• Line-up Parameters
• Move Declaration Near Reference
• Move Initialization to Declaration
• Promote to Parameter
• Remove Block Delimiters
• Remove Parameter
• Remove Redundant Conditional
• Rename Local
• Reorder Parameters
• Replace Temp with Query
• Replace with Local
• Reverse Conditional
• Simplify Expression
• Split Conditional
• Split Conditional (and duplicate else block)
• Split Initialization from Declaration
• Split Multi-variable Declaration
• Split String
• Split Temporary Variable
• Split With Statement
• Widen Scope
• Widen Scope (promote to field)

And eight consume-first declaration and quick fix features:

• Add Contract
• Add Else Statement
• Declare Field
• Declare Local
• Mirror Code
• Reverse For Loop
• Rotate 90 Degrees
• Spell Checker

Also, we're working to improve our refactoring support for the 10.2 release. We've also recently improved Quick Nav to make navigating to JavaScript functions as easy as navigation in C# or VB. This improvement will ship in 10.2 but is available now for CodeRush customers in a daily build.

Full Disclosure -- I lead the CodeRush team at DevExpress.

Answer 2

The problem with something like Javascript Intellisense is that it really needs to have supernatural powers in order to have any clue about what a piece of code means. Like here, in this function fragment:

return function(a) {
  var x = a.

Now I've just typed that "." after "a", and I hit "tab" for auto-complete. What is an IDE to do?

In some limited cases, you can make some OK guesses; like, the editor can make some assumptions if you've told it you're using jQuery for example, and it sees

$('something').

well it's a decent guess that completing with jQuery APIs is the right thing to do. That's never going to be much better than a guess, however. Even with that jQuery example, the editor is still going to be stuck with some hard problems:

$('something').each(function(_, element) {
  if (element.

After that ".", what should auto-complete show me? Well, a super-smarty editor might be willing to go out on a limb and assume that the "element" is a DOM node, but it'd have to be paranormal to know what kind of DOM node.

Now, another thing one could do would be to enable some sort of comprehensive hinting system, such that the programmer could explicitly tell the editor what's what. That'd take a little bit of the soul out of Javascript for me, but I guess some people might find it useful.