As some of you may know, I had the privilege of speaking at the GWT conference hosted by Pearson Education this past week. I was part of the GWT tools panel moderated by Adam Houghton, creator of GWTFlow. The rest of the panel included Eric Clayberg of Instantiations, Ray Cromwell CTO of Timepedia, and Fred Sauer creator of the gwt-dnd library. Being part of the tools panel was great, but I think that with most conferences, the really fun part were the discussions between talks.
Some of the more notable characters there were David Geary and Billy Hoffman. David is a veteran author, with his last book being one on GWT (of course I would still recommend GWT in Action!). It was great talking with David, and his presentation was really well done. His experience shows, and he knows how to entertain a crowd. Outside of his duties he was pretty easy to spot, he was the only one wearing shorts.
Billy Hoffman, a hacker, security researcher, and recently author, gave a talk on Ajax Security. He is extremely passionate about his work, and it really showed in his presentation. He covered a ton of material, and could have covered a ton more if given more time for his presentation. In talking with Billy, he had indicated that Ajax is very scary from a security standpoint. This is partially because the code examples that you find in developer documentation are riddled with security problems. His book was the only one I picked up during the conference, and although I just started reading it, it looks like it will provide me with a lot of useful knowledge.
Some of the others there were Bruce Johnson, Ryan Dewsbury, Rob Jellinghaus, Joel Webber, Scott Blum, and the list goes on and on and on. The best art is that none of them were there to push their books, promote Google, or push their products. Instead it was about furthering GWT, finding out how GWT has solved real world problems, and providing information to those new to GWT. Each night of the conference we would hold a free-form session to discuss ideas and talk about GWT.
In between sessions I was able to talk with a lot of interesting people and see some of their GWT work. And now that I have seen some of these real products using GWT I am completely blown away with what can be accomplished with GWT. For at least a couple of them, using GWT to build their project was their second or third try at getting it to work. It was both enlightening and encouraging.
So, without going on and on, let me say a few things. First, it was fantastic to finally meet in person those who I had only known over email. Second, it was great to meet all of you who had read my book or used the GWT-WL, and had nice things to say about it. I don't do this sort of stuff for money, so it was very encouraging and makes me want to do more. Third, we need to do it again soon! The conference was fantastic and we need to do this more often. And if you didn't make it to this one I hope to meet you at the next one.
It was great meeting you and doing the tools panel. I was amazed by the sheer number of people doing GWT applications and the number of people who wanted to contribute to GWT open source. The conference certainly surpassed my expectations.
Great to meet you too. What surprised me were the number of developers that were there just to find out more about GWT, and figure out if it is the right tool for their needs. It ended up being a nice mix of people.
There's a "standard model" that works for writing reliable, performant and secure RIAs -- it works for GWT, Flex, and Silverlight and plain old AJAX apps too.
The model is that one user UI action should cause one http request with the server and the server should send back a bundle that has everything needed to update client state and redraw.
Sound familiar? This is the proven model that conventional web applications use -- it works, unlike the generation of failed "client/server" apps we saw in the 90's that showed that the general problem of client/server choreography is too hard in practice; particularly with a system like GWT that offers very little support for dealing with concurrency.
Put all the business logic on the server; maybe you can do some form validation on the client, but do it again on the server. Since GWT lets you code with the same language on client and server, it's easy to reuse the same code.
Both client and server should send each other "state update" packets that bundle an arbitrary number of commands that are, preferentially, bundled into a single transaction.
Disregard at your own risk: put business logic on the client if you like, but don't expect your app to be secure.
Post a Comment