Check out these videos from Paul Irish on using console effectively:

http://www.youtube.com/watch?v=4mf_yNLlgic

http://www.youtube.com/watch?v=nOEw9iiopwI

Since you are an emacs user, you may want to try mooz's community fork of Yegge's js2-mode https://github.com/mooz/js2-mode

Haven't tried it myself, but you may also want to look at Moz Repl in emacs. http://www.emacswiki.org/emacs/MozRepl

Finally, check out Christian Johansen's and Magnar Sveens .emacs.d for some ideas on how to set up your emacs for javascript.

https://github.com/magnars/.emacs.d

https://github.com/cjohansen/.emacs.d

For TDD, you 3 main options worth checking out are: Buster.js looks really promising and does both server-side and client-side testing.

If you don't like buster.js for whatever reason, Mocha is a popular node.js server-side testing option and Jasmine is a popular client-side testing option.

I use it dozens of times a day -- it's critical for writing and understanding JS.

Since some folks write JS that has to go through a "build" process, it's easier to set a breakpoint in the debugger than to go back, modify the code, and "re-build" to get a breakpoint.

If you are worried to modify your code because of the long build process then the build system probably needs rethinking - make sure that only the files that were modified are rebuilt, configure your text editor so that it runs build script on file save.

To each there own as to how setting breakpoints works best for them in their workflow--my only reason for commenting was to let people know there were other ways to set breakpoints than adding "debugger" lines all over their code.

The debugger also lists all breakpoints set through it, which lets you easily jump to them.

For complex/single page applications, the `debugger` pseudo-keyword is not quite that good.

If I'm working with the code in a text editor, it's usually easier for me to find the code block in the text editor and type 'debugger' rather than root around in the dev tools.

In the WDT, there's a keystroke which you should be able to find (it's command-L in Safari)

0 : https://github.com/sstephenson/sprockets

[1]: https://github.com/magnars/js2-refactor.el

I haven't used it myself because I haven't done any JavaScript since finding out about it, but it seems like a brilliant addition to the already superb Emacs JavaScript experience.

You can also set up flymake mode with JSHint[2] to get style tips and warnings in your buffer[3]. JSHint is like JSLint but more configurable.

[2]: http://www.jshint.com/

[3]: https://github.com/daleharvey/jshint-mode

http://www.youtube.com/watch?v=mHtdZgou0qU

Besides videos, check out Javascript Garden:

http://bonsaiden.github.com/JavaScript-Garden/

Javascript Weblog:

http://javascriptweblog.wordpress.com/

Here are some links over on Quora:

http://www.quora.com/What-are-the-best-resources-for-learnin...

The three books worth getting for someone who is already a programmer are: Crockford's "Javascript: The Good Parts", Stoyan Stefanov's "Javascript Patterns", and Resigs's "Secrets of the Javascript Ninja"

IMHO, there are few videos worthwhile.

Inspect the DOM and set modification and event listener breakpoints: http://code.google.com/chrome/devtools/docs/elements.html

Assets, Cookies, Databases: http://code.google.com/chrome/devtools/docs/resources.html

Network timings: http://code.google.com/chrome/devtools/docs/network.html

JavaScript debugger, breakpoints, watch expressions: http://code.google.com/chrome/devtools/docs/scripts.html

Profile everything, network, scripts, styles, layout, painting, garbage collection: http://code.google.com/chrome/devtools/docs/timeline.html

JavaScript CPU and Heap profiling: http://code.google.com/chrome/devtools/docs/profiles.html

JavaScript console, see errors, execute code, inspect breakpoint scope: http://code.google.com/chrome/devtools/docs/console.html

* Safari has the same developer tools as chrome (they're part of the Webkit package), though Safari's tend to lag, and Chrome adds some stuff not present in mainline.

* Firefox has Firebug (third-party extension) and new releases have added a few built-in console-type stuff.

* Opera has Dragonfly, it's a built-in but (in my experience) tends to "feel" flakier than either WDT or Firebug.

* MSIE has its own devtools, they're horrendously bad in MSIE8 and still pretty bad in MSIE9 (they're flaky and tend to be unstable, they're also harder to use and extremely ugly). This is probably the devtools you'll find most painful. I do not know what will be in IE10. Purely for debugging I believe you can also hook Visual Studio (including Express Edition) and get a more full-featured debugger.

Some IDEs can also do remote JS debugging, which is actually pretty freaky. IntelliJ IDEA 9.0+ (and derivatives, RubyMine, PyCharm, PHPStorm and WebStorm) can be hooked in Firefox and Chrome with a bit of setup[0].

[0] http://wiki.jetbrains.net/intellij/Debugging_JavaScript_with...

I also find the debugging experience better: the debugger seems stabler, and is definitely better:

* Default watches (scope variables) are more flexible (in fact, they're flexible at all)

* The stack pretty prints function arguments, you don't necessarily have to visit each level and check its locals

* Firebug hyperlinks objects and functions to (respectively) the object inspection tab and their source location

The WDT's timeline is not very useful in my opinion, the "network tab"'s overview on the other hand is great for understanding how resources are loaded and affect each other (or what the xhr sequences are when you seem to have a bug there)

> my debugger consists of alert()

For debugging: get used to webkit inspector and Firebug. console.log is the best thing since sliced bread (object inspection, etc). Use a `debugger;` statement to insert breakpoints [3].

node.js: get started with Express [4] and mocha [5]. Make the jump to coffeescript after you're comfortable, it's a great fit on the server. Read howtonode's articles to get an introduction to various aspects of node [6].

[1] jshint.com

[2] https://github.com/mishoo/UglifyJS

[3] https://developer.mozilla.org/En/Debugging

[4] http://expressjs.com

[5] http://visionmedia.github.com/mocha/

[6] http://howtonode.org/

https://github.com/johnbender/jshint-service

You can use the provided address in the post commit hook if you don't feel like setting up the server yourself.

[edit: post commit -> pre commit]

Oh also: python -mjson.tool is great for formatting json on the command line. Like: curl -XGET http://example.com/API | python -mjson.tool

For example, doing comparisons (x == null) or (x != null) is a well known shortcut for checking vs null or undefined. There's nothing inherently "bad" about using that shortcut.

(of course, there's really no reason to be using JSLint over JSHint anyway)

Keep in mind, this is simply an opinion. Although not everybody appreciates JSLint's emphasis on explicitness and readability, there are still a great number of people who do. To the OP, try both, and decide for yourself which one helps you write better code.

Two, forget your traditional OOP roots, JavaScript is loosely typed, it doesn't have classes… it's very different. You simply won't be able to use it like Java.

Three, Eclipse (and probably other IDEs, too) is perfectly capable of debugging your JavaScript without using `window.alert();`. When testing your code in the browser you can use its own dev tools to inspect values at breakpoints and so on. Webkit's dev tools are my favorite.

Four, install a CLI interpreter with a REPL if you don't have one already. `jsc` is standard on Mac OS X but there are a lot to choose from, including `rhino`, `spidermonkey`… Your browser's dev tools has a REPL, too, if you like it more. Either way, a REPL is very handy when you need to try out a few things without messing anything.

Five, you might want to force your code to comply with loosely defined and not even widely accepted code standards. Installing a `jslint` variant on your system may help.

Six, keep in mind that JavaScript's development is definetely not centralized. While there is a standard body officially responsible for its elaboration, nothing is written in stone. New frameworks/ideas are poping every week only to be replaced by a "better" alternative the week after. It's all vey exciting but also very chaotic. Focusing on the basics first will help you keep your head above the water.

Never use alerts to output debug info - the alert itself may interfere with the events you are trying to debug

console.log is mostly reliable - but sometimes the value of a variable will not be what you think due to firebug weirdness (or hoisting?) - use break points instead.

If you are required to make stuff work in IE the JS debugger that comes with IE8+ is actually rather good (and more stable than Firebug).

JS Lint your code but don't use an overly zealous settings. JS is flexible - no need to constrain yourself.

The only book worth reading IMO if you really want to learn the details is "JavaScript - The Definitive Guide" by David Flanagan (ISBN 0596805527).

Crockfords good parts is mostly about his general preferences for programming style. Definitely don't read it like the bible.

If you want to focus on UI learn how to use events properly - this means not using frameworks but doing it from scratch yourself.

Read up on event driven programming and asynchronous behaviors

Learn JS first - then jQuery, Prototype, whatever second.

BTW Using PHPStorm on Win7 64

If you're looking for something free, you might check out the cloud9 editor. You can try the hosted version and install it locally.

Also, a tool like JSHint (less opinionated than lint) is a practical necessity.

I'm using Jasmine (and Guard) for that.

It helps to get a better understanding of the language/platform in my opinion.

http://discontinuously.com/2011/03/vim-support-javascript-ta...

I've written a Vim plugin that wraps DoctorJS, but I reckon that there should be equivalents for Emacs.

Framework wise, I am loving http://Knockoutjs.com, its an MVVM design style, similar to the pattern frequently used for Silverlight development, and its got great tutorial and support on the site. I particularly like the Knockout mapping plugin as it will automatically map JSON into a ViewModel, sweet!

Checkout the author Steve Sanderson's blog also, well worth reading : http://blog.stevensanderson.com/

I have been getting familiar with http://amplifyjs.com which simplifies ajax request management and client side storage, as well as a publish/subscribe messaging.

Also recently stumbled upon http://xuijs.com/ which I intend to get more familiar with!

Good luck with your ventures in javascript!

    function c(x){
        console.log(x || "!");
    }

Not in firebug (anymore), although the hyperlink will lead to the object itself, in its new version: http://jsfiddle.net/sgGEW/

The Webkit console does have that issue.

For editing, I use Sublime Text 2, which just introduced code completion in the last version. It's awesome.

Based on your recommendation, I tried Sublime Text 2. It looks good but the code completion is partial; just like it is in the Chrome console or Visual Studio.

For example, if you type: var req = new XMLHttpRequest(); req.

the methods available for req (instance of XMLHttpRequest) do not show up.

Sublime's auto completion just helps me a lot when I have to repeat things or if I have to change lots of text in different places all at once (tip: hold down command when clicking when you have your cursor somewhere else on the page)

Didn't see anyone mention Cloud9 which I think will debug Node.js stuff on the server. People did mention console.log which honestly I end up relying on way too much. There is also the debugger in Chrome or Firebug.

Also there is TDD/BDD like Vows (vows-bdd) or Jasmine etc., which if you actually get into doing that (honestly I have tried but I usually don't) that would mean usually writing smaller amounts of code and testing them more immediately (unit or integration tests) which would mean that typos and other bugs are easier to isolate and correct.

I think people mentioned jslint. CoffeeScript makes JavaScript overall easier and less typo-prone I think.

- Breakpoints in Firebug script debugger

- Find state of variables by assigning them to global vars temporarily, e.g.:

var debugState; // Delete me once you've finished debugging

function someFunction() { var state = 'interesting value I want to inspect'; .... do some work on 'state' debugState = state; }

Then access debugState in the Firebug console. The console allows you to use JavaScript to interact with your page.

- Using console.log(msg, ...) in your scripts. You can pass multiple variables and these will all get output to the console, e.g.:

console.log('The Carousel:', carousel, 'Foo:', bar, ...)

This happens sometimes to me, especially when I bundle all my JS resources together into one file. JSLint doesn't help, as some 3rd party libraries don't pass JSLint tests.

What I end up doing is adding console.log/alert statements all the way through the scripts to narrow down where the script aborts. There must be a better way?!?

If you don't need Closure's minified output, don't use it; the error messages are still nice.

If you don't want to drop Closure into your app's JS build chain, use a Makefile for quick syntax checks: http://pastebin.com/raw.php?i=cqX165iD

Here's the link that I used to get started:

https://github.com/joyent/node/wiki/Using-Eclipse-as-Node-Ap...

Browser projects often have pretty complex build requirements - concatenation, minification, etc. A lot of people end up writing a ton of shell script spaghetti, or using a js-specific framework (jake, cake, etc.), but I've found that unless you need something super fancy, plain old Make is just fine.

Or consider eclipse plus the spkt extension, which offer code completion for extjs.

If you aren't using sencha stuff, then ms visual studio has pretty good javascript support.

Use firefox w firebug, and try jasmine for unit testing

https://github.com/facebook/jsgrep

https://www.youtube.com/watch?v=AOnK3NVnxL8

https://github.com/dannycoates/node-inspector