DWR: State of the Union
So DWR is now part of the Dojo Foundation. I thought it would be good to quickly summarize where we are, and what I'm working on, and to give everyone a chance to comment.
DWR 2.0 has been out for 6 months or so. At the time, I swore that the next release would be a small one, called 2.1. However it appears that I’m not good at swearing because there is lots in the next release - I think we’re going to have to call it 3.0.
Just as a quick recap, here’s what changed with 2.0:
- Reverse Ajax which I define as Comet or Polling or Piggyback, whichever works best.
- Spring Namespace support, Guice support, Annotations etc.
- etc. Every release needs some etc. See the release notes for more.
Since 2.0, we've been working on the following adding support for JSON, Bayeux, images/binary file upload/download, a Hub with JMS/OAA support and more reverse ajax APIs. I also want to get some Gears integration going.
There are also a whole set of non-functional things to consider:
- Moving the website to directwebremoting.org
- Restart chasing CLAs, using a foundation CLA rather than a Getahead CLA
- Get some lawyer to create a CLA so Getahead can grant rights to the Foundation (or something similar)
- Get someone to pony up and let us move to SVN
- Unit tests
DWR Hub and integration with JMS and OpenAjax Hub: We have a hub, along with one way integration with JMS. The OpenAjax portion will be simple except for the getting the OpenAjax Hub to work smoothly with JMS part.
Reverse Ajax Proxy API Generator: The goal with this is a program that will take JavaScript as input, and output a Java API which, when called, generates JavaScript to send to a browser. Some of this work has been tricky, but then meta-meta-programming was always bound to be hard. This currently mostly works with TIBCO GI, but more work will be needed to allow it to extract type information from other APIs. You can see an example of how this is beginning to evolve in yesterday's article at The Server Side. I hope we will be able to create some Dojo integration for 3.0 too.
JSON support: One goal is a RESTian API so you can do something like this: http://example.com/dwr/json/ClassName/methodName/param1/param2 and DWR will reply with a JSON structure containing the result of calling className.methodName("param1", "param2"); It would be good to support JSONP along with this. We might also allow POSTing of JSON structures, although I’m less convinced about this because it quickly gets DWR specific, and then what’s the point of a standard. Status - DWR has always used a superset of JSON that I like to call JavaScript. We do this to cope with recursive data, XML objects, and such like. I’ve done most of the work so that DWR can use the JSON subset, but not created the ‘handler’ to interface between the web and a JSON data structure.
Bayeux Support: Greg Wilkins (Jetty) committed some changes to DWR, which need some tweaks to get working properly. Greg still intends to complete this.
File/Image Upload and Download: This allows a Java method to return an AWT BufferedImage and have that image turn up in the page, or to take or return an InputStream and have that populated from a file upload or offered as a file download. I’ve had some bug reports that it doesn’t work with some browsers, also we need to find a way to report progress to a web page simply. See this post on Ajaxian for more.
DOM Manipulation Library: Currently this is limited to window.alert, mostly because I’m not sure how far to take it. There are a set of things like history, location, close, confirm that could be useful from a server, and that are not typically abstracted by libraries.
Gears Integration: I’ve not started this, but it needs to take higher priority than it currently does. It would be very cool if DWR would transparently detect Gears, and then allow some form of guaranteed delivery including resending of messages if the network disappears for a while.
Website: We need to get the DWR website moved away from the Getahead server, and onto Foundation servers. There will be some URLs to alter as part of this, and I don’t want to lose Google juice by doing it badly. The documentation for DWR 2 was not up to the standards of 1.x, and while it has been getting better, we could still do more. One thing that has held this back has been lack of a DWR wiki. I hope we can fix this with the server move.
Source Repo: We are currently using CVS hosted by java.net. They support SVN, but want to charge us a few hundred dollars to upgrade. I expect to move away from collab.net/java.net CVS some time early next year.
Unit Tests: I've been trying for ages to find a way to automatically test with multiple browsers and servers. WebDriver looked good for a while, but it doesn't look like the project is going anywhere particularly quickly, so I'm back trying to get Selenium to act in a sane way.
Etc: There's always 'other stuff'. I've particularly not gone into things like Grizzly support. There's plenty of etc in this release too.
Browser Wars
Alex:
To get a better future, not only do we need a return to “the browser wars”, we need to applaud and use the hell out of “non-standard” features until such time as there’s a standard to cover equivalent functionality. Non-standard features are the future, and suggesting that they are somehow “bad” is to work against your own self-interest.
Ten years ago, in 1997, some people spent ages getting DHTML pages working across IE and Netscape, and when we were done we felt dirty and bruised. Some of us crawled back into our caves resolving that stabbing ones-self repeatedly with a sharp object was more preferable.
However, some people saw it as an opportunity.
In 2007, the people that saw it as an opportunity have created Dojo, YUI, JQuery etc. So this time around we're ready for them, and it doesn't have to hurt. This time around it's a matter of waiting for Alex, John etc to have taken all the pain and revved the frameworks.
Comparing the Evolution of Java and JavaScript
Java:
Java is the most used language in the known universe. It is also a very simple* language. Some people believe that there is some scope in enabling Java to accommodate more programming styles (e.g. functional programming via closures). Others believe that being lightweight is a virtue.
JavaScript:
JavaScript is the most deployed language in the known universe. It is also a very simple* language. Some people believe that there is some scope in enabling JavaScript to accommodate more programming styles (e.g. by adding classical inheritance not just prototypal inheritance, and an optional type system). Others believe that being lightweight is a virtue.
Features:
It's interesting that the current simple version of JavaScript already has the features (i.e. closures) that people want to keep out of Java otherwise it will become too complex, and that Java already has some of the features (i.e. classical inheritance) that people want to keep out of JavaScript, otherwise it will become to complex.
Crossroads:
The Java language is challenged by languages such as Ruby, Groovy and even Scala, all of which support closures. The majority of people that have spent serious time with these languages prefer them over Java for at least some set of problems.
The JavaScript language is challenged by Silverlight. Microsoft try to avoid saying things like "death to Ajax", but secretly (or not so secretly depending on who you talk to) they would love to control the platform once more, and Silverlight is the latest attempt at regaining control.
Features vs. Complexity:
Joel noticed that there is a big difference between good developers and bad developers. Google noticed it with it's picky hiring process. On many projects there are a few developers that do all the real work, while others just slow things down.
But much of the "keep complexity out of the language" debate is aimed at helping the people that write less code anyway.
Nail-guns and angle grinders are dangerous tools, but the building trade accepts the danger in the name of greater productivity. In software development where the difference between good and bad developers is that much greater, and where developers don't actually get physically maimed, the argument for power over simplicity is that much stronger.
In summary, extra power helps smarter developers work more quickly, but makes life harder for less smart developers. Since a small number of smarter developers generally do better work than a large number of no so smart developers, we should tend slightly toward giving developers more powerful tools.
Java:
In Java, BGGA closures enable higher-order programming. It's hard to say that the addition of closures in and of itself would cause a complexity implosion, after all, Java is virtually the only modern day programming language without them. It could be argued that the Java language can't be evolved to accommodate them, but I'm leaning towards there being a net gain by including them.
Interestingly, Google Android contains a clean room re-implementation of Java. If Sun (or the JCP) accepts closures, and if (as seems likely) Google votes against them, what will happen to Android? Will it follow how Google votes, or how Java evolves?
JavaScript:
With JavaScript, people see a neat, compact language and fear it turning into Java. The good news is that it won't fully turn into Java because JavaScript already has closures and no one thinks they should be taken out ;-) The danger of the "features over complexity" argument, is that it can be applied indiscriminately, creating a monster, and the fear is that JavaScript will become a monster.
I'm gradually coming round to the opinion that many of the changes proposed to JavaScript actually reduce complexity. There are nearly as many frameworks that add classical inheritance to JavaScript as there are Ajax frameworks. Having one solution that we can all agree on can't be a bad thing even if you prefer prototypal inheritance.
*: For some value of simple. The exact definitions of simple used in these 2 paragraphs are not necessarily the same.
Changes for DWR
This is very good news for DWR and for Ajax on Java.
The short version is that DWR is now part of the Dojo Foundation and that I now work for SitePen. This means that I'll be working nearly full-time on DWR rather than spending part of my time stuck in a big enterprise with Word as my IDE churning out technical architecture documents.
There are a whole bunch of questions that I just know I'm going to get asked:
Does this mean that DWR is going to become part of Dojo?
No. DWR will remain totally independent. There are some bits that I'd quite like to steal (JS compression for example) but you won't need to use Dojo if you want to use DWR or the other way around.
What's going to happen to Getahead and the DWR website?
For some time you've been able to visit www.directwebremoting.org and get redirected to the DWR website. We'll be moving the DWR website over to Dojo Foundation infrastructure and making use of the new domain at the same time. I'll be keeping my blog at Getahead for now at least. Consulting deals that Getahead would have done in the past will now be done by SitePen.
Who are SitePen?
SitePen employ a bunch of cool hackers: Alex Russell and Dylan Schiemann and many other Dojo people, Kevin Dangoor (Turbo Gears), and many more. They offer support packages for Dojo and now DWR, but also develop complete solutions.
What's happened to the TIBCO deal?
It's not gone away. I'll still be working to enhance DWR's Reverse Ajax proxy APIs, which from the next version of DWR particularly should aid DWR/GI integration.
Kevin Hakman from TIBCO is quoted on the official press release:
"Development teams, both small and large, have quickly discovered the benefits of using DWR in conjunction with leading Ajax libraries like Dojo, TIBCO General Interface, Scriptaculous, and others. DWR joining the Dojo Foundation is a great win for the DWR community," said Kevin Hakman, director, TIBCO Software, Inc. who has been a corporate sponsor of DWR's development for more than a year. "The close alignment of these projects, and the anticipated integration points between them, will serve to further simplify creating Ajax applications for Java developers."