CLOSE ×
Get in Touch
Thank you for your interest! Please fill out the form below, and I will do my best to get back to you.

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form.

Introducing JSWidgets

Garth Henson
|
JavaScript
|
9 Mar 2011

I have been, for some time, working on a concept that would allow the average JavaScript user to create robust, interactive applications with ease. A daunting task, I know, but having tried to implement so many bloated libraries for simplistic interaction, I wanted to create a way for the beginning or average web developer to create advanced modules quickly. One of the biggest things I have noticed in recent years is the lack of attention given by many to the client side code structure. With this project, I hope to help educate developers a bit more in the necessity of code separation, documentation and reuse of code.

I have been asked if I’m guilty of reinventing the wheel, and it is possible that you may think so, but I feel this offers a level of uniqueness not found in a library this lightweight. In fact, the purpose of this library is not to be a solution to the need in and of itself, but rather it is intended to lay the groundwork for developers to quickly extend their own widgets and have them working in no time. While I am introducing this library in its infancy, I am already in the process of overhauling the template structure to leverage Underscore.js, the most lightweight and robust JavaScript template engine I’ve found to date.

The Problem

Many people are interested in having interactive portions of their website be self sustaining, whether that be from an automatic update script running or even via user events within the page. In order to have individual portions of the page be able to make requests modularly while still retaining their persistence within the DOM can be tricky, and though many have handled it quite well, even more have not. For instance, if you have a scoring algorithm for a fantasy football site that you want to be able to update in real time as the game progresses, how would you handle it? Further, how would you aggregate the 3rd party data and run your algorithm succinctly, updating it within its context on the page?

It is interaction such as this that have been performed well within sites like ESPN but not executed well by the average site. With JSWidgets, you can easily define a front-end widget to do just what you need.

The Solution

There is no such thing in life as a “solve-all” or universal solution, but I have attempted to target the most common challenging needs within the infrastructure of a website and build some common solutions to them within JSWidgets. By extending the BaseWidget object or one of the several core widgets included in the library, you can customize a solution that fits your exact need. There is even an HTML5Widget that checks and caches the most commonly used HTML5 elements for the current browser and allows you to write joint functionality to best present usability to your viewers based on their currently supported technologies.

By breaking down the needs into manageable chunks, we can easily extend and attack individual issues that can be used over and over again. The design of the library is such to encourage modular development: defining JavaScript objects that can be reused over and over within different contexts to solve a variety of like issues. From weather and maps to Twitter and Facebook, widgets can easily be created to display and manage any type of information. Additionally, by using the JSWidgets manager object, you can even have persistent data between the widgets on a page and have them render according to the data loaded by other existing widgets.

The Structure

Following a basic JavaScript inheritance pattern, any module can be declared by extending the BaseWidget (or any other existing widget) object. So, if we were going to create a weather widget based on HTML5’s geolocation, we could simply extend the HTML5Widget object like so:

We have defined two member methods: isSupported() which simply returns whether or not the browser supports the required geolocation and renderContent() which calls the parent updateContent() method to give the viewer a message about the render failure.

Since the HTML5Widget extends BaseWidget and does not override the constructor method, we can now create an HTML5WeatherWidget object and attach it to a div on our website by ID:

That’s all there is to it! Of course, there would be some implicit things happening within the structure of the markup and such, but you can read more about that in the documentation as time progresses. In the meantime, I’ll be working on refining and optimizing the code in order to get the best punch for the bandwidth.

Please feel free to send me questions, ideas and recommendations regarding the project. When the time gets a little closer to opening it up fully to community support, I’ll host it on Google Code, but in the meantime, I’m working on getting the documentation and core to a solid position.

I hope this is going to be of use to some of you, and I look forward to seeing where it heads.

Garth Henson
Garth is as a lead engineer at The Walt Disney Company, specializing in JavaScript applications.

Recent Blog Posts

Let's Work Together
Contact Me