Jim Driscoll's Blog

Notes on Technology and the Web

Archive for the ‘web’ Category

Thin Server the Hard Way (Model layer)

leave a comment »

This post is part of a series examining the Modern Web. Currently, I’m trying to assess pain points in creating a Single Page application, and to do that, I’ve created a simple application which does inventory management. You can find the (somewhat sloppy) code on Github, if you want to follow along.

After my previous post looking at routing, today we’ll examine how to handle the model layer of our single page app.


The first step on something like this is to decide on an initial architecture. QEDServer has a fairly simple REST API for fetching and updating records in the database – the only mildly tricky part is to format and pass it parameters. So a fairly lightweight wrapper around the jQuery AJAX API is probably all that’s required. Let’s model what how it’d be used, in this case for fetching a page of results containing the names of Categories for our products:

            page: currentPage,
            search: search,
            error: onFetchError,
            success: onFetchSuccess,
            complete: onFetchAlways


The REST API we’re using already has a paging facility (you pass it a URL param of ?page=number) as well as search (passing a URL param of ?q=searchterm), so the JavaScript API wrapper we need to develop only needs to smartly handle parameter building for the URL, which is a pretty simple task. We’ll also want to have success, error and complete callbacks, which are handled by the jQuery AJAX API already. So, the finished code is really pretty simple:

        getCategories: function getCategories(params) {
            var error = params.error || null;
            var success = params.success || null;
            var complete = params.complete || null;
            var page = params.page || 1;
            var search = params.search;
            var endpoint = '/categories.json?';
            if (!!search) {
                endpoint = endpoint + '&q=' + search;
            endpoint = endpoint + '&page=' + page;
                type: 'GET',
                url: endpoint,
                success: success,
                error: error,
                complete: complete,
                dataType: 'json'

A thin wrapper around the AJAX API, which simply builds a URL and returns the results in the supplied callbacks.

Much like building a front controller, this was trivially easy, but it didn’t have to be – there’s other features we could add in here, the most important of which are cacheing and pagination. Rather than always using the server to handle pagination and fetching values from the server every time, it would be far, far better to prefetch large chunks of data from the server, and let the client model layer handle the caching. But because of the design of the QEDServer REST API, which only allows fetching of 10 records at a time, that would have been counter productive in this case. And cacheing server data on the client opens up the problem of currency – making sure that the client data and server data are in sync. This implementation mostly just hand-waves that away.

Pain Points

In my simple implementation, there really were no pain points, but as I mentioned, I’d hope that any client side Model layer would handle cacheing and pagination as well as offer some hints on how to implement data synchronization.

So, with the Model and Front Controller out of the way, it’s time to move into the View Layer, which presented far more problems. But first, we’ll detour into what capabilities Bootstrap provides.

Written by jamesgdriscoll

January 25, 2014 at 11:44 AM

Posted in ajax, HTML5, REST, web

Thin Server the Hard Way (Routing)

leave a comment »

This post is part of a series examining the Modern Web. Currently, I’m trying to assess pain points in creating a Single Page application, and to do that, I’ve created a simple application which does inventory management. You can find the (somewhat sloppy) code up on github, if you want to follow along.

Previously, I covered the basic architecture. Today I’d like to examine how to handle routing via a front controller. As I’ve mentioned before, this proved to be one of the easier tasks.

As background, recall that the anchor is the last portion of every URL, and is set off from it via the # character, which is also called a hash (or octothorpe, if you’re a serious geek). All of our href values will just have these anchor tags, such as href="#home". When a user clicks on that link, we want to rerender the page to make it look to the user like they’ve gone to a new place – but without having to roundtrip to the server to get all of the new HTML. Possibly, we may not have to go to the server at all, if we’ve cached values. This will give the user a much snappier experience, and is pretty much how most modern web sites work nowadays (though some also use the newish history.pushState function, which lets you avoid all this anchor stuff on compatible browsers).

The pattern to follow here is a simple one: For any action which you want the user to be able to bookmark, use an anchored URL. For any action which is inappropriate to bookmark (such as deleting a record), use a click handler.

First, we create a module (jqcontroller) which will handle all the routing. Inside it, we’ll create a hardcoded routing table, which will associate names with the route to take:

// routing table
var routingTable = {
    home: jqproduct.displayHome,
    products: jqproduct.displayProductsPage,
    categories: jqproduct.displayCategoriesPage,
    productAdd: jqproduct.displayProductAddPage,
    defaultPage: jqproduct.displayHome
defaultPage = jqproduct.displayHome;

So, when we receive a URL that looks like #home, we’ll call the function jqproduct.displayHome.

We also need to create an onhashchange handler:

function hashChangeHanderSetup() {
    // when the hash changes, go through the router
    $(window).on('hashchange', function router() {

Here, we’re using jQuery to add a new handler on the window object. When the URL’s hash changes, call the jqcontroller.route function, passing in the new hash value.

Of course, we have to call that setup message during initialization for it to work. While we’re at it, let’s allow for routing to an initial location, so that when users bookmark the location, navigating back to it functions correctly:

initializeModule: function initializeModule() {
    // initial route

The actual router code called by these functions couldn’t really be much simpler, though it’s complicated by one additional requirement – we also want the hash to contain parameters, so that if you search, for instance, by product name, the hash may look like #products&search=Time – we’ll need to strip that out, and so we’ve created an additional utility method to do that called getPage:

route: function route(url) {
    try {
        var page = pub.getPage();
        var hash = url.split('#')[1];
        if (!!hash) {
            location.hash = hash;
        if (!page || !routingTable[page]) {
        } else {
    } catch (error) {
        // in production, this could write to console, 
        // or do something else useful with error reporting

Here, the meat of the code is simply calling routingTable[page](), which means “look up the value of page in the routing table, and execute that as a function”.

So, that’s it in a nutshell. As I mentioned, there’s additional code to handle parameter passing in a hash, but otherwise, there’s not much else.

As pain points go, this isn’t so bad. It’d be nice to have all this code encapsulated in a reusable library, but doing it myself wouldn’t be a terribly difficult task. Of more concern is that there isn’t any support in my code for history.pushState() and related APIs. Though as I mentioned, there needs to be server side support for that as well.

So, any MV* framework would need to support such a simple front controller pattern, as well as (optional) pushState. But since that’s a rather low bar, I don’t expect that to be an issue.

Next up, I’ll talk about implementing the Model layer, which was another fairly easy task.

Written by jamesgdriscoll

January 22, 2014 at 6:54 PM

Posted in JavaScript, web

Thin Server Architecture

leave a comment »

As I mentioned previously, I’m looking at the new ways of developing Web Applications that have turned up in the last few years. If you already know about Thin Server Architecture, feel free to skip ahead.

Single Page Applications were already the Next Big Thing back in the mid-2000’s – serve a single page for your web application, then as much as possible (in practice, almost always) simply serve deltas back to the user to avoid page reloading. The advantage you gain from doing this is a much more snappy use experience, with a page that starts to feel a lot like a native app. However, for many (i.e. most) of these initial SPAs, much of the page rendering logic still resided on the server.

Thin Server Architecture takes this a step further. By moving page rendering logic onto the client, you gain additional advantages – using REST means that you can take advantage of proxied requests. Also implicit in this design is that you’re moving state management to the client as well. Moving state management and page generation to the client can radically reduce server load, which immediately gives significant advantages for scalability. Remember that, in total, your users have way more CPU than you do.

Essentially, what you’ve done is keep only database-centric tasks on the server. Authentication (login identity), Authorization (data view permissions) and Validation are the three most commonly cited. The server becomes a thin shell on top of the database. Even validation is done client side, with server side validation done primarily to protect data integrity, not as an otherwise critical part of the control flow.

Is that an oversimplification? Certainly. Just as you can move critical business logic into your database in stored procedures, you can do the same thing with Thin Server. And for some things, like cascading changes to maintain data integrity, this would make real sense.

In addition to page view logic moving to the client, many newish HTML5 APIs also provide additional capabilities that you can exploit. You can store data on the client (or just cache it) via localStorage. You can use history.pushState to update the browser’s URL to add bookmarkability (real URLs, not just anchors! But of course, there’s no support for this in IE8). This works rather well, up to a point.

Where this becomes problematic is when users do deep linking of those URLs that were generated from history.pushState. While it’s true that clients, in total, have more CPU than you, for many of them (especially those on mobile devices), the amount of CPU they can bring to bear at any given moment is limited. The last thing you want to do is to do all this work to get a server that can shovel pages out the door with sub 50ms response times, only to have the client’s phone browser spend 3s rendering it, as it plays through a bunch of JavaScript to build up the correct state.

The obvious solution is to do an initial page render on the server, serve that, and do all further renderings on the client. Additionally, while you’re rendering the client web page, you can seed all your JavaScript functions with the JSON state that they’ll need to spin up, enabling everything to get up and running after the initial load. This hybrid approach is certainly going to be considered best practice (if not already), and you can already see folks referring to it as such – though it does seem as though it might be easiest to do with a framework that spanned both client and server using the same language and libraries… Which is a strong argument for node.js.

Certainly something to watch.

Another buzz phrase that’s popular right now is API First Design. The rise in popularity of mobile devices has led to a conflicting need – there are now effectively two web platforms to design for, a Mobile Web, with severe memory, bandwidth and resource constraints, and a Desktop Web, where those restrictions only apply modestly, if at all. (This is known as the “web first” vs. “mobile first” argument.) The API First design movement says that you should design your REST API first, around the information you actually wish to convey and manipulate. Once you have that, you can design for anything you want – desktop web, mobile web, an application, or even open things up to a third party. Frankly, the idea makes a lot of sense, and I’m reminded of the reason why Google Plus bellyflopped on it’s first outing. Lack of a defined API can be crippling to a product in surprising ways.

Hopefully, this was helpful in understanding this new Web world we’re living in.

Next, let’s look at what folks are using for IDEs these days.

Written by jamesgdriscoll

December 20, 2013 at 10:58 PM

Posted in JavaScript, REST, web

A Visit to the Modern Web

leave a comment »

My previous post covered how I came to be a bit of a time traveller to the world of modern Web technology.

This time, let’s talk more about the world as I left it.

The Web Development World in 2008

Single page applications (SPAs) were all the rage. The various JavaScript libraries were duking it out. GWT was compiling Java into JavaScript. There was quite a bit of tension between the SOAP and REST camps, and JSON was still kind of a new thing (IE added support, finally, in 2008). Ruby on Rails had reached Maximum Hype, and subsided, and everyone was writing their own Rails-like framework in their own favorite language.

On the Java side, there was still a notable tussle between varying page definition frameworks, like Tapestry, Wicket and JSF – all server side technologies, though increasingly, support for SPAs was being rapidly added. IE6 was still a (rapidly vanishing) thing, and support for things like WebSockets was forecast to not really be fully adopted for years. For client side work, libraries were primarily downloaded off a website and incorporated into existing build frameworks (maven, for instance, if you were a Java shop), and testing was done with tools like Selenium. Relational databases were pretty much the only game in town, though some bleeding edge early adopters were using other technologies (the term NoSQL wasn’t even in common use until 2009).

Contrast that with what I’m seeing now… Warning: Opinions ahead.

The Web Development World of late 2013


As a complete non-surprise, JSON appears to have won out over XML as a data-interchange format. It’s just so much simpler for the simple case, and with native support in pretty much every available browser, I don’t see XML used anywhere client-side except for the DOM. From my recent observations, it seems to be rapidly bleeding into the server side as well. And speaking of non-surprises…


As a Web partisan, I can’t say I’m especially surprised by this one. Yes, I know that (insert name of shop here) is actively using SOAP and loves it, just as there were always shops who swore by the control that CORBA gave you. But really, for mainstream adoption, REST won, and won big. This leads directly to the next point…

SPAs are pretty much all Thin Server

Most SPAs that I’ve seen described for startup are pretty much all based on the Thin Server architecture. Stateless REST calls, transmitting JSON to the client. The advantages for scaling are simply so large, and the performance benefits that you can get from proxied requests is also so large, that it’s the default architecture that’s adopted by most new sites. As a (former) stateful framework guy, I’d argue there’s a place for that architecture too, but there’s no denying which way things are moving. But as a downside to this, you really need a new way to organize your JavaScript on the client. More (much more) on that shortly. (Also, if you’re not sure what Thin Server really is, I intend to go over that in a later post.)

jQuery won

While other libraries such as Dojo and ExtJS are certainly still around and in wide use, jQuery as the main mechanism for DOM manipulation is just ubiquitous. (Trust me, at the time, this wasn’t as obvious an outcome as it now seems.) The other frameworks that it competes with generally try to do a lot of other things in addition to DOM manipulation, and for the client side web, small wins. Which brings me to a second point – for the mobile web, even jQuery seems to be too large for some purposes, and an even newer jQuery compatible library, Zepto, appears to be ascendant. It’s both modular and much smaller than jQuery – but it gets that partially by ignoring IE (they only just added support for IE10, and earlier versions of IE are not supported, and apparently never will be). Which leads to one of my more surprising discoveries…

IE just doesn’t matter like it used to

It’s more than a little early to say: “ding-dong the witch is dead” – IE8 still has at least a 10% market share – but rather surprisingly, I’m seeing more and more libraries as I keep exploring that simply don’t bother to support it. And not just IE8, which is certainly on it’s way out the door, but IE in general seems to be something developers are increasingly caring less about. (Zepto, for instance, used to bluntly say they didn’t support IE at all, and only recently added IE10 support). And for some uses, that makes total sense – if you’re targeting mobile, the number of mobile IE browsers is microscopic. Sadly, Microsoft still can’t get it together well enough on the standards support, even in IE11, and you constantly run across the phase “works in all browsers except IE”. Maybe next year.

JavaScript is cool. Really cool.

It was while reading Crockford’s “JavaScript: the Good Parts” that I first really understood that JavaScript was actually a pretty nifty little language. But back then, I didn’t have very much company. Today, everyone is writing in JavaScript3. In fact, they prefer it – so much so, that…

Full Stack JavaScript is a thing.

You can write your client side code in JavaScript using an IDE written (and extended) in JavaScript, utilizing JavaScript libraries downloaded and managed by JavaScript, build with a JavaScript program scripted in JavaScript, minified, checked and tested (with a headless server!) via JavaScript, and deploy to a JavaScript server which visits a database which is extended in JavaScript. Crikey.

Preprocessors are a big deal.

For a language that’s getting so much love, there sure are a lot of projects to hide it. CoffeeScript seems to be the most popular by far, but besides that, there’s Dart, TypeScript, and dozens more. They add static typing, async processing, and various other language extensions.

It’s not just JavaScript that’s a target for preprocessors – CSS is also the target of preprocessors. The big three are Less, Sass, and Stylus. They add additional structural features to CSS, such as methods and mixins.

You want to use the Node.js ecosystem

Pretty much everything you’ll want to do to build and maintain a modern website is available to you via the node.js ecosystem. It’s package manager, npm, is so ubiquitous that it’s possible to argue that if you aren’t on the npm registry, your software may as well not exist. And though many of the open source tools on there aren’t more than a year or two old, they’re mostly of commercial quality. This is a big enough topic that it deserves a separate post.

All the cool kids are using a NoSQL database

The structure of a NoSQL database makes them much more suited to use in an on-demand cloud instance. Their general lack of transaction support doesn’t mean they’re a good fit for every task, but when you’ve got a massive amount of mostly static data to serve, they’re just the thing. (They’re also a great thing for searching really large datasets as well.) More about that in a future post as well, though I don’t yet feel comfortable talking at length on this topic yet.

There’s a JavaScript library for everything. In fact, there’s 10.

Want to using templating on your web client? Pick from any of a dozen (though there are certainly some that are the most popular). Need to manipulate arrays (or fix this to make sense)? You’re covered. A lot. Want to test your code? You’re spoiled for choices. If you want to do it in JavaScript, someone’s already written a library for you. And the odds are good that it’s small, fast and covers most corner cases already. Did I say we’re in the early adopter phase? We may have already crossed the chasm to early mainstream.

So, that’s where we are – a changed world of Web Development. Next, let’s talk about the architecture that’s becoming the default choice for large scale web apps – Thin Server.

Written by jamesgdriscoll

December 16, 2013 at 5:32 PM

Posted in JavaScript, web

Catching up with the Modern Web

leave a comment »

I’ve been doing work on various Web technologies since Clinton was President. I’ve been involved in Internet technologies since… before that. Throughout the late 90’s and most of the next decade, I worked on Web technologies in one fashion or another, either as an engineer or a manager. We worked on, and invented, any number of technologies whose names you’d recognize (though I usually had a peripheral role).

My last project for Sun, implementing the Ajax front end for JSF‘s reference implementation, was heavy JavaScript work. Because we didn’t want to have any dependencies on external libraries, it was done as close to the metal as you can get in DOM programming. (And since IE6 support was, IIRC, required, it was quite an adventure.)

But then, as Sun spiraled downward toward it’s eventual dissolution, I ended up leaving hard core Web technologies to work on solutions for a somewhat smaller (though still pretty large) set of customers – and though I still worked making Web based solutions, I began to focus primarily on more backend problems like DSLs and metaprogramming.

Gradually, I stopped paying attention.

Every now and then, something would peep through my blinders. Since I was paying attention to language developments, I heard about Node.js, CoffeeScript, and Dart (though I admit to not being exceptionally impressed by any of them on first hearing). I attended a number of talks by Douglas Crockford, and I had some vague notion that the Thin Server model was taking over. I heard, often through friends, that NoSQL was a thing now. There were offhand references to client-side MVC here and there, as well as more esoteric things like Hypermedia and HATEOAS.

As part of my job, I began working in JavaScript somewhat heavily again, mostly instrumenting a JavaScript component (CodeMirror, which I can’t say enough kind things about, nice stuff). Almost on a lark, I decided to attend the local HTML5 Developers Conference – one of the major advantages of working in Silicon Valley is that such things are readily available to you if you’re willing to take the time to seek them out.

The conference was extremely eye-opening. While I was napping, a whole new ecosystem had opened up around the world of Web Development. As is usual in technology, after a brief period of consolidation and extension of the latest greatest tech (server side Java), a whole new way of doing things was being born.

In the month since, I’ve immersed myself as much as possible in this new world, and I love what I’ve found.

If, like me, you haven’t been paying as much attention to new developments as you should, it’s time to start. Things have settled down a little bit, but are still in the early adopter phase of the adoption lifecycle — though I believe that they’re rapidly crossing the adoption chasm.

Don’t have a month or two to burn to learn all this new stuff? Stick around – I intend to report what I’ve found.

Written by jamesgdriscoll

December 14, 2013 at 9:47 AM

Posted in JavaScript, web

IE, Memory Management, and You

leave a comment »

In a recent blog, commenters took me to task for a perceived IE 6 memory leak. It wasn’t actually there (they were wrong), but in attempting to prove myself right, I found a couple of memory leaks under IE in JSF’s Ajax support. Since I just spent a week learning how all this functioned, I thought I’d set it down so that others could learn from my efforts.

Now, none of the information that I’ll present here is new – it’s been discussed among Ajax programmers for at least the last 4 years. If you’re a web guru, it’s likely that you’re not going to learn anything new here (thought I’d welcome any additional information and corrections). But at least a couple of the points I’ll illustrate below are either poorly communicated or misunderstood. I’ll include a number of links at the end of this article. There are also very significant differences between IE 8 (which mostly works), IE 7 (which is bad), and IE 6 (which is just awful). I’ll try to point out the differences as they matter for each.


First – use the right tool for the job: In order to spot leaks, you’ll need to download a tool that can detect them. By all accounts, sIEve is the way to go. It uses IE itself, and introspects to get it’s data. The UI is pretty primitive, but I can’t recommend it enough – it’s truely invaluable. Since it uses IE for it’s work, you’ll need to run it on a machine that has IE6 installed – presumably in a VM. You’ll also want to have it running on a machine that has IE 7 and IE 8 as well, just to be sure. XP fits nicely on a VM that runs on my Mac, and this is how I use it.

Cyclic Leak

Now that that’s out of the way, it’s time to talk about the very worst of the memory leaks in IE – the dreaded cyclic reference, which the commenters thought that I’d committed. Under certain conditions, IE 6 will “leak” DOM nodes, retaining them, and the javascript objects that point to them, until the browser is either shut down, or crashes entirely due to lack of memory. Ugh! To understand how this happens, you really only need to know two things:

  1. IE 6 (and 7!) reportedly has very primitive garbage collection using reference counting
  2. There are two memory spaces in IE, one for JavaScript, and the other for the DOM, and they don’t communicate well.

What could go wrong? Well, lots. The commenters thought that the rule was: A leak will occur if any reference is made in JavaScript to an element that isn’t eventually set to null. That’s close, but not quite correct. The real rule is: A leak will occur if the JavaScript code contains any reference to the DOM that isn’t released in some way, either by going out of scope or being explicitly unset.

When IE 6 sees a JavaScript variable that is pointing to something in the DOM (typically, an element or node), it will record that reference, and not collect it – even when you surf over to a new page. And the DOM won’t be collected, since there’s a reference to it from JavaScript. These two objects, and all the stuff that references them, will stick around until shutdown. In IE 7, the geniuses at Microsoft saw the bug, and said “Hey, I know how to fix that, let’s garbage collect everything when we leave the page.”. Nice improvement, but it still doesn’t fix the bug, since if you’re developing a page that is designed to be used for a long period of time (like many page-as-application apps are now), it’ll still crash the browser. Apparently, they saw the error of their ways eventually, since this behavior is no longer present in IE8. (All this is confirmed by my testing with sIEve.)

So, in the example that had in my previous blog, there was no memory leak, because the variable that pointed to the element eventually went out of scope. So – how to you create variables that don’t go out of scope? The easiest way is to put them in an object – this was the leak that I eventually found in JSF. The fix there was to null out the object manually. But there’s another, more insidious way to create an object – create a closure. That creates a function object implicitly under the window object, and that will never go out of scope. But the key thing to remember is that you need to be aware of when things go out of scope when coding in IE, and act accordingly.

But wait! There’s more

If that was the only problem, life would have been fairly easy for me the last week. But that’s not the only bug that the Web Wizards of Redmond chose to deliver to their unsuspecting consumers. There’s another bug in IE (again, only in IE 6 and 7 – IE 8 appears to have fixed it per my testing), which also leaks DOM nodes that aren’t cleaned up until you leave the page. Apparently, when the IE DOM receives a call from the removeChild or replaceChild functions, it doesn’t actually, err, remove the nodes. It just leaves them there, hanging around the DOM like party guests that don’t have the sense to leave after the host has started handing out coats. While these nodes will eventually be cleaned up when the user leaves the page, this still causes problems for page-as-app programs, as in the cyclic leak for IE 7, above. While the removeChild call is fairly notorious for this, I had to find out about replaceChild with my own testing (though I did find a few obscure references once I went looking for it).

That means that instead of saying node.parentNode.replaceChild(newNode, node), you instead should say something like: node.parentNode.insertBefore(newNode, node); deleteNode(node); (with an appropriate if statement for isIE(), and a deleteNode function that doesn’t use removeChild). And instead of saying node.parentNode.removeChild(node); you instead are reduced to coding something like: node.outerHTML = ”; (again, with browser check). Except that when you combine that with IE’s horrible problems with manipulating tables, it may fail. So instead, you’re probably better off with something like this:

                var temp = document.createElement('div');
                try {
                    temp.innerHTML = ""; // Prevent leak in IE
                } catch (e) {
                    // at least we tried

Again, possibly with an isIE() check.

Hopefully you found this description of IE’s Memory “Management” useful. Here’s a few of the links that I used for research, that I found the most helpful.

As always, I look forward to any comments. Especially about this topic – I’m far from expert in this area.

UPDATE: John Resig just posted about a very interesting looking tool. Haven’t checked it out yet, but if it’s got him excited…

(This article originally published on my java.net blog on November 13, 2009.)

Written by jamesgdriscoll

February 9, 2010 at 11:19 PM

Posted in JavaScript, web

An (almost) comprehensive list of Web Components

leave a comment »

In talking with Andy Schwartz before our recent talk together at Oracle Open World, Andy mentioned that he’d like to see some new components make it in to JSF 2.1.

I’d like to see that too – but what new components? To aid the discussion, I thought it might be handy to make up a list of components that I think would be handy for JSF – but please, don’t take this as an endorsement of any particular component for inclusion into the spec. At best, I can see us adding only a handful, perhaps 3 or so. Still, once started, this kind of project becomes it’s own end – so I decided it might be good to publish such a list. Many of these components already exist in some form or another for JSF, or as a JavaScript Widget that could be wrapped in a JSF component – so most of them are available today.

Basic Html

Most of the basic HTML components are already well covered, but there would seem to be a little room for a few very basic components

  • File Upload
  • This is pretty basic – and Servlet 3.0 just added it.

  • Formatted i18n data
  • These can currently be done with converters and validators, but is there a better way?

    • Date entry/display
    • Time entry/display
    • Currency entry/display
  • Flat Tree
  • A very basic hierarchical data visualization component that has no JavaScript required.

  • Static Progress Status
  • A bar which indicates percent complete, a static version of the Ajax version below

  • SingleRowSelect
  • A radio button that works with a table.

  • HTML5
  • There’s new stuff coming up – should we start to care? IE is, as usual, the lone holdout.


Components for navigating from one page to another.

  • Breadcrumb Trail
  • Almost standard on many sites now, a horizontal list, often limited to three deep, that allows you to backtrack through your history without the back button.

  • Navigation List
  • A fairly straightforward list of links that navigate to different pages in the site. Often put in a Navbar on the left of the page.

  • Navigation Tree
  • Like a Navigation List, but with hierarchical categories


Components that deal with identity and authorization.

  • Java EE Login
  • This one would seem to be a no brainer, but it’s actually a bit hard to get right.

  • Logout
  • If you log in, you should be able to log out.

  • Register
  • Probably not possible in a fully reusable way, since Java EE doesn’t specify a standard registration API.

  • Forgotten Password/Username
  • Same problem as Register

  • Capcha
  • This would be very useful, but probably not amenable to standardization, since the robots keep getting smarter.

Simple Rich UI

  • Framebuster
  • The war between the framers and the framebusters means that this will be obsolete almost immedately on release, but it might be worthwhile to try.

  • Tabbed Pane
  • Basic Web component or rich component, depending on whether you use DHTML. Since DHTML is probably easier for the end user, it’s my preference to have it in this list.

  • Spinner
  • Increment an integer value by a set amount at the press of a button, or manually enter a number. Implemented as a demo in Mojarra 2.0.

  • Slider
  • Analog slider to choose a numeric value, or manually enter a value.

  • Calendar
  • Need to also include options to pick a date, or only a month, or even only pick a year. May be hard to do reusably, since styling matters so much. Wrapped a YUI Calendar widget as a component as a demo in Mojarra 2.0.

  • TimeSpinner
  • A special case of a spinner, for picking a time.

  • ColorPicker
  • A very special case, but easy to implement.

  • ModalWindow
  • Alert box.

  • ModalDialog
  • Alert box, with two or more buttons.

  • Popup Menu
  • FloatingWindow
  • A detached embedded window, that you can move around within the HTML frame or window that contains it. After a brief burst of popularity, I’ve seen usage drop off.

  • Tag Cloud
  • I’m frankly not convinced of the usefulness of this particular visualization, but many designers seem to love it.

  • TabularData
  • A table that’s modeled on a database set, rather than being explicitly bound to the HTML table. Would include sorting, at a minimum, and also probably reorder of rows. Maybe even filtering?

  • Menubar
  • Drop down menu bar. Many HI people hate them on the web.

  • CommandBar (icon button)
  • Essentially, a horizontal strip of buttons.

Filthy Rich UI

Really elaborate graphical components. Harder to do as a standard, since styling becomes so important.

  • Carosel
  • Like Apple’s cover flow, flip through a set of images to select one.

  • Accordian
  • Just because I’ve never seen it implemented well doesn’t mean it’s useless.

  • EditText (in place edit)
  • Easy to do, but hard to get right, I’ve implemented it as a demo in Mojarra 2.0.

  • Shuttle (Switch List)
  • Fairly common, I’ve implemented it as a demo in Mojarra 2.0.

  • ComboBox
  • Essentially a static version of the AutoSuggest component, below.

  • Collapsible Tree
  • Tomahawk has had a tree for years.

  • RichTextEdit
  • Several good JavaScript widgets exist for this functionality.

  • RSSReader
  • Update a page automaticially with the latest blog posts. Far more useful than you might first think, since many programs (like hudson, for instance) now export data as RSS.

  • Slideshow
  • A fairly complex JavaScript widget.

  • Lightbox
  • An incredibly complex JavaScript widget for organizing images.

  • Charting
  • Incredibly complex, and incredibly useful, this is probably best done as a completely separate software product. Some JavaScript widgets already exist, and some JSF components already support this…


Things that are probably best implemented as behaviors.

  • Tooltip
  • Probably almost trival to implement.

  • DragAndDrop
  • The opposite of trivial to implement, it could still be incredibly useful. Some support in various JSF component sets already.

  • Clientside Validation
  • A customer request since year 2000.


  • AutoSuggest
  • The “shopping cart” of the Ajax world. Note that Andy is working on a demo that implements this as a behavior. Supported as a component in some JSF component sets.

  • Poll
  • Besides periodic updates, also handy for keeping sessions alive, and avoiding many cases of view expiration. Less necessary if we implement Comet, but probably still useful as simpler solution.

  • Map
  • Relying on an external service means that this is probably not suitable for standardization.

  • Progress Indicator
  • Progress of a server operation

  • Busy Status Indicator
  • Essentially a binary version of Progress Status


I’m sure I’ve left some out – suggest more in the comments…

(This article originally published on my java.net blog on October 14, 2009.)

Written by jamesgdriscoll

February 9, 2010 at 11:13 PM

Posted in web