GWT, EVA, and treating my NIHS.
Wednesday, January 16th, 2008As I age and develop more and more pragmatic realisations about engineering project management and what it takes to make a task not only technologically, but economically viable, I find that I am growing more successful in my battle with a syndrome from which I suffer more than most people — Not Invented Here Syndrome, otherwise known as reinventing the wheel.
NIHS is a particularly bad disease to have concomitantly with strong purist sensibilities toward programming as an art and a discipline, not merely a tool for accomplishing certain ends in a functional, utilitarian kind of way. (The latter, with some notable exceptions, is the dominant conception of it in the world of business. It’s “programming,” you see, not “software engineering.”) This leads to a basic intuition that does make business sense: the fundamental need for frameworks, libraries, decomposition, and code reuse. The reasons may boil down to a dilution of the economic facts with considerations of elegance, artfulness, simplicity and conceptual integrity on a detailed level, the result is the same.
However, the interaction of these sensibilities with a strong case of NIHS is particularly harmful in that it leads one to assume the task of developing such tools entirely on one’s own. I cannot recall how many ambitious open-source projects of mine have gotten bogged down in the need to fulfill a prerequisite gap with APIs, libraries, toolkits, utility routines, interfaces, hooks, etc., and thus never shipped — never saw the light of day.
So, I am currently working on EVA (Evariste Voice Arbiter), a SIP-based hosted VoIP billing / mediation solution based on OpenSER. It is most immediate in the Evariste software product pipeline. I conceived of it back in August and had spent much of the fall building the backend1 (primarily OpenSER and PostgreSQL stored procedures) on top of my day job, taking care to provision decent business infrastructure to support it along the way, including a bug tracking/issue tracking/development workflow management system, a relatively detailed specification, and concrete, enumerated project milestones, and indeed, even some testing methodologies.
When I finally got to the part where I start working on the front-end - the GUI interface for the web application that binds the front-end to the backend, and the associated web services to provide those hooks - it was my natural inclination as an NIHS sufferer to conceive of building an in-house PHP/AJAX framework with high-level web service interface capabilities using JSON as a transport. I began to develop it slowly and aimlessly, calling it EvPHPTK, and even meticulously documented the API and developed unit tests for every component.
Earlier this year, despite entreatments to consider it by Storm, I rejected the use of Symfony as a development framework for the PHP front-end. I also generally have taken a very sceptical view of dozens of toolkits with prebuilt PHP and AJAX widgets, such as Dojo. This has less to do with aversion to frameworks as such and more with the fact that I simply found them aesthetically displeasing from the vantage point of my purism on various fine points.
Long story short, I had some time to actually consider this in detail over the Christmas holiday and came to an epiphany that led me to throw away EvPHPTK and score a major goal against my NIHS. I am going to use Google Web Toolkit to build the front-end.
It’s a rather radical decision, all things considered, but I’d like to take a moment to elucidate why I think it is meritorious from a business and technical standpoint. It was not without considerable pain that I abandoned a darling premise of my software development methodologies and sold out to the exigencies of practicality.
The reality, is, however, that Evariste is not in the web application framework business. It is neither a product nor a core competency. And if EVA and the other ambitions I have for this business are to ever be realised, they are not going to materialise by sticking to my incumbent ways. I do not actually have time to write umpteen gazillion lines of JavaScript plumbing for XMLHttpRequest callbacks or intricate, application-specific DOM manipulation. I’m just way past any interest in that whatsoever. I don’t care.
For those not wholly familiar, GWT is a free web application development toolkit from Google that allows one to develop GUIs in Java, using API idioms and design patterns essentially familiar to those who have implemented GUIs in Swing or its legacy predecessor, AWT.
A cross-compiler then generates the appropriate JavaScript to perform all the necessary feats of “AJAXian” DHTML, DOM manipulation, and other interface mechanics. One of the key “selling points” of the framework is that this is done with a view toward the lowest common denominator of browser compatibility in this area, theoretically preventing one from worrying about the interoperation of the JavaScript with particular browsers or the handling of arcane browser quirks. To the extent that there is still room for incompatibility, it is going to be on the CSS side, as the framework requires all GUI elements to be styled outboard rather than nativising CSS manipulation via the DOM through its API routines.
The framework also implements a substantial subset of the core Java runtime environment (JRE) API, including support of most data primitives, collections, data structures, and associated manipulation classes. Thus, it is quite possible to accomplish many things programmatically within the GWT-powered application code apart from drawing the interface itself, to the extent that it is possible to accomplish anything of substance in Java on the application level.
In many ways, I loathe Java. What’s more, despite some experience with it (a large part of it in a second-level introductory CS course — the only one I ever took), I am not fundamentally a Java programmer by pedigree, and cannot claim any exceptional competency in it. However, I have come around to the persuasion that it is fundamentally good for one thing, and one thing only: building GUIs. This helps me see the value in GWT.
GWT does other neat things. It is very web-services oriented, and supports JSON readily and extensively. This makes it possible to readily couple it to a web services backend in another language; I certainly do not intend to do the web services backend in JSP (yuck!). Most likely the backend mediation will take place via a Perl dispatcher (with mod_perl). Thus, I have the satisfaction of knowing that neither the resulting generated code for the front-end nor the backend RPC callbacks will ultimately be in Java. The Java code ends up being more of a dialect - a descriptor - for the GUI than a runtime determinant of it.
Clint inquired why it is precisely that I do not consider using one of the PHP frameworks out there that accomplish similar things. The reasons are manifold; for one, I just do not like the frameworks that I have seen. They strike me as very incomplete in their functionality and design methodology, for one. I see one challenge of the development process handled very gracefully and artfully, and another one heavily stilted or left out in the cold entirely. A lot of them also seem very fly-by-night and whimsical, both in their essential conception and in their development history, and I am not endeared to the idea of adopting them as a dependency for a mission-critical commercial application.
Another big reason is that I am increasingly dissatisfied with PHP as a way to develop web applications. Rather unlike some of what’s been related to me in other jeremiads against PHP from folks like Brian or Jonathan, my reasons have little to do with its performance characteristics, scalability, its technical robustness, or compatibility issues.
It’s more that I just don’t see it in what is fundamentally a scripting language a way to design enterprise-worthy applications that appeals to me. If web applications are the new fashion, and nobody does standalone GUIs anymore, that’s good and fine; please, sign me up for the revolution, rifle in one hand, constitution in the other. But in that case, I want to be able to harness the paradigmatic benefits of doing a standalone GUI inside a web application context, from the ground up, end-to-end. Why does the development process have to be reduced to scriptable particles inside HTML pages? It’s high time I had my cake and ate it too.
In other words, I really shouldn’t have to write any HTML, use any templates, or provide bindings between static content and dynamic constructs at all if I am writing an application. That’s what appeals to me about using GWT; it lets me truly build a completely dynamic interface from scratch, and achieve a more wholesome, genuine separation of interface from underlying functionality — the ideal aim of all good programming.
It’s going to be a tough learning curve, for sure. Being neither a Java programmer nor experienced with GWT, I have little sense of design patterns or best practises or various other methodological intangibles that — unlike the basic learning of a programming language’s grammar and syntax — take years to achieve competency in. But I am very excited and optimistic about choosing GWT to drive my “web 2.0″ applications.
1 Yes, it is very sad that it takes me several months to do that. I used to be able to pull off such feats in a few days of solid, sustained work, but this isn’t high school anymore. 