Java technology is traditionally strong on the server side. However, in the last couple of years one might notice some kind of stagnation in the area of Java web development. To explain what I mean, I will need to show you a brief history of Java web development.
In the first stage of web development, it was typical to have some code that a web server could invoke to produce dynamic content. The traditional solution is to have a program written in Perl or C and to invoke it through a CGI interface. The Java solution was different however, and that solution was rather advanced for its time. Java code was running on the server as a servlet, a kind of plug-in maintained by a servlet container.
The servlet way was superior because it ensured higher scalability, but perhaps even more importantly from the developer's point of view, a servlet developer could spend more time writing application-specific code, since many of the lower level issues were handled by the servlet container. At that time, Java technology was ahead of the rest of the web development world.
The next generation of web technology was about embedding pieces of code into an HTML page in order to make it dynamic. You can see this approach in JSP, ASP, PHP and ColdFusion.
Again, Java technology was ahead, because JavaServer Pages took special care about separation between the application code and its presentation logic. Ideologically fortified by Model-View-Controller design pattern, this approach culminated in Apache Struts framework.
Basically, a Struts application is a traditional servlet/JSP application, but this framework offered a number of efficient solutions for common problems of web development. Struts developers could avoid reinventing the wheel and reuse existing solutions by modifying them with application-specific code. This significantly increased the efficiency of large-scale web development, and Struts framework became extremely popular, once again ensuring the leading position of Java technologies.
However, around the same time Microsoft came up with an alternative technological solution, ASP.NET. This was a component-based approach which was supported by a sophisticated integrated development environment (IDE), Visual Studio, ASP.NET resembles RAD solutions that brought desktop development to a new level of productivity some years ago. An ASP.NET developer can drop a few components on the page, set their properties in a visual property editor and run the application—all in just a few seconds.
This is when the feeling appeared that the Java approach is not quite the best anymore. ASP.NET was quickly gaining popularity, while the mainstream Java approach was exemplified by a Struts application, not component-based, and was still quite a low-level solution.
The Java world tried to retaliate by creating JavaServer Faces specification. Externally, it resembles ASP.NET, but is built on top of the existing Java-specific solutions.
JSF is supported and promoted by major software vendors like IBM, Oracle, and BEA, and it's implemented in their state-of-the-art commercial IDEs. Its approach was very similar to the Microsoft approach, but somehow JavaServer Faces didn't gain the popularity it was expected to gain. Maybe that is because to create the JSF specification, so many different parties had to come to a compromise.
Or maybe the problem is in the fact that the JavaServer Faces specification is created using existing Java solutions and has inherited their weaknesses. For example, JavaServer Pages technology, used by JSF to render pages, was very sound for its time, but a JSP page can easily become an unintelligible mixture of HTML, standard tags, custom tags, and EL expressions. Also, JSF has some older features from Struts, like its navigation configured in a lengthy XML file. As a result, JSF technology is difficult to comprehend, learn and work.
Or perhaps the problem with JSF is that it mimics so closely the Microsoft solution, while the Java world has its own laws, and something that is good for Microsoft might not be equally good here?
My point is that if we look at Tapestry, the framework that was never supported or promoted by billionaire corporations, we might notice that it can easily compete with the most recent versions of ASP.NET in many respects.
Features like code-behind in ASP.NET that allows the separation of code of the page from its template, is an integral part of Tapestry from the very beginning of the framework. In fact, in Tapestry you cannot just mix code and HTML since all Java code goes into the page class.
In fact, many solutions that are promoted as advanced features of ASP.NET can be found either in the core Tapestry framework or in a library of custom Tapestry components, such as Tacos.
It may well happen that with time, as more people realize the benefits of Tapestry, it might become the model for the next generation of a Java web framework specification.
However, nothing is perfect, and Tapestry has its downsides too. One of them is the fact that the framework's development goes ahead in huge steps, which makes the next version very different from the previous one. To fully appreciate what this means, let's have a look at a brief history of Tapestry.
Tapestry was originally conceived by Howard Lewis Ship around the year 1999, but the early versions of the framework are not widely known.
Tapestry 3 became the first well known version, and I used it for my first Tapestry application that I created in the summer of 2005. Tapestry was a great relief after my experience with servlets and JavaServer Pages. Its approach was very easy for me to understand, maybe because in the past I had plenty of experience with Borland Delphi, a very popular Rapid Application Development environment.
However, some features were not fully implemented in Tapestry 3. Most notably the validation subsystem was somewhat deficient. Also, some obvious components were missing, and I had to create a number of custom components myself (although that wasn't too difficult, frankly speaking). All in all, I was very happy that I had learned Tapestry, and I was going to use it for years.
However, when Tapestry 4 appeared in January 2006, it was so different that I had to learn the framework again. It was not a problem though as Tapestry 4 had streamlined and made many features easier than in the previous version. Most significantly, Tapestry 4 was built on top of Hivemind, another Open Source project created by Howard Lewis Ship. Hivemind made it possible to easily extend and configure Tapestry, but most notably, it allowed users to inject anything into the page, as Hivemind was (and is) quite a capable Inversion of Control container. Also, Tapestry introduced a brand new user input validation subsystem, flexible and easy to use.
On a negative note, Tapestry 4 was not compatible with Tapestry 3, and upgrading an application to the new version required a substantial amount of effort.
Tapestry 4.1 became another major step in the development of the framework. It came with Dojo JavaScript toolkit built into it, and as a result it made AJAX functionality easily available to Tapestry developers. It looks like version 4.1 will stay here for a while and allow many people to benefit from using it for building their web applications. It still has a few places where it could be streamlined or enhanced, but, it is a powerful and developer friendly framework.
Very soon however, it became clear that Howard Lewis Ship was working on a completely new, fifth version of Tapestry, and that version was not just a step, but a quantum leap forward. Tapestry 5 was created from scratch, and on one side, it incorporated all the best ideas accumulated by Tapestry developers over the years, while on the other side it got rid of those solutions that proved to be obsolete or inefficient. Needless to say that neither Tapestry 3 nor Tapestry 4 were compatible with Tapestry 5, although their approach was very similar.
Tapestry 5 is a truly contemporary framework. It was specifically designed to be extremely developer friendly. Page classes are now POJOs (Plain Old Java Objects), since they do not need to inherit from any framework-specific classes, and we have more freedom in choosing how to implement them. They are easy to test too. To give Tapestry hints on what we expect from it, we use Java annotations, and the framework adapts to our requirements instead of expecting us to adapt to its rules.
Tapestry 5 comes with new powerful components. Their rich functionality can be easily adjusted for a specific application's needs, and so there will be significantly fewer cases when we need to create custom components. Creating custom components is even easier now than it was before, so our creativity is not limited in any way.
Tapestry 5 is significantly faster than the previous versions too. Not to say that those were slow. Tapestry 3 and Tapestry 4 applications are as fast as any other Java web application. All versions of Tapestry were created with great scalability in mind, which means that Tapestry applications can work under a significant workload—say, thousands of visitors using the application simultaneously.
I am not going to list here all the novelties of Tapestry 5 as we are going to learn them in the course of this book, but I encourage you to visit the Tapestry website (http://tapestry.apache.org) and read what the creators of the framework write about the new version. In general, it is significantly easier to learn to work with and efficient too.
It is also stated by its creators that Tapestry 5 will become a stable long-term platform for the future development of the framework. They have taken special care to ensure that the future versions of the framework will be backward compatible.