For tools: I prefer Google Chrome’s inspector to Firebug, but it’s pretty much a wash. I use Emacs with js3-mode, which does a lot of great syntax highlighting / error catching kind of stuff—if you’re not using a really smart editor like that, then something like JSHint or JSLint would probably be a good idea.
Also, being extremely fast-and-loose with your code’s (and data’s) structure. One of the advantages of a very dynamic language like JS is that you can very quickly change aspects of your design, without even having to think of it as a ‘design’. You can make small changes and instantly see what happens without breaking anything. If you decide to represent something as a string rather than an int, you probably don’t need to change 500 interfaces to make it work, so just make the change without thinking about it. This way of thinking makes experimentation a lot quicker and easier, and then it shouldn’t take much work to ‘refactor’ once something is working pretty much the way it should.
Also, this is a bit obvious, but when writing code in a modular fashion, each module should be wrapped in a function and put at most one name in the global scope. js3-mode (and JSLint) let you put a comment at the top of a js file like /* global foo bar */ so you don’t get warned about undeclared variables that you know about—if that list gets too long, it might be time to rethink the interface between modules.
I forgot to mention, for full disclosure: I’m the maintainer of js3-mode. Also, there’s an existing issue that indentation can take a really long time (like a second) for really long js files (longer than I would ever create).
For tools: I prefer Google Chrome’s inspector to Firebug, but it’s pretty much a wash. I use Emacs with js3-mode, which does a lot of great syntax highlighting / error catching kind of stuff—if you’re not using a really smart editor like that, then something like JSHint or JSLint would probably be a good idea.
Regarding best practices, I recommend npm style.
Also, being extremely fast-and-loose with your code’s (and data’s) structure. One of the advantages of a very dynamic language like JS is that you can very quickly change aspects of your design, without even having to think of it as a ‘design’. You can make small changes and instantly see what happens without breaking anything. If you decide to represent something as a string rather than an int, you probably don’t need to change 500 interfaces to make it work, so just make the change without thinking about it. This way of thinking makes experimentation a lot quicker and easier, and then it shouldn’t take much work to ‘refactor’ once something is working pretty much the way it should.
Also, this is a bit obvious, but when writing code in a modular fashion, each module should be wrapped in a function and put at most one name in the global scope. js3-mode (and JSLint) let you put a comment at the top of a js file like
/* global foo bar */so you don’t get warned about undeclared variables that you know about—if that list gets too long, it might be time to rethink the interface between modules.I forgot to mention, for full disclosure: I’m the maintainer of js3-mode. Also, there’s an existing issue that indentation can take a really long time (like a second) for really long js files (longer than I would ever create).