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.
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.
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).
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.
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).