My next project will probably be a JavaScript game, but I started with Java because it’s my favorite language. Although I often use JavaScript too.
I don’t want to start “what is your favorite language” mindkilling debate, but for me programming in Java is more pleasant than in JavaScript. Partially because of the language, partially because of the tools. It is nice to write an anonymous function in JavaScript quickly, but I prefer a language with mandatory variable declaration and static typing, because it finds many errors in compile time, which saves me a lot of work and frustration (this is not so important when I write the new code, but becomes significant when refactoring). Also my favorite tools, Eclipse and JUnit are free. Writing and maintaining longer programs in JavaScript is rather inconvenient… but maybe it’s because I’m doing it wrong.
So if there are JavaScript fans on LW, I would like to ask—what are the best practices when developing a browser application (e.g. a game) in JavaScript? Google typically returns low-level answers, such as “always declare variables”, “always use a semicolon” and “give your variables meaningful names”. Let’s suppose I’m already a relatively good programmer, but my experience is mostly outside of JavaScript. Are there any best practices or good free tools that an experienced JavaScript programmer could recommend me? I currently use Eclipse as a syntax highlighter, a JQuery library, and Firebug plugin. Please recommend me what you use and consider useful.
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).
This might still be low-hanging fruit, but learn how to test specific modules, learn how to quickly identify which module is at fault, and learn to map your own common mistakes, as well as also mapping those mistakes where you spend 2 hours and feel like a fool for not catching it in 5 minutes.
More concretely, make small changes, test them, then make another small change.
Also, especially for javascript, I cannot stress enough the value of having even a basic reversion control system of “copying the folder and renaming it after each major stable milestone”. I have saved myself hours of debugging by just reverting a module of code to a known-working version and writing the code change a second time (usually this time without whatever stupid mistake I made)
I seem plagued by a tendency to leave off a semicolon or to do “if (x=5)” instead of “if(x==5)”, which often leads to very annoying sessions of bug hunting in Javascript. I also code using nothing but notepad, though, so I don’t have tools which will catch silly mistakes like this. Having a proper IDE might make some of this advice less relevant (that said, I love coding in Javascript + notepad specifically BECAUSE it hones all of these skills—I can debug completely unknown code from my co-workers extremely fast thanks to a couple years writing games under these restrictions :))
Could you tell me more about this—what is the best method and tool for unit testing in JavaScript? In Java I use JUnit for the non-GUI parts, and the GUI parts I simply don’t test… perhaps I should test them too, but in my programs most of complexity is in the non-GUI parts, so if I test them, most of the work is covered.
JavaScript feels more integrated with the GUI (the browser). In theory, it is an independent language, which can be embedded in browser or in anything else, and all the browser stuff is just like an additional library. When I will write more complex JavaScript programs, I want to write them in the way that separates the program logic from the browser API. And I would want to unit-test the logic. Shortly: I would like to unit-test JavaScript code in a JUnit style, not in a “browser emulation” style. What would be the best approach to do that? Also with regards to browser emulation or integration, which are the best tools? I have tried some (Canoo WebTest, Selenium), and they seem rather inelegant when compared with JUnit testing. Although Selenium also has a programming mode that seems more friendly; I haven’t tried it yet. I would appreciate some help here, so I don’t have to study and experiment with dozen tools.
especially for javascript, I cannot stress enough the value of having even a basic reversion control system of “copying the folder and renaming it after each major stable milestone”.
Yep, this is my blind spot. I know I should do it, I don’t do it, and I often run into problems that this would prevent. I’ll try to remember to install Subversion at home. Thanks for reminding me about this!
Subversion was good for its time, but a new generation of version control systems has sprung up — DVCSes (“distributed” version control). The new model is superior even for individual developers; some examples:
To get started all you have to do is enter a command to “turn this directory into a repository (a versioned directory)”, rather than having to choose/set up a server, access control, layout, naming schemes, etc as the “centralized” model (CVS, SVN, etc.) requires.
In a typical centralized VCS, when you commit changes, they are permanently in the repository as a new version; if it turns out you made a mistake, not in your code, but in how you added it to the repository (e.g. forgot to include a file), you have to make a new revision. With DVCSes, you can prepare your changes as a series of individual commits/revisions and polish and revise them before making them part of the permanent/public record. The major benefit of this for development is that it means you can commit often — every time you have made an improvement, commit it, thus preventing yourself from accidentally overwriting it without record during further development. If you make a mistake, or if the changes you made turn out to be a bad idea, you can always revert to last commit without losing anything else; and the diffs between revisions become single-topic, so more straightforward to understand.
I personally favor Git as being quick to use and flexible, but Git is generally considered obtuse in its command syntax so I wouldn’t specifically recommend it to someone new to version control. There are also Mercurial (hg), Bazaar (bzr) and Darcs (that last being a bit of an oddity in itself).
I recommend against using Subversion for new work.
Regarding unit testing JavaScript, I recently asked this question myself at Stack Overflow (and if you’re not familiar with Stack Overflow and the Stack Exchange Network, I recommend you should; it is a great place to get answers for technical problems), and ended up using Jasmine. I’m skeptical of the “BDD” thing, but it seems a perfectly fine tool for unit testing. I’m using it (example) to test logic inside the browser — that is, I load a web page which runs the tests and becomes the report of results — but I understand it can also be used from a “headless” environment of your choice.
Unfortunately, I do Javascript using notepad, so I can’t really help you on tools.
I’d usually just write a “UnitTest” function and put my code there. From the browser, you can directly invoke a function, so you’d just do “UnitTest();” or “UnitTest_Module8();” and have them display results in the form of alerts or such.
Another useful technique is to add a label or textbox to the HTML, and then keep running debug information there, for tracking variable that you suspect might be getting set wrong. I’d also often scatter alerts through my code, just so I could tell “Okay, it has reached this point in the code” or “Okay, at this point, x=5″
IMO, the major power of javascript is the ability to run commands “on the fly” from the browser itself, and the ability to very quickly modify the source code and re-run the program.
My next project will probably be a JavaScript game, but I started with Java because it’s my favorite language. Although I often use JavaScript too.
I don’t want to start “what is your favorite language” mindkilling debate, but for me programming in Java is more pleasant than in JavaScript. Partially because of the language, partially because of the tools. It is nice to write an anonymous function in JavaScript quickly, but I prefer a language with mandatory variable declaration and static typing, because it finds many errors in compile time, which saves me a lot of work and frustration (this is not so important when I write the new code, but becomes significant when refactoring). Also my favorite tools, Eclipse and JUnit are free. Writing and maintaining longer programs in JavaScript is rather inconvenient… but maybe it’s because I’m doing it wrong.
So if there are JavaScript fans on LW, I would like to ask—what are the best practices when developing a browser application (e.g. a game) in JavaScript? Google typically returns low-level answers, such as “always declare variables”, “always use a semicolon” and “give your variables meaningful names”. Let’s suppose I’m already a relatively good programmer, but my experience is mostly outside of JavaScript. Are there any best practices or good free tools that an experienced JavaScript programmer could recommend me? I currently use Eclipse as a syntax highlighter, a JQuery library, and Firebug plugin. Please recommend me what you use and consider useful.
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).
This might still be low-hanging fruit, but learn how to test specific modules, learn how to quickly identify which module is at fault, and learn to map your own common mistakes, as well as also mapping those mistakes where you spend 2 hours and feel like a fool for not catching it in 5 minutes.
More concretely, make small changes, test them, then make another small change.
Also, especially for javascript, I cannot stress enough the value of having even a basic reversion control system of “copying the folder and renaming it after each major stable milestone”. I have saved myself hours of debugging by just reverting a module of code to a known-working version and writing the code change a second time (usually this time without whatever stupid mistake I made)
I seem plagued by a tendency to leave off a semicolon or to do “if (x=5)” instead of “if(x==5)”, which often leads to very annoying sessions of bug hunting in Javascript. I also code using nothing but notepad, though, so I don’t have tools which will catch silly mistakes like this. Having a proper IDE might make some of this advice less relevant (that said, I love coding in Javascript + notepad specifically BECAUSE it hones all of these skills—I can debug completely unknown code from my co-workers extremely fast thanks to a couple years writing games under these restrictions :))
Could you tell me more about this—what is the best method and tool for unit testing in JavaScript? In Java I use JUnit for the non-GUI parts, and the GUI parts I simply don’t test… perhaps I should test them too, but in my programs most of complexity is in the non-GUI parts, so if I test them, most of the work is covered.
JavaScript feels more integrated with the GUI (the browser). In theory, it is an independent language, which can be embedded in browser or in anything else, and all the browser stuff is just like an additional library. When I will write more complex JavaScript programs, I want to write them in the way that separates the program logic from the browser API. And I would want to unit-test the logic. Shortly: I would like to unit-test JavaScript code in a JUnit style, not in a “browser emulation” style. What would be the best approach to do that? Also with regards to browser emulation or integration, which are the best tools? I have tried some (Canoo WebTest, Selenium), and they seem rather inelegant when compared with JUnit testing. Although Selenium also has a programming mode that seems more friendly; I haven’t tried it yet. I would appreciate some help here, so I don’t have to study and experiment with dozen tools.
Yep, this is my blind spot. I know I should do it, I don’t do it, and I often run into problems that this would prevent. I’ll try to remember to install Subversion at home. Thanks for reminding me about this!
Subversion was good for its time, but a new generation of version control systems has sprung up — DVCSes (“distributed” version control). The new model is superior even for individual developers; some examples:
To get started all you have to do is enter a command to “turn this directory into a repository (a versioned directory)”, rather than having to choose/set up a server, access control, layout, naming schemes, etc as the “centralized” model (CVS, SVN, etc.) requires.
In a typical centralized VCS, when you commit changes, they are permanently in the repository as a new version; if it turns out you made a mistake, not in your code, but in how you added it to the repository (e.g. forgot to include a file), you have to make a new revision. With DVCSes, you can prepare your changes as a series of individual commits/revisions and polish and revise them before making them part of the permanent/public record. The major benefit of this for development is that it means you can commit often — every time you have made an improvement, commit it, thus preventing yourself from accidentally overwriting it without record during further development. If you make a mistake, or if the changes you made turn out to be a bad idea, you can always revert to last commit without losing anything else; and the diffs between revisions become single-topic, so more straightforward to understand.
I personally favor Git as being quick to use and flexible, but Git is generally considered obtuse in its command syntax so I wouldn’t specifically recommend it to someone new to version control. There are also Mercurial (hg), Bazaar (bzr) and Darcs (that last being a bit of an oddity in itself).
I recommend against using Subversion for new work.
Regarding unit testing JavaScript, I recently asked this question myself at Stack Overflow (and if you’re not familiar with Stack Overflow and the Stack Exchange Network, I recommend you should; it is a great place to get answers for technical problems), and ended up using Jasmine. I’m skeptical of the “BDD” thing, but it seems a perfectly fine tool for unit testing. I’m using it (example) to test logic inside the browser — that is, I load a web page which runs the tests and becomes the report of results — but I understand it can also be used from a “headless” environment of your choice.
Unfortunately, I do Javascript using notepad, so I can’t really help you on tools.
I’d usually just write a “UnitTest” function and put my code there. From the browser, you can directly invoke a function, so you’d just do “UnitTest();” or “UnitTest_Module8();” and have them display results in the form of alerts or such.
Another useful technique is to add a label or textbox to the HTML, and then keep running debug information there, for tracking variable that you suspect might be getting set wrong. I’d also often scatter alerts through my code, just so I could tell “Okay, it has reached this point in the code” or “Okay, at this point, x=5″
IMO, the major power of javascript is the ability to run commands “on the fly” from the browser itself, and the ability to very quickly modify the source code and re-run the program.