Ask HN: JavaScript Dev Tools
I'm an experienced developer who is really interested in JavaScript frameworks such as Node.js, Backbone, and client side stuff such as Sencha.
However, I'm struggling with them, which I think is because I haven't found the right tooling or a setup that suits my workflow.
On my Java, Rails and C++ projects, I'm equally as happy in emacs as I am in a richer IDE, but this combination of loosely typed JavaScript and poorly documented framework APIs based around massively nested maps means I can barely get a page of moderately complexity to even parse.
When I get past that, my debugger consists of alert().
What am I missing in order to be able to effectively work with JavaScript? Would you recommend any particular APIs, Frameworks, Articles etc to get started?
79 comments
[ 4.3 ms ] story [ 86.9 ms ] threadFor 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)
- 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, ...)
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.
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.
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
I'm using Jasmine (and Guard) for that.
It helps to get a better understanding of the language/platform in my opinion.
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.
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
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/
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)
Oh also: python -mjson.tool is great for formatting json on the command line. Like: curl -XGET http://example.com/API | python -mjson.tool
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]
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.
Here's the link that I used to get started:
https://github.com/joyent/node/wiki/Using-Eclipse-as-Node-Ap...
https://github.com/facebook/jsgrep
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.
https://www.youtube.com/watch?v=AOnK3NVnxL8
https://github.com/dannycoates/node-inspector
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
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()
* 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...
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
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.
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