Our new cloud-based Members Only is in GW- What?Monday, June 6, 2011
(by Doria Howe)
The development team here has been in a fit of excitement for months about the tools they are using to build "Cumulus", our new web-based software for non-profits. I figured if I was going to have to talk to prospective users about the software, I'd better understand what all the fuss is about. So I sat Michael down and made him give me a tutorial.
Doria: So my first question is simple. We're using the Google Web Toolkit to build this app. What the heck is the Google Web Toolkit?
Doria: Actually, ecma sounds like something you could catch. But why is everything all about Javscript now. What about the other languages we used to use to build web apps? Like php?
Michael: OK. Let's think about viewing a web site as if you were watching a movie on-demand on your TV. The pictures you see are retrieved by some device at the cable company and sent out to you. If you decide to go back and watch a scene again, you click some controls on your remote that tell a device back at the cable company to resend those images. So we can say those images are managed at the "Back-End."
But what about when you turn up the contrast or brightness on the image? Those functions do not need to be sent to the cable company - they can be managed by the monitor you are watching on. We can say these commands are processed at the "front-end." A web-site is just like this. Some commands require action from the "back-end" - the web server - and others can be managed by the "front-end." -- the browser.
If you think about it, you'll see that the more that can be managed by the front end, which is right in your living room, the faster and more responsive the system will be. But some stuff MUST be managed in the back - for example, you don't store a million films in your TV set... you rely on some other company to that, so the images in the movie absolutely must come from the back-end. In a nutshell, the content management belongs on the back-end, and the display management on the front-end.
Doria: Is that how websites have always worked?
Michael: Originally, web sites were designed so that virtually everything was handled at the back end - by the web server. When you requested to see some other data, the server fetched that data, drew up a new page for you by inserting the data into an otherwise static html page, and sent you that fully formatted new page over the wire.
And since the pages are drawn dynamically, they can feel a lot more like the screens in traditional software, with drag and drop for example. So the recent history of web development is to move all the display-related functionality to the front, where it logically belongs. This style of programming is called AJAX - an acronym I'll explain some other day.
Doria: But GWT is not the only tool for building an AJAX site, is it?
Doria: Speaking of those other toolkits, what about an aftermarket? We've always been able to help our users get new functionality up and running quickly by using third-party tools for a lot of special purposes. Are there component libraries available for GWT? Or is it still too far out on the bleeding edge?
Michael: There are actually a lot of third party GWT tools around already. The same people who wrote the ExtJS library I mentioned earlier have created a product called GXT that provides a host of improved components for GWT. We're using it in our Cumulus product. But there are several other libraries and frameworks available as well, for example, just today I stumbled across a GWT charting library I want to try out called FusionCharts.
Doria: So how did Google end up creating a developers' tool anyway? That seems pretty far from their main line of business.
Michael: Google creates a lot of software and is always trying to improve that process. They purchased the first version of GWT - actually purchased the company that developed it - to use in their own development efforts. Gradually all of Google's apps are being rewritten in GWT. Adwords and Blogger are GWT apps, for example.
Doria: Thanks, Michael. Next time, I'm going to get you to explain SOAP.