Today we have Bruce Johnson of the GWT team talking to us about GWT 1.5. He discusses the new features, such as the long awaited Java 5 language support, performance improvements, and much more.
It is very nice to take an application, run it through the new GWT 1.5 compiler, and get an instantly faster running application “for free”.
There are terms of use that you should abide by, and some other comments:
An area to pay special attention to relates to correctly identifying
yourself in your requests. Applications MUST always include a valid and accurate http referer header in their requests. In addition, we ask, but do not require, that each request contains a valid API Key. By providing a key, your application provides us with a secondary identification mechanism that is useful should we need to contact you in order to correct any problems.
Check out the updated documentation for more details on each API:
I had a funny feeling that we would see frameworks and tools starting to support Google App Engine. Appcelerator has added support into their SDK, so you can now create an App Engine project.
<divclass="logo" on="click then script[window.location.href='http://www.appcelerant.com/?p=54']"><h1style="display: none">App Tunes</h1></div>
<divclass="powered_by" on="click then script[window.location.href='http://www.appcelerator.org/']"><h4style="display: none">Powered By Appcelerator</h4></div>
</div>
<divid="body"style="visibility: hidden" on="l:app.compiled then visible">
<app :as_flexflow id="flow" on="r:get.albums.response then execute or r:select.album.response then select"
I have been really looking forward to seeing the Google App Engine launch, and get in the hands of developers. This is just a preview release, and I obviously would like to see more languages and frameworks above and beyond Python and what we have now. The non-Pythonistas will all be saying "what about [insert my language and framework]". Slowly, slowly, catchy, monkey.
What is the Google App Engine?
Google App Engine lets you run your web applications on Google's infrastructure. App Engine applications are easy to build, easy to maintain, and easy to scale as your traffic and data storage needs grow. With App Engine, there are no servers to maintain: You just upload your application, and it's ready to serve your users.
You can serve your app using a free domain name on the appspot.com domain, or use Google Apps to serve it from your own domain. You can share your application with the world, or limit access to members of your organization.
App Engine costs nothing to get started. Sign up for a free account, and you can develop and publish your application for the world to see, at no charge and with no obligation. A free account can use up to 500MB of persistent storage and enough CPU and bandwidth for about 5 million page views a month.
During the preview release of Google App Engine, only free accounts are available. In the near future, you will be able to purchase additional computing resources.
You have to understand the limitations, and the model that is being used. In my mind this is very different than other solutions like EC2/S3. There are very different use cases at work choosing between a low level (and hence very flexible!) provisioning system like EC2, and a deployment solution that gives you a sandbox to deploy applications. Google App Engine is a full stack.
The stack gives you access to Bigtable, which also means that you are not in the world of booting up MySQL. You do things "the Google way" and some people will like it, and some will not. That is fine!
What excites me about this, is that I often have a bunch of little applications that need a host. Sometimes it can be a pain to setup. Other times you would like to make the service public but don't want people to go hog wild and give you bandwidth costs and contention for your other apps on your host. Now I have a simple place to put these little apps, and this is where Ajax comes in.
As we develop richer applications with more client side logic, and natural service separations, we can create these modules as Google App Engine apps that do one thing well. There will be a natural fit for applications built with GWT, Flex, and other rich component toolkits.
Google App Engine doesn't give you something that you couldn't do in an Ajax application, but it does give you a place to throw up these services in short order. This is one step on the way to the world of DEPLOY. There are other services with different tradeoffs, such as Heroku.
I would love to see JavaScript on the server as an option, but that is back to language wars....
NOTE: Google I/O is a conference being held at San Francisco on May 28-29 2008. APIs like this will be talked about. I will be there. And lots of good folks will be there (Steve Souders, Mark Lucovsky, Guido van Rossum, Jeff Dean, Chris DiBona, Josh Bloch).
The team used a lot of the principles from Steve Souders book: High Performance Web Sites and ended up with a nice gain:
According to our latency measurement stats, the user-perceived latency on Google Code dropped quite a bit, anywhere between 30% and 70% depending on the page. This is a huge return for relatively small investments we've made along the way, and we hope you'll find these techniques useful for your own web development as well.
The changes were low hanging fruit that most of the sites could also implement:
Combined and minimized JavaScript and CSS files used throughout the site
Implemented CSS sprites for frequently-used images
Implemented lazy loading of Google AJAX APIs loader module (google.load)
I have seen the huge batches of cell phones that companies keep around to test their applications on. Companies like UI Evolution have come along to try to help out the madness of getting something that works across more than a couple of them.
Not only do you have the problems of handsets, but you also have the network lock-downs and the hoops you have to go through to get an application onto a large set of devices.
Since the iPhone, I have strongly believed that history is going to repeat itself, and the Web is going to win on the mobile.
Today we're announcing the launch of Google Gears for mobile, a mobile browser extension for creating rich web applications for mobile devices. The first version is now available for Internet Explorer Mobile on Windows Mobile 5 and 6. It's a fully functional port of Google Gears v0.2 that can be used to develop offline capability into your mobile web applications. You can also create slick and responsive applications by hiding latency issues through controlled caching of data and storage of information between sessions. We're also working to bring Google Gears for mobile to Android and other mobile platforms with capable web browsers.
There are already a handful of Windows Mobile web apps that use Google Gears for mobile, such as the social payment service Buxfer and online applications provider Zoho. Read more about these applications and how they use Google Gears for mobile on the Google mobile blog.
I got to fly back home to London to talk to members of the mobile team. Below is an interview with a couple of the engineers, and there is also a high level look at the news:
I am really excited about what this means for the future of mobile development. I want to be able to develop applications using Ajax on the phone, and see tools like Gears give me access to native APIs on those devices. I really hope that the iPhone SDK also offers more on the JavaScript API side too (as well as Cocoa). How nice would it be to take your iPhone app and finally get some onPinch goodness, and camera.takePhoto.
Ben Lisbakken, who sits 100 feet away from me, developed gearsAJAXHelper, a library that bridges the AJAX search and feed APIs with Gears, to get a speed improvement:
We decided it would be cool to write a small library to make it easy for you AJAX APIs developers to write quick-loading, always fresh searches/feeds. The gearsAJAXHelper has two main features - it allows you to store and return key/value pairs from the local database, and it allows you to choose whether you want all resources files on the page (images, CSS, Javascript, HTML) to automatically be cached in the Gears cache.
The key/value pair database feature let's you store the query/results as a key/value pair. Then, the next time the query is made, the results can be served from the database while fresh results are being retrieved. This dramatically reduces the latency in queries/feed grabs.
The (optional) automatic cacheing of resource files will make it so that each time the user visits your webpage they will be getting resources served from their Google Gears cache, not new versions from the internet. Be careful when using this feature, as you might not want stale content to be served. There is also a refresh function, to clear the Google Gears cache of old files.
You can take a look at the sample, that saves the content for presidential candidates so if you click back on an area, you get instant loads.
Gears gives you all of the components that you need to take your application offline. If you have the type of application that for now wants to just take some of its content offline, that should be trivial to do right?
That was Brad Neuberg's position, so he created Gears PubTools as a way to make that happen. These tools are for content authors that don't even want to touch JavaScript.
How you use it?
Point to a Gears manifest file (a special file that lists all the pages to take offline) with a simple HTML attribute:
NOTE: This shows the Desktop Shortcut API that you can use in any offline application.
You don't even have to write the manifest file yourself! PubTools includes a simple bookmarklet that developers can drag to their browser's toolbar. Just navigate to the web pages you want offline, press the "Generate Manifest" bookmarklet, and a dialog will appear with the full manifest file generated for you ready to cut and paste into a file.
The core Google Gears gives us the building blocks that we can then build on top of to give users really easy tools and APIs. It has been great to see Brad join the Gears team and see him work on some of these issues. I expect to see much more from him in the future. What would you like to see?
New modules: HttpRequest and Timer. The main reason for these modules was that developers told us they wanted to make HTTP requests and create timers inside Gears workers. But these modules can also be used outside of workers. For example, one advantage to using the Gears HttpRequest module instead of normal XMLHttpRequest is that Gears HttpRequest module addresses a common problem making comet-style applications work on IE.
Improved support for handling errors in workers. This is an area where we received a lot of good feedback. Now, errors from workers are automatically bubbled up to the main page by default so that you can see them in the error console or in Firebug. Or, you can handle them explicitly with the new onerror event.
Ability to load workers from a URL, even cross-domain URLs. We've long wanted the ability to load workers from a URL. We've also wanted to provide a way for different domains to communicate safely. This is useful in the case of mashups, or when an application spans multiple domains. The new createWorkerFromUrl API solves both these problems.
Now 0.2 is in production, the Gears team can look to 0.3 and items such as:
Would you like to be able to make a quick call to get a JSON response that ties together a social graph made up of resources available on the Web?
Brad Fitzpatrick, Kevin Marks, and others at Google have released a new Social Graph API that does just that:
The new Social Graph API makes information about the public connections between people on the Web easily available and useful. You can make it easy for users to bring their existing social connections into a new website and as a result, users will spend less time rebuilding their social networks and more time giving your app the love it deserves.
Here's how it works: we crawl the Web to find publicly declared relationships between people's accounts, just like Google crawls the Web for links between pages. But instead of returning links to HTML documents, the API returns JSON data structures representing the social relationships we discovered from all the XFN and FOAF. When a user signs up for your app, you can use the API to remind them who they've said they're friends with on other sites and ask them if they want to be friends on your new site.
This is exciting to me as:
It actually uses the microformat standards such as XFN
, Interview
