Open Source Web Technologies Gone Wild!

We web developers live in amazing times. The boundaries of what we can do with HTTP to deliver great content and services to users and applications are being expanded every day. The triumvirate of the web—HTML, CSS, and JavaScript—are being pushed to new heights of sophistication and power. JavaScript alone has come a long way in the last 10 years, going from the programming language that everyone loved to hate—or at least, make fun of—to one of the main drivers of innovation on the web today.

The recasting of JavaScript as a worthy development tool has been fueled by the phenomenal growth of libraries and frameworks that make JavaScript programming fun and—gasp!—productive. Ajax paved the way for the surge of libraries and frameworks, and jQuery quickly gained traction by virtually eliminating most of what was painful about JavaScript programming against the DOM. The sheer brilliance of using CSS selectors to reference DOM objects still amazes me, and not just because it means I have one less syntax to learn.

So we really do live in amazing times, and it's never been better to be a web developer. But this emergence of JavaScript as a preeminent programming language has almost gone too far. Now that JavaScript is no longer the ugly duckling, multitudes of people have come out of the woodwork, each with a JavaScript library, so now, there's a dizzying array of libraries available, with at least a dozen in every conceivable category. Having a lot of options is sometimes a good thing, but not so much in this case. It would be one thing if each category had a lot of crap with one good, dominant library that you could find and use for just about anything. But the reality is that there are a lot of really good libraries out there, and many of them are in the same category, completely overlapping each other. How do you find the best one for your needs, even for a single application, much less as a foundation that you want to learn and know well to use in many applications?

Shampoo Shopping

Finding the best JavaScript library for your needs is a bit like buying shampoo at any large super store. Unless you know exactly what you want, you can spend some serious time examining all the options that are available, trying to make sense of the insane claims that each product makes about how wonderful you'll be if only you start using that it. You can eliminate a few from consideration based on features and specs, but even then, you'll still be left with about 237 good options for washing your fluffy mane. So you close your eyes, point to one, and give it a try. If that doesn't work out, you try another, and repeat the process in an endless, decidedly non-agile reiterative loop.

Another issue with this situation is the identity of major backers behind some libraries; companies like Microsoft, Google, the Mozilla Foundation, and many others. It almost seems as though you can't consider yourself a serious Internet startup any more without your own JavaScript library or framework.

Finding the Right Library

Case in point. Lately I've been working on a nifty little search page that's part of a much larger, comprehensive membership website. Enter in a few search criteria, and the page goes off through the magic of Ajax and an existing bundle of web services to hunt down the best option for the user from a database of thousands. I built the core page using KnockoutJS for databinding and templating duties, and jQuery for, well, everything that jQuery does so wonderfully. These choices tied my hands for what was to come, but didn't really limit me all that much, other than to eliminate a few incompatible options.

There was also an important user requirement: the ability to bookmark different searches so that users could save and retrieve the ever-changing results as they changed over time. (The underlying database is a set of options maintained by the U.S. federal government, providing thousands of available programs, so the results for any given search changes almost daily.) No problem, I said, I can do that. I then set off to figure out the best way to maintain state in a nearly stateless world; a solution that would be supported by most of the user agents our users were likely to use. Thankfully, I was allowed to assume JavaScript support.

When searching on Google or Bing for available solutions, it quickly became apparent that there were three oft-recommended possibilities:

I won't bore you with the details, but I tried and discarded each in turn for a variety of reasons. jQuery History held the most promise, but my client was leery of its apparent lack of activity in the last year, and that wasn't helped by the lead developer's silence in response to my request for an update or any indication of life in the project. In the end, each had shortcomings that prevented the solution from working for this particular page.

Hit and Miss Solutions

I finally admitted defeat and fell back on the use of HTML5's History API with a bit of JavaScript trickery to support a few older browser versions. The solution is working fine, but it left me wondering about the lack of a suitable library option for such a fundamental need in certain types of Ajax-like applications. Even with the overwhelming number of JavaScript libraries, we've not yet reached the point of having a good standard solution for even standard problems. I don't think that lack is because everyone has fully adopted HTML5 and its many juicy technologies that handily solve so many infrastructure problems. The web remains fertile ground for innovation. I just wish that day-to-day problems had better, more widely used and supported solutions.