Web Widgets

Read/Write Web posts a good survey piece on web widgets. They’re mini-applications that add functionality to your site from another site.

Traditionally, if you needed a particular tool, you’d download it and run it on your PC. Then the web came along, and now you can edit images, cut video, and of course work on your documents and spreadsheets all within your web browser. Great! But all those functions are on different sites. What if you want to use some of those advanced functions on your own site (like your blog)?

Enter widgets. They allow your blog to call up functions (and possibly content) from another web site using standard web code. That’s what allows YouTube clips to appear in blog posts. But that’s just the beginning, as Read/Write Web explains.

At the other end of the spectrum from widgets is SaaS. Enterprise applications are now being delivered not in a shrink-wrapped box for you to install on your big local server, but in real time over the web. Of course you pay big bucks for this, but it can actually be cheaper than maintaining the software and local server. As these services mature, it makes more and more sense from an engineering perspective — why solve a problem every time it occurs when you can solve it once, centrally?

As computing power gets cheaper, it becomes more efficient for medium and large web apps to provide widget-like integration with users’ own sites. You probably wouldn’t want mission-critical data out on a free server (although a lot of people are putting sensitive files up on Google Apps). But what if you could invoke another site’s enterprise-level functionality, apply it to your local data, and mash it together on your web site?

Why would anyone give away such critical software? The same reason that sites give away widget functionality now: because user participation (and the resultant market share) is more valuable than license sales. Just as “You’re a Nobody Unless Your Name Googles Well,” your web app is a nobody unless users can access it freely, as in freedom and as in beer. (See my previous post; same concept, different context.)

While the paid SaaS model makes sense as a transition from the buying-software-in-a-box model, license fees and proprietary APIs only hinder the success of web services. We may end up with something that much more closely resembles YouTube when the widgets grow up.