Our new cloud-based Members Only is in GW- What?

Monday, June 6, 2011

Our new cloud-based Members Only is in GW- What?(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?
Michael: Google Web Toolkit (GWT) is an open-source web development environment that lets developers code both the front-end and back-end of a web app in Java. It then converts the front-end to Javascript, building different versions to handle the differences between browsers.

Doria: Why not just write everything in Javascript ourselves?
Michael: Because Javascript is so difficult to maintain. Difficult to debug. We'd need to worry a lot more about browser differences. For a lot of reasons programmers can be more productive in Java. We have access to the full set of Java tools for debugging and testing. This means creating and maintaining the software is quicker for us - and cheaper for users.

Doria: Aren't Java and Javascript pretty much the same anyway? Converting from Java to Javascript sounds like much ado about nothing.
Michael:  I know it seems odd, but Java and Javascript are totally different languages that have very little to do with each other except the name Java. Javascript was originally called "ecmascript", but people thought it ecma was not very catchy.

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: Php is a language used on the back-end. Javascript has become the universally supported language that runs in the front-end, in the browser.


Doria: OK, let's roll back for a minute. I hear you developers talking about the front-end and the back-end all the time. What does that really mean?

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.
Modern sites just ask the server for the data, and have a program that runs in the browser re-draw the parts of the page that have changed. There is less to transmit, and less to render visually - hence a much faster result all around.

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?
Michael. Not at all - but in our view, it's the best. There are a number of very full-featured Javascript frameworks available for creating these front-ends directly in Javascript. jQuery and ExtJS come to my mind immediately. But GWT has all those advantages I've already listed, advantages that make the programmer more productive - which in the end, keeps the cost down for the buyer.


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: But does this lock us and our users into needing GWT versions of everything? Like what about that nice free Javascript slide show program we've been using? Do we need to rewrite that in GWT now? Doesn't this cut our users off from a lot of tools out there?
Michael: Actually, not at all. GWT let's us use native Javascript anywhere we wish. That slide show is a perfect example. There is a lot of free open source Javascript we'd hate to lose access to. For example, the HTML editor we're using is a Javascript tool. We're using it in the GWT program with no difficulty.

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. 



 

Powered by Orchid Suites
Orchid ver. 4.7.6.