Components vs. Widgets (or: Contextual Agnosticism)

When demonstrating our widget platform (WebWidgetry(tm) and MashupStudio(tm)), one of the first things most people ask me is, "what do you guys view as the definition of 'widget'?"

In another post of mine (Widgets are Applications without Boundaries), I offer a couple of very quick and dirty rules to answer that question. Here I will dive (however briefly) into one of those qualifiers while talking about the difference between the term 'component' and the term 'widget'.

Firstly, yes I will admit that in many ways the two terms are interchangeable (especially based on my criteria as outlined in the above referenced post). Both terms describe an encapsulated piece of functionality designed for reuse in various contexts. But I would say that there is enough of a differentiation to warrant the existence of a word such as 'widget', as buzzword-ish as it may be.

To me, the difference is this: a component is authored against a known target execution environment, therefore while the context it is consumed in may change based on the application, the range of possible contexts is limited to only those that apply to that target environment (java, .NET, php, etc...). For example, you have a favorite suite of UI components for X language or Y platform. In order to be consumed across execution environments, the code must be ported over, and in many cases it is not feasible to consume them in XYZ context therefore a hunt is begun for a comparable component that will fit.

A widget, if built upon what I view as a true "widget architecture", is authored either without regard to the potential context within which it may be consumed (i.e. with inherent support for consumption in arbitrary environments via UI rendering that adapts output based on the requesting agent/device and host environment, etc...), or in such a way that it could easily be extended or adapted for consumption in arbitrary contexts. The widget is responsible for pulling in its own required resources within whatever host environment it finds itself in.  This is abstract speak to some degree, in that the actual work of adapting a widget for consumption in a new context may or may not (in practice) end up being "easy". Also, it is still necessary in most cases to load some kind of "runtime" into the host environment first which will be responsible for managing the scores of widgets and orchestrating messages, etc...

But, what if the host environment is, say, the Internet, and the runtime is say, a platform for application development and deployment that exists as a series of connected services on said Internet? Widgets can be authored in many manners. XHTML and javascript can be a default pair of constructs to declare layout semantics and behavior, but widgets can also be authored with other technologies to render the UI and process behavior and interactivity... as long as there is a common way to express the widget's UI and behavioral interface to the runtime. A couple examples of this that I like are the Flex-Ajax bridge and Media Machine's Flux Player X3D-js bridge.

What I'm getting at is that something as micro as a "component" can not survive out in the wide open expanses of the "internets", at least not if surviving requires the component to be easily consumed/used under arbitrary conditions. The more macro "widget" on the other hand... well I guess I'll just leave the comparison here: widget is a wonderful word to describe a component that transcends traditional deployment limitations; one that has evolved beyond a component and can survive out there in the big, wide world's web.

Technorati Tags: widgets web2.0 web3.0 webwidgetry mashupstudio ryangahl nthpenguin