There’s a new contest on GWT Site, and it’s the biggest one yet. There’s 16 prizes to be won, including EXT GWT and GWT Designer licences and copies of three different books on GWT. To enter, you just need to subscribe to the sites email newsletter and/or add a comment to the blog post.
Good luck!
Adam
First of all, I would like to apologize everybody for not writing for the last two months or so. I’ve been so swamped with work, that I didn’t even have time to read all my feeds in Google Reader - not even speaking of writing something here. Hopefully now, I’ll find a little more time for that. So without any further ado, let’s get to the topic of today’s post.
Lately, I’ve been doing some work with Grails on a custom back-office application for a medium sized company here in Krakow. The application isn’t very complex - mostly CRUD operations, nothing really complicated. We chose Grails as our Web Framework, because we think it’s ideally suited for this type of stuff (talk about Rapid Application Development…). At some point we decided to add some Dynamic HTML/AJAX features - dynamic grids, that load data from the server without refreshing the page, some animation here and there, some dynamic menus, dialogs etc.
My first JS library (if you can call it that) of choice has been GWT. For some time I’ve played with Ext GWT (I know I bashed it before on this bog, but we didn’t really mind the application going GPL here). What I’ve found out, is that GWT isn’t especially well suited as as sprinkle-on-top solution for “ajaxifying” your site. Don’t get me wrong - I love GWT, it has no match for creating a fat-client JS application: the Swing like UI programming, static typing, all the Java IDE goodness at your disposal, and to top that performance and cross-browser compatibility. Even if I had to program every widget by myself, I’d choose it any day over any other solution. The problems start when you just want to add a little of the AJAX magic here and there in an existing application. In such case, more often than inserting some widget into a div on a HTML page, you want to manipulate the DOM tree. Sometimes you don’t want to have the code that decides what to insert where placed in the GWT module - maybe you want to have some function like insertGridHere() with parameters indicating stuff like URL to take the data from, title of the grid, etc. that could be placed anywhere in the HTML code of your page.
GWT hasn’t been designed with stuff like that in mind - the DOM manipulation API has been only available since version 1.5 RC2, and it only provides some basic DOM manipulation methods - nothing like JQuery, for example. Speaking of devil - a couple of months back Timepedia announced GQuery - a GWT port of JQuery library. I have high hopes for this library, although without commercial support, or even half-decent documentation I don’t think it will be able to take off. I would really like to see people developing plugins for GQuery, like they do for JQuery. You see - the strength of JQuery doesn’t lie as much in it’s excellent support for DOM manipulation, special effects etc. it’s in the plethora of plugins available for it. Want a AJAX-enabled grid control? - there’s like 5 of them. Modal windows, tooltips, accordions? Everything you could imagine is there, and often there’s more than one option to choose from.
Even though I started implementing the dynamic features of my application in GWT, I’ve switched to JQuery along the way. It has it’s disadvantages - I’m never sure if the code I write will run in every browser we want to support (big, big, big disadvantage), the code is not obfuscated in any way (although this can be prevented by using a JS minifier). I also find that I much prefer to organize my code into many little .js files (for better readability), which in turn makes my application initialize slower (I need to use .js packer). The advantages however include having the aforementioned plethora of plugins available at my disposal, each of which is usually designed to be used separately (unlike the usually tightly integrated libraries like Ext GWT). Most of the time the JS code is a lot less verbose than the corresponding Java code I’d have to write to implement the same functionality.
Although for now my first choice for “sprinkle-on-top” AJAX applications is JQuery, I’d really like to go back to GWT. The lack of cross-browser compatibility of the code I write in JS is really annoying. To have the abilities of JQuery, combined with even a friction the number of plugins available for it, and the features of GWT like Java programming language (code organization, code documentation, automatic refactoring, code completition etc.), highly minified and performant code it produces and many other advantages it has, would be a dream come true.
In my opinion GQuery should be adopted by the core GWT team and incorporated into the framework as an addition to the DOM manipulation features it already has. This would probably result a number of plugins springing up to life, and better support for the library. It would also greatly increase the GWT’s abilities to enhance existing web applications. Other than that I’d like to see some kind of ability to define JS libraries in GWT with a public interface, that could be called directly from JavaScript on a HTML page. An interface like that could be probably already defined with a mix of pure JavaScript and JSNI, but why resolve to dirty hacks, when we could have this use-case covered in the core library?
And how about you? Are you using GWT to enhance existing applications? Should GWT even be used for that? What kind of features would you like to see added to the core library, to help you with that task?
A couple of days ago, Sanjiv Jivan announced the names of the new members of the Gwt-Ext project. This comes after his decision to step down as a project lead, which was triggered by the Ext JS license change (and the discussion that followed). I don’t really want to summarize the argument between Sanjiv and Jack Slockum (Ext JS main contributor). Below are the links to the relevant blog posts:
As of now, the Gwt-Ext project supports only the LGPL(ish) Ext JS 2.0.2, and not the GPL 2.1 version. I strongly support that decision, but cannot help but to wonder if the Gwt-Ext project still has a future. Gwt-Ext is a GWT wrapper for Ext JS, and as such should do it’s best to support the current version of the wrapped library. On the other hand, a huge selling point for it was that it was free (as in free beer), and going in the other direction, would mean loosing that advantage. How will the new contributors deal with adding new features to Gwt-Ext? As long as they were wrapping Ext JS, they only had to wait for the Ext team to add some feature and wrap it, now they will have to start thinking about adding new stuff by themselves. Won’t that be too much of a burden? I really admire Sanjiv Jivan’s work, so it’s not easy for me to say that I don’t really see a future ahead of his project. It’s by no means his fault, and I really hope I’m wrong. There is just no right direction in which the Gwt-Ext project can turn, and any decision made by the team will probably be a wrong one. This pretty much signals that Gwt-Ext will soon face extinction.
This brings me to the main point, which I meant to discuss in this post. How much this Ext JS license changing business affects the GWT library landscape? You may remember Gwt Site having a contest for the most popular GWT library, here you can find the results of that contest, and below you can read the Top 5 GWT 3rd part libraries as of January 14th 2008:
As you can see, the two most popular of those libraries are Ext Js based. MyGWT, now an Ext product rebranded to Ext GWT (for the sake of clarity I’ll refrain here from using that name in favor of MyGWT), is a library that directly competes with Gwt-Ext, but written completely in Java. The earlier versions of MyGwt used only Ext JS images, version 1.0 uses also it’s CSS stylesheets. With Darrell Meyer joining the Ext team, the license/business model change also affected MyGWT (despite Darrell announcing that MyGWT will stay LGPL in 1.0 earlier on MyGWT forums).
Today of the two most popular GWT libraries, one changed it’s licence, and is no longer freeware, and the other one’s fate is still uncertain. I don’t have a problem with paying for MyGwt, mind you. Actually, if Darrell announced the change a couple of months back, I probably wouldn’t complain at all. It’s pretty common to pay license fees for widget libraries after all. The problem for me is that the licensing terms seem no longer to be in Darrell’s hands, but Jack Slockum’s and I just plainly don’t trust that guy at all.s For all I know tomorrow MyGwt might be AGPL/Commercial and God knows how the commercial licence terms will change in future. Charges per deployment / user/ CPU - everything seems possible if Jack decides that he’s still making not enough money out of his library.
I have mentioned before the OpenEXT project, which is going to be a set of patches that you apply onto the Ext 2.0.2, this way conforming to it’s license and being effectively a fork of Ext JS. I think it would be great to see someone doing something simmilar with MyGwt. MyGwt was licensed under pure LGPL license, with the exception of the so called “assets” (css and image files). Maybe it would be possible to create a real fork of this project given that it’s only dependency on Ext JS lies in the assets? I don’t feel up to the task, but I still hope that someone will eventually step up:)
For me, both MyGWT and Gwt-Ext are now practically useless. It’s a real shame since these are really wonderful tools for creating slick-looking back-office applications. However I cannot invest my time (and therefore money) in creating software using a tool, which might stagnate or become no longer supported (Gwt-Ext), and I don’t want to give money to an unethical and greedy company owned by Jack Slockum. So what can be used instead of those two libraries? I’ll propably check out IT Mill Toolkit which is licensed under Apache 2.0 licence, or maybe just stick with plain old GWT widgets - the new showcase application looks pretty nice, and there will be three styles to choose from. Anyway I think that with recent developments, a place has opened in the market for a new Gwt-Ext/MyGwt-like library. Hopefully it will emerge soon.
When Ext license change topic was still hot, one of the bloggers wrote a nice post titled “Ext Discovers Step 2 of the Slashdot Business Model?“. To thank you for reading this pretty long post, I’ve decided to add an episode clip from South Park, which I thought about immediately after reading his post. Unluckily for us, Ext JS team has discovered what the step 2 is…
Cheers!
Psyho
Not everybody knows that you can specify for some ant targets to run only when some set of files was updated. It is particullary useful when working with GWT or Ivy.
In my GWT projects I usually have tasks like run-shell (which runs a hosted-mode browser) and compile-gwt (which runs the GWT compiler). The run-shell task depends on the compile-gwt task, but this would cause my GWT code to be recompiled every time I run the hosted browser. You may ask - why would you even rerun GWT shell, if you didn’t modify any of the GWT source files? The answer is quite simple - sometimes you don’t make any changes on the client, but only on the server-side and wan’t to see how these changes affect the client. Or maybe you just don’t want to recompile your GWT code every time you need to create the .war file and deploy your application or run ivy:retrieve everytime you run your build script. Anyway, I find this trick pretty usefull.
So how does the magic hapen? The whole trick is possible thanks to Ant’s uptodate core task. Below is the snippet from the example build.xml file:
<uptodate property="gwtBuild.notRequired"
targetfile=".gwtBuild">
<srcfiles dir="src"/>
</uptodate>
Uptodate task sets Ant property (here called “gwtBuild.notRequired”) when targetfile is newer (more up-to-date) than any of the files in the srcfiles fileset. Here I’m comparing it to the all directory contents, but srcfiles is a normal ant fileset so you can always use include and exclude tasks within. You can also use mapper subtask instead of targetfile for more complicated use cases.
So now that we know how the magic is done, it’s time to put it to a good use:
<target name="compile-gwt" unless="gwtBuild.notRequired">
<!-- invoke the GWT compiler here -->
<touch file=".gwtBuild"/>
</target>
The touch target will create .gwtBuild file if it doesn’t exist or update it’s last modified time otherwise. It should be invoked after the compilation succeeds, bacause if it wasn’t, in case of compilation failure the target would not be executed again unless any of the source files was modified. The “compile-gwt” target will execute only if the gwtBuild.notRequired property is not set thanks to the “unless” attribute.
Now for the finishing touch we need to delete the flag file in our clean task:
<target name="clean">
<!-- Delete the flag file for compile-gwt -->
<delete file=".gwtBuild"/>
<!-- Delete other files and directories -->
</target>
To illustrate usage of this technique I’m attaching to this post a simple GWT project with an Ant script. The project was tested on Windows with GWT 1.5M1 and GWT 1.4.61. To run it simply change the gwt.home property in build.properties file to point to your GWT installation directory.
Click here to download sample project
Hope you’ll find this tip usefull:)
Psyho