In 2004, we had a good idea what was wrong with the web frameworks we’d been using (Struts and Maverick) at Topicus for a number of our projects. They didn’t scale for development, they made refactoring hard, and they inhibited reuse, to name a few of our complaints. Just about everyone in our company agreed that developing web applications with Java wasn’t a lot of fun, particularly when it came to the web part; and those with experience in programming desktop applications wondered about the huge gap between the programming models of, say, Swing and Struts.

After a long search, one of our colleagues, Johan Compagner, stumbled across Wicket, which had been made publicly available by Jonathan Locke a few weeks earlier. Although it was still an alpha version and far from being ready to be used in our projects, everyone involved in the framework quest recognized its potential. We decided to start a prototype with it, and unless the prototype turned out to be hugely disappointing, this would be the framework for future projects.

Our personal involvement in Wicket came about suddenly when, a few weeks after our discovery, Jonathan announced that he planned to drop the project and accept a new position at Microsoft; he felt that continuing to work on Wicket might be a conflict of interest. We quickly got a group of people together—Johan Compagner, Juergen Donnerstag, Chris Turner, and the two of us—and took over the project. As it turned out, Jonathan’s job was short lived due to other conflicting interests (regarding a startup he co-owns), and he was soon back on the Wicket project.

We spent our evenings over the next few months ramping up for the first Wicket version; during the day, we used Wicket for a first real project. The fact that Topicus allowed us to do that has made all the difference for Wicket; it wouldn’t otherwise have become so good so quickly. We believe the investment has paid back tenfold.

Soon after the 1.0 version was released, we started to promote Wicket on Java community sites like The Server Side and JavaLobby. After all, the more users an open source project has, the more testing hours it gets, and the greater the chance that corner cases will be well-covered; and, in the long run, projects need enough people to continue when the interests or priorities of older members shift.

The feedback we got from those first promotions wasn’t always positive. Most people liked the programming model, but some had objections: that we should have been supportive of the proposed standard web framework for Java (JSF), that a stateful programming model wouldn’t scale, and—last but not least—that we were lacking documentation.

With a few notable exceptions, most open source projects are poorly documented. These projects are worked on by software engineers, not copy writers, and most of them (including us) prefer to write code instead of manuals, especially when doing it in their spare time.

Wicket has had pretty good API docs from the start, and the code is well organized, but the documentation was sparse at that time. And even though the community has contributed enormously to our wiki, and most of the questions you’ll ever have about Wicket can be found in the mailing-list archives, Wicket still lacks a well-written online tutorial (although you can find several on the internet, focused on specific topics).

We launched several initiatives for writing a good tutorial. We tried to write one ourselves, but improving the code always felt more important. We tried to get writers to join us. Alas! Although we had a few candidates, their endeavors turned out to be short lived. We realized that the only way there would ever be authoritative documentation on Wicket would be for us to write a book. Yep, that’s the book you’re reading right now!