Consider the Humble DIVlet

A lot of our customers have a big interest in widgets. They are seen as a simpler approach to the many attempts at working with portals and portlets that limited the capabilities of web applications more than they expanded them. We have an interest in web widgets too. LMN Solutions has been building modular web applications for a long time, and using a widget approach to do this makes sense.  To be clear here, a rough definition of a widget is some portion of the page in a web application which is provided by a different web application.  For example, the home page of the LMN Solutions website contains a Twitter widget to display our latest Tweets.  The HTML content of that portion of the page is brought in a via a JavaScript snippet in our web page that downloads to your web browser. The browser initiates a separate request to the Twitter web application and renders the response into the page. Other examples are contextual ad widgets that examine the content of the rest of the page and find ads relevant to that content.

Many of our competitors' interest and approach to widgets, however ,seems to often focus on defining complex frameworks by which to provide them.  Rather than take the widget provider's simple approach of creating a snippet of JavaScript that you drop into a DIV tag on your web page, our competitors obsess about providing frameworks by which the widgets interact, taking us back towards the bad old JSR-168 portlet days. There also are some more functional technologies here, like Microsoft Sharepoint, which allow Web Parts to be custom coded into that application framework.  What we don't see a great amount of support for, at the architectural level, is the simple approach that is so popular and useful on the real Internet.

One possible cause of this is that the technology of bringing in some web content from another application just doesn't have a good name. A few years ago, when we were engaged in a campaign to defeat another painful attempt to foist a JSR-168 portlet container upon customers that didn't need or want it, we hit upon the name DIVlet for the concept of "just putting some JavaScript in a div tag" and registered divlet.com. Giving the approach a name seemed to provide a level of comfort with the customers that helped them see the simplicity of that strategy. We even helped build some personalized DIVlet containers that would let the users drag them around the page for organization and persist the state- just like iGoogle! The world then seemed to moving in the right direction. Of course, this never lasts.  There are efforts afoot to "standardize" on various widget frameworks, to legislate great additional complexity for little marginal benefit.  I would ask those involved to consider the humble DIVlet.  It just works.