Hacker News Reader

Comment by malandrew | Hacker News Reader

Like dangrossman said, use console.log.

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.

View on HN

I would add one very useful hint which was not mentioned in Paul's videos: place the word "debugger" (without quotes) anywhere in your script to set a breakpoint.

I'm always surprised more people don't know this. I haven't seen it any books and only occasionally in tutorials.

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

Breakpoints, yes. But many folks (myself included) set the breakpoints in the debugger itself--you don't have to put that line into your code to set a breakpoint.

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.

It would be even easier if you could just fix the build system.

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.

It's not that it's long, it's that it has to be done at all. Even without a build process (or one like ours that takes at most 5-10 seconds) it still takes longer than finding the line of code you're concerned about and setting a breakpoint within the debugger itself.

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.

Another reason to use breakpoints in the debugger itself, when doing client-side development, is that you usually don't need to refresh the page (well, you may have to, if the breakpoint is in a piece of code that executes only on page load). You set the breakpoint, trigger the action that executes that code (or call it from the console) and you're already debugging :)

Setting it from the debugger window itself is simpler, allows for setting a conditional breakpoint and allows for disabling (temporarily or completely) the breakpoint without having to source-edit and reload the page.

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.

I have a lot of trouble finding the desired code block in, say Firebug or Chrome dev tools. Especially if a page has multiple concatenated JS files. The search box is helpful, but often unreliable.

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.

Both WDT and Firebug let you jump to a given line. In Firebug, type # followed by the line number in the search box.

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

That doesn't work if you are using CoffeeScript which has no direct line translation. 'debugger' is the best way that I've found.

Similarly, we concatenate our JS with sprockets[0] -- so what's on line 50 of module.js in the pre-compiled code base may be on line 1350 of app.js in the browser.

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

Can't believe I wasn't even aware of this. I've been manually setting breakpoints for years... Thank you!

js2 mode, especially mooz's fork, is really, really awesome! Another minor-mode to consider is js2-refactor[1], which leverages js2 mode to make refactoring JavaScript code easier on Emacs.

[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

This is great - thanks! Are there any other good screencasts similar to the Railscasts?

The only other video that sticks out in mine head is this Google Tech Talk by Nicholas Zakas about javascript performance.

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.

Hasn't SOTJN been in early access mode for like 3 years? I bought a copy way back when it was first released but I've given up on it ever being finished.

Reply on news.ycombinator.com