From the fall of 1998 through late 1999, I worked on a mix of interesting projects for my then-employer, Primix, a Boston Internet consulting firm. The first of these was a standard CRUD (Create Read Update Delete) application, and it used servlets and JavaServer Pages (JSPs). Despite the fact that we were a small team (just three or four of us at various times) working on a very modest application, it seemed like we were constantly having to reinvent the wheel. I?d had some exposure to Apple?s WebObjects framework, and the difference between the two approaches was like night and day: Not only did WebObjects have better tool integration, including a WYSIWYG (What You See Is What You Get) HTML editor, it was easier to use even without the extra tools, just by editing the underlying template and configuration files. We were a small, smart, experienced team—but working with servlets and JSPs was always an uphill battle compared to using WebObjects.
A major part of this problem was impedance; each developer worked in his or her own corner of the application and had a particular way of working. Different developers used different naming conventions and solved similar problems in different ways—which caused extra grief when new developers cycled through the team, or when we had to venture outside our little fiefdoms to fix bugs. Remember, this was a time before J2EE servers really existed, before custom JSP tag libraries, before Sun had even started promoting the Model 2 design pattern. It was also obvious that WebObjects, with its notion of components and all the magic it did to hide URLs from the developer, was a far superior option. At the same time, steep licensing fees and lukewarm support and marketing by Apple made pitching a WebObjects solution to clients a nonstarter. We soldiered on with servlets and JSPs.
Near the end of 1999 I was left with engagements in the pipeline but no short-term responsibilities. What was to eventually become Tapestry started as a kind of mental doodle: How does WebObjects do it? I started drawing diagrams and sketches, puzzling out a way to gracefully connect stateless HTTP requests to stateful Java objects via Java servlets, and eventually decided to code up a little prototype to see if my ideas would work. Somewhere along the line, I came up with the name: Tapestry.
Tapestry quickly took on a life of its own; as primitive as that early code base looks compared to the Tapestry of today, it was still a solid foundation, something that would start to address the issues Primix had with servlet and JSP development. Primix was in the business of creating high-quality web sites on a regular basis, and Tapestry was a platform that would support the solid software engineering principles necessary to achieve its goals. Tapestry set up shop at SourceForge (http://sf.net) and was released under the Lesser GNU Public License.
Along the way, I realized something profound: I could make a difference. Interesting software didn?t have to come forth directly from the Suns, IBMs, and Microsofts, or even from the Apaches; it could be homegrown, like Tapestry. With Tapestry, I really thought I could change the world...or at least, the little niche of the world that writes web applications in Java.
As fun as working on the code has been, the most fascinating part of Tapestry has been the creation of a real, online community around Tapestry. These are people for the most part I have yet to meet, who have recognized Tapestry as a Good Thing and who work as hard as I do to improve and promote it. It was on the strength of this community that Tapestry relocated from SourceForge to Apache?s Jakarta project, alongside established projects such as Struts, Turbine, and Velocity.
Crafting a book about Tapestry has been more difficult and more intense an experience than anything else related to the project, but ultimately the result is worth the effort. What you are holding in your hands may open up a whole new approach to web application development for you and (I hope) will change your world for the better.