Activate your free membership today | Log-in

Friday, June 5th, 2009

Page Speed: New open source Firebug performance extension from Google

Category: Google, Performance, Utility

Richard Rabbat and Bryan McQuade have introduced a new tool called Page Speed that is a fully open source (e.g. it has a public bug database, process for accepting code contributions, roadmap, etc) performance Firebug plugin:

Page Speed is a tool we’ve been using internally to improve the performance of our web pages — it’s a Firefox Add-on integrated with Firebug. When you run Page Speed, you get immediate suggestions on how you can change your web pages to improve their speed. For example, Page Speed automatically optimizes images for you, giving you a compressed image that you can use immediately on your web site. It also identifies issues such as JavaScript and CSS loaded by your page that wasn’t actually used to display the page, which can help reduce time your users spend waiting for the page to download and display.

People will obviously compare it to YSlow (I wish they called it GFast ;) but there are some differences beyond the fact that it is Open Source which will hopefully allow a community to grow:

  • Not only will the tool note that images can be optimized, but it will do the work for you!
  • It automatically minifies your JavaScript for you and outputs it so you can use that
  • Profile Deferrable Javascript option will automatically identify candidates for lazy loading
  • An enhanced net panel with a better into cache hits and misses. I believe this is written in C++, so it gets around the “in process” limitations of Firebug’s Net Panel.
  • Many different rules and checks

A must see performance tool to add to your belt. You can check out all of the rules and enjoy the tool!

Posted by Dion Almaer at 12:53 am
11 Comments

++++-
4.4 rating from 44 votes

Friday, May 29th, 2009

Web Storage Portability Layer: Abstract on top of HTML5 and Gears Storage

Category: Database, Google

Robert Kroeger has released a nice library for local database access. The Web Storage Portability Layer nicely abstracts on top of HTML5 and Gears for database access.

The WSPL consists of a collection of classes that provide asynchronous transactional access to both Gears and HTML5 databases and can be found on Project Hosting on Google Code.

There are five basic classes:

google.wspl.Statement - A parametrizable SQL statement class

google.wspl.Transaction - Used to execute one or more Statements with ACID properties

google.wspl.ResultSet - Arrays of JavaScript hash objects, where the hash key is the table column name

google.wspl.Database - A connection to the backing database, also provides transaction support

google.wspl.DatabaseFactory - Creates the appropriate HTML5 or Gears database implementation

Also included in the distribution is a simple note-taking application with a persistent database cache built using the WSPL library. This application (along with Gmail mobile for iPhone and Android-powered devices) is an example of the cache pattern for building offline web applications. In the cache pattern, we insert a browser-local cache into the web application to break the synchronous link between user actions in the browser and server-generated responses. Instead, as shown below, we have two data flows. First, entirely local to the device, contents flow from the cache to the UI while changes made by the user update the cache. In the second flow, the cache asynchronously forwards user changes to the web server and receives updates in response.

By using this architectural pattern, a web application can made tolerant of a flaky (or even absent) network connection!

You can of course take a peak at the code to see how it works, for example:

JAVASCRIPT:
  1.  
  2. google.wspl.DatabaseFactory.createDatabase = function(dbName, dbworkerUrl) {
  3.   var dbms;
  4.   if (window.openDatabase) {
  5.     // We have HTML5 functionality.
  6.     dbms = new google.wspl.html5.Database(dbName);
  7.   } else {
  8.     // Try to use Google Gears.
  9.     var gearsDb = goog.gears.getFactory().create('beta.database');
  10.     var wp = goog.gears.getFactory().create('beta.workerpool');
  11.  
  12.     // Note that Gears will not allow file based URLs when creating a worker.
  13.     dbms = new wireless.db.gears.Database();
  14.     dbms.openDatabase('', dbName, gearsDb);
  15.     wp.onmessage = google.bind(dbms.onMessage_, dbms);
  16.  
  17.     // Comment this line out to use the synchronous database.
  18.     dbms.startWorker(wp, dbworkerUrl, 0);
  19.   }
  20.   return dbms;
  21. };
  22.  

Nicely done. It would be great to see a version that acts as a shim and when in Gears mode manually implements the HTML5 standard API so you can write your user code to that and not a new google package.

Posted by Dion Almaer at 8:45 am
7 Comments

++++-
4.3 rating from 25 votes

GWT team Wave’s goodbye to annoying question; It’s the API stupid

Category: Google

"Why doesn't Google use GWT more?"

That is a question that I was asked maaaany a time. There are sites like Base and the old mashup editor and others.... but "why not something big like Gmail?"

It was always so tough because it wasn't a totally fair question.

  1. Google has some of the best Ajax hackers out there. Teams with that talent may not be the right people to use GWT!
  2. A lot of sites were written before GWT was created, and migrating something is a different proposition

Google Wave on the other hand, had the chance to really evaluate GWT and they went with it. There was a talk at Google I/O about why, and some of the cool new features they use such as runAsync that does some incredibly smart things to lazily load code when needed (and gives you a much smaller initial download).

I don't have much to add to the massive coverage that Wave has gotten today. I see two pieces. The one that most people focus on is how it looks and what the site does. It is very rich, and cool, and some people will try it and some will not like how it feels.

That isn't the piece I am most excited about. Although it is great to reboot what a communication tool could be in 2009, but I am much more excited about the APIs. A lot of servers and frameworks and languages are vying for the "real time Web server" trophy. What Wave gives you is a federated implementation AND a spec to build your own stuff. At its core I see it as a great way API to let people collaborate on a shared object. That is a fantastic building block.

When I heard about it, I immediately thought about my own world of Bespin of course. From the initial prototype we had the notion of creating a collaborative social experience with code. One feature that has long been on the drawing board can be seen here:

We want to tie chat/status/microblogging content to files and even code snippets in a project. Imagine being able to highlight some code and see not only who created it and when, but also what was discussed. The social bar on the right has some of that concept. Then down below you see the timeline view that lets you go back in time and see the code change before your eyes. Maybe you want to replay the coding that a coworker did while you were out instead of staring at the diffs? This is the kind of thing that I hope we can experiment with Wave to do. We will see!

Posted by Dion Almaer at 12:24 am
9 Comments

++++-
4 rating from 39 votes

Tuesday, April 21st, 2009

O3D: Google releases 3D API in a Browser Plugin

Category: Google, Plugins

Google has released O3D, a browser plugin that gives developers a 3D API. It sits at a slightly higher level than other APIs (such as OpenGL / Canvas 3D type implementations) so it will be interesting to see if developers like the higher level abstraction, especially for building games. These APIs can also be implemented on top of the lower level APIs, so in theory it could sit on top of Canvas 3D.

There are plenty of demos, samples of code and shaders (they created a O3D shading language.

Interestingly, it embeds V8 as the JavaScript engine which makes for a uniform engine, but unfortunately you can't use your browser debugger (e.g. no Firebug).

It has also been carefully positioned "This API is shared at an early stage as part of a conversation with the broader developer community about establishing an open web standard for 3D graphics."

It is interesting to see another new plugin from Google. I always hoped that Gears would be one developer plugin to rule them all but then we have the Earth API, and this (as well as the non developer ones like the defunct Lively).

Anyway, cool to see rich experiments in bringing 3D to Web developers, and I look forward to seeing what people do with it! Leisure Suit Larry 3D anyone? :)

Posted by Dion Almaer at 2:23 pm
13 Comments

++++-
4 rating from 48 votes

Wednesday, April 15th, 2009

Speeding Up Urchin with Dojo, Part 2

Category: Dojo, Google

Last year, we covered Pete Higgin's blog talking about how to load Google Analytics in a more responsive manner. Google may not have improved the situation since then (really?), but the Dojo folks have packaged up Pete's script into the recently released Dojo 1.3 and Alex Russell recently posted a great summary of issues with Google Analytics and an example of the new code:

[Google Analytics] but it tends to load slowly. There are several reasons for this:

  • Another DNS lookup to resolve http://www.google-analytics.com/. This DNS entry is likely to be “warm” given how frequently ga.js is used on the web, but as Jim Roskind explained on the Chromium blog, it’s the outliers that kill you.
  • It’s kinda big. At 9K on the wire (22K unzipped), ga.js is kinda chunky for what it does most of the time, namely tracking a single page load.
  • The default instructions are bone-headed. They direct you to do a document.write() which is a blocking, synchronous operation WRT page loading. This is tres dumb. Reasonable people should just include ga.js with a <script> tag, but nearly nobody does. Turns out that sane defaults still matter.
  • Load times seem totally random. As with DNS lookup, ga.js’s latency varies wildly. This isn’t backed up by anything empirical, but many pages feel blocked by ga.js for a near eternity.

The code is now simplified into this:

HTML:
  1. <script type="text/javascript"
  2.   src="http://ajax.googleapis.com/ajax/libs/dojo/1.3/dojo/dojo.xd.js">
  3. </script>
  4. <script type="text/javascript">
  5.   dojo.addOnLoad(function(){
  6.     setTimeout(function(){
  7.       dojo.require("dojox.analytics.Urchin")
  8.       dojo.addOnLoad(function(){
  9.         var tracker = new dojox.analytics.Urchin({
  10.           acct: "UA-XXXXXX-X" // your tracking # here
  11.         })
  12.       })
  13.     }, 100)
  14.   })
  15. </script>

Check out Alex's blog entry for more details.

Posted by Ben Galbraith at 8:30 am
13 Comments

++++-
4.1 rating from 28 votes

Wednesday, April 8th, 2009

Google talking about HTML 5 and the Mobile Web

Category: Google, Mobile

The Google Mobile folks talked about the new Gmail Mobile launch that uses HTML 5 technology to speed up the experience, and work offline.

On the developer side of the house we get to see a little teaser of what the team will be sharing with us:

Of course we didn't get there without a few hard knocks. As an evolving standard, HTML5 has been fast-changing target and we've skinned our knees and bruised ourselves along the way. So rather than just deliver the fruit of all those bumps and scratches to end users in our own products, we decided we wanted to write a few blog posts to share what we've learned so that others can take advantage of HTML5 as well.

Great to see the mobile Web continue to merge as just One Web, and I look forward to hearing from the trenches on issues the team ran into, so we can learn from them.

Posted by Dion Almaer at 7:20 am
4 Comments

++++-
4.8 rating from 12 votes

Tuesday, January 27th, 2009

Gmail Offline is here (or coming soon for you!)

Category: Gears, Google, Offline

Gmail Offline has been an incredibly long wished for product feature and now it is coming (takes time to push it out to people and it will appear in Settings - Labs).

This is a big deal. It uses Gears of course, and many people are always saying "it's about bloody time."

This is easy to say from the comfort of the arm chair at home. In reality, an architectural change like this is huge. Moving to a sync model that works reliably is tough in the best of times, and when you try to do it to a product that is popular, it gets that much harder to do right.

I got to use this when I was working at Google and saw numerous ups and downs (one version works well, then it gets buggy, then it gets better, etc). It was fantastic to be able to use it on the plane (or would have been if I wasn't scared that someone would look over my shoulder). It resets expectations. You get used to opening up the browser when you KNOW you are offline. Having this in a product that you use as much as email will change user behaviour and will lead us down the path of more easily being able to do browser like things when connectivity is rough. Hell, knowing that WiFi jumping up and down won't affect me is a big deal.

Congrats to Andy Palay and the team. I hope that we get to see an interview him as he discusses the architecture and the various tweaks to that architecture as they nailed this all down. We have much that we can learn from the process.

If you don't have it in your "Labs" settings (I don't right now, and the witing game is annoying I know!) check out the high level video:

Posted by Dion Almaer at 7:48 pm
14 Comments

++++-
4.5 rating from 22 votes

Thursday, January 22nd, 2009

Having fun in the Ajax Playground

Category: Google, JavaScript, Showcase

Ben Lisbakken, a chap who I had the pleasure to work with at Google, has done a really nice job creating a Google Ajax API Playground, an area that allows you to touch and feel the APIs in real-time:

Ben said:

The AJAX API Playground is currently loaded with over 170 samples for 8 Google JavaScript APIs (Maps, Search, Feeds, Calendar, Visualization, Language, Blogger, Libraries and Earth) that you can edit and run to help you explore what our APIs have to offer. There are also Save and Export features. The save feature allows you to hold onto an edited sample so you can continue working on it later while export lets you modify a sample and export the code to a sticky URL where it will run by itself.

Since everyone likes to set up their environment differently, I made the three major sections (pick, edit, run) moveable and resizable, and the run section can pop-out to a new window. And what kind of Googler would I be if I didn't include a search bar to let you find samples by name, tags or category?

At Google we strongly believe in open source, so this code is under an Apache 2.0 license and uses open source libraries and tools: jQuery, jQuery UI, App Engine, YUI Compressor, and CodeMirror. If you want to use the framework to show off your own code samples, please feel free to use it! Adding new demos is simple--find it here on Google Project Hosting and learn about adding samples.

Very nice indeed!

Posted by Dion Almaer at 9:12 am
6 Comments

++++-
4.3 rating from 21 votes

Tuesday, December 9th, 2008

Native Client: Open ActiveX?

Category: Google

Google has released a cool research project called Native Client, a new browser plugin (how many plugins now? gears, toolbar, lively [for awhile], earth, ...) that allows you to compile with a special GCC compiler down to x86 that can run in the browser. IE is missing so far, but remember this is a research preview (not sure how 64 bit comes in here etc).

Joel Webber had an interesting comment:

"We ported an internal implementation of H.264 video decoding [...] Performance of the original and NaCl versions were comparable and limited by video frame-rate". Think about this for a second -- it makes it entirely feasible to download untrusted software video codecs (among other things) to the browser. I don't care how fast you make Javascript; I'm pretty sure it will never be able to do this.

Others are talking about a marketplace for addons. It seems like the first demos are always the porting of games. We saw the same thing with Alchemy which allows C/C++ to run in the Flash VM.

With JavaScript speeding up, and our abstractions getting better and better, I don't see people writing entire Web applications in C, however this is a new extension mechanism that has been added to the toolbox. If you need to integrate with legacy code, or need access in a way you couldn't get done before, this could be for you.

Maybe it will be a good bridge technology that we can use, at least before we get richer and richer APIs into the browser itself (e.g. implement some of HTML 5 and new APIs using this until browser support).

What do you think?

Posted by Dion Almaer at 12:10 am
4 Comments

+++--
3.6 rating from 18 votes

Monday, November 17th, 2008

State of the Open Web Talk

Category: Conferences, Google, Standards

I recently gave a State of the Open Web talk as part of the Google Developer Days overseas, in Italy, Russia, the Czech Republic, and Israel (I'm getting over a 10-hour jet lag right now - whew). The talk description:

"Come learn about the state of the Open Web, what it is, and why it is so important. In this presentation you will learn about the latest Open Web technologies, including the Canvas tag, Web Fonts, SVG, HTML 5, and see demos, code snippets, and the state of their implementations across browsers. Discover what you can use today (more than you'd expect!) and what remains to be done."

[Disclosure: I work for Google on the Open Web Advocacy team]

Posted by Brad Neuberg at 8:00 am
7 Comments

+++--
3.8 rating from 16 votes

Wednesday, October 29th, 2008

Chrom(e|ium) Details: I/O, Responsiveness, UI, and Graphics

Category: Chrome, Google

The Google folks have been doing a really good at consistently blogged about the decisions that were made as they created Chrome:

Graphics in Google Chrome

Google Chrome uses a library called Skia, which is also the graphics engine behind Google's Android mobile OS. The two projects share code that implements WebKit's porting API in terms of Skia. Google Chrome also uses Skia to render parts of the user interface such as the toolbar and tab strip. I'm going to talk about some of the history that led us to choose Skia, as well as how our graphics layer works.

I/O in Google Chrome

We moved the I/O onto a number of background threads which allow the user-interface to proceed asynchronously. We did this for large data sources like cookies, bookmarks, and the cache, and also for a myriad of smaller things. Writing a downloaded file to disk, or getting the icons for files in the download manager? The disk operations are being called from a special background thread. Indexing the contents of pages in history or saving a login password? All from background threads. Even the "Save As" dialog box is run from another thread because it can momentarily hang the application while it populates.

Content, not 'Chrome'

To achieve the streamlined feel we were after, we knew we would have to cut some things, and while we had our own intuitions about what was and wasn't useful in current browsers, we had no idea how those ideas matched to reality. So in typical Google fashion, we turned to data; we ran long studies of the browsing habits of thousands of volunteers, compiled giant charts of what features people did and didn't use, argued over and incorporated that data into our designs and prototypes, ran experiments, watched how our test users reacted, listened to their feedback, and then repeated the cycle over and over and over again.

Even the the more subtle parts of our first-level UI were subjected to similarly intense scrutiny - "what shade of blue best suits XP users", "should the tabs start 18 or 19 pixels below the top of the window?", "what's the correct offset between our buttons?". The answers to these questions were debated and tested for our entire development cycle, and we saw that opinions consistently differed greatly depending on whether we had been Windows 3.1, OS7 or even NeXT users and developers.

The Google Chrome Sandbox

Google Chrome's multi process architecture allows for a lot of flexibility in the way we do security. The entire HTML rendering and JavaScript execution is isolated to its own class of processes; the renderers. These are the ones that live in the sandbox. We expect to work in the near future with the plug-in vendors to securely sandbox them as well.

I have to admit that I personally wish Cairo was chosen, as having the Google engineers behind that project would have been amazing, and benefit would be had for all of the applications that use it.

Posted by Dion Almaer at 8:14 am
Comment here

+++--
3.9 rating from 16 votes

Thursday, October 16th, 2008

Google Chrome History Issue

Category: Browsers, Google

Amongst the reactions to Google's release of Chrome was the developer's howl of pain at the thought of another major browser on which to do compatibility testing. Google's generally asserts that Safari compatibility results should be the same as Chrome's, but Nathan Hammond stumbled across a divergence that he finds troubling and which Google shows no inclination to fix. Says Nathan:

There exists a bug in Google Chrome that breaks most history managers. Most all current history managers rely upon form-based storage to repopulate their history stack after navigating away from and returning to the present document object, but Chrome doesn't refill form fields when that happens. The result of that is that Google Chrome is currently incompatible with websites using the current generation of history management plugins, and, if their issue tracker has anything to say about it, will remain that way. The bug was closed as "wontfix" due to a misunderstanding. However, it still needs to be addressed to meet the goal of Chrome as I heard at The Ajax Experience 2008: a goal of not fracturing the web and creating yet another browser we developers have to test in and code around.

Nathan elaborates on his blog.

Posted by Ben Galbraith at 9:00 am
9 Comments

+++--
3.8 rating from 24 votes

Friday, September 26th, 2008

Google turns 10, and gives us a nice scrollable timeline

Category: Google

Google has turned 10, and we wanted to celebrate. Soon we will be a teenager :)

The site for the Tenth birthday has some nice features, including a scrolling time line of the history that is very Gooey indeed.

There are nice subtle elements to the component. If you scroll the bar you will see that the size of the blue area changes as the scope changes.

It's fun to look back and see how bad the original logo was (no comment on the current one ;)

Posted by Dion Almaer at 3:59 am
4 Comments

++++-
4.6 rating from 22 votes

Tuesday, September 2nd, 2008

Google Chrome, Chromium, and V8

Category: Browsers, Google

It is really exciting to see the level of pace that browsers have been setting recently, especially with respect to performance.

I have been able to keep in sync with Google Chrome the new browser, and Chromium, the open source code-base it comes from. There are a couple of innovations that have been great to see such as the multiple process model for tabs and windows, the unified tab and search functionality, and at the core, V8.

V8 is the super-speedy JavaScript VM by Lars Bak of Sun HotSpot fame. When you run JavaScript benchmarks on this puppy, you see very speedy responses indeed. The V8 part of the comic says it well:

The breakthrough of having hidden classes to look at structures and work out the shared information (e.g. object Foo looks like a Person). Once you have that data, you can optimize in the same way you would class systems. V8 improvements consist of:

  • Compiler: Instead of using interpretation, JavaScript gets compiled down to native code
  • Inline caching: Optimize for accessing, and function calling
  • Very efficient memory management system

What version of JavaScript? "V8 implements ECMAScript as specified in ECMA-262, 3rd edition, and runs on Windows XP and Vista, Mac OS X 10.5 (Leopard), and Linux systems that use IA-32 or ARM processors."

If you are interested in the benchmark suites, you can run them and check them out.

Some of the core technology is also exciting to geeks. For example, as this code is operating system neutral we use the Skia Graphic Library (SGL) used by the Android team.

What about the process manager? John Resig has interesting thoughts on that with the rub: "The blame of bad performance or memory consumption no longer lies with the browser but with the site."

Alex Russell also has some good thoughts on the importance of Chrome, and Christopher Blizzard (Mozilla) also has some thoughts on how this shows the browser market is strong.

This is all great to see. Not only is this just the beginning for Google Chrome, Chromium, and V8 (I am dying for a Mac version!), but the other browsers are keeping pace too. The end result is a better Web for users, and a higher quality of product for developers to build against!

Posted by Dion Almaer at 2:00 pm
53 Comments

++++-
4.6 rating from 54 votes

Friday, August 29th, 2008

GWT 1.5 final release is shipped and out the door

Category: GWT, Google, Java, Library

I have seen the GWT team working very hard indeed on GWT 1.5, and they must be very happy to see the final release shipped and complete:

GWT 1.5 delivers what we think are an impressive number of improvements, about four hundred issues if you're counting. We're also happy that one of those is issue 168, our most-requested feature, Support for Java 5.

The high level new feature sets are:

  • Java 5 language support and enhanced JRE emulation
  • Performance optimizations and easier JavaScript interop
  • Prettier widgets, better DOM, accessibility, and bi-di

You can see a lot of this at work in the showcase area. There you will see all of the widgets and examples that come out of the box, and the community has developed even more for you. In particular, Ray Cromwell has some great real world examples that he shares in his book and talk.

Download GWT and take a look.

Posted by Dion Almaer at 10:51 am
2 Comments

+++--
3.9 rating from 26 votes

Thursday, August 28th, 2008

GALGWT 1.0… it isn’t a land next to Mordor

Category: GWT, Gears, Google

GWT has long had a project that aimed to give rich support for Google APIs called GALGWT, or "Google API Libraries for Google Web Toolkit".

This project has stepped up to higher gear recently, and we have seen the GALGWT 1.0 release candidate appear.

What is in GALGWT?

The project is a collection of libraries that provide Java language bindings
and API specific 'plumbing' for some Google JavaScript APIs. The goal is to
make it easy for developers to use these JavaScript APIs with GWT. Libraries
available at this time include a new version of Gears, as well as new
libraries for Gadgets and the Google AJAX Search API.

Gears 1.1 Library

A new version of the Gears library is available. In addition to the earlier
version's support for the Gears LocalServer, Database, and WorkerPool, 1.1
adds integrated support for offline applications and updated sample
applications. The bindings have also been refactored to use GWT 1.5
JavaScript overlay types and a new package hierarchy.

Gadgets 1.0 Library

The Gadgets library simplifies gadget development with GWT by automatically
generating a Gadget specification from Java source and inserting a selection
script in the specification much like a regular GWT project. After compiling
your gadget with GWT, all files are in place to publish your gadget. This
version currently supports the legacy Gadgets API based on the _IG_...
namespace.

Google AJAX Search 1.0 Library

The Google AJAX Search API lets you put Google Search in your web pages,
including Web, Local, and Multimedia searches. This library allows you to
access the API from Java code compiled with the GWT compiler without having
to write additional JavaScript code.

Posted by Dion Almaer at 5:45 am
Comment here

++++-
4.2 rating from 6 votes

Next Page »