Google and Adobe have been working on improving the indexing of Flash applications. In the past we could simply look at the SWF files and try to grab strings out of them, but there was zero context.
To go further Google uses the SWF Searchable work from Adobe to be more of a ‘human’ actor on the application.
This is what it doesn’t do:
Googlebot does not execute some types of JavaScript. So if your web page loads a Flash file via JavaScript, Google may not be aware of that Flash file, in which case it will not be indexed.
We currently do not attach content from external resources that are loaded by your Flash files. If your Flash file loads an HTML file, an XML file, another SWF file, etc., Google will separately index that resource, but it will not yet be considered to be part of the content in your Flash file.
While we are able to index Flash in almost all of the languages found on the web, currently there are difficulties with Flash content written in bidirectional languages. Until this is fixed, we will be unable to index Hebrew language or Arabic language content from Flash files.
This is good news for all rich applications. One of the common worries when it comes to richer application development is “what do search engines see” and we sometimes see people go back to the simpler world just to make that happier. With the search engines stepping up themselves, we can go back to writing applications that make sense for our human users, and hope that the computers catch up. Of course, we always have to do so in a practical way.
Some good stuff came out from my employer. First, we have the Gears 0.3 release which includes support for Firefox 3! I have been using it for awhile, and it has been great. The team wanted to get it out before the Firefox 3 launch (planned for June 17th). A plugin like Gears can get deep into browser internals, so it is a challenge to keep up to date as APIs change in beta releases, so it is great to be out there now and I we will take a close look at the final release!
I just got to announce the Google AJAX Libraries API which exists to make Ajax applications that use popular frameworks such as Prototype, Script.aculo.us, jQuery, Dojo, and MooTools faster and easier for developers.
Whenever I wrote an application that uses one of these frameworks, I would picture a user accessing my application, having 33 copies of prototype.js, and yet downloading yet another one from my site. It would make me squirm. What a waste!
At the same time, I was reading research from Steve Souders and others in the performance space that showed just how badly we are doing at providing these libraries. As developers we should setup the caching correctly so we only send that file down when absolutely necessary. We should also gzip the files to browsers that accept them. Oh, and we should probably use a minified version to get that little bit more out of the system. We should also follow the practice of versioning the files nicely. Instead, we find a lot of jquery.js files with no version, that often have little tweaks added to the end of the fils, and caching is not setup well at all so the file keeps getting sent down for no reason.
When I joined Google I realised that we could help out here. What if we hosted these files? Everyone would see some instant benefits:
Caching can be done correctly, and once, by us... and developers have to do nothing
Gzip works
We can serve minified versions
The files are hosted by Google which has a distributed CDN at various points around the world, so the files are "close" to the user
The servers are fast
By using the same URLs, if a critical mass of applications use the Google infrastructure, when someone comes to your application the file may already be loaded!
A subtle performance (and security) issue revolves around the headers that you send up and down. Since you are using a special domain (NOTE: not google.com!), no cookies or other verbose headers will be sent up, saving precious bytes.
This is why we have released the AJAX Libraries API. We sat down with a few of the popular open source frameworks and they were all excited about the idea, so we got to work with them, and now you have access to their great work from our servers.
Details of what we are launching
You can access the libraries in two ways, and either way we take the pain out of hosting the libraries, correctly setting cache headers, staying up to date with the most recent bug fixes, etc.
The first way to access the scripts is simply be using a standard <script src=".."> tag that points to the correct place.
For example, to load Prototype version 1.6.0.2 you would place the following in your HTML:
You will notice that the version used was just "1". This is a smart versioning feature that allows your application to specify a desired version with as much precision as it needs. By dropping version fields, you end up wild carding a field. For instance, consider a set of versions: 1.9.1, 1.8.4, 1.8.2.
Specifying a version of "1.8.2" will select the obvious version. This is because a fully specified version was used. Specifying a version of "1.8" would select version 1.8.4 since this is the highest versioned release in the 1.8 branch. For much the same reason, a request for "1" will end up loading version 1.9.1.
Note, these versioning semantics work the same way when using google.load and when using direct script urls.
By default, the JavaScript that gets sent back by the loader will be minified, if there is a version supported. Thus, for the example above we would return the minified version of jQuery. If you specifically want the raw JavaScript itself, you can add the "uncompressed" parameter like so:
Today we are starting with the current versions of the library, but moving forward we will be archiving all versions from now onwards so you can be sure they are available.
Here I am, talking about what we are doing in two short slides:
The Future
This is just the beginning. We obviously want to add more libraries as you find them useful. Also, if you squint a little you can see how this can extend even further.
If we see good usage, we can work with browser vendors to automatically ship these libraries. Then, if they see the URLs that we use, they could auto load the libraries, even special JIT'd ones, from their local system. Thus, no network hit at all! Also, the browser could have the IP addresses for this service available, so they don't have the hit of a DNS lookup. Longer lived special browser caches for JavaScript libraries could also use these URLs.
The bottom line, and what I am really excited about, is what this could all mean for Web developers if this happens. We could be removed of the constant burden of having to re-download our standard libraries all the time. What other platform makes you do this?! Imagine if you had to download the JRE everytime you ran a Java app! If we can remove this burden, we can spend more time flushing out functionality that we need, and less time worrying about the actual download bits. I am all for lean, but there is more to life.
Acknowledgements
I want to acknowledge the other work that has been done here. Some libraries such as jQuery and Dean Edwards Base were already kind of doing this by hot linking to their Google Code project hosting repository. We thought this was great, but we wanted to make it more official, and open it up to libraries that don't use our project hosting facilities.
Also, AOL does a great job of hosting Dojo already. We recommend using them for your Dojo needs, but are proud to also offer the library. Choice is good. Finally, Yahoo! placed the YUI files on their own CDN for all to use.
Doctype is an exciting beast, and for many reasons. Having a place to collect this data is key, and as I said yesterday, I can't wait to see it grow as an open resource.
The other cool part of Doctype is that there are tests to backup claims. This seems like a "no brainer" as some of my 'sherman' friends would put it, as it is the corner stone of science.
Mark Pilgrim has released Google Doctype, an open encyclopedia and reference library. Written by web developers, for web developers. It includes articles on web security, JavaScript DOM manipulation, CSS tips and tricks, and more.
The reference section includes a growing library of test cases for checking cross-browser and cross-platform compatibility.
This is just the beginning for the ambitious project, which is open source, and open licensed (Creative Commons). Now it is out there we, the developers, have the option to add valuable data to grow the corpus.
Congrats to Mark on the launch. I know that it has been a huge amount of work for him, and I am excited to see it out there. Below is Mark talking about the project:
You may also notice the document reader application, which is driven by GWT.
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....
