Ask HN: JavaScript Dev Tools
79 comments
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.
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 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.
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.
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.
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.
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.
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.
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)
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
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
[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.
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.
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
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
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...
* 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...
In my experience, the Webkit tools (particularly in Chrome and Iron) are ahead of Firebug, especially when trying to debug minimized JavaScript (pretty print is included in the tool--in Firefox, you need an additional plugin). Firebug can get laggy when debugging large JS files, too.
I've found firebug to be superior to CDT in every way
Firebug doesn't have anything close to the Timeline in Chrome. It doesn't have heap profiling either...
Webkit's logging is asynchronous and delayed, this tends to make firebug comparatively significantly better.
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)
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)
I've found that it chews through memory and drags down the whole browser, even when I'm not actively using it.
That was true a year or two ago, but I've found it much improved as of late. Fb 1.7 is very good.
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/
I meant "from 1.7", sorry.
Am I missing something, or is this only relevant to client-side code? The OP is talking about server-side code.
> Backbone, and client side stuff such as Sencha
> my debugger consists of alert()
> my debugger consists of alert()
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/
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/
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]
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]
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
Oh also: python -mjson.tool is great for formatting json on the command line. Like: curl -XGET http://example.com/API | python -mjson.tool
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.
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.
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.
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)
(of course, there's really no reason to be using JSLint over JSHint anyway)
Well that was actually my point; JSHint is effectively a highly configurable version of JSLint.
JSLint is already a highly configurable version of JSLint. JSHint is a leniently configured JSLint.
breacimanno said it all. JSLint is highly opinionated, JSHint gives you the extra control so that you can use it just to catch mistakes, not conform your style to someone else's standard. I use a textmate extension that lints on every save, it's not practical/healthy to keep ignoring warnings - you know what that will lead to.
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.
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.
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.
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.
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.
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.
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 :(.
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
BTW Using PHPStorm on Win7 64
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.
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.
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.
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.
I'm using Jasmine (and Guard) for that.
It helps to get a better understanding of the language/platform in my opinion.
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.
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.
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.
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!
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!
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()
I shortened console.log() with a function I use in development called c()
function c(x){
console.log(x || "!");
}
> 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.
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.
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.
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.
For editing, I use Sublime Text 2, which just introduced code completion in the last version. It's awesome.
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.
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.
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)
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)
I just found out that Eclipse was able to provide code completion on JavaScript file! You have to create a JavaScript project.
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.
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.
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, ...)
- 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, ...)
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?!?
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?!?
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
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
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.
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...
Here's the link that I used to get started:
https://github.com/joyent/node/wiki/Using-Eclipse-as-Node-Ap...
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.
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.
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
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
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
https://github.com/facebook/jsgrep
Node inspector and Chrome Developer Tools seem pretty nice.
https://www.youtube.com/watch?v=AOnK3NVnxL8
https://github.com/dannycoates/node-inspector
https://www.youtube.com/watch?v=AOnK3NVnxL8
https://github.com/dannycoates/node-inspector
TDD with Jasmine will help you maintain control as your codebases get larger.
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.
http://jsbeautifier.org/ for pretty printing. I'm using this for minified scripts and JSON strings.
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.
[deleted]
[deleted]
Jetbrains WebStorm or Visual Studio with Resharper. And of course Firebug and the tools in Safari/Chrome.
i find sites like jsFiddle and jsbin extremly useful when programming in javascript or tools like jsLint
Coffeescript
console.dir is really useful. It give you variable structure in console.
You are missing firebug, chrome dev tools
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?