Web Info & Tutorials

I sometimes get asked “why doesn’t Google eat it’s dogfood and use GWT”. I normally point them too:

• GWT has been out for just over a year (> 1 million downloads), so it is obvious that properties from 4 years ago may not be running GWT :)
• There are several parts of Google that do use GWT (such as Base)
• Just because we offer an open web toolkit doesn’t mean that it is the right tool for every web application out there.

We are starting to see more and more applications from Google make it out with a “powered by GWT” sticker. One high profile case is the new Google Mashup Editor which actually consists of three distinct parts:

• The Mashup Editor, which is itself an Ajax application.
• A server-side hosting framework, which provides developer services (e.g., source code management via Google Code project hosting) and mashup services such as Google Base and a data store that can be accessed via feeds.
• A JavaScript client library that implements the mashup UI controls and data processing functionality. The server-side components leverage Google’s scalable infrastructure and provide access to Google services via the Google data APIs protocol; the client-side components were developed exclusively using the Google Web Toolkit.

Rich Burdon, of the Google Mashup Editor team, wrote about why GWT was chosen. Here is a closer look:

Before starting the project, our team already had a lot of experience building complex AJAX applications by hand — and had experienced many of the problems associated with this approach. Here are some of the reasons why we chose to use GWT rather than rolling our own native JavaScript framework this time around:

1. Tools matter. As a veteran of the long-ago vi versus emacs debates, it’s interesting to see the same enthusiasm go into the Eclipse vs. IntelliJ IDE arguments. Whichever side you’re on (I fought for the latter in both cases, but we have members of both camps on our team), tools can make a huge difference in terms of developer productivity. You used to think twice before refactoring a large component that needed attention; having the tool take care of these kinds of complicated, repetitive (and error-prone) tasks makes life easier and can lead to better quality.
2. OO is a good idea. I remember figuring out how to make JavaScript objects polymorphic and finally understanding what a closure is. Indeed, my colleague Stephan Meschkat, who works on the Maps API, often reminds me of JavaScript’s inherent power and elegance. However, I like to have keywords like “interface,” “private,” and “final” at my disposal — even better to have my compiler (and my editor) remind me that I’m attempting to call a function with inappropriate arguments. Type safety saves debugging time, and OO abstractions can help to reduce complexity in your code.
3. Compatibility. Java’s original slogan of “write once, run anywhere” fell victim to the intense competition between browser developers. Although JavaScript, being a smaller core language, has fared somewhat better, the complexities of juggling different DOM implementations over a growing number of browser platforms makes writing cross-platform AJAX components difficult. GWT’s ability to insulate you from much of this complexity probably makes it a no-brainer for this benefit alone.
4. The client is only half the story. Both the Mashup Editor and the resulting mashups themselves interact with Google services; being able to code both sides of a remote method call in the same language has some obvious benefits. Aside from the relative simplicity afforded by the GWT RPC mechanism, both client and server components can share constant definitions and in some cases, simple functions.
5. Open systems are less scary. A programming framework is something that introduces abstractions. The benefits include making complex concepts simple and quicker to implement; the downside is that if you want to do something that the framework wasn’t designed for, you’re on your own. It was important for us to be able to get under the hood and tweak the native JavaScript. For example, the Mashup Editor’s template-processing functionality uses a native JavaScript library that we borrowed from the Google Maps API.

Christian Effenberger is back with some more Canvas goodness. He has created Edge.js, a library that lets you apply an image mask (in the form of another image) to any image via unobtrusive CSS.

You initialize via:

And then you can simple add classes to the image: class="edge imask1".

It was a feeling to foregather Dan Yoder terminal week, and correct after the word he pings me with an intent he grilled up titled Really Simple Data.

RSD is added accumulation format. Yup, you got it, still added yaml It tries to achive:

• The quote-free naivety of CSS.
• The plasticity of YAML.
• The meta-data friendliness of XML.
• The angle grammar of JSON.

Examples

RSD as an object:

CSS w/ Behaviours and nesting:

Dan has a employed JavaScript parser and a Ruby edition is forthcoming.

There was a lot of discussion around events and Safari on the iPhone, when it first came out.

Neil Roberts of SitePen has noted that with the iPhone 1.0.1 update, we have some fixes, and some new issues:

I’ve been following John Gruber on Twitter, who just noticed that the iPhone update (1.0.1) now updates Safari with the ability to send key events. Fantastic! 2 steps forward.

But, onkeyup is broken. You see, the onkeyup event is supposed to be called after a key event has officially propagated through the page. This is very important, because by the time onkeyup gets called, the page should have adjusted itself for this newly inserted character. For example, in a text input box, when you press a key it doesn’t show up in that input box until after onkeydown and onkeypress have been called, but does show up before onkeyup is called. Pretty much the whole reason that onkeyup hook exists at all, is so that you can be notified after this change has happened. The iPhone sends onkeyup before the page has been updated. 1 step back.

What this means is that sites that rely on using the onkeyup event to tell what is in their text entry box will break. There is a simple solution though! (other than having to find the key value in the event object) Just use setTimeout, with a timeout of 0 and you’ll be able to see the proper value. For example:

PLAIN TEXT

JAVASCRIPT:

1.  
2. input.onkeyup = function(e) {
3.     setTimeout(function(){ alert(e.target.value); }, 0);
4. }
5.