Java – When to Use Local Classes?

The IDE-based niceties are not available* in a dynamic language such as javascript. You have to learn to do without them. You'll have to replace tool support with better design.

Use a module pattern -- either by hand, or with a tool like requirejs. Keep the modules small, so that you can reason about them easily.

Don't define as many types -- use anonymous objects created close to the point of call. Then you can look at the caller and the callee and know what's going on.

Try to avoid coupling your code to the DOM -- Try hard to limit the amount of DOM manipulation you do in your code. If you can pass in selectors or jQuery collections, do that rather than having your code know about the page structure.

*_{If you're using a popular library, you can get fake autocomplete, but it's more like "show all jquery methods" than like "what properties does this object have". It saves typing, but offers no guarantee of correctness.}

The story of equals() combines several unfortunate design decisions that are now impossible to change, and that every Java user just has to live with one way or another: it is deeply woven into the semantics of the standard container types, it is automatically inherited by every user-defined class but with a behaviour that is usually not what you want, and defining it without also defining hashCode() silently results in undefined behaviour (i.e. the language imposes certain requirements on you but has no way of warning you if they are unsatisfied.)

You can get along by simply never defining the method IF you never use such objects anywhere that would expose the unwanted behaviour. But since software development is a cooperative game, this requires an iron-clad, no-exceptions, disciplined rule of "Absolutely no Foo widgets in Sets, ever!!" that everyone involved with the code must know and follow 100%.

It can be worthwhile to impose such a rule in order to gain some performance, just as with other very fundamental principles of coding - e.g. "No null return values, ever!" is a common strategy to save a lot of checking for null. But this depends on how much you really profit from the small simplification for each class. The downside is that you have added another unspoken assumption that all users of your class must know and follow, or silently suffer from undefined behaviour.