The Google Web Toolkit (GWT) has held the promise of web-programming nirvana since it's introduction a few years back. Yet in practice, it has fallen short of it's heavenly goals for several reasons. First of all, it adds minutes to a code-compile-test cycle that coders have gotten used to taking seconds. Debugging in the GWT shell requires the patience of a saint. And lastly, it forces an awkward split between the code that runs on the browser and the code that runs on the server.
Admittedly, most of these problems and more exist in traditional web-programming environments, which is why I've always considered the browser-based apps as a huge step backwards in user interfaces, both in terms of coding them and using them. It also means that anyone with the wherewith-all to do web coding are the stars of the coding world. Everything is moving to the web, from games to business app, and if you're not on the band-wagon, your going to be the COBOL coders of the modern era.
GWT was supposed to solve all that by allowing all web coding in Java, there-by allowing the great abundance of Java tools to be used, and anyone with Java skills to become a web-programming star. It was genuinely easy to create the ubiquitous 'hello world' web app and have it up on your browser in seconds. The problem is that it didn't scale. The minute you tried to do anything real with it, the compile time started taking forever. You couldn't split up your code and have some of it pre-compiled, everything that ran on the browser side had to be compiled in one step. Add to that the lack of libraries and features that Java programmers have gotten used to over the years. You couldn't use one of the many XML libraries available, you were stuck with a very basic XML parser. There wasn't a tradition 'Class' object so no introspection, or dynamic object creating, which is the main-stay of anyone that is trying to separate out application code from architectural code. One way of over-coming much of this was to move code over to the server side which had access to the complete richness of the Java language and libraries. In all MVC architectures that I've seen thus far, this was done by splitting the model side and providing a synchronization layer between the client and the server.
Then, last week I was reading on the Archiva developers mail list about a planned refactoring, which would include the UI. It was suggested to use GWT for the UI, but Vaadin was also mentioned as a possibility. I had not heard of Vaadin before, so I did a quick google search for it and looked through some sample code that they had. It looked a lot like a GWT app, a module that was loaded at the start, creating a UI with java classes, a simple model binding for the UI. I was amazed when I downloaded it and compile it, it compiled in seconds, with only the standard Java compiler, and yet it ran like a full browser app. Where was the GWT compiler? How was all this UI code running in the server? There was no messy configuration, no limitations on the Java code. It was like compiling a simple Swing program, but it ran in the browser, just like a GWT program.
I had to find out what the magic was behind all this. After digging around a bit, I discovered that they had made a fundamental shift in the MVC architecture. Instead of splitting the model and keeping it synchronized, they split the client. Aha! all of a sudden, the possibilities became apparent. The Vaadin library had come from a different place, by creating an abstract terminal model for the browser prior to the advent of GWT. When GWT came along they adopted it into their model. Now we could have a GWT app, with most of the programming done in the server. The only time you needed to deal with GWT is when creating custom widgets.
I wanted to put Vaadin to use, and I had been working on my factory model application during my spare time for several week prior (as I mentioned in my last post on JAXB/JPA). I decided to created a GUI front-end for that model with Vaadin. In almost no time, I adapted their form example to my part object, so now I had a simple CRUD (Create-Read-Update-Delete) form for parts. Then, I adapted that form for stockroom, with equal ease. I factored out a basic CRUD form, and then created forms for all of the static objects in the factory model. I added drop-down lists for all one-to-n relationships that had a reasonably small n-count, and the dual-list chooser for n-to-n relationships. Basically, I had created a substantial fraction of an entire business application in just a few spare hours over a few days. The great part was that it worked without coercion directly with all my JPA objects. Here was a library that 'just works' with JPA. Most of the nuances of servlet programming were invisible to me (everything ran inside a session). And I had none of the issues of dealing with the browser.
The Aha moment wasn't actually mine, it was a 'domino' Aha moment. Obviously the people at Vaadin (which is a Finnish word for a semi-domesticated adult female reindeer) had the initial moment when they had the fore-sight to tame the web side by creating the abstract terminal model. They then embraced GWT as the language of choice for creating the web side of the terminal model. For me, the Aha moment was the sudden realization of all the possibilities that this confluence enabled.
I will continue to work with this library to see how well it does for other typical web application stumbling blocks such as grids for large tables, and editable grids. It has been a pleasure to work with so-far, hopefully it scales well, and is easily adaptable. If it continues to make coding fun, it will certainly become my primary means of coding for the web. I think that basic GWT still has a place, especially for browser applications that don't conform to the terminal model.
No comments:
Post a Comment