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
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!
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:
// Comment this line out to use the synchronous database.
dbms.startWorker(wp, dbworkerUrl, 0);
}
return dbms;
};
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.
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.
Google has some of the best Ajax hackers out there. Teams with that talent may not be the right people to use GWT!
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!
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.
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? :)
[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.
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.
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:
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.
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).
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]
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.
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.
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.
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.
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 historymanagers 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.
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."
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."
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!
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
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.
, Performance
