JavaScript Badges and Widgets Considered Harmful

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

Wordpress.com, 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 :-)

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 WordPress.com. 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.

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 del.icio.us 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.

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?

Don

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.

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 (atdmt.com).

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.

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.

[1] http://engtech.wordpress.com/2007/01/15/mybloglog-widget-for-wordpresscom-blogs-one-of-the-best-web-widgets-available/

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

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.

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

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

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

Jeremy,

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.

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

actually, mybloglog is one of the few 'widgets' i'll use because they have a non-javascript solution. for myspace and wordpress.com, 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.

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.

Dossy:

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.

Oops. Another comment engine eating link tags. Here's another try: http://ramin.wizen.com/2007/02/12/are-javascript-badges-really-bad/

Talk about pet peeves... :-)

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

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

Matt and the crew at wordpress.com 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...

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 del.icio.us badge - with caching it's much faster and also kinder to the del.icio.us servers than the original - http://www.ejeliot.com/blog/74

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.

Thoughts?

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

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

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.

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

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.

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

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?

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.

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.

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. http://www.intel.com/cd/ids/developer/asmo-na/eng/336424.htm

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? ;)

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?

I want to reiterate what Ed says in his response (http://jeremy.zawodny.com/blog/archives/008547.html#comment-34454): Having server-side cachable versions of relevant badges revives their ROI quotient. I like the del.icio.us badging we have on the YUI website (http://developer.yahoo.com/yui/), 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 del.icio.us 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.

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)

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.

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.

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

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!

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?

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.
PS
I've replied more in-depth here: http://blog.othersonline.com/2007/02/post.html

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.

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.

Jeremy,

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: http://www.musestorm.com/blog/?p=85

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.

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

Andy:

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

Jeremy,

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.

Alex

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

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.

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

Very nice, Rae.

For anyone wondering, look here: http://www.sugarrae.com/blog/

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.

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.http://www.yiqiei.cn

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.