
Ask HN: JavaScript Dev Tools - benjaminwootton
I'm an experienced developer who is really interested in JavaScript frameworks such as Node.js, Backbone, and client side stuff such as Sencha.<p>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.<p>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.<p>When I get past that, my debugger consists of alert().<p>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?
======
malandrew
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.

~~~
jarek-foksa
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.

~~~
adrianparsons
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.

~~~
bcrescimanno
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.

~~~
jarek-foksa
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.

~~~
bcrescimanno
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.

------
GICodeWarrior
Chrome Developer Tools is a powerful and often underutilized toolbox.
<http://code.google.com/chrome/devtools/docs/overview.html>

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>

~~~
elchief
I've found firebug to be superior to CDT in every way

~~~
hack_edu
I've found that it chews through memory and drags down the whole browser, even
when I'm not actively using it.

~~~
masklinn
That was true a year or two ago, but I've found it much improved as of late.
Fb 1.7 is very good.

~~~
mun2mun
Are you using firefox 3.6? Current firebug version is 1.9 and it has some cool
new features <http://hacks.mozilla.org/2012/01/firebug-1-9-new-features/>

~~~
masklinn
I meant "from 1.7", sorry.

------
ricardobeat
JSHint [1] - don't fall prey to JSLint's dictatorship UglifyJS [2] for
compression

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/>

~~~
HoLyVieR
If you are seeing JSLint as a dictatorship, you are probably seeing those
tools from the wrong way. Those tools helps you spot potential mistake and
help your code be a little better. What they give you is advice, you will find
that from time to time the advice they give you aren't that great and you are
always free to ignore them in those cases.

~~~
bcrescimanno
The problem is that JSLint goes further than static analysis and suggests what
could be considered simply "stylistic" changes to match the way Crockford
thinks javascript should be written.

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.

~~~
lazerwalker
It sounds to me like what you need isn't an escape from JSLint, but rather a
better JSLint config file that skips the stylistic checks you dislike. JSLint
at its strictest can definitely be a little too strict.

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

~~~
bcrescimanno
Well that was actually my point; JSHint is effectively a highly configurable
version of JSLint.

~~~
masklinn
JSLint is _already_ a highly configurable version of JSLint. JSHint is a
leniently configured JSLint.

------
johncoltrane
First, learn vanilla JavaScript. Don't bother with all those libraries and
frameworks as they try really hard to iron out JavaScript's particularities.
When you know how to deal with scope, the prototype chain and a reasonable
amount of DOM stuff you can choose tools to make your life simpler or realize
that all the snippets you have accumulated are, in fact, your own framework.

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.

------
doc4t
I found the WebStorm IDE from JetBrains to be excellent. It has very good JS
support and is very extensible. Many of my collegues use TextMate.

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.

~~~
meow
I found WebStorm useful too. Only problem is how slow it feels to be (after
using visual studio for other development). Listing members of an object by
typing a "." (dot) takes for ever. Also, it takes so much of RAM :(.

~~~
doc4t
True - it does take a lot of RAM but it doesn't seem to be too sluggish.
Currently I'm working on my laptop (old Dell D830 4GB RAM) with 4 rather big
projects open and I don't have any problems.

BTW Using PHPStorm on Win7 64

------
GnarlinBrando
<http://addyosmani.com/blog/> has a lot of good info on working with
javascript. The recommended reading in the side bar, particularly javascript
garden and principals of idiomatic javascirpt have useful notes about the
language and testing suites. I really like Sublime Text 2, there are some
great packages for web development and javascript specifically available for
it. Plus SFTP and GIT plugins. The Yahoo theater stuff, and crockford's
lectures are good. But I would start with Addy Osmani's site and the stuff he
recommends.

------
scriby
My team at work uses Webstorm. It's a bit of a memory hog, but it works pretty
well. The integrated debugger is great, and you get immediate feedback if your
JS doesn't parse. The main weakness is the autocomplete could be a little
smarter, but it's not useless. The editor regularly goes on sale for $40.

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.

------
thibaut_barrere
As someone who is doing much more CoffeeScript and JavaScript than before, one
things helps a lot: unit tests.

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

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

~~~
unoti
Agreed. Unit tests are the one saving grace of Javascript, for me. I use
Jasmine and CoffeeScript as well. The unit tests seem to only help me for the
backend parts of my projects. In Javascript right now for me this is games, so
there's a great deal of code that I haven't figured out how to unit test
effectively-- specifically graphical stuff drawing on canvas. But CoffeeScript
+ Jasmine is truly wonderful. Fast, fun, it feels like I'm blasting out work
faster than I ever have before in any other combination. It took a little
while to figure out how to get Jasmine to test async things.

------
int3
There's a very nice Javascript tags generator created by Mozilla called
DoctorJS (formerly jsctags). It does a bunch of static analysis that makes up
for Javascript's weak typing. I've made a blogpost about it here:

[http://discontinuously.com/2011/03/vim-support-javascript-
ta...](http://discontinuously.com/2011/03/vim-support-javascript-taglist-
plus/)

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

------
shaydoc
As far as IDE's I have found JSLint in jsfiddle.net
(<http://jsfiddle.net/shaydoc/geQvz/>) handy, else I've just got reacquainted
with the javascript way and been developing in notepad. Google Chrome has
fantastic developer tools as already mentioned! debugging is a sinch and
console.log is brilliant!

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!

------
drumdance
Use console.log() instead of alert. In Firebug you can do this with any object
and inspect it. But be aware that those objects are "live" - if they change at
some poing later in your code, the console object will update. If I need to
inspect an object in isolation, I throw an exception right after console.log()

~~~
artursapek
I shortened console.log() with a function I use in development called c()

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

It's pretty helpful, I can quickly throw the line c(); anywhere just to log if
it happens when/if it should. And it stays out of your way, unlike alert()
which is terrible and should be deprecated.

------
dangrossman
Learn only one thing at a time, and console.log instead of alert. I like
Chrome's JS console. I code in a generic text editor with highlighting but no
code completion. If you can't get your code to even parse correctly then it's
a problem with writing too much code between runs, not the tools.

~~~
miles_matthias
I really like Chrome's JS console as well. It's my little sandbox where I can
try out some JavaScript until I get it just right.

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

~~~
matthiasb
When I saw this post on HN, the first thing I did was to search for
"completion" in the page. I have been looking for this feature since I started
to write my first JavaScript.

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.

~~~
miles_matthias
Yea that is true. That's when I would normally open the Chrome console, set a
break point, and click through the local variable to see what might work for
me, then try it out in the console until I get what I want, then paste it into
sublime.

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)

~~~
matthiasb
I just found out that Eclipse was able to provide code completion on
JavaScript file! You have to create a JavaScript project.

------
ilaksh
I think that most people share your pain, even if they have been doing mainly
JavaScript for awhile. I know I do.

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.

------
eliot_sykes
For debugging client-side JavaScript, some things you can try for size in
Firebug:

\- 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, ...)

------
sashthebash
Related question... what do you do when the execution of your script just
aborts without an error?

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?!?

~~~
twirlthestash
Try Closure Compiler instead of JSLint. It will catch your syntax errors
without being so opinionated.

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>

------
zeekay
Using jslint has saved me a lot of time (I lint everything on write in vim
using syntastic). Syntax errors can pass silently leading to difficult to find
bugs. Using strict mode helps with this as well. I have also started to prefer
Chrome for client-side JavaScript development, it seems to let less slide than
Firefox, although Firebug is pretty dang nice.

------
lemnitram
For the last 6 months I've been using eclipse+chrome plugin to debug my
node.js app. It works well and in combination with nodeunit it's been very
productive.

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

[https://github.com/joyent/node/wiki/Using-Eclipse-as-Node-
Ap...](https://github.com/joyent/node/wiki/Using-Eclipse-as-Node-Applications-
Debugger)

------
jayferd
Everybody here's given pretty good advice.

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.

------
elchief
First off, Sencha Designer 2 just came out (beta) and will support graphical
layout plus code editing. U shud try that.

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

------
CGamesPlay
This won't be relevant to you right now, but once you start dealing with a
large code base, jsgrep is a tool that I wrote to enable easily searching and
modifying certain code patterns:

<https://github.com/facebook/jsgrep>

------
Or1on
Node inspector and Chrome Developer Tools seem pretty nice.

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

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

------
nathansobo
TDD with Jasmine will help you maintain control as your codebases get larger.

------
ssuraj
VJET JS plugin for eclipse ide is fine alternative it has good text editor for
JS and in association with ebay nodejs,jquery and json templates provides
features like auto assist.

------
mun2mun
[http://hacks.mozilla.org/2011/11/firefox-tons-of-tools-
for-w...](http://hacks.mozilla.org/2011/11/firefox-tons-of-tools-for-web-
developers/)

------
lignuist
<http://jsbeautifier.org/> for pretty printing. I'm using this for minified
scripts and JSON strings.

~~~
unwiredben
<http://jsonlint.com> is good for just JSON-verification and pretty-printing.
I've used it a lot with API outputs to make them readable.

------
Flow
Jetbrains WebStorm or Visual Studio with Resharper. And of course Firebug and
the tools in Safari/Chrome.

------
mouseroot
i find sites like jsFiddle and jsbin extremly useful when programming in
javascript or tools like jsLint

------
betageek
Coffeescript

------
smagch
console.dir is really useful. It give you variable structure in console.

------
shareme
You are missing firebug, chrome dev tools

