Widgets harmful or not?

Jeremy Zawodny of Yahoo recently wrote about "Javascript widgets considered harmful" where he talks about why Javascript widgets and badges have annoyed him. He calls out several good points about the current crop of widgets out there right now. This is a valuable discussion and probably has happened several times in the past ten years - procedural code .vs. declarative, server-side generated content .vs. client-side includes, security of client scripting, etc. Here are his objections (you should read the comments there as well) Since I've just recently implemented a fairly nifty widget at Others Online, I thought I'd share my thoughts.

1. They are a hack. Well, I don't agree. Javascript, DHTML and DOM access were designed for programmatic access and extreme flexibility, just this sort of functionality. However, I do believe there are 'better' or more 'appropriate' alternatives, such as client-side includes and server-side includes. But browsers aren't good at client-side includes (IFRAME, <object type='text/html>, etc) and not all blogging systems provide easy access to server side includes. Once the vendors of both notice how  white-hot the demand for widgets are, they'll respond. In the meantime, people are making their own solution. That's a good thing.
2. Search engines - meaning the content of the widget isn't available to spiders or included in Web search engines. This is a cost/benefit decision each author can make themselves and Jeremy - working at Yahoo - naturally favors inclusion in a Web search index. Personally, I do also, but until the browser vendors make client-side includes much easier there aren't many alternatives. Sure, the search engine vendors could evaluate the Javascript, but come on - really?
3. Site performance. This one I didn't understand until I read some of the comments. A Javascript snippet that is pasted into the middle of an HTML file will be evaluated by the browser before the following HTML is displayed. If the Javascript does something slow, like access the network, then the Web page below that Javascript snippet will be delayed. I noticed this when developing the Others Online widget and did two things to not get in the way of the page rendering - use setTimeout to perform the widget display later (after the page is fully loaded) and make sure the data underlying the widget is served very fast and is very cachable. The asynchronous rendering on the client does not use document.write(), but uses getElementById() and element.innerHTML. If the element doesn't exist when the widget first runs, it actually does use document.write() to create a stub element, which is then filled in later. As for caching, it only took a few hours to check the relevant specs and test out the correct HTTP headers to use to get caching to work. I also use JSON for data delivery rather than XML and XmlHttpRequest, but I haven't found XmlHttpRequest to be any slower than a JSON include.
4. Hard to skin. This I have to disagree with. I knew what I wanted our widget to do - adapt to the ambient display. The perfect technology is CSS so this is extremely easy to achieve. I think what Jeremy was getting at is that programmers that build widgets don't understand how to use CSS effectively, or just don't take the time to learn. I think CSS is wicked cool and everyone remotely involved with widgets and HTML really needs to understand how to apply CSS to any UI they are building. There are a few issues using CSS with widgets. For example, a page author wants to simply cut/paste the widget code in one place - they don't want to also add style definitions or link to an external CSS stylesheet. This means widget developers effectively cannot use 'class' attribute. Usually a minor annoyance, but for pseudo-element selectors like a:hover, there is no alternative. Widget authors simply can't control those styles. There is a CSS3 approach, but no browser supports it. One tip I have for designers - don't use pixels for dimensions, use points or EMs. This scales better when the page author chooses different fonts and sizes, and it also scales when the reader increases the font size - which I do all the time, because I sit so far away from the monitor because my cat insists on sleeping in my lap while I code.
5. They're not secure. This I agree with. Using client side includes (such as IFRAME tags) is more secure. However, the Others Online widget has a legitimate need to access the page content - it can extract meaning from the page and find relevant people based on that context. I would be perfectly happy if the browser makers supported an attribute on the script tag that would specify the permissions to be read-only. That way the widget could be a client-side include or IFRAME yet still have access to content of the including page.
6. Don't work everywhere. True, but what does? When there are solutions for the security concerns, then there will be broader support from blog service providers and MySpace style sites.