Lloyd Hilalel and the Yahoo! BrowserPlus team have released a BrowserPlus SDK which allows you to easily create your own services: We're extremely happy to announce the availability of the BrowserPlus SDK. This first SDK and the accompanying documentation gives you all the tools you'll need to start extending the web using BrowserPlus. Getting started is easy, you can hop over to our tutorial and write your first service in about 15 minutes. In addition to the SDK, we've pushed a new platform version, 2.1.14, that fixes several bugs reported by all of you. We deeply appreciate your continued contributions and hope with the SDK and our ongoing process of open sourcing BrowserPlus we'll empower you to contribute even more to the project. A Ruby example service is shown: PLAIN TEXT RUBY:  class MyGreatServiceInstance     def initialize(context)     end         def HelloWorld(transaction, args)       transaction.complete("Hello # from my great service!")     end   end       rubyCoreletDefinition = {     'class' => "MyGreatServiceInstance",     'name' => "MyGreatService",     'major_version' => 0,     'minor_version' => 0,     'micro_version' => 1,     'documentation' => 'A GREAT service.',     'functions' =>     [       {         'name' => 'HelloWorld',         'documentation' => "Say \"hello\" to the world",         'arguments' => [           {             'name' => 'who',             'type' => 'string',             'documentation' => 'who you want to say hello to',             'required' => true           }         ]       }       ]     }  There is also a new service released: Welcome the new Zipper service to our collection! A big problem with some web apps today is being able to efficiently attach all file types. Zipper plays nicely with Uploader and lets you compress files or folders on the client before uploading them. This service should be considered alpha, and we look forward to your feedback and ideas on how to make this more useful. We've got lots of ideas of which way to take this service (lzma being first and foremost), but would love to hear your thoughts.

Adobe has been bashed pretty hard in the past for their lack of Linux support in both Flash and AIR (deservedly so). It was a segment of the development and user market that really wanted to leverage Adobe technology but pretty much had their hands tied. It's evident that Adobe is listening as they announced yesterday that AIR v1.5 now supports Linux. This means that Linux users can now use popular applications such as TWhirl & Kuler while developers can begin taking advantage of the robustness and stability of the Linux desktop environment for AIR development & deployment. We announced back in September that Adobe was pushing hard on the Linux front with a beta of AIR for Linux and they've come through producing a platform that now allows cross-platform desktop development for Windows, OS X & Linux. The only downside to this announcement is that 64-bit support isn't immediately available in the new release but it doesn't mean that it can't work. Adobe has published a knowledgebase article that runs you through the steps of making AIR v1.5 work with 64-bit Linux distros. To get started building desktop apps for Linux using AIR, just grab: Download Adobe AIR 1.5 for Linux Download Adobe AIR 1.5 SDK for Linux They've also published a FAQ that could help in troubleshooting any issues with installation.

Mark Pilgrim has a new episode of This Week in HTML 5 that covers the onbeforeunload event. To get there, a lot happened, which Hixie explained: Someone asked for onbeforeunload, so I started fixing it. Then I found that there was some rot in the drywall. So I took down the drywall. Then I found a rat infestation. So I killed all the rats. Then I found that the reason for the rot was a slow leak in the plumbing. So I tried fixing the plumbing, but it turned out the whole building used lead pipes. So I had to redo all the plumbing. But then I found that the town's water system wasn't quite compatible with modern plumbing techniques, and I had to dig up the entire town. And that's basically it. After going into the detail of the actual unraveling, Mark gets to the skinny: The most interesting part of this new definition is the script group, a new concept which now governs all scripts. When a Document is created, it gets a fresh script group, which contains all the scripts that are defined (or are later created somehow) in the document. When the user navigates away from the document, the entire script group is frozen, and browsers should not execute those scripts anymore. This sounds like an obvious statement if you think of documents as individual browser windows (or tabs), but consider the case of a document with multiple frames, or one with an embedded iframe. Suppose that the user clicks some link within the iframe that only navigates to a new URL within the iframe (i.e. the parent document stays the same). The parent document may have some reference to functions defined in the old iframe. Should it still be able to call these functions? IE says no; other browsers say yes. HTML 5 now says no, because when the iframe navigates to a new URL, the old iframes script group is frozen -- even if there are active references to those scripts (say, from the parent document), browsers shouldn't allow the page to execute them. The main benefit of this new concept of script groups is that it removes a number of complications faced by the non-IE browsers. For example, it prevents the problem of scripts suddenly discovering that their global object is no longer the object that they think of as the Window object. Script groups are also frozen when calling document.open(). Freezing script groups also defines the point at which timers and other callbacks are reset, which is something that previous versions of HTML had never defined. In related news, Jacob Gube has a guest post on RWW covering 5 Exciting Things to Look Forward to in HTML 5.

Joe Walker and team have announced the first RC for DWR 3.0. We asked Joe to tell us what is new: DWR now supports: varargs method overloading typed parameters binary file upload/download it has a set of new types it can marshall DWR will let you use JavaScript to implement Java interfaces (e.g. to register a Listener interface to publish changes to waiting browsers using Reverse Ajax), we now have 3 modes to control resource usage and there is a more scalable Reverse Ajax layer. There are new integrations with Dojo, TIBCO GI and Aptana Jaxer, and a new DOM manipulation library. We have special asynchronous servlet support for Tomcat and Glassfish, and our Spring and Guice integrations have been beefed up. We now support JSONP and JSON-RPC, and there's a whole bunch of etc thrown in for good measure too. There is a more complete list at Joe's blog, or you can just skip straight to the download page.

Here is a fun one for Friday, Hallvord Steen discusses the error reports coming in for Opera 10 that are to do with the version number. That's right, it appears that a number of people use the first character as the version number, which means that Opera 10 is showing up as Opera 1: So we're busy preparing the major upgrade from 9.5x and 9.6x - and what's more obvious than calling it Opera 10? What's in a name, or a version number? Apparently a lot of trouble. As Andrew Gregory already noticed, we're the first browser ever to release with a two-digit version number. If websites assume that version numbers always have a one-letter "major" part and look for a single digit, they are going to "detect" Opera 1! Since we released the first preview of Opera 10, we're seeing the bug reports come in. Web sites go belly up because of their bad sniffing.

David King has created a small JavaScript library dlink that styles your links to let the user know if the link is internal, external, a subdomain, an anchor on the same page, or an email link. To setup, you can simply: PLAIN TEXT HTML:   <script type="text/javascript" src="http://oopstudios.com/dlink/dlink.js"></script>   <!-- use class=dlink --> <div class="dlink"> your <a href="#">link filled</a> content... </div>   <!-- change styles a.internal  {color: #D47700;} a.external  {color: #0074D4;} a.subdomain {color: #D43500;} a.email     {color: #00B235;} -->  

Pixastic uses <canvas>'s ability to expose raw pixel information to perform Photoshop-style image manipulation effects all in your standards-based browser. For an example of Pixastic in action, the library's authors have built a cute little Photoshop clone in a browser: Here's an example of using the underlying API: PLAIN TEXT JAVASCRIPT:   var img = document.getElement("myImage"); // get the image element   if (img.complete) {     // make sure the image is fully loaded         Pixastic.process(                 img,                 "brightness",   // brightness/contrast adjustment                   {              // options object                           "brightness" : 60,      // set brightness option value to 60                         "contrast" : 0.5,       // set contrast option value to 0.5,                         "rect" : {            // apply the effect to this region only                                 "left" : 100,                                 "right" : 100,                                 "width" : 200,                                 "height" : 150                         }                 }         ) }   There's also a jQuery plug-in wrapper, allowing you to do stuff like this: PLAIN TEXT JAVASCRIPT:   // invert the image with id="prettyface" $("#prettyface").pixastic("invert");   // convert all images with class="photo" to greyscale $(".photo").pixastic("desaturate");   // chained blur and a regional emboss, see image further down $("#myimage")         .pixastic("blurfast", {amount:0.2})         .pixastic("emboss", {direction:"topleft", rect:{left:50,top:50,width:150,height:150}});   The architecture of the library is nice; there's a small core Pixastic library file (pixastic.core.js) and then each effect is factored out into its own JS file. A handy web interface lets you download your own minified subset of Pixastic. Cool!

Herb Sutter is a great leader in our industry, and he has taken on Jeff Atwood's post on Web 2.0 app design. It comes to the age old issue of how "desktop-y" do you make your Web application? Herb believes that having them look like desktop apps is natural. I think that I disagree. I like Gmail because it is a great blend of web-y and desktop-y. In fact, it is more like pine on the Web than Outlook on the Web :) The best applications seem to nail that blend of both worlds. What do you think? This is Herb's conclusion: Most SaaS/Web 2.0 applications today look and feel pretty much the way GUI applications looked and felt like on DOS, before technologies like Windows and OS/2 PM existed. Around the late 1980s, people wrote lots of GUI applications that ran on DOS, but we didn’t have a widely-used common GUI infrastructure that handled basic windows and menus and events, much less standards like CUA that tried to say how to use such a common infrastructure if we had it. So they each did their own thing, borrowing where possible from what seemed to work well for GUIs on other platforms. Twenty years ago, everyone writing GUIs on DOS designed the UIs as best they could, borrowing where possible from what they saw worked on platforms like the Macintosh and Xerox Alto and Star — but the results were all over the map, and would stay that way until a standard environment, followed by standard guidelines, came into being. Today, everyone writing rich Web 2.0 applications is doing their own thing, borrowing as best they can from Macs and Windows and others — but the results are all over the map, and will continue to be until there actually is such a thing as a UI standard for rich-GUI web applications. You can see that in the differences between Zimbra and Outlook Web Access. In the meantime, it’s not just okay to borrow from what we’ve learned on the desktop; it’s necessary. And the question isn’t whether metaphors users already understand on the desktop will migrate to the web, but which ones and how soon, because it’s the whole point of SaaS. The industry will soon be going well beyond Google Apps; with offerings like Office Online already announced for the short term, which puts still more rich-client GUI apps like word processors and spreadsheets in the browser (with functionality somewhere between Google Apps and the desktop version of Office). Zimbra and Outlook Web Access aren’t examples of poor web app design, but exactly the opposite: They’re just the beginning of the next wave of rich web apps.

Steve Souders has a nice performance roundup for 2008 that details some of the important utilities and knowledge that we gained this year. His post gets even more interesting when he posits about the future, including: Visibility into the Browser: Packet sniffers (like HTTPWatch, Fiddler, and WireShark) and tools like YSlow allow developers to investigate many of the “old school” performance issues: compression, Expires headers, redirects, etc. In order to optimize Web 2.0 apps, developers need to see the impact of JavaScript and CSS as the page loads, and gather stats on CPU load and memory consumption. Think “Web 2.0?: Web 2.0 pages are often developed with a Web 1.0 mentality. In Web 1.0, the amount of CSS, JavaScript, and DOM elements on your page was more tolerable because it would be cleared away with the user’s next action. That’s not the case in Web 2.0. Web 2.0 apps can persist for minutes or even hours. If there are a lot of CSS selectors that have to be parsed with each repaint - that pain is felt again and again. If we include the JavaScript for all possible user actions, the size of JavaScript bloats and increases memory consumption and garbage collection. Dynamically adding elements to the DOM slows down our CSS (more selector matching) and JavaScript (think getElementsByTagName). As developers, we need to develop a new way of thinking about the shape and behavior of our web apps in a way that addresses the long page persistence that comes with Web 2.0. Performance Standards: As the industry becomes more focused on web performance, a need for industry standards is going to arise. Many companies, tools, and services measure “response time”, but it’s unclear that they’re all measuring the same thing. Benchmarks exist for the browser JavaScript engines, but benchmarks are needed for other aspects of browser performance, like CSS and DOM. And current benchmarks are fairly theoretical and extreme. In addition, test suites are needed that gather measurements under more real world conditions. Standard libraries for measuring performance are needed, a la Jiffy, as well as standard formats for saving and exchanging performance data. JavaScript Help: Browsers also need to make it easier for developers to load JavaScript with less of a performance impact. I’d like to see two new attributes for the SCRIPT tag: DEFER and POSTONLOAD. DEFER isn’t really “new” - IE has had the DEFER attribute since IE 5.5. DEFER is part of the HTML 4.0 specification, and it has been added to Firefox 3.1. One problem is you can’t use DEFER with scripts that utilize document.write, and yet this is critical for mitigating the performance impact of ads. Opera has shown that it’s possible to have deferred scripts still support document.write. This is the model that all browsers should follow for implementing DEFER. The POSTONLOAD attribute would tell the browser to load this script after all other resources have finished downloading, allowing the user to see other critical content more quickly. Developers can work around these issues with more code, but we’ll see wider adoption and more fast pages if browsers can help do the heavy lifting. Steve has been teaching a class on performance at Stanford this semester. You can check out his final and midterm to see if you could ace the exam. Also, you can see material from the guest lecturers. Check it out. And, what are you looking forward to in 2009 wrt performance?

John Resig and Jan Odvarko have announced something pretty darn cool, FireUnit. FireUnit provides a simple JavaScript API for doing simple test logging and viewing within a new tab of Firebug. The example given shows the API nicely: PLAIN TEXT JAVASCRIPT:   // Simple true-like/false-like testing fireunit.ok( true, "I'm going to pass!" ); fireunit.ok( false, "I'm going to fail!" );   // Compare two strings - shows a diff of the // results if they're different fireunit.compare(   "The lazy fox jumped over the log.",   "The lazy brown fox jumped the log.",   "Are these two strings the same?" );   // Compare a string using a regular expression fireunit.reCompare(   /The .* fox jumped the log./,   "The lazy brown fox jumped the log.",   "Compare a string using a RegExp." );   // Display the total results fireunit.testDone();   // -- browser events   // You can also simulate browser events var input = document.getElementsByTagName("input")[0]; fireunit.mouseDown( input ); fireunit.click( input ); fireunit.focus( input ); fireunit.key( input, "a" );   // -- Run batches   // Or run multiple pages of tests: fireunit.runTests("test2.html", "test3.html");   // Place at the end of every test file in order to continue fireunit.testDone();  

I am proud to be able to announce the new currency converter on Yahoo finance. Why? Because it is a perfect example of how a complex rich user interface can be built in an accessible manner. As the main developer, Dirk Ginader explains: About 9 months ago my fellow co-worker, the User Experience Designer Graham Beale, and I started developing ideas for a prototype of a new Currency Converter for the worldwide relaunch of Yahoo! Finance. We wanted Features we haven't seen like this in the Internet so far. We wanted conversion without a page reload, searching for currencies like in the Firefox 3 "awesome bar", total accessibility, much more and of course everything in realtime. There will be an in-depth article on how Dirk and his colleagues (with a special mention to Artur Ortega who did all the screen reader testing) build the converter on the Yahoo Developer Blog after the holidays. For now, have a look at the code and see the wonderful attention to detail. One of the main tricks they've done can be mentioned already: dynamic re-writing of form labels.

Remon de Boer sent us a link to Achmea.nl, a Dutch website that brought back memories of Thomas Fuch's Ajax makeover of Gucci's website some time ago. Ironically, Achmea.nl starts out by displaying a Flash-powered "Loading" graphic: But once the site loads, it's all Ajax. Powered by YUI, the site sports animated roll-overs, smooth transitions, and otherwise feels like Flash. Nice work!

Yensdesign has a nice little example of a music player UI that uses mouse gestures and key handling to give a clean experience. Songza did a great job here, and I still use it to find songs for the kids.

Jeffrey Sharkey has created OilCan a thin wrapper on top of the WebKit shipping on Android that allows you to install userscripts that allow you to access to Android "Intents". Intents are very nice abstractions that allow you to access large components and reuse them in different ways. Romain Guy has a nice post on them. OilCan lets you customize any website by inserting JavaScript to change the website and help it reach into the Android world using intents. OilCan inserts some powerful buttons into normal websites, and that power comes from Android intents. We didn't write a barcode scanner or the radar app into OilCan, but using intents we can launch those apps with parameters. We can request the Barcode Scanner app to scan something and return the code to us, or launch the Radar app with a specific lat/lon. Userscripts can do other cool stuff, like hide the navigation columns in Wikipedia to make it easier to view on small screens. This is a proof-of-concept for now, and will probably turn into a binary plugin for the default Browser in the future. A nice piece from an example shows the intent call out: PLAIN TEXT JAVASCRIPT:   function generate(item) {      var helper = document.createElement('input');      helper.type = 'button';      helper.value = 'Scan barcode...';      helper.addEventListener('click', function(event) {          // use the intentHelper bridge to fire an intent to Barcode Scanner          // it's available in Market, or from http://code.google.com/p/zxing/          var result = window.intentHelper.startActivityForResult(JSON.stringify({              action:'com.google.zxing.client.android.SCAN',              category:['CATEGORY_DEFAULT']          }));            // parse the result we get back, and read the barcode from the extras          result = JSON.parse(result);          item.value = result['extras']['SCAN_RESULT'];      }, false);      return helper;  }    Very cool!

We desperately want users to upgrade to the latest and greatest. A prominent and respected Web citizen recently said "With Ajax we are developing to 1997 technology, and are restricted by IE 6." What if you didn't have that nagging feeling, and instead could use the platform that sits below the clients of modern browsers? You could do a hell of a lot more. Well, maybe we get a small bone in the zero day exploit for IE that is doing the rounds right now. Some are arguing over how easy or hard it is to get safe (run some regedit really OK?) but scary it is. Other folks can't gloat though, as who know what the hackers will find next. But, for now, we may get a few switchers. Maybe the IT guys who made the call to write ActiveX components back in the day will finally get a kick up the backside and move over? The end users? Hmm, I wonder how many are paying any attention versus clicking on the big "Internet" button and doing their thing.

Alex Russell decided to rewrite and create Census 2 to act as a new benchmark for various RIA techniques. This is based on the the original Census benchmark done by James Ward of Adobe. There are several goals of this re-write: Fairness. Tests need to be run multiple times for them to be representative in any way. Likewise, systems not being directly tested need to be factored out as much as possible. C2 does this by reducing the number of dependencies and running tests (at least) 5 times and discarding outliers before reporting an average. I’ve also worked to make sure that the tests put the best foot forward for all of the tested technologies. Hackability. Benchmarks like Census serve first as a way for decision makers to understand options but second as a way for developers to know how they’re doing. Making it trivial to add tests helps both audiences. Portability. The test suite should run nearly everywhere with a minimum of setup and fuss. This ensures that the largest numbers of people can benefit from the fairness and hackability of the tests. The results so far have been instructive. On smaller data sets HTML wins hands-down for time-to-render, even despite its disadvantage in over-the-wire size. For massive data sets, pagination saves even the most feature-packed of RIA Grids, allowing the Dojo Grid to best even XSLT and a more compact JSON syntax. Of similar interest is the delta between page cycle times on modern browsers vs their predecessors. Flex can have a relatively even performance curve over host browsers, but the difference between browsers today is simply stunning. Given the lack of an out-of-the-box paginating data store for Flex, RIAs built on that stack seem beholden to either Adobe’s LCDS licensing or are left to build ad-hoc pagination into apps by hand to get reasonable performance for data-rich business applications. James Ward has already exchanged some mail with me on this topic and it’s my hope that we can show how to do pagination in Flex without needing LCDS in the near future. The tests aren’t complete. There’s still work to do to get some of the SOAP and AMF tests working again. If you have ideas about how to get this done w/o introducing a gigantic harball of a Java toolchain, I’m all ears. Also on the TODO list is an AppEngine app for recording and analyzing test runs so that we can say something interesting about performance on various browsers. Census 2 is very much an open source project and so if you’d like to get your library or technology tested, please don’t hesitate to send me mail or, better yet, attach patches to the Bug Tracker. Interesting to see this kick off, and I hope that a community forms around it.

Subscribe to the Tech Luminaries Podcast on iTunes Dion and I have been wanting to do a podcast series for a long time that is more casual then Audible Ajax--just chatting with some of the luminaries in tech about their careers and such. We collected some content quite a ways back and have finally gotten around to releasing some of it over on TechLuminaries.com. We think our first episode may be of interest to the Ajaxian community: we interview Brendan Eich, Mozilla’s CTO. As you know, Brendan invented JavaScript and helps steer its evolution both in his role at Mozilla working on a JS implementation and in his participation with the ECMA committee overseeing JavaScript's future. We recorded this long before we ever considered coming to Mozilla, which casts a weird perspective on the interview. Hope you enjoy it.

This is a fun canvas demo by Stefan Pettersson that brings you back to your Amiga days (if you remember those, or weren't an Atari man). You can check out the JavaScript that makes the world turn. function start() { var resolution = 25; var speed = 0.02; var position = 150; var size = 50; var step = Math.PI * 2 / resolution; var bars = []; bars.push( new RasterBar(step, size, speed, getColor1) ); bars.push( new RasterBar(step, size, speed, getColor2) ); bars.push( new RasterBar(step, size, speed, getColor3) ); var t = 0; setInterval(function() { ctx.clearRect(0,0,600,400); t += 0.03; if (t > Math.PI*2) t = 0; for (var i = 0; i < bars.length; i++) { bars[i].oldPos = bars[i].newPos; bars[i].newPos = position + Math.round(100 * Math.sin(t + i*(Math.PI*2) / 3)); if (bars[i].oldPos >= bars[i].newPos) { bars[i].draw(bars[i].newPos); } } for (var i = 0; i < bars.length; i++) { if (bars[i].oldPos < bars[i].newPos) { bars[i].draw(bars[i].newPos); } } }, 25); } And as Stafan says, listen to this in the background!

The UML diagram above is from Matt Prokes as he creates Java-like interfaces for JavaScript. He has a full example: An example of an object which requires an implementation of the interface. PLAIN TEXT JAVASCRIPT:   //This code is valid, and the execution will be successful. function executeInterface1(executeThis){   var castedIface = executeThis.cast('TestInterface');   castedIface.testMethod1(1,2,3); }   //This code is valid, but the execution will not be successful. function executeInterface2(executeThis){   var castedIface = executeThis.cast('TestInterface');   castedIface.testMethod2(4,5,6); }   Alright, lets instanciate, the objects and set them to variables. Feel free to type in the variables and take a look, on the firebug window! PLAIN TEXT JAVASCRIPT:   InitedTestObject = new TestObject(); //variable not used in this example, but I thought I would still make it available! CastedTestInterface = InitedTestObject.cast('TestInterface');   Ok, so lets try it out! We wrap it all up in some simple div tags with onclick events. PLAIN TEXT HTML:   onclick="executeInterface1(InitedTestObject)" onclick="executeInterface2(InitedTestObject)"  

Eric Wahlforss, the founder of SoundCloud, wrote in to tell us about "The Cloud Player", a iTunes / Songbird clone written entirely in Ajax: we just released an open-source itunes-clone built in jquery (and app engine, soundmanager 2, soundcloud api), complete with smart playlists, drag'n'drop, keyboard shortcuts, load-as-you-scroll playlists, playlist sharing, waveform display of tracks, etc. we've extended jquery ui a bit for this to happen. It's using soundcloud.com as the primary music source, and the SoundCloud JSONP API to access the track metadata, available at http://soundcloud.com/api. I like how it shows the waveform of the entire track at the bottom of the screen. Unfortunately, it's limited to the rather tiny music selection on soundcloud's service, but since it's open-source, the future is interesting indeed. Eric sent along a playlist with some of his electronic playlists: http://www.thecloudplayer.com/share/3e718. Nice work!