So, I've been taking Udacity's "HTML5 Game Development" course, and I have some first impressions.
First, Udacity. It's a "free, online courseware" thing that grew out of some private money thrown at Stanford University. Wikipedia gives great article here. But it's free. And, sure, maybe there are classes that would be of more use to me than this one, but I've never developed games and having a solid grounding of high-frame-rate, canvas-oriented web technologies is probably not a bad thing for someone in my shoes to have.
But while I've never developed games, I have developed a metric buttload of HTML applications, helping to sell everything from movies to gene sequencers to, today, textbooks. And I have some very (er, very) strong opinions about the quality of code I've seen in the Udacity quizzes. And that opinion is: the code styling taught Udacity "HTML5 Game Development" is not just bad, it's actively harmful to developers.
First, the basics: the code examples make heavy use of variables being declared before being defined. The functions will be defined "out of order"; functions will often refer to functions defined later in the code. This works fine because everything's in a single scope and function names are defined as scope variables, "hoisted" to the top of the existing scope for declaration. FuncA() calls funcB() before funcB() is defined, but it works the outer scope is run before the inner scopes. This is an artificial condition of Udacity's use of Jasmine to "test" the user's code, and if new programmers get in the habit of assuming it's always true then, later, when the code base is big and hairy and complicated, name collision, undefined code blocks, and heartbreak are sure to follow.
But the worst was the last example: loading animation frames. It was bad because it assumed that all the frames would be loaded before your animation line was hit; there was no waiting to ensure that all nineteen images had been loaded before triggering the animation. You merrily started 19 loads and fell immediately into the animation loop. (I'm not going to complain too loudly about how the code demands that certain features go in exactly the right named blocks of your code: if I want to put my animation in an anonymous function in the animate() function, rather than in the setup() function where Jasmine expects to find it, that's my call, but...) The correct technique is to create a callback with an enclosure that counts the number of frames loaded, and when the number of frames completed equals the number of assets, then you trigger the next the phase. I did this and didn't get any points off, fortunately. Udacity's code example only "works" because it's likely most new developers will get it wrong the first few times, and by the time it's actually working the images will be in the cache, and network load delays won't be an issue.
A student who gets it right the first time is gonna get a mess.
I do hope that a more formal introduction to large-scale project management is in the works for this. Otherwise, all Udacity's "HTML5 Game Development" class is going to produce is a lot of script kiddies who know just enough to make fools of themselves.