For a long time now I've been meaning to write about the seemingly ubiquitous JavaScript Badges/Widgets/Thingies that you see on blogs and web sites everywhere. Heck, I even have one on my site right now (over there--on the right).

But you'll notice that I have only one (MyBlogLog). It's one more than I'd like to have, but it's quite compelling. These JavaScript and, to a lesser degree, Flash droppings have annoyed me for a long time.


  1. They're a hack. With all the talk of how the web has "become writable" with advent of blogs and self-publishing tools, you'd think that we'd have a better way of getting third party content on to our sites. Given that an overwhelming number of sites that are likely running PHP or some other "dynamic" hosting setup, these least common denominator solutions just feel wrong. (This could easily be followed by a rant on problems with the spread of web services and RSS.)
  2. Search engines. Unlike most other forms of on-line publishing, these little gems convey little if any information to search engines. In the old days (meaning "just a few years ago"), we used to actually link to things we found interesting. Search engines were able to mine that aggregate data to help make decisions about popularity and importance. But when it comes to search, these JavaScript and/or Flash creations might as well be invisible. They benefit individual readers but really don't contribute to the web in general. They're little data islands.
  3. Site performance. Look no further than Mike Arrington's TechCrunch Down. Iím Pissed. to get a sense of what can happen. "...we have a lot of third party widgets, ads and analytics apps running on the site. They are often the cause for slow load times."
  4. Hard to skin. Seriously. The vast majority of people using them can't figure out how (or don't even realize it's possible) to modify their appearance. The result is that those who use lots of them end up with sites that look reminiscent of MySpace. I'm not saying that I don't enjoy Fred Wilson's blog (note also its loading time), but let's just say I'm glad I read it in an RSS aggregator most of the time. (No offense, Fred. I know you like to experiment a lot with these things. I get that.)
  5. They're not secure. Every time you drop a new JavaScript include on your site, you're giving a third party access to a wealth of information about your site visitors, your content, their clicks, and so on. They can modify the page, snoop on your users, re-write your links, and do all sorts of nasty stuff. Granted, this is rare in practice, but how do you really know that?
  6. Don't work everywhere. People love the simplicity of "paste this in and you're done" but the reality is that these things don't work everywhere. Larger sites, MySpace being the canonical example, recognize the security and performance problems associated with these things and have banned them outright.

If it's not obvious by now, I use them very sparingly on my site. I think long and hard about whether it's really worth it before I get yet another party involved in the performance and security of my site.

Anyway, I just waned to get that off my chest and have something I could point to when I object to these in the future. But at the same time, I also realize that these things are here to stay and they're an increasingly important part of Yahoo's business. That doesn't mean I can't object on semi-elitist technical grounds, right?

What I'd really like to see is this: For every badge/widget/gadget out there, I'd like to see a discoverable API that allows me to get the same data via a simple REST based API that emits RSS (with extensions where it makes sense). The link to get that data should be rendered on the badge. Think of it as a "View Source" for badges.

Then we could plug the data into Pipes to do all sorts of intersting things.

Now it's your turn to call me an idiot. Or a hypocrite for using a JavaScript based advertising system (or embedding YouTube videos) that could be considered a JavaScript widget (using a somewhat liberal notion of "widget"). You have my permission. :-)

Posted by jzawodn at February 12, 2007 07:54 AM

Reader Comments
# Eran Sandler said:

The problem with a "view source for widgets" is that for most users it gives little to no value (and therefore little to no incentive for widgets providers)., for example, forces people to pass their widgets some type of certification before everyone can use it (although their widgets are PHP code and not JavaScript which, potentially can make even more bad things than a JavaScript).

The certification can simply be a site that verified that these things do exactly what they say they do.

Or, all you really need is FireBug and you have a "view source" to everything a widget does :-)

on February 12, 2007 08:11 AM
# Toni said:

I agree with you Jeremy. Given the rapid rise of widgets as a new type of distribution mechanism, this is a problem we have to deal with.

Eran Sandler: you are correct in that we do not allow abitrary embeds (javascript or otherwise) on It's exactly for the security and performance reasons that Jeremy outlines. Our solution has been to whitelist embed codes that our users ask for and that we've had a chance to verify for security or performance issues.

on February 12, 2007 08:48 AM
# jr said:

I absolutely agree that "badges" are a weakpoint. Of the two I host, only one (flickr) is external to my blog, and even that is forced to the bottom of the page. I rolled my own plugin that has caching for when the service is down.

The problem/reason that sites promote badges are that they're little ads for those services. Likewise, the vast majority of folks out there don't know or don't want to learn how to roll their own service, use a complicated "plug-in" or do anything more than cut and paste so that they don't break the internet.

But yeah, I don't use a service unless there's an API that lets my site continue to work.

on February 12, 2007 08:58 AM
# Don MacAskill said:

Hey Jeremy,

I agree almost completely, with one exception:

I think your second point, the Search Engines one, isn't the fault of the widget, it's the fault of the search engines themselves. With nearly every web app getting richer and more interactive through the use of scripting, to the point that many of them don't contain HTML pages at all, it's the search engine's job to figure out how to parse and index those things.

I'm not saying this is an easy job, but it's fairly easy to see that the future of the web is going to be apps in which much of the content is scripted, and if the engines don't figure out how to process it, we're going to start losing the ability to search some of the most important data on the web.

I'd love to see "view source" for widgets, though, and I'm in the position to make that happen for SmugMug. We already publish our API docs, have dozens of different API feeds, etc. How would you like the link displayed, formatted, and where should it link to? The docs? Some discovery mechanism ala Atom?


on February 12, 2007 09:01 AM
# Pooya Karimian said:

Good topic to think about. It could also be that we need a more powerful IFRAME like tag. A security context enforced by browser for widgets which contains server side content but from a different server than the web page itself. But something that also integrates easily and transparently with pages, unlike IFRAME. I'm not sure but there could be already ways to hack the current IFRAME tags to do this. Well and your solution is to rely on trusted sites like Yahoo to filter out the data and then we include those on our site.

on February 12, 2007 09:26 AM
# Corey Gilmore said:

Fred's page is insane - Firebug shows 213 requests and 1.71 MB of content loaded with only half of it from cache.

There is no reason someone couldn't write a wrapper in their language of choice that they could host with their site and would cache the output of the widget or badge, other than they shouldn't have to. Most of the problems I have aren't from the badges though, but any attempt at monetization, especially from sites using Atlas (

on February 12, 2007 10:17 AM
# Brian Donovan said:

What's compelling about MyBlogLog other than the fact that it was purchased by Yahoo?

If I've missed a post on this point in the past, I apologize. You can just post a link for me and I'll check it out.

on February 12, 2007 11:23 AM
# Andreas Gohr said:

From what I understand, there is a way to include the MyBlogLog widget without JavaScript. It's done for a Wordpress plugin I found at [1]

I hadn't the time yet to dig into it but it looks promising.


on February 12, 2007 11:31 AM
# said:

I agree with your point about the badges, it really slows down my site and it breaks my xhtml compliance. Hopefully these problems will disappear in time as network response times improve.

Whatever happened to the popularity of blazingly fast web sites of web 1.0? Thankfully I keep a web server hidden away running Open BSD, and it feels like therapy compared to the bloatware that goes into web servers these days. :)

on February 12, 2007 11:47 AM
# Dave McClure said:

don't know if i agree/disagree just yet... i'm a fan of add-ins/widgets/etc, and i think they provide a good bit of value, but i'd probably agree there's some downside & risks.

more importantly tho, you missed a HUGE opportunity to title this post "We Don' Need No STEENKIN' Badges!". big mistake.

on February 12, 2007 12:15 PM
# Jeremy Zawodny said:

Heh, good point Dave. I'll have to do better about post titles. :-)

on February 12, 2007 12:22 PM
# Joe Duck said:

>>discoverable API that allows me to get the same data via a simple REST based API that emits RSS<<<

Wow, this sounds interesting and positive. Wouldn't this allow you to build super combo-gadgets that would have any of the features from several gadgets/widgets/websites?

I'd be interested in how this would affect, for example, MyBlogLog as a community.

At a relatives house I was struck by how he had totally gadgetized his (Apple) desktop as a sort of instrument panel for weather/flights/pix/etc. Clearly this approach will become more common and I think may become dominant in the next few years.

on February 12, 2007 12:25 PM
# Scott Rafer said:

@Don -- Why is indexing the individual pages/apps even the right solution at all? The high-value widgets are the gateways into entire networks, which can interact with the search engines in their individual ways and point back to the individual pages in a distributed fashion.

on February 12, 2007 12:26 PM
# Mark said:


Just do what I do; a cron job that runs curl on the widget address every so often, saves the output, and just uses an include to display the content. I use a jsp include, but I'm sure you could do it in php as well. No relying upon third parties for your page display time performance, no annoying dns round trip times, everything just works.

on February 12, 2007 12:58 PM
# Ramin said:

Jeremy, I respectfully disagree with most of your points. The reasons are too long to post in a single comment. Sorry to link-whore, but I posted them on my own blog.

On preview: D'OH! Dave McClure beat me to the obvious punchline :-)

on February 12, 2007 01:14 PM
# adam said:

actually, mybloglog is one of the few 'widgets' i'll use because they have a non-javascript solution. for myspace and, they'll give you an image based html code that pulls an image that's generated on the fly. it's a very simple solution, albeit one that won't work for all types of widgets.

i think most people who beg for javascript widgets for every platform out there fail to realize #5. thank you for putting it so clearly.

on February 12, 2007 01:14 PM
# Dossy Shiobara said:

Jeremy, you're blaming the symptom, not the cause. If modern web browsers could load JS requests asynchronously and render its results on-demand, it would be a non-issue. Slow responding (and performing) JS would simply cause the individual widgets to delay and/or time out.

The problem is when a web page's design is done such that the page won't render until the JS is requested, retrieved and executed. That's not a JavaScript problem. It's a design and implementation problem.

on February 12, 2007 01:15 PM
# Jeremy Zawodny said:


You're right. I am really bitching more about JavaScript than widgets. Hmm. But some of the complaints are still there. I'd like skinning that average people get, the APIs, etc.

on February 12, 2007 01:26 PM
# Ramin said:

Oops. Another comment engine eating link tags. Here's another try:

Talk about pet peeves... :-)

on February 12, 2007 01:30 PM
# Jeremy Zawodny said:

My pet peve is people who DON'T read the BOLD "No HTML tags, sorry." note that's part of the comment box label and then bitch about their tags getting eaten. :-)

on February 12, 2007 01:33 PM
# Scott Rafer said:

@ Dossy/Jeremy, I've often wondered what the browsing experience would be like with a greasemonkey script that added a "defer" to all JS. I don't think it would quite work right, but it would be instructive.

on February 12, 2007 01:58 PM
# Jope said:

Matt and the crew at have the same take as you do, especially on security, as javascript can't be used in our blogs.

Thruth is, you don't miss much by not getting javascript, and they have even figured out clever ways to imbed YouTube videos and other stuff without the user copying in any js code...

on February 12, 2007 02:22 PM
# Ed Eliot said:

The main problem with these JS badges is that they rely on adding a script tag at the point at which you want the badge to appear in the page. Browsers block page loading whilst downloading JS so any slowness in these badges stalls page loading, in the worst case almost indefinitely. What's really needed is for browsers to implement a script timeout attribute so badly behaved badges (and sometimes more importantly, adverts) are terminated if they take to along to appear. Interestingly Opera, unlike the other major browsers, does kill scripts after a few seconds so the impact is greatly reduced.

Of course badges could be rewritten so that you include them at the bottom of the page. That way most of the page would have loaded before any badge scripts were reached and you could then use DOM methods to write the badge into/or after and existing container on the page. Definitely not as easy and some rethinking required for those badges which use document.write but definitely worth the effort.

Personally I'm in favour of writing server side versions which implement caching. Most badges are pretty easy to reproduce server side if the raw data behind them is exposed via a URL and it's a good chance to clean up the sometimes flaky front-end code (not pointing any fingers ;-)). I recently wrote a server side version of the badge - with caching it's much faster and also kinder to the servers than the original -

on February 12, 2007 02:26 PM
# Jeremy Toeman said:

I agree with you in principle, but what about the problems with fraud.

For example, Feedburner displays number of subscribers. I can look at the badge being used, and 100% verify it's a true count. If a user makes their own badge, how do I know it's really hooked up to their blog's data set?

I'm advising a company right now on their badge implementation, and we don't want to go JS, but can't figure out any other methods for "proving" the data point.


on February 12, 2007 02:48 PM
# Joshua said:

" They benefit individual readers but really don't contribute to the web in general."

Um.... so what exactly is the web for? I think I'll design my site for readers, not for spiders.

on February 12, 2007 03:16 PM
# adam said:

Jeremy, I understand where you're coming from, but think about the alternative, someone write a PHP blog system, it doesn't thread requests, it doesn't cache, it sends the requests and gets content back one at a time.

- how slow would this be for 5 widgets to get the content back? The php page might not be able to return any html?
- what happens when a service is down or has an error, it could prevent the entire page from loading or at least force the user to wait 1-2 minutes

I recognize good caching methods, and smart CSS and design can really reduce the speed that things load. But unless we go back to frames or iframes or invent something new, javascript seems like one of the better ways to do these things.

- adam

on February 12, 2007 03:24 PM
# Jeremy Zawodny said:

I actually think that advertising and/or reader metrics is a speical case. Again, JS isn't the ideal solution, but it works pretty well in practice.

on February 12, 2007 03:29 PM
# Nik Cubrilovic said:

great post, same thoughts have been in my mind esp. since the TC frakas.. the best point is re: security - does somebody need to exploit this before ppl realize what embedding actually means

one part solution is to use IFRAME's around third-party content, since the content then sits within its own container (both security and pageload)

second part is for said developers to learn Content-Cache: and Last-Modified:

third part is rel='prefetch'

fourth part is faaaaastr serving

on February 12, 2007 03:34 PM
# said:

Considered Harmful Considered Harmful.

Please think of the children and come up with something better. That phrase has become so trite and overused that it has no shock value anymore.

on February 12, 2007 05:22 PM
# Jeremy Zawodny said:

That's EXACTLY why I picked the title I did... :-)

on February 12, 2007 05:23 PM
# Gary Johnson said:

You say Why?

Numbered Bullets how trite.

Its a Hack?
Don't work everywhere? What does?

What I would like to see? REST with RSS, is that not someone's HACK?

on February 12, 2007 05:51 PM
# Philipp Lenssen said:

I agree with most of your analysis of the problems (that's why I add none of these at my blog). I'll add another problem: some of these widgets aren't even adding value in the first place, they just *look* cool. And that's why I see a problem with your proposed solution: take away their cool looks by reducing it to a (well-working, skinnable) RSS output, and you've taken away their instant cool looks. You know, tag clouds, fading images, animations, gadgety lil boxes. All this is part of their appeal.

on February 12, 2007 06:03 PM
# said:

I particularly hate these widgets because they render blogs useless on mobile devices. Mobile data is expensive and more bloat doesn't help.

Although I should say that I wrote a crappy widget way back when, so I'm hardly innocent.

on February 12, 2007 07:02 PM
# Robyn Tippins said:

I have to admit I spelled your name wrong once so I almost killed my comment. I do the same thing with addition comments, so fault is with the user.

First, Amen to Dossy. Now, I have always been a widget user, but until I saw our Web 2.0 TDK I had not taken the time to really learn about the backend of a javascript widget.

I had no idea of the safety issues, only that often they broke on my own blog when the javascript was no longer in communication with the originating server.

I paired down my own widget use to a handful, just for real estate reasons, but I just can't give them up altogether. I hope more widget purveyors offer up an html solution. I'm sure the simple fact that everyone wants their jank on MySpace will speed that up. Can you believe we will actually have a reason to thank MySpace? ;)

on February 12, 2007 08:23 PM
# Paul Stamatiou said:

Wow, the homepage of A VC loaded 1.68MB! It took 16 seconds to load on my side, but 812kB of that was from my cache, so I think it's safe to assume a new visitor would be waiting for the greater part of a minute waiting for his site to load. Anyone remember that study a while back stating that if a site takes more than 4 seconds to respond/load, people will close it?

on February 12, 2007 08:24 PM
# Eric Miraglia said:

I want to reiterate what Ed says in his response ( Having server-side cachable versions of relevant badges revives their ROI quotient. I like the badging we have on the YUI website (, but I wouldn't do it if I didn't have Ed's solution in place. For the vast majority of users, that badge has no performance impact. And it still shows up with the most recent cached data even if is offline. I agree wholeheartedly that badges are generally harmful if implemented in the standard fashion; but if badge providers take a page from Ed's book, I think we can be much more sensible as shoppers in that arena.

on February 12, 2007 11:31 PM
# Aditya Kuber said:

If JS and other such apps are useless to the growth of the web and if search engines cannot mine them for data, who's fault is it? As a blogger, i like the uses they offer and yes, i do want my site to be indexed in as much detail as possible, but shouldn't the search giants find a way around this? (And maybe make the scripts safer! :P)

on February 13, 2007 01:18 AM
# Rob said:

The sad part is in this web2.0ish world, with it's user generated content and social bookmarking, sharing their lives while trying to monetize their sites, without their widgets, badges and wotnots, most of them wouldn't actually have anything to say.

on February 13, 2007 03:17 AM
# PanMan said:

I wanted to respond, but Don MacAskill basically made my point: I build websites for visitors, not search engines. If they can be found, that's nice, but if search engines don't understand certain modern techniques, they are to blame, not the other way around.

on February 13, 2007 04:16 AM
# Ara Pehlivanian said:

You forgot to mention that most JavaScript badges use document.write() which is evil in and of itself, but worse still it doesn't work at all in sites served with the application/xhtml+xml MIME type (aka real XHTML pages).

Though, if you really must use them, I've written a fix ;)

on February 13, 2007 05:01 AM
# Doug K said:

I ultimately feel that MySpace removed javascript support because they were unwilling or incapable of implementing its usage correctly not because of the threat it caused. If you read how MySpace operates they are in a constant reactionary mode of operation. This makes it very difficult for them to plan how they will be able to handle javascript (or any other component of their tech) and instead of limiting how it is used they limit it completely. They took the easy way out and harmed their users by restricting what they could do on their pages.

Ultimately, MySpace controls the pages that they present. In this case they have been heavy handed. If I can't even link to another page from a widget then there is a problem. They are breaking the model of the Internet and to your point, if javascript is the cause of MySpace performance problems then there is a problem because javascript is executed on the client and widgets are fed from other sites. I think MySpace performance problems are related more to their rapid growth and their choice of architecture and technology. If widgets are causing poor performance it is the fault of the widget creators/hosters and it would make more sense for MySpace to limit widgets if their performance was god-awful or inner working harmful rather then punish everyone.

Javascript and Flash a hack? That's an interesting thought. The problem here is the incompatible implementations of javascript in browsers, not javascript itself. This makes javascript appear hackish because developers have to jump through hoops to get it to work properly.

Search engines can't search it because the implementation of the technology has gotten ahead of them. To say widgets are no good because you can't find the data in search engines points more to a problem with search engines rather then widgets.

Site performance is always effected by bad decisions. Creating a site based exclusively on flash will cause performance problems. Placing large pictures all over your site will effect performance. Just because there are widget junkies out there who use every widget available does not mean widgets are not viable. When Fred Wilson's site was changed to reload his content first and then the widgets there was a great increase in the 'perceived' performance of the page. Design decisions weigh highly in this equation. Poor design of sites does not mean widgets are bad.

Hard to skin lies on the widget makers backs and as the tech matures you will see this become easier.

Not secure...yes that's true but you as a site owner have to take on some of the responsibility here and know what you are getting when you put a widget on your site. If you ask the widget creator for this information and they are not forthcoming then don't do business with them. Remember that security of your site should be your responsibility, not someone else's (unless you pay them, of course, and ultimately it is still yours).

Don't work anywhere is more the result of inconsistent implementations of tech (different IE and Firefox implementations/not following standards of javascript) and decisions of companies to limit functionality (usually bad decisions), not because of widgets themselves. To say that widgets suck because a site doesn't let you implement them reflects negatively on the site, not the widget.

As to what you would like to see, here I can't agree more! Any widget creator that who isn't exposing their data for the world to use is making a big mistake. If I create a widget I will give you that data in as many ways as I possibly can and REST/RSS are fantastic ways to do this. The more used a companies data is the more valuable that company becomes.

Finally, Pipes is Cool!

on February 13, 2007 08:04 AM
# JJ said:

Re #2: web engines should adapt to websites, not the other way round. How difficult is it to embed a JS interpreter within the engine?

on February 13, 2007 09:15 AM
# Mike D said:

Thanks for raising these points and starting this discussion. I just finished a fairly nifty widget at Others Online so your post was extremely timely. Widget are hot right now but it's easy for folks to forget the basics. I just hope that a real solution for what I consider a client-side include approach is forthcoming from browser vendors.
I've replied more in-depth here:

on February 13, 2007 10:14 AM
# Scott Lawton said:

iFrame is nice in theory, but doesn't work for widgets that have variable dimensions (e.g. show n results, where the text of each isn't fixed). Granted this is a special case, but it's a useful one.

on February 13, 2007 11:40 AM
# Amit Patel said:

At some point, object-oriented programming became common, and people starting putting code and data together. Once you do that it's very hard to do anything with that data. Then we had RSS, Atom, and other forms of XML teaching us that the data is much more valuable if you can separate data from code. And now we have Javascript and Flash widgets that tie data and code together again, making the data far less useful.

I avoid the widgets on my site, because they slow things down, have security issues, and tie together code and data.

I'd probably use widgets if the browser model let me put in the code and get the data from elsewhere. I think JSON is a good step, but I need a way to load only JSON (not arbitrary Javascript) from a third party site, and browsers don't support that (yet). The prominence of widgets might even encourage browser vendors to build technology that allows for easier, safer, and more flexible widgets.

on February 13, 2007 06:43 PM
# Ori said:


You make some valid points, but these could be applied to all end-user software (how many times have you installed something that didn't work right, had bugs, slowed down you machine, etc?)
I've answered in depth on our blog:

on February 14, 2007 03:09 AM
# Andy Beard said:

Jeremy you are an idiot (I was just following instructions)

Seriously in response to some of the questions raised by previous commenters.

MyBlogLog gives social proof, and encourages subscriptions

Long term the service can potentially become a hub for all kinds of online activities. there are good reasons the Yahoo team are so excited about it.

Here is a tip - if someone wrote a good "idiots guide" to using curl to cache widgets and improve performance, they are going to get a huge amount of link love.

Ideally make it a Wordpress plugin with a nice interface to store bits of widget code, and create tokens / function calls that can be added to a template or post.

You will probably find less than 1% of Wordpress users have heard of "curl" and even less have the knowledge to use it.

on February 14, 2007 05:36 AM
# Ed Eliot said:

After posting yesterday I thought a bit more about the problem last night and collected my thoughts in a post on my site ( which considers possible improvements to JavaScript badges and PHP code to use as the basis of server-side badge versions.

on February 14, 2007 06:26 AM
# Jeremy Zawodny said:


Thanks. It's about time that someone confirmed my idiot status. :-)

on February 14, 2007 07:05 AM
# Alex Iskold said:


You bring up a lot of good points. Widgets, though, are not going to go away, and they are quite useful despite all the things that you mentioned.

I do like the idea of having an API, and the first thing that comes to my mind is that this has been done already before. Think Java Servlets or Applets or even Beans. The point is what we need is container-based technology to host widgets. This is exactly what companies like Widgetbox and ClearSpring and others are pushing for.

We then can adopt a standard API for hosting, rendering and having widgets interact with their environment. Further to your point. RSS is not going to be comprehensive as it is not a really a structured data format. What we need is XML-based API that could be transformed to RSS, but also could be richer. We need to then also facilitate the exchange of information between the widgets on the page so that they can be more environment aware.

Finally, regarding the speed issue. This is the fundamental problem with our current client web technologies - javascript and flash just do not seem to work well when there is a lot of each on the page. This is something that I think will evolve and will get better.


on February 14, 2007 07:47 AM
# Sean O'Donnell said:

I tried the MyBlogLog widget on my site for a bit, but it seemed more of a security risk for (3rd-party tracking of) my visitors than anything my web site would benefit from, so I removed it.

MyBlogLog is an ok service and all, but I'd much rather use an XML REST/SOAP API, than include some nasty javascript 'widget'.

on February 14, 2007 03:29 PM
# Aaron Shear said:

Capacity and growth to scale is always a problem for widgets like these. How can a small entity come out with a cool widget and a dedicated web server and expect to grow? If it becomes explosively popular, it will affect all of the sites using it.

Next is the question of caching content, but is that a logical step when a widget may only be good for its freshness.

Just random thoughts.

on February 15, 2007 01:56 PM
# Rae said:

I won't put a widget on my site if I can't skin it to blend seamlessly. End of story. Luckily, mybloglog is totally smackable in that regards... and people like graywolf made niftier, cooler versions than those available on the site and graciously allow people like me to use them on our blogs. :P

on February 18, 2007 08:13 PM
# Jeremy Zawodny said:

Very nice, Rae.

For anyone wondering, look here:

on February 18, 2007 08:28 PM
# Scott Cliburn said:

I agree with statements about not putting widgets/gadgets or alike on my personal sites. I will however bombard sites that I personalize (myspace, google) etc with anything and everything I like.

If I can't skin it or have something similar to where I'm posting it, it don't happen.

I'm creating a few widgets/gadgets for different purposes and have gone to the extent of starting the framework for the alternate provisions of data.

In regards to creating a widget in a dynamic language like PHP/ASP, well right now thats not feasible either. All you do is create a new support call for why a users mimetypes don't support that language, or different syntax issues.

on February 21, 2007 02:57 PM
# said:

The AIM bot is behaving strangely right now. Looks like somethingís going on over at AOL. The bot is always appearing online, even when we attempt to bring it offline. And it is always replying with a message about being too busy to handle requests ó a message that we didnít create.

Weíve notified AOL of the problem, but as today is the Independence Day holiday here in the US, we donít expect any action on their part until tomorrow.

on July 28, 2007 03:25 AM
Disclaimer: The opinions expressed here are mine and mine alone. My current, past, or previous employers are not responsible for what I write here, the comments left by others, or the photos I may share. If you have questions, please contact me. Also, I am not a journalist or reporter. Don't "pitch" me.


Privacy: I do not share or publish the email addresses or IP addresses of anyone posting a comment here without consent. However, I do reserve the right to remove comments that are spammy, off-topic, or otherwise unsuitable based on my comment policy. In a few cases, I may leave spammy comments but remove any URLs they contain.