Oh the buzz. Oh the excitement. Oh the AJaX Gods has released their secret sauce with an Apache license.

Google Web Toolkit allows one to develop AJaX web applications entirely in Java, and deploy as HTML/JavaScript.

This confirms what I said 354 days ago:

Questioning AJAX: In essence, you are developing a web application in name only. The expectations/experience impedance will be the down fall of AJAX.

From a development perspective, especially for new projects where I have a choice between Web vs. Swing (or some other GUI technology) the line needs to be drawn differently: Instead of dividing them up like this

• Web apps, including traditional (request/response) and AJAX
• GUI apps

I would divide them differently now

• Request/response web apps
• Rich apps, including AJAX web apps and GUI apps

Now that developing an AJaX application is really the same thing as developing a GUI application, I want to draw your attention to what Eric Burke said 776 days ago:

GUI Programming is Hard: Let me qualify what I said in the first paragraph. Creating a bad GUI is really, really easy. Creating a "good" GUI is really, really hard.

I'm not saying Google Web Toolkit is a bad thing. To the contrary, it's a very good thing. It means our ten year delusion that web page scripting could win over true GUI development like Windows, Swing, SWT, Cocoa, or even Motif, for that matter, is coming to an end. Web programming has just become the usage of another Toolkit, the GWT.

BTW, have you tried to google for "Google Web Toolkit" yesterday and early today? The hits are all irrelevant. I have to go to Yahoo!Search to find it. No, I'm not making this up. I was trying to find the home page link for this blog entry, and I have to use my CustomizeGoogle Firefox extension to try all the other search engines.

Ironic, isn't it.

Mark and Jonathan had a little Subversion problem today. They wanted to move a directory in the repo and had a hard time doing it.

I've been using Subversion for a long time and never had any problems with it. However, I had never attempted to move a directory. So I tried a little experiement with my toy repo using the svn command from Cygwin:

[weiqi@gao] $ svn co file:///var/svnroot
A    svnroot/trunk
A    svnroot/branches
A    svnroot/src
A    svnroot/src/foo.txt
A    svnroot/tags
Checked out revision 14.
[weiqi@gao] $ ls
svnroot/
[weiqi@gao] $ cd svnroot
[weiqi@gao] $ ls
branches/  src/  tags/  trunk/
[weiqi@gao] $ svn move src trunk
svn: Can't move 'trunk/src/.svn/props/foo.txt.svn-work.tmp' to 'trunk/src/.svn/p
rops/foo.txt.svn-work': Permission denied

I don't know what causes this problem. But the problem goes away if I performs a server side move (svn move file:///var/svnroot/src file:///var/svnroot/trunk).

---

"Why can't they just add the directory moving (and atomic commit) features to CVS?"

"The maintainers of CVS wrote Subversion."

---

And then there's Bazaar-NG (bzr). It's in both Cygwin and Fedora Core 5. I vaguely know that it's a new kind of source control system, but not much more. I read about it on Mark Shuttleworth's blog 10 days ago.

Mark Shuttleworth, for those who don't already know, is the man behind the Ubuntu Linux distribution. (He was on stage with Jonathan Schwartz at JavaOne on Tuesday announcing the availability of Java in Debian and Ubuntu repositories.)

Bzr is definitely different from CVS and Subversion. Their tutorial is easy to follow. And I like the fact that I'm always working in a branch and can commit to my branch without bothering other developers. However, some of the other features are not so easy to get used to. For example, there is not a central repository. (I guess that's why it is called a decentralized source control system.) Everybody has his own branch, which they can push to a web site for others to marvel at. And everybody can merge from everybody else's branch.

It also seems to me that all the revisions are stored in a .bar subdirectory of the working directory, just like in the SCCS days. If I loose my hard drive, I loose my branch.

What do you do when you want to release version 1.0? Whose branch do you use?

However, this blog entry from Tom Albers shows a different scenario where bzr's usage may add value. Because you can very easily bring any old directory laying around your hard drive under bzr's control (bzr init; bzr add; bzr commit;) you can version directories that isn't normally versioned.