I'd like to add an answer to this question as I've been trudging through some good, bad but mostly ugly Java lately and I have a whole new whopper-load of gross over-generalizations about Java and Java devs vs. JS and JS devs that might actually be based in something vaguely resembling useful truth.
There Are IDEs But It Can Be Helpful to Understand Why There Haven't Been Many
I've been trying Webstorm out now that I find myself drawn to Node development and it's not-bad-enough that I actually bought it but I still tend to open js files in Scite more often than WS. The reason for this is that you can do a lot more with a lot less in JS but also because UI work gives immediate feedback, browser dev tools (Chrome's and Firebug in particular) are actually quite excellent, and (accounting for non-browser contexts) re-running altered code is fast and easy without a compile step.
Another thing I'm fairly convinced of is that IDEs basically create their own demand by enabling sloppy code which you really can't afford in JavaScript. Want to learn how we manage in JS? It might help to start by trying to write something non-trivial in Java without an IDE and pay close attention to the things that you have to start doing and think about in order to actually be able to maintain/modify that code without an IDE moving forward. IMO, those same things are still critical to writing maintainable code whether you have an IDE or not. If I had to write a 4-year programming curriculum, it wouldn't let you touch an IDE for the first two years in the interest of not getting tools and dependencies twisted.
Structure
Experienced JS devs dealing with complex applications can and do structure their code. In fact it's one thing we tend to have to be better at with an early history that lacked IDEs to read the code for us but also because powerfully expressive languages can powerfully express completely unmaintainable disaster codebases very quickly if you don't code thoughtfully.
I actually had a fairly steep learning curve in understanding our Java codebase recently until I finally realized that none of it was proper OOP. Classes were nothing more than bundles of loosely related methods altering globally available data sitting around in beans or DTOs or static getters/setters. That's basically the same old beast that OOP was supposed to replace. So I stopped looking and thinking about the code basically. I just learned the shortcut keys and traced through the messes and everything went much more smoothly. So if you're not in the habit already, think a lot harder about OOD.
A well-structured JS app at the highest level will tend to consist of complex functions (e.g. jQuery) and objects interacting with each other. I would argue that the mark of a well-structured, easily maintained app in any language is that it's perfectly legible whether you're looking at it with an IDE or Notepad++. It's one of the main reasons I'm highly critical of dependency injection and test-first TDD taken to the extreme.
And finally, let go of classes. Learn prototypal inheritance. It's actually quite elegant easy to implement when you actually need inheritance. I find compositing approaches tend to work much better in JS, however, and I personally start to get ill and have EXTJS night-terrors any time I see more than one or two levels of inheritance going on in any language.
Core Principles First
I'm talking about the core stuff that all other good practices should derive from: DRY, YAGNI, the principle of least astonishment, clean separation of problem domains, writing to an interface, and writing human legible code are my personal core. Anything a little more complex that advocates the abandonment of those practices should be considered Kool Aid in any language, but especially a language like JavaScript where it's powerfully easy to leave a legacy of very confusing code for the next guy. Loose coupling, for instance, is great stuff until you take it so far that you can't even tell where interaction between objects is happening.
Don't Fear Dynamic Typing
There aren't a lot of core types in JavaScript. For the most part, dynamic casting rules are practical and straight-forward but it pays to learn them so you can better learn to manage data flow without needless casts and pointless validation routines. Trust me. Strict types are great for performance and spotting problems on compile but they don't protect you from anything.
Learn the Crap out of JS Functions and Closures
JS's first-class functions are arguably the main reason JS won the "Only Language Worth Touching the Client-Side Web With Award." And yes, there actually was competition. They're also a central feature of JS. We construct objects with them. Everything is scoped to functions. And they have handy features. We can examine params via the arguments keyword. We can temporarily attach and fire them in the context of being methods of other objects. And they make event-driven approaches to things obscenely easy to implement. In short, they made JS an absolute beast at reducing complexity and adapting varying implementations of JS itself (but mostly the DOM API) right at the source.
Re-Evaluate Patterns/Practices Before Adopting
First class functions and dynamic types render a lot of the more complex design patterns completely pointless and cumbersome in JS. Some of the simpler patterns, however, are incredibly useful and easy to implement given JS's highly flexible nature. Adapters and decorators are particularly useful and I've found singletons helpful for complex ui widget factories that also act as event-managers for the ui elements they build.
Follow the Language's Lead and Do More With Less
I believe one of the Java head honchos makes the argument somewhere that verbosity is actually a positive feature that makes code easier to understand for all parties. Hogwash. If that were true, legalese would be easier to read. Only the writer can make what they've written easier to understand and you can only do that by putting yourself in the other guy's shoes occasionally. So embrace these two rules. 1. Be as direct and clear as possible. 2. Get to the damn point already. The win is that clean, concise code is orders of magnitude easier to understand and maintain than something where you have to traverse twenty-five layers to get from the trigger to the actual desired action. Most patterns that advocate that sort of thing in stricter languages are in fact workarounds for limitations that JavaScript doesn't have.
Everything is Malleable and That's Okay
JS is probably one of the least protectionist languages in popular use. Embrace that. It works fine. For instance you can write objects with inaccessible persistent "private" vars by simply declaring regular vars in a constructor function and I do this frequently. But it's not to protect my code or users of it "from themselves" (they could just replace it with their own version during run-time anyway). But rather it's to signal intent because the assumption is that the other guy is competent enough to not want to mangle any dependencies and will see that you're not meant to get at it directly perhaps for a good reason.
If Java is All You Know, Dabble in Something With a Non-C-Based Syntax
When I started messing with Python because I liked what I was hearing about Django, I learned to start separating syntax from language design. As a result, it became easier to understand Java and C as a sum of their language design parts rather than a sum of things they do differently with the same syntax. A nice side-effect is that the more you understand other languages in terms of design, the better you'll understand the strengths/weaknesses of the one you know best through contrast.