Ajax View: Remotely Monitoring Client-side Web App Performance and Behavior

Emre Kıcıman and Benjamin Livshits of Microsoft research have created a new project called Ajax View:

The goal of the Ajax View project is to improve developer’s visibility into and control over their web applications’ behaviors on end-user’s desktops.

The Ajax View approach is to insert a server-side proxy (or web server plugin) in-between the web server machines and the end-user’s browser. This proxy captures the web application’s JavaScript code as it is being sent to a browser and rewrites the code to insert extra instrumentation code. The injected instrumentation code runs with the rest of the web application inside the end-user’s browser and can capture performance, call graph, application state and user interaction information, providing visibility directly into the last hop of the user’s experience.

Because Ajax View is rewriting web application code dynamically each time a user visits the web site, it can:

1. Serve different instrumentation code to different users. This allows us to distribute instrumentation code across many users, spreading the cost of gathering lots of information such that no single user pays a high performance penalty.
2. Adapt an instrumentation policy and serve different instrumentation code over time. For example, we can drill-down into performance problems and gather extra context about bugs

The prototype will setup a local proxy server that rewrites your script code and instruments it.

A crude view is:

PLAIN TEXT

JAVASCRIPT:

1.  
2. <script>
3. LogScriptEnter(); // ADDED
4.  
5. function HelloWorld( a, b ) {
6.     LogFuncEnter(“HelloWorld”); // ADDED
7.     alert(‘hello world!’);
8.     LogFuncExit(“HelloWorld”)); // ADDED
9. }
10.  
11. LogScriptExit(); // ADDED
12. </script>
13.  

This is all just research-y and they “are considering several future directions for the project, including further research into instrumentation policies to help developers debug their application, and the possibilities of integrating this technology into developer tools and/or web server infrastracture.”

This seems a little weak, although it is just a research project. Someone we all know well and love said this about the project: “with MS Research I would expect a Firebug clone with voice recognition: computer, select the 4th div after the second h2 in the third paragraph”

(Via Ajaxian.)

Windows Script 5.7 released

I have little announcement to make today. Windows Script 5.7 which ships with different flavors of Windows® Vista is now available for Windows® 2000/XP as well as Windows® 2003 Server.
This download will install Microsoft® Windows® Script containing Visual Basic® Script Edition (VBScript.) Version 5.7, JScript® Version 5.7, Windows Script Components, Windows Script Host 5.7, and Windows Script Runtime Version 5.7.
Why should you care about this update ? If you ever encountered performance issues running AJAX applications (e.g. Gmail), you should absolutely consider installing this update. This update includes an updated Garbage Collector that used to previously make AJAX appliications run pretty poorly. This update is available on Vista and we are now providing this to all supported OS versions (XP, Win2K, Win2K Server). You will see noticeably better performance on your favorite AJAX applications and with more and more AJAX applications coming on line, you will be very happy you did this.

Below is the download link for the updates.

Download Windows Script 5.7 for Windows 2000
Download Windows Script 5.7 for Windows XP
Download Windows Script 5.7 for Windows 2003 Server

Also lot of people might be wondering what all changes has gone inside this release. A quick look at release note will give you all the detail. The release notes can be downloaded from here.

Happy downloading and enjoy all the benefits of Windows Script 5.7 on other OS too!!

Thanks,
Don Raman

(Via JScript Blog.)

CompressorRater: Compare the squeeze

The JavaScript camp can get a bit obsessed with squeezing, and Arthur Blake’s CompressorRater tells you how far you can go:

There are many tools available that can help you compress your JavaScript code but it can be time consuming and difficult to analyze which tool work the best for a given situation. The goal of this web application is to report aggregated statistics on the general level of compression in all these tools, as well as allow developers to easily play with and compare the different tools on their own JavaScript code without having to set up all the tools on their own.

The following compression tools are compared, both with and without the affects of additional gzip compression that are supported natively by modern web browsers.

The tool will try all of the usual suspects for you, in various modes. I ran gears_init.js into the sausage factory and got out:

Oh, and it has been a couple of days, so Julien has released a new version of the YUI Compressor (2.1).

(Via Ajaxian.)

Cerny.js: Schema for JSON

Cerny.js brings you the fun and frolics you have grown to love from XML schema:

A Cerny Schema allows us to validate a JavaScript object. If an object passes the validation, we can be sure that certain statements are true for the object, if it fails validation, the validation report will inform us, which statements do not hold. Schemas allow us to write simpler code, because certain facts about an object are given and do not have to be checked. This will also result in more readable and thus better maintainable JavaScript code. On the other hand if we do not use schemas, the assumptions that we make on the data structures we are working on are scattered in the code and the same assumption might checked more than once.

A simple example is that of a Person, which a schema, and validation:

PLAIN TEXT

JAVASCRIPT:

1.  
2. // Define a Person schema
3. Person = {
4.   firstName: nonEmptyString,
5.   middleName: optional(nonEmptyString),
6.   lastName: nonEmptyString,
7.   dateOfBirth: optional(pastIsoDate)
8. };
9.  
10. // Create a Person
11. var csp = {
12.   firstName: “Charles”,
13.   middleName: “Sanders”,
14.   lastName: “Peirce”,
15.   dateOfBirth: “1839-09-10″
16. };
17.  
18. // Validate the Person
19. var report = CERNY.schema.validate(csp, Person);
20.  

(Via Ajaxian.)

Create your own iGoogle with Prototype

Sébastien Gruhier, AKA Mr. Proto, is at it again coming up with a new Portal class for Prototype which gives you that ability to create a UI like NetVibes or iGoogle. For those that don’t know, Sébastien is also the author of the very sweet and popular Prototype Window and Carousel classes.

The Prototype Portal Class continues along the same lines providing a straightforward method of adding portlets and styling them. The portlets include DnD and selectables functionality making them fall neatly into place when dragging them around. The code to implement this is VERY easy to understand:

You need to instanciate a Portal class with those columns:

var portal = new Xilinus.Portal(“#page div”)

Add widgets to this portal. There is a Widget class, fully CSS skinnable (there is a default theme), just create a new Widget instance and add it to the portal by specifying the column index. For example:

portal.add(new Xilinus.Widget(), 0)

// Or with title and content
portal.add(new Xilinus.Widget().setTitle(“Widget Title”).setContent(“bla bla bla”), 1);

While you still have to do the advanced legwork to build a Netvibe-like application, the Prototype Portal class gives you the foundation to build upon.

You can an example here and download the code here.

(Via Ajaxian.)

Yojo: Loading YUI with the Dojo loader

I like Dojo 0.9, and I think it has a great solution to loading JS modules dynamically. The core of the Dojo loader has been there since the beginning of the project, but with the addition of the xdomain loader, it really shines (disclaimer: I work on the xdomain loader). It allows anyone to use all of Dojo from a CDN without having to download it.

The loader is a great fit for any JavaScript library that has more than a couple of files to load, and where the files can have dependencies on other files. I touched on this topic during my Ajax Experience talk about Dojo's xdomain loader. This post explores a real-world example: using the Dojo loader to load YUI.

First, a demo. Here is a page that loads the YUI rich-text Editor using the Dojo loader. If you have a DOM inspector tool, you can verify that the modules where loaded by looking at the dynamically created script elements inside the head element.

How was it done?

1. I started with the 2.3.0 YUI source that Jonathan Bond-Caron modified to put in calls for dojo.require/provide (but he used a different namespace name). Jonathan opted for using module names for the dojo.require/provide calls, but I converted them to just be the file names so that I could avoid having to do a mapping (configuration) step.
2. I converted directories and file names with dashes to use underscores. Since they are used as the dojo.provide() resource name, they have to be valid JavaScript object identifiers (no dashes in JS variable names).
3. I did a modification to base.js to make sure the right YAHOO object was used — there is a scope difference when a file is built as an xdomain file via the Dojo build system.
4. Converted the test page to include the Dojo loader and use dojo.require/provide calls instead of script tags.
5. Run a Dojo custom build that generated xdomain .xd.js files for the YUI modules. I also just built the Dojo loader and not all of the things that normally come in the basic dojo.js.

The biggest step was specifying each file's dependencies by putting dojo.require() calls in each JS file. Thankfully, Jonathan had done the work already.

File size impact

Here are the file size comparisons (sizes are gzip sizes in bytes):

• 3697 yuiloader-beta-min.js (YUI's beta loader)
• 5632 dojo.js (Use this if you are loading all code from same domain)
• 8950 dojo.xd.js (Use this for loading code across domains)

(The demo above is *not* using gzipped or optimized files, so its file sizes will be different)

dojo.js/dojo.xd.js also includes things mentioned in this post (see Basic loader section), like

• DOMContentLoaded/dojo.addOnLoad()/dojo.addOnUnload()
• dojo.get/setObject
• djConfig setup
• a basic XMLHttpRequest creation function.

dojo.xd.js also includes dojo.i18n. I have a couple of ideas on reducing the size gap between dojo.xd.js and dojo.js.

Comparing with YUI Loader

YUI does have a beta code loader, yuiloader. However, I do not feel it is sufficient for programming in the large, and for keeping encapsulation. I am not fully conversant with the yuiloader, so I'm happy to make any corrections to my comparison below.

Configuration vs. Convention

yuiloader uses configuration over convention, which means you need to register with the yuiloader a name for your JS module, where to find it and its dependencies. In the long run, this is a more verbose approach than using a convention. In Dojo, you register a base path for a “namespace”, then a simple convention is used to convert “path.to.resource” to [namespace prefix]/path/to/resource.js (or .xd.js in the xdomain loading case).

This results in less code when specifying dependencies. If you are an end user of the modules, you do not have to worry about mapping out all the dependencies yourself.

Breaks encapsulation

Since you need to specify all dependencies up front, you break encapsulation. You have to know about a module's dependencies before using it and you have to update the dependency list registered with yuiloader if the module changes.

Build optimizations

Not a problem for yuiloader directly, but the Dojo build system can analyze the dojo.provide()/require() mappings in the modules so you can build a custom “rollup” file that includes all the modules you need in one file.

Different loading profile

From what I can tell, yuiloader only loads one file at a time, and waits until it is loaded before loading the next one, so it can avoid issues with something loading before a dependency is loaded. The Dojo xdomain loader starts appending script tags as soon as it knows it needs to load them, waits for them all to load, then defines the modules in the right order. Dojo can do this because the build process wraps the module code in a function, so that the code does not execute when the script is first loaded.

i18n

Dojo has a neat way to do internationalization (i18n) by using JSON localization (l10n) bundles. These bundles can be optimized during the Dojo build process just like normal JS modules.

yuiloader advantages

yuiloader has some nice features missing from today's Dojo loader:
- Can load any code on the net, and does not require a build step, given the caveats above. This is possible with dojo.io.script, but that is not part of the Dojo loader, so it requires extra work by the developer.
- You can load CSS files. I would like to support a “dojo.requireCss()” that would give you this functionality and still leverage the convention-based name-to-path mapping that Dojo uses.

Next Steps

I would like to see YUI and Dojo converge on using the same type of loader for their code. There is a generic need for this functionality, and it would be good to start standardizing on an approach.

Obviously I would like to start with the Dojo loader and the dojo.provide/require approach and make any modifications that YUI might need to fulfill their needs. I am sure the Dojo loader code could use improvements, in particular the xdomain loader. Look at the file. Isn't that scary? It scares me and I wrote it! Let's see if we can make it better.

I am also open to other paths if Dojo's loader does not seem like the way to go. However, I would like some solution that keeps encapsulation and can leverage a build process for optimizations.

This is also an important test case for further YUI/Dojo collaborations. We are solving lots of the same issues, and I think we will serve the Open Web better if we work together rather than separately.

I am sure that Dojo would love to have some YUI people as Dojo contributors. Yahoo has already been generous in allowing Dojo to use their YUI Reset CSS rules in our “reset CSS”. And Dojo's very liberal open source license allows YUI to pick up any piece from Dojo. I am looking forward with working with the YUI team on issues that affect both YUI and Dojo.

By the way, this invitation to work on a common loader is not just for YUI: I know jQuery is looking for something in this area, and I can see where Ext would benefit from it too. Let's try to work out a solution together. Feel free to contact me at jburke at dojotoolkit dot org. Feel free to start the conversation by just listing your loader requirements.

(Via Dojotoolkit Happenings.)

Google Web Toolkit: Towards a better web

Posted by Bruce Johnson and Dan Peterson, Google Web Toolkit team

We’re very pleased to tell you that the Google Web Toolkit (GWT) is no longer in beta as of today’s release of GWT 1.4. For Java developers who have used GWT to create high-end web applications over the last year, this may not seem all that surprising. But if you haven’t yet heard the story behind GWT, this seems like the perfect time…

If you’ve been in the technology industry for a while, you probably remember when enterprises and software vendors had to think pretty hard about whether to develop locally-installed desktop applications or web-based browser applications. These days, whether you’re building mashups, gadgets, or full-blown applications, it’s a no-brainer: the browser is the delivery platform of choice. However, users expect more from the up-and-coming generation of web applications than the simple click-and-wait of yesterweb. And if you’re a web developer, you know that this requires AJAX, the cluster of technologies including JavaScript and dynamic HTML that can make browsers do backflips.

But the stark reality of AJAX applications is that, although they can deliver sexy features and great usability, they are unusually hard to engineer. Browser quirks and the anything-goes nature of JavaScript will inevitably frustrate even the most dedicated developers and add risk to your schedule with every line of code written. If you do eventually manage to construct a complex AJAX application that works, you’re likely to find that maintaining it over time can be a major challenge. And all that doesn’t even scratch the surface of testing, optimizing, securing and internationalizing your application. (If you are currently working on an ambitious AJAX project and haven’t yet come to this conclusion, please re-read this post in six months when you’re further along!)

We’ve learned a lot from our experiences building web applications, and we’re happy to share the tools we’ve created. Google Web Toolkit is an open source project that helps Java developers harness the richness of AJAX in a cross-platform, web-friendly environment. The magic trick is that GWT cross-compiles Java source code into standalone JavaScript that you can include in any web page. Instead of spending time becoming JavaScript gurus and fighting browser quirks, developers using GWT spend time productively coding and debugging in the robust Java programming language, using their existing Java tools and expertise. Naturally, GWT is also a great way to easily take advantage of the latest-and-greatest Google APIs and browser enhancements, such as Google Gears.

In addition to making debugging far easier, GWT’s unique compilation-based approach to AJAX has the nice property that it rewards developers for good software engineering practices. Java source code that is clear and organized can be easily optimized by the GWT compiler, which is a nice antidote to the frequent hack-and-slash approach that’s all too common in JavaScript development. As your application grows, the GWT compiler begins to pay off in even bigger ways. Unused code is automatically removed so that scripts are smaller and pages load faster. Complex code can be automatically coalesced and simplified. Most importantly, because the Java language is statically typed, many common errors can be caught during development rather than production. You can observe the high-performance results yourself in GWT’s sample Mail application.

Technical details aside, GWT makes it easy to develop fast, friendly web apps that users love — which is, after all, the point.

Download GWT 1.4.

(Via Official Google Blog.)

Aptana Recap: Milestone 9 released

This week, the Aptana team released Milestone 9 as its current official release.

New Release

The Aptana team promoted Build 16696 to official “current” release status. Build 16696 is a Milestone 9 release, featuring support for PHP. This release features PHP Code Assist, code outlining, and improved syntax colorization for PHP.

Tips and Tricks

Looking for an easier way to navigate your code in the current Aptana Editor? You can use the alt+up arrow or alt+down arrow keys to move the current line (or selection) up or down in the current editor.

Community Buzz

We love to hear what our users our creating with the Aptana IDE. One of our forum users, Sembiance, recently developed a very cool online Solitaire game using Aptana. To learn more about Sembiance’s project see the forum post.

Next Week

Next week, we’ll be working on fine-tuning the new plug-in supporting the EXT v1.1 library. We’re also starting work on a plug-in for Dojo 0.9. The Aptana team will also continue its Milestone 10 development work.

(Via Aptana :: Weblog.)

Featured Mac Download: Integrate Subversion with Finder with SCPlugin

Mac OS X only: Access and write to version control Subversion repositories using SCPlugin, a Mac version of Windows only TortoiseSVN that integrates with Finder. SCPlugin has been around as a Subversion tool for a while, but the newly released 0.7 version promises that it’s “now ready to be your one-and-only Subversion interface.” SCPlugin works the same as TortoiseSVN, so our previous guide to TortoiseSVN should help you get started. If you’re completely new to the idea of version control with Subversion, here’s how to set up a personal home Subversion server. Thanks Andrew!

(Via Lifehacker.)

Reflex: Cover flow for your soul

Christian Effenberger, Canvas Library Creator Extraordinarie, has created Reflex.js 1.1, which allows you to add a Cover Flow effect (including reflection) to images on your web pages.

It works in all the major browsers – Mozilla Firefox 1.5+, Opera 9+, IE6+ (tilting missing) and Safari. On older browsers, it’ll degrade and your visitors won’t notice a thing.

As per usual, usage is via a simple microformat using CSS classes such as reflex iopacity75.

(Via Ajaxian.)