Widgets, Templates, and DRY

Widgets are just templates. Simply put, yes, but it's true at one level or another. There are many ways a front-end developer can go about designing and implementing widgets — using frameworks made for such a purpose, or just staying consistent with your own patterns and principles. Who knows, maybe if you're of the latter camp, you eventually roll your own framework that supersedes anything that's on the market. And the funny thing is, you didn't set out to dominate a technology area — it just happened as a result of ironing out your own development pains. This is true of many, many successful open source projects.

And that's the motivation for me with widgets. Whether I'm using something pre-packaged and ready to configure, or rolling my own widgets, the problem is the same. How do I write this code once? How do I stay true to the DRY principle?

The concept of a widget in front-end development isn't all that different from the concept of an HTML template. Most web application frameworks support the notion of template rendering, and this action is performed on the application server. That made a lot of sense back when there weren't many JavaScript-driven applications. The idea was, still is today in some sense, that the HTML had logic included in them. In particular, looping logic that does things like fill out table rows. These template processors also perform more rudimentary tasks like variable substitution. The looping idea within templates is the interesting part to me because it saves the programmer time and effort.

Another good one is the idea of template inheritance. I'm not sure which template system introduced it, but I'm most familiar with the Django version of it. The idea is that your user interface is going to have a lot of consistency between pages. In should anyhow, as this is good design. But it's also repetitive from a coding perspective. Inheritance in templates was a great innovation in the DRY principle.

We still have DRY challenges like this today in UI development, it's just that the problem has shifted a little — closer to the browser. We're not so much thinking about the backend framework as much as we're thinking about designing something that adheres to some API design. We're focused on decoupling the UI from the hot and new backend technology of the week. And so we have to innovate in the same way as template rendering systems did when they were the prominent force in delivering user interfaces to the client. We're already innovating along these lines.

Take any given JavaScript widget library. Some are geared toward completeness. These libraries try to give the developer everything they could possibly need to develop a user interface, including the necessary tools and patterns. Some other libraries are geared toward giving the developer a small set of widgets, and a robust underlying architecture. These libraries are focused more on flexibility and stability as opposed to the completeness of a solution. So no matter what end of the spectrum you find yourself on as a JavaScript developer, there is something usable out there in the ecosystem for you to use. It's very difficult to justifiably start solving a problem without the help of a widget.

So is that all widgets really are — glorified templates that spit out HTML? They do more than this, but at the same time, they do less than templates do. Templates are geared toward a whole page. Widgets can be arbitrary in size, but in general, they're small — focusing in on one control that manipulates the application, or displays something useful. This fine-grained approach to assembling user interfaces generally works better than trying to fit all the inherent variability into a template. It's easier to have the page simply manage a given set of widgets. It's also easier to identify patterns and hammer out widgets that address that problem. Because they're smaller in size and scope, widgets don't require a heavy investment on part of the developer. As you're looking through and reading the markup in your web application, you'll notice repetitive constructs, and a widget is a great way to rid yourself of them. Have the widget assemble the tougher pieces on top on the standard markup.

The idea of progressive enhancement is where widgets really pull their weight. Simply because the whole idea behind progressive enhancement is to build the simplest possible user interface, something that works on every device and is immediately understood by anyone interacting with it. Then, as you progressively develop widgets, they're placed on top of the basic content. The widgets encapsulate the design complexity, and also exposes a safety switch to turn the added functionality off.

And it's not only markup that we're concerned about in front-end development. Widgets can help use there, but user interfaces are reactive systems that must be ready to respond to a user dragging an element across the screen or the arrival of fresh data over the network. Some of the behavior is encapsulated within the widget as well. It's not the application logic that's daunting in UI development — that stuff is usually easy enough. It only appears that way when it's mixed in with piles of widget code that hasn't made its way to a widget yet.