Page is a not externally linkable
Fotiman - 2:35 pm on Oct 21, 2010 (gmt 0)
I'm going to go ahead and disagree with just about everything JAB Creations just said. :)
Use XHTML as actual XHTML, which means serving pages as application/xhtml+xml so you can't use document.write as you're not supposed to in the first place; use alert() for debugging.
1. IE browsers don't support support pages served as application/xhtml+xml without some tricks, so right away you'd be alienating a huge customer base. In addition, *most* websites are not extending the HTML set of tags, which means that an XHTML doctype is not appropriate, and an HTML doctype is. This does not really apply to learning JavaScript, though.
2. There's no rule that says you're "not supposed to use it [document.write] in the first place", though I agree that best practice is to avoid it as it is timing related (if document.write executes after your page has finished loading, it will replace the entire document). There are better alternatives to document.write.
3. alert() is one way to debug an application, but there are also some other alternatives that don't block processing. For example, creating your own logging mechanism to output to the page or using something like the Yahoo UI Library's logging. Another option still is using Firebug to step through your code (there are other JavaScript debuggers available too).
Don't use innerHTML, it's total junk and is completely unreliable; stick to using the DOM and all the element methods that for some reason refer to elements as nodes (just how amateurs refer to elements as tags).
innerHTML is totally reliable and is used by many of the top JavaScript frameworks. Claiming that it's junk and unreliable is, quite frankly, totally wrong. I'm not opposed to using DOM methods, but there is nothing wrong with using innerHTML.
Don't put scripts in the body element, put them in the head element; people will say that hurts performance, it doesn't but what it does do is NOT allow lazy coding practices.
Again, I disagree. The best place for scripts is at the end of the document just before the closing </body> tag. While JavaScript files are being downloaded and processed, the browser blocks all other resources from being downloaded. Placing the scripts at the end of the file allow the browser to download other resources in parallel, thereby giving a more responsive feeling experience to the end user. In addition, placing scripts in the <head> does not prevent lazy coding practices. I think JAB's argument is that it prevents the use of document.write, but it really doesn't. For performance reasons, place scripts just before closing </body> tag.
Don't use frameworks EVER. They don't work when things get mission critical, they're wholly unreliable, and they easily alienate dial-up users who have more market share then IE6 in the US/UK/etc.
I disagree. Frameworks today are small. The production version of jQuery 1.4.3 is 26 KB. The YUI2 Core (which provides excellent DOM and Event utilities) is 13 KB. On a 56K dialup connection, that's about 3.7 seconds and 1.9 seconds respectively (for the initial download... after that the browser can cache them). And saying they don't work for mission critical applications is just plain silly. There are a ton of applications that use frameworks today with no problem. They save time, and often provide the functionality you need with a smaller footprint than if you develop that functionality yourself (because they've gone through several iterations of optimization).