The Confounding Saga of Java Web Application Development

Java is a large and robust programming language which is loaded with features such as the Collections framework of data structures, integration frameworks such as JDBC, JMS, as well as networking primitives, threading, dynamic class loading, and Lambda expressions, to name just a few. Java also benefits from open-source frameworks for additional functionality, such as Apache Commons. I started developing in Java with version 1.0.2 and built many solutions with the language over the years, but something that has long frustrated me with the Java ecosystem was the number of Web application frameworks. This list always seemed way too big…

Source:  https://en.wikipedia.org/wiki/Comparison_of_server-side_web_frameworks

… as it represents an almost paralyzing set of choices. The list isn’t even complete as it does not include proprietary frameworks from the early days of Web-application servers such as NetDynamics and Kiva or include any number of custom/in-house frameworks that were never open-sourced. One way to interpret such variety is that it showcases the ingenuity of the overall Java development community.  There is truth to that. But a more pragmatic interpretation is that if there are that many frameworks attacking roughly the same problem it is also indicative of a technical community not working as efficiently as it should be. What happened here?

Broader Context

Every historical evaluation requires context, and there is a lot to unpack on this topic.  Java 1.0 was released in 1995 and its early years overlapped heavily with early years of the Internet as we know it today.  HTML, HTTP, and Web client programming patterns were all concurrently – and rapidly – evolving along with Java in the mid to late 1990’s. The HTML specification went from HTML2 in 1995 to having significant major versions being released in the same year (HTML 3.2 in January 1997, HTML 4.0 in December 1997), with HTML 4.0 being re-released in April 1998, and HTML 4.01 coming out in December 1999. The HTTP 0.9 specification came out in 1991, and then went 1.0 in 1996 with HTTP 1.1 coming out in 1997.

Those protocols were evolving and being implemented in a new software component called a Web browser which we now take for granted. The market share of browsers from that period saw significant year to year changes:

Source:  https://en.wikipedia.org/wiki/Usage_share_of_web_browsers

When Java came on the scene, Netscape was the dominant browser, but Microsoft’s Internet Explorer quickly started making headway. The reason browsers are so relevant to this post is that they are the execution environment for client-side Web development, with inevitable variations in terms of supported capabilities, patterns, and platforms between implementations. It can be difficult to establish a stable server-side Web framework if the client-side keeps changing radically.

This is also the period over antitrust investigations because of the bundling of Internet Explorer with the Windows operating system, with then-Microsoft CEO Bill Gates  deposed by the U.S. Government regarding Netscape. It is easy to forget that potential remedies of that case were Microsoft being split into multiple companies. There was a lot happening and a lot at stake. It is also worth noting that none of those early browsers exist anymore.

Web Client Programming

While it might seem obvious now that Javascript-in-the-browser would be the dominant web client programming pattern, this outcome was anything but obvious within the first few years of Java. There were multiple patterns contenting for dominance during this timeframe, such as:

• Java Applets
  • Java Applets were a client-programming model used to provide interactive features to Web applications within sandboxed Java Virtual Machine in the browser. 
  • Hopes were high for Applets, but adoption never quite took off as anticipated due to a variety of technical challenges.  Applets were also caught in the middle of Microsoft’s browser and Java lawsuits in the late 1990’s which didn’t help.
• JavaScript
  • JavaScript was first implemented in 1995 in the Netscape browser. 
  • This language was apparently originally going to be called LiveScript but was changed to JavaScript to take advantage of the marketing around Java, even though the language was not based on the Java Virtual Machine.  
• ActiveX Controls
  • ActiveX controls were a component model that was specific to Internet Explorer that were supported from 1996 to 2013.
• VBScript
  • VBScript first appeared in 1996 in Internet Explorer and was modelled on Visual Basic, another being Microsoft technology.

 

Java Web Application Framework Timeline

Web programmers during that timeframe were clearly living through some interesting times. The following is a timeline of a subset of the available Java Web Application frameworks to review which options were available when and why:

• Jakarta Servlet
  • Jakarta Servlets first appeared in 1996 as the Java Servlet API
  • This was a response to writing Web server Common Gateway Interface (CGI) programs in Perl or C/C++. Developers now had a way to write Web applications in Java, albeit at a fairly low-level.
• Jakarta Server Pages
  • Originally created in 1999 as Java Server Pages (JSPs) to extract view definition from Java servlet code to a templating mechanism.
• Struts1
  • Struts was created in 2000 as a reaction from developers who were frustrated with JSPs.
• Apache Tapestry
  • Apache Tapestry was first open sourced in 2002, and in 2004 was released as an Apache Jakarta sub-project.
  • Tapestry’s creator apparently wanted to have a Java implementation of WebObjects, which was closed source and based on Objective-C.
• Apache Click
  • Apache Click was created in 2003 and became an Apache project in 2009.
  • Apache Click was retired in 2014.
• Jakarta Server Faces
  • Jakarta Server Faces 1.0 came out in 2004 and were originally known as Java Server Faces (JSF). 
  • The 1.x version leveraged JSPs as the templating mechanism.  The 2.x leveraged another mechanism called Facelets, which were reportedly borrowing concepts implemented in Tapestry.
• Spring MVC
  • Spring MVC 1.0 came out in 2004.
  • Spring MVC was a reaction to Struts1, which in turn was a reaction to JSPs.
• Apache Wicket
  • Wicket came out in 2004 and became a top-level Apache project 2007.
  • Wicket was a reaction by developers who were not satisfied with Tapestry.
• Stripes
  • Stripes came out in 2005 and has been dormant since 2016.
  • Stripes was also a reaction to Struts1, which was a reaction to JSPs.
• Google Web Toolkit
  • Google Web Toolkit (GWT) came out in 2006 with a paradigm of supporting end to end Java. 
  • Java could be used on the backend, and then a subset of Java could be used for client programming which would be converted into JavaScript executing in the browser at runtime by GWT.
• Struts2
  • Struts2 came out in 2006.
  • Once more with Struts, this time with more feeling!
• Vaadin
  • Vaadin was created in 2009
  • Vaadin’s pre-2009 origins are similar to those of GWT in terms of supporting Java end-to-end, at one point even utilizing GWT.
  • Vaadin is a Finish word, providing further evidence of Java’s global appeal and that the namespace of Java Web Application frameworks was becoming increasingly crowded.

Again, with all due respect to the authors of each of the framework authors, this is just a subset of the options.

So What Happened?

This Is A Hard Problem…

In Java’s defense, few languages seem to do this well. Python is a very successful multi-purpose programming language, but it also has no shortage of web frameworks, although not as many as Java.

… But Not An Impossible Task

The Ruby programming language developed a niche in web development, but curiously the framework proliferation didn’t happen to the extent it did in Java or Python.  A few key frameworks emerged as the default option, particularly Ruby on Rails.

The Java ecosystem is much larger than Ruby’s so this isn’t an entirely an apples-to-apples comparison, but it still raises some interesting questions. Are Ruby developers not smart enough to create a cornucopia of complex and competing UI frameworks? Or perhaps it indicates that Ruby developers are if not smarter at least better organized to generally avoid that kind of problem in the first place.

Framework Creator Syndrome

The need to be a framework creator, instead of a framework contributor or user, can sometimes turn pathological. “Not invented here” can manifest in many ways and many places but I think it is amplified by the sophisticated Java ecosystem, which is populated by many talented software engineers who like to create things.  I think the syndrome could be an explanation for some of the framework overlaps, but not all of them.

“Java Is A Back-End Language”

I think that biggest contributing factor was a mindset that seemed to take hold of Java primarily being a “back-end language” and that the front-end was somebody else’s problem. Java was certainly very effective in server-side development. Java was, in fact, trying in the front-end arena as it had multiple thick-client user interface frameworks such as AWT, Swing, and Applets, but with mixed results. And Java was trying with Web development frameworks as well: JSPs and JSFs were also a part of the formal Java ecosystem.

The problem was one of efficacy and lack of a “default” Java web framework that had enough feature functionality, promotion, and adoption that the community could broadly stand behind—especially one that was a part of Core/Enterprise Java. This responsibility ultimately rested with the designers of Java. One could excuse the lack of such a default option existing from 1995 to 2000 due to the general chaos of the Web during that period as previously mentioned, as well as the emergence of Java-based web application servers which all initially had proprietary UI frameworks. But it seems like a stronger candidate framework could have formed thereafter as there was clearly a need. In lieu of that, the broader community had to largely keep addressing web development on their own, and arguably by 2006 the framework horses had left the figurative barn and there was no going back. Java developers deserve credit for continually seeking to innovate in this space, but it is unfortunate that the results became so fragmented.

References

• Related BLOG@CACM Posts
  • Why are there so many programming languages?
• Comparison of Server-Side Web Frameworks
  • https://en.wikipedia.org/wiki/Comparison_of_server-side_web_frameworks
• Browser Usage Share
  • https://en.wikipedia.org/wiki/Usage_share_of_web_browsers
• Microsoft Antitrust
  • https://en.wikipedia.org/wiki/United_States_v._Microsoft_Corp.

 

Doug Meil is a software architect in healthcare data management and analytics. He also founded the Cleveland Big Data Meetup in 2010. More of his BLOG@CACM posts can be found at https://www.linkedin.com/pulse/publications-doug-meil