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.

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?

[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.

[tikhonj]

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

[benjaminwootton]

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

[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

[masklinn]

And such tools are available in all modern browsers:

* 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...

[elchief]

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

[neilk]

Am I missing something, or is this only relevant to client-side code? The OP is talking about server-side code.

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

[johnbender]

I created a small node server to provide jshint as a service to people who don't care to install node on their machines. It also includes a git pre commit hook to lint each of your staged commits.

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]

[meta]

Second jshint. I use syntactic vim plugin, could never go without it anymore. http://stackoverflow.com/a/5893447. Also node-dev https://github.com/fgnass/node-dev

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

[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.

[brendoncrawford]

JSHint [1] - don't fall prey to JSLint's dictatorship

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.

[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 :(.

[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...

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.

[masklinn]

> But be aware that those objects are "live" - if they change at some poing later in your code, the console object will update.

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.

[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.

[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...

[jneen]

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