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…
… 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?
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:
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
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:
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.
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
As if to prove the point, someone pointed out that I had forgotten to include Apache Cocoon, another framework that dates to 1998. https://cocoon.apache.org/
Displaying 1 comment