You searched for: 'native'

Thursday, November 23rd, 2006

qooxdoo 0.6.2 Released

Category: JavaScript, Library

qooxdoo has a new release that adds support for Webkit.

As mentioned above and already announced in our developer blog, qooxdoo now includes support for WebKit. We expect to fully support the next major version Safari 3.0 which will be based on the current development of WebKit. There is only limited support for Safari in its current version 2.0.4, though. Reason is, that Safari 2.0 still has many bugs that can hardly be worked around. Luckily, many of those bugs are already fixed in the nightly builds of WebKit. Besides the various bugs, Safari 2.0’s JavaScript engine and its execution speed is not competitive with respect to the latest versions of the other major browsers (Firefox 2.0, IE7, Opera 9). Good news is, that the current builds of WebKit are tremendeously faster than Safari 2.0, approximately by a factor of 7-8 for a typical qooxdoo demo.

Check out the release notes for full details on changes in this release.

Some of them are:

  • Made qooxdoo completely XHTML compatible. Replaced all uppercase tag names with their lowercase variant.
  • Improved NativeWindow to support the querying of the load state. Added events for “load” and “close”.
  • Modified XmlHttpRequest and related APIs to respect the latest suggestions from Microsoft.
  • Added IframeManager to manage visible iframes in order to protect the application events of the “surrounding” document from getting interrupted while switching document context (particularly drag & drop over embedded iframes)
  • Added Resizer widget to allow of customization regarding the dimensions of any widget by the user.

Posted by Dion Almaer at 9:39 am
1 Comment

4.3 rating from 27 votes

Thursday, November 16th, 2006

Google Web Toolkit 1.2 Released

Category: Google, GWT, Toolkit

GWT 1.2 has been officially released.

The last important bugs have been squashed from the RC that was out there recently.


  • Create a Widget by compositing other Widgets. Lay out Widgets automatically in Panels. Send your Widget to other developers in a JAR file.
  • To communicate from your web application to your web server, you just need to define serializable Java classes for your request and response. In production, GWT automatically serializes the request and deserializes the response from the server. GWT’s RPC mechanism can even handle polymorphic class hierarchies, and you can throw exceptions across the wire.
  • No, AJAX applications don’t need to break the browser’s back button. GWT lets you make your site more usable by easily adding state to the browser’s back button history.
  • In production, your code is compiled to JavaScript, but at development time it runs in the Java virtual machine. That means when your code performs an action like handling a mouse event, you get full-featured Java debugging, with exceptions and the advanced debugging features of IDEs like Eclipse.
  • Your GWT applications automatically support IE, Firefox, Mozilla, Safari, and Opera with no browser detection or special-casing within your code in most cases.
  • GWT’s direct integration with JUnit lets you unit test both in a debugger and in a browser…and you can even unit test asynchronous RPCs.
  • Easily create efficient internationalized applications and libraries.
  • If GWT’s class library doesn’t meet your needs, you can mix handwritten JavaScript in your Java source code using our JavaScript Native Interface (JSNI).

As we mentioned when we released the 1.2 Release Candidate, you can now develop and debug with GWT on Mac OS X in addition to Linux and Windows. We are pretty proud of this particular feature because GWT is now about as “platform independent” as you can get: develop on Windows, Linux or Mac OS X and deploy to IE, Firefox, Safari and Opera on any platform, without any special cases in your code. (If you want a bit more detail about our implementation of Mac OS X support, our release nomenclature and other tidbits, this recent InfoQ interview may interest you.)

We also have already talked about how much faster the 1.2 hosted mode debugging environment is. And it is. If you’ve ever found yourself dropping to the command line using only the GWT compiler because hosted mode was too slow, you really should check out 1.2. Refreshes in hosted mode are almost instantaneous, and hosted mode lets you actually debug your code.

Posted by Dion Almaer at 6:39 pm

4.2 rating from 25 votes

Popup Nightmare 2.0?

Category: Advertising, Security

Nat Torkington on the O’Reilly Radar recently commented on the rise of “floats” (AKA “divdows”, “Ajax dialogs”).

One of the really big issues facing us, IMHO, is the new Javascript-driven ad technology called “floats”. They’re not separate windows popped up, they’re in-window divs that move up to obscure the web page and force the user to click to dismiss them. They can’t trivially be blocked because they’re generated by Javascript code within the page, and identifying such code is a similar problem to identifying viruses. They ruin the user’s experience by being unavoidable and maximally intrusive.

At the moment they’re rare (e.g., TVNZ and MSN only show them once per user per day) but if we learned anything from 2001 it’s that greed will ruin user experience if it can get an extra buck in ad revenue. We got popup blockers as a result of the 2001 popup orgy. What’s going to save us from the 2007 float invasion?

It’s really not as scary as it sounds, as these new popups can only live inside the tab/window of the app that launched them – sites that run annoying Ajax popups are only doing themselves a disservice, the web equivalent of nagware. Christian Flury has outlined the counter-arguments.

  • Javascript pop-up windows left a trace in your working environment: Even after leaving the page that had triggered them, you still had those few additional browser windows open – and those were the days before tabbed-browsing became popular, so it was already difficult enough to stay on top of your zillions of open browser windows
  • Psychologically, from a site owner’s perspective, a pop-up window is not as closely associated with your page as an ad that occupies your own real estate, so to speak.
  • More importantly, back in the olden days, it was far from obvious, especially to the not so tech-savvy, which page had actually triggered the pop-up window.

That said, there are still security implications – with richer graphics and browser scripting, it’s easier to pretend you’re a native OS dialog box.

Posted by Michael Mahemoff at 5:34 pm

3.4 rating from 95 votes

Thursday, November 9th, 2006

Fjax: Switching the A to F means what?

Category: Flash, Framework

Jay and Steve McDonald didn’t like traditional Ajax (the libraries, the XML parsing (even though you can use JSON of course)) and decided that they could create “smoother, more desktop-like web experiences that AJAX promises”, as they said in an interview at

What is Fjax?

Website: “Fjax is an open, lightweight, cross-browser methodology for Ajax-style web 2.0 development
Fjax is a technique focused on drastically streamlining the XML handling layer of web 2.0 applications. Picture Ajax’s XML parsing and handling with less than 65 lines of code! It’s not a replacement for toolsets that provide presentation-layer visual gizmos. Think of it as a new engine to put under the hood of all the great widgets that are already out there.”


Jay: Flash. XML. Approachable. Dynamic. Content.
Steve: fun, easy, compiled, creative, secure.

The website is of course done in Fjax and follows a single page application paradigm (apart from some pages that do get url changes so you can reload them). To get links that work you need to click “Permalink this page”. This is the same issue as you have in the normal Ajax world when you are swapping out content dynamically of course.

The interview asks Jay and Steve about:

  • They say “necessity is the mother of invention”. Is that true with FJAX? Was that your experience in coming up with this technique as an AJAX alternative?
  • Have you used FJAX extensively in your own design work? Have you seen other people use the technology effectively?
  • What’s been the biggest challenge in bringing FJAX to the public consciousness? How has the development community responded?
  • Are you seeking any sort of trademark for the term “FJAX” and have you contacted Adobe about FJAX?
  • With advancements in streaming video, css integration, and xml parsing Flash has suddenly become a staple in the world of Web 2.0. However, this takes some of the “open source” credo out of Web 2.0 development and creates a dependency on a commercial tool. Do you have any thoughts on Flash’s second life?
  • What are Flash’s weaknesses and what kinds of improvements would you make if you were head of product development at Adobe?
  • You’ve been featured in for your technique and you have a website dedicated to FJAX. Has your discovery of FJAX, and the subsequent attention, affected your current design/consulting business?
  • In your opinion, what’s the most exciting thing about the Web today?

This could be a nice easy to use framework, and Flash isn’t as scary as it used to be (politically as well as technically). Personally, we think that Fjax IS still Ajax, even if it isn’t AJAX.


Posted by Dion Almaer at 8:45 am

2.6 rating from 42 votes

Wednesday, October 25th, 2006

Dojo 0.4 Released

Category: Announcements, Dojo

The Dojo team has fully released version 0.4 which “contains many exciting new features, a whopping 529 bugs closed, and the initial release of the long-awaited documentation tool, with inline API documentation that will continue to improve with follow-on releases. These improvements will make Dojo appealing to entirely new audiences and will bring Ajax applications to a new level of acceptance as a first-class user environment. Some of the highlights include:”

  • dojo.a11y: the foundation for accessibility (a11y), implemented in some of Dojo’s widgets in 0.4 with more to follow in 0.5. Dojo strives to provide keyboard function as well as integration with high-contrast mode and screen readers for the visually impaired.
  • dojo.charting: A charting engine to implement a variety of chart types using vector graphics
  • dojo.gfx: a 2D vector graphics API which renders natively to browsers as SVG or VML
  • dojo.i18n: a follow on to the translation support in 0.3.1, there is now build support for collecting localized resources in a single file as well as support for localized date and time formatting. More formatting types and more localization to come in 0.5.
  • dojo.lfx: major improvements, such as chainable animations
  • dojo.namespaces: support for extensible widget namespaces and an automatic widget manifest loading feature.
  • dojo.widget: new widgets like Clock, FilteringTable, ProgressBar, plus enhancements to Editor2 and the AccordionContainer. Also localization of some widgets, such as DatePicker.
  • AOL’s contribution of a linker for Javascript, not yet integrated into the build.

The roadmap has also been updated, showing 0.4.1, 0.5 and beyond.

Posted by Dion Almaer at 12:45 am
Comment here

4.3 rating from 41 votes

Tuesday, October 24th, 2006

JSONRequest Proposal

Category: Ajax, JSON, The Ajax Experience

Douglas Crockford of Yahoo, a pioneer of JSON, presented “JSON: The X in Ajax” at The Ajax Experience Tuesday afternoon.

In the presentation, Douglas discussed his proposal for native support of a new JavaScript object named JSONRequest. The object would provide a simple API for issuing Ajax requests to exchange JSON data using the following methods:

var request =, data, callbackFn);
var request = JSONRequest.get(url, callbackFn);

Other key points about the proposed object included:

  • Requests are transmitted in order
  • Requests can have timeouts
  • Requests can be cancelled
  • Connections are in addition to the browser’s ordinary two connections per host

Douglas has published more information about his proposal. The object itself is also available for download.

Posted by Tom Geer at 4:19 pm

4.1 rating from 49 votes

Dojo In Depth with Alex Russell

Category: Dojo, The Ajax Experience

After a thorough Introduction to Dojo, Alex Russell demonstrated some of the lastest additions to the Dojo Toolkit at The Ajax Experience. Two areas new to Dojo 0.4 stood out.

First, dojo.gfx now provides a common API to native 2D graphics across browsers. The API takes advantage of the native SVG support in Firefox 1.5+ and Opera 9, while still providing functional graphics in IE. Native SVG support in Safari is also on the way.

Second, Alex’s demonstration of cometd was very impressive. Cometd utilizes a publish/subscribe model and offers sub-second notification to browser-based clients.

Feel free to check out the slides from “Dojo In Depth”.

Posted by Tom Geer at 12:15 pm

3.6 rating from 20 votes

Monday, October 23rd, 2006

Google Web Toolkit – Performance and Interoperability

Category: GWT, The Ajax Experience

The Google Web Toolkit (GWT) is Google’s solution to making Ajax development easy for Java programmers. Google’s Bruce Johnson spoke about GWT at The Ajax Experience on Monday.

As we all know, Ajax development introduces some complexities (browser incompatabilities, managing numerous technologies within the page, etc.). GWT is a Java framework that nearly eliminates these complexities from the Java developer’s radar. Using GWT, the Java developer writes Java code that is compiled into Ajax-enabled pages by the GWT compiler. The compiler generates HTML and JavaScript that works in all major browsers while hiding many of the messy details from the Java developer.

Other highlights of Bruce’s presentation included:

  • Numerous demonstrations that showed simple Ajax-enabled applications generated with a small amount of Java code
  • Easy management of history and bookmarking inside of the Ajax application
  • Interoperability (GWT-generated code is easily integrated into existing pages)
  • An overview of the JavaScript Native Interface (JSNI) which enables the developer to include JavaScript libraries in their GWT Java source.

Posted by Tom Geer at 10:45 pm

2.9 rating from 20 votes

ASP.NET: Replacing HTML without UpdatePanel

Category: .NET

Scott Guthrie has posted a discussion of injecting HTML into a page in ASP.Net, without using UpdatePanels.

Usually when I integrate AJAX functionality into my code I just end up using the built-in server controls that ASP.NET AJAX provides (UpdatePanel, UpdateProgress, etc) and the cool controls in the ASP.NET AJAX Control Toolkit.  Scott Hanselman had jokingly called using these AJAX controls “cheating” when he interviewed me two weeks ago for his latest podcast – since they don’t require that you write any client-JavaScript for most common scenarios.

This weekend I decided to focus my coding on some of the client JavaScript pieces in the ASP.NET AJAX framework that don’t use UpdatePanels at all, and to experiment with alternative ways to use the server to easily generate HTML UI that can be dynamically injected into a page using AJAX.  In the process I created what I think is a pretty useful library that can be used with both ASP.NET AJAX and other AJAX libraries to provide a nice template UI mechanism with ASP.NET, and which doesn’t use or require concepts like postbacks or viewstate – while still providing the benefits of control encapsulation and easy re-use.

Posted by Michael Mahemoff at 6:08 am

3.8 rating from 40 votes

Wednesday, October 4th, 2006

“Don’t Waste Time” with Graphical Ajax Solutions

Category: Editorial, Flash, UI, Usability

ZDNet’s Ryan Stewart argues against performing interactive graphics with Ajax (i.e. standard web technologies). The article relates to my post on different techniques for graphics with Ajax (covered on Ajaxian).

Michael responds that the main argument against Flash is the user base, then goes on to list the plusses and minuses of "richer plugins".

You simply should not be trying to create a rich, graphical experience in Ajax. The options (SVG, Canvas, VML, ect) are buggy, supported in different ways depending on the browser, and, for the most part, are a poor experience for both users and developers.

The kind of rich interactivity that Flash and Windows Presentation Foundation provide are going to be leaps and bounds ahead of what any browser technology can do, and that's why they will succeed. The web becomes richer every day. Video and Music are taking the web by storm, and with the surge in broadband adoption, people are making these things part of their every day web experience. Ajax applications can't take advantage of them in the way the Flash or WPF can.

Flash (more generally, Richer Plugins) was actualy one of the graphics techniques mentioned in the original article. It’s all about trade-offs. I’ve actually argued myself that Ajax developers ought to take Flash more seriously, as it’s an excellent complement to Ajax. Flash sometimes makes a nice sweet spot – with graphics and multimedia closer to that of the desktop than standard DHTML/Ajax, but still living in a web platform that’s often more convenient than the desktop. The two monster apps of the past 12-18 months, YouTube and MySpace, demonstrate the power of Flash and multimedia on the web.

The benefits of Flash over Ajax are self-evident and undeniable, but Flash comes with its own set of problems too – not every user has Flash installed, not every user has the latest version, not every network allows Flash applications to run, not every developer and company wants to commit to proprietary technology when viable alternatives are available. Ajax apps tend to be easier to degrade gracefully as well; Flash is more all-or-none.

What if I want to introduce a histogram to an Ajax enterprise app? I’ll happily use a DOM/CSS library like CSS Graphs. Or if I’m writing a Firefox extension, I might use a data: resource to create a whimpy graphic since I no longer care about portability or even extravagant display. Maybe I want a 16×16 heatmap next to each search result – I’ll draw it with a Canvas and keep all the search results in standard HTML. And so on. See? Competent developers don’t engage in dogmatic battles, because they know software is all about trade-offs. Many times, Flash wins. Many times, it loses.

Last word goes to Ryan:

Don’t waste time trying to build the next generation of the web with graphical Ajax solutions … you already have a solution, and it’s getting more robust by the day. As your web applications start to require a more rich environment, embrace Rich Internet Applications – you’ll be better off.

Posted by Michael Mahemoff at 4:44 pm

3.3 rating from 42 votes

Friday, September 8th, 2006

WebOS Versus Webified Desktops

Category: Editorial

ReadWriteWeb takes on Webtops in an article that has gained traction in the blogosphere. the following downsides are noted:

  • Works at the mercy of the network and the server load.
  • While the many enabling capabilities of network-based storage architectures are of
    substantial value – issues of authentication, access control, and security/privacy of the
    stored data remain. Are you going to let someone else handle your data? Would you trust a
    startup to protect your critical data? [Ed: for an interesting side argument, see this discussion of
    IBM’s SoulPad from a year ago]
  • The privacy, control, reliability and performance issues prevent the WebOS from
    being an alternative to the ever-more-affordable and easy-to-use desktop.
  • WebOS requires a fast and reliable (if not flawless) connection to
    work correctly.
  • Inability to operate peripheral devices.
  • Web applications rely on open source infrastructure and an array
    of technologies and formats – and these are constantly changing, often with no
    regard for being backwards compatible.

Another issue for webtops is the lack of context. Unless there’s a plugin involved, they can’t record the user’s surfing patterns, so the user has to be more explicit in customizing the interface, and more diligent in maintaining it.

The article goes on to mention some internet-connected desktop apps, like ITunes, Second Life, and Excel 2007, suggesting that a better direction is to improve the desktop. While these are indeed good examples that illustrate the power of a connection desktop app, they can hardly be compared directly to just the webtop category. problems. Webtops are hardly a proxy for all “Web 2.0” – or Ajax – applications, as the article seems to imply. Comparing Web 2.0 to the desktop would have to involve a more detailed consideration of the Office wannabees, web-based aggregators, and online music managers, for starters.

Anyway, the article offers a worthy reminder that connected apps do not have to run inside a browser. One further issue is the interaction between connected apps and web apps … there’s no reason why a word-processor, for example, can’t run on both platforms, connected to the same data source.

Posted by Michael Mahemoff at 2:08 am

3.6 rating from 40 votes

Thursday, September 7th, 2006

Live Filter Pattern

Category: Articles, LiveSearch

Peter Forde has written a piece on re-inventing search with a Live Filter pattern.

The article talks about his reasoning behind filtering vs. alternatives like Live Search, and ends with a Live Filter demo.


Many of the concepts in this article would be very difficult to implement without Ruby on Rails. Rails introduces the concept of Partials. Partials are nothing more than snippets of fully formed XHTML which get inserted into the innerHTML of objects in a browser’s DOM by JavaScript. The specifics of this process are outside of the scope of this article. While you can update the innerHTML of a DIV or SPAN using any Ajax-capable scripting language such as PHP, there is an architectural elegance that enables this filtering system that we believe would be difficult to replicate.

Implementing a filter system that works across all common browsers is a real challenge, full of gotchas and necessary hacks. While nothing here is offensive, you might be surprised at how involved it can get. The reason being that it is of paramount importance to maintain the function and behaviour of the browser’s built-in Back button.

There are two main issues to solve. First off, if you modify the contents of your DOM with Ajax and JavaScript, move to another page, and then return to the form submit page, each major browser seems to corrupt the state of elements on the page in subtle and different ways. For example, Firefox will corrupt the selection state of checkboxes generated at run-time! The second problem is that if a user returns to the search interface with the Back button… what is the user going back to? Suddenly our flow diagram just got a lot more complicated!

The first revelation is that you should be prepared to write client-side functions to persist, restore, and clear the visual state of your filter. When you render the interface, all of your elements will be in their default state. During your document’s onload event you will want to execute an initialize function that can then “hydrate” the state of your elements from a hidden form. Likewise when submitting a query, you will not want to process the data associated with the form elements you see. Instead, “de-hydrate” the state of your interface into data on a hidden form that can be easily passed on.

During the initialization process, you will need to generate a new key value that could be assigned to a query request should one be submitted. You will use this value to build the action attribute of the hidden form that they might submit! This does need to be performed dynamically, in case the user has returned to a previously rendered page with their back button. Browsers can simply not be trusted to clear their page caches, no matter how many META directives you push down in your HTTP header.

One behaviour we’ve evolved while iterating this filter pattern is to remember the state of the last search when returning to the search page via navigation — unless the user specifically clicks on a major site navigation link to go to the search page. We interpret this behaviour as expressing a desire to start a new search from scratch. You’ll want to experiment and see what feels right for your project. These sorts of decisions are subjective and might change with feedback.

Live Filter Demo

Posted by Dion Almaer at 10:50 am

3 rating from 49 votes

Thursday, August 31st, 2006

Mini Review of “Javascript: The Definitive Guide, 5th Edition”

Category: Book Reviews

The latest edition of the venerable tome JavaScript: The Definitive Guide is a sorely needed update. I guess it took Ajax, Web 2.0, and an intervening five years to revive interest in in this quirky client-side language. The fourth edition, while still providing a good formal specification of the language, had fallen woefully out of date both with some of the new features introduced in recent browser versions and in terms of practical examples of how JavaScript is being used to enable Ajax and Web 2.0 applications.

I don’t mean to give a full review of a thousand plus page book here. Rather, I just want to focus on the chapter that covers client-side persistence. In the fourth edition, the corresponding chapter only discussed “cookie scripting.” While this chapter does talk about cookies, it delves into a number of other options for persisting data on the client.

Unfortunately, for a book that describes itself as the “definitive guide”, it only discusses three options for persistence: cookies, IE userData persistence and Flash SharedObjects. This coverage is far from definitive. In fact, Brad Neuberg in his discussion of enumerates seven different client-side storage mechanisms:

  1. Cookie Storage Provider – uses cookies to persist the hash table
  2. Flash Storage Provider – uses Flash’s SharedObjects to persist data
  3. ActiveX Storage Provider – uses COM’s File APIs to persist data
  4. XPCOM Storage Provider – uses XPCOM’s File APIs to persist data
  5. Form Storage Provider – uses the text autosave features of a hidden form to save transient data (the Really Simple History library uses this trick)
  6. WHAT WG Storage Provider – uses native browser persistence to store data, as defined by the WHAT Working Group.
  7. IE Storage Provider – uses IE’s proprietary abilities to store up to 60K of data.

Maybe this is just a sign that the use of JavaScript has grown so far beyond what was common or even thinkable in 2001 that it is simply isn’t possible to write a definitive guide, at least not in a thousand pages. Would you buy a book called “Java: The Definitive Guide?” Probably not.

What is there — the discussion of Flash SharedObjects and IE userData persistence — is pretty brief in comparison to the exhaustive treatment of cookie persistence. It does give you a basic description and enough code samples to get you started, but a cookbook it is not. The section on persistence alternatives has the feeling of an afterthought — something shoehorned into the book relatively late to address Ajax and Web 2.0. In fact, many parts of client-side portion of the book have that feel.

I think the book is still worth buying as a language reference, if only for its treatment of closures and object creation, but for now you’ll have to look online for more detailed, exhaustive, and “definitive” treatment of many topics.

Posted by Dietrich Kappe at 11:05 am

4.1 rating from 30 votes

Tuesday, August 22nd, 2006

Qooxdoo releases version 0.6 RC1

Category: Dojo, Framework, Toolkit

Qooxdoo (pronounced “cooks-do”) has released version 0.6 RC 1. This framework has come a long way since our first post on it over a year ago. Qooxdoo is a LGPL javascript framework with a rich set of widgets and supports namespaces, events, drag and drop, and layouts. For a quick look, check out the demos (particularily the “at-a-glance demo”), or go straight to the download page.

Details on this release:

  • widgets based on the on the features of the included layout managers, no need to know HTML or CSS
  • built with class-based OO and leverages object-oriented JavaScript. Uses namespaces and does not modify or extend native JavaScript types.
  • full set of widgets similiar to that of native desktop applications, with support for keyboard navigation, focus and tab handling and drag & drop
  • abstract transport layer supports queues, timeouts and implementations via XHR, Iframes and scripts with support for event based programming.
  • build system (generator) to package only the needed classes for optimization when in production

Does anyone have some real world experience with this framework? Maybe some comparisons to Dojo or some of the commercial toolkits?

qooxdoox demo in action

Posted by Rob Sanheim at 1:47 pm

4.1 rating from 31 votes

Saturday, August 19th, 2006

Bayeux: A JSON Protocol For Publish/Subscribe Event Delivery

Category: Comet

Some people poo-poo Comet as being too ‘complicated’. The cometd team and others are trying to change that, and created Bayeux.

Bayeux is a JSON-based protocol for clients to register interest in events and for servers to deliver them in a more timely fashion than Ajax-based polling allows. The goals of the Bayeux spec so far have been to:

  • make event delivery fast
  • keep it simple
  • provide extension points in the protocol

Alex Russell says more about how Cometd, Bayeux, and Why They’re Different

As a result we’ve variously rejected plans that involved implementing some subset of XMPP in JSON or actually tunneling XMPP over some other carrier. JSON libraries are available almost everywhere and you can’t beat the speed of eval for message deserialization on the client. It keeps things fast, simple, and pluggable. Authentication and authorization, while being given spots in the protocol, have also been left entirely to implementations to negotiate. The result has been that implementations have gotten off the ground very fast. Since the protocol doesn’t specify any guarantees around durability, entirely ephemeral event busses can be as conformant as MOM-style guaranteed-delivery systems.

So what, then is Cometd and how does it relate to this Bayeux specification? The short answer is that Cometd is a project to provide several reference implementations of Bayeux and to evolve the spec until it’s good enough for some other group to take over maintenance. Bayeux and Cometd are two complimentary parts of a plan to tackle the complexity around building and deploying comet apps, and we’re hoping for many independent Bayeux implementations outside of the Cometd project. For more interactive apps to finally take off, we need a set of portable concepts about how this kind of message passing should be handled in much the same ways that Ajax could be thought of as “RESTian web services for browsers”. Today lots of folks are thinking about event busses under the buzzword banner of SOA, but hopefully in the same way that REST was the lighter but easier variant of SOAP for doing request-response web services, Bayeux can be the less-sophisticated (but easier to use) alternative to exotic schemes for connecting MQSeries and TIBCO to browsers.

Posted by Dion Almaer at 10:14 pm
1 Comment

3.5 rating from 34 votes

Tuesday, August 15th, 2006

Survey of Javascript Inheritance Techniques

Category: JavaScript, Programming

Josh Gertzen of Thinwire has written up a detailed survey of techniques for OO-style inheritance in Javascript, leading up to the technique he’s recently developed to overcome flaws in the existing approaches.

I set out to see if I could devise a working design of my own. It took me about a week to work out something that behaved correctly under all situations, but once I felt confident that it was working, I quickly integrated the approach into the framework. As it stands now, both the beta and beta2 releases of ThinWire leverage that initial design.

His analysis starts with standard prototype chaining techniques (SubClass.prototype = new BaseClass();) and explains where they fall down, in particular problems with calling superclass methods. He then walks through a range of improvements, notably Doug Crockford’s well-known “classic inheritance” technique.

Admittedly, Crockford’s approach is one of the most solid that I found and there is no arguing that based on the body of work he has done on JavaScript programming, he is a master of JavaScript. However, if you review the code for the three classes and then look at the output, you’ll notice that there is subtle issue.

… (I)t should be clear that the results of the above example are incorrect. Additionally, a downside of Crockford’s approach and of many other approaches, is that every super call requires an additional method call and additional processing of some kind. Whether this is an issue for your situation, will depend on how many super calls you have in your code. ThinWire makes extensive use of super calling in it’s client-side code and therefore it’s important that super calls are as fast as possible.

Josh eventually developed an alternative solution that is somewhat Aspect-Oriented:

Essentially, ‘extend’ wraps every method in your class definition with an intermediate function that swaps the super class reference ‘$’ to the correct reference with every method call. The only real issue with this approach is that it requires a number of intermediate functions, which may have an impact on performance.

A further refinement exploits the little-known callee property.

(T)he ‘arguments’ array contains a reference in the property ‘callee’, which points to the current function that is being executed. This is important, because it’s the only way that you can get such a reference since the function reference available via the ‘this’ object, always refers to the overridden function that is defined in the class at the top of the hierarchy.

See Josh’s article for all the code and analysis on Javascript inheritance techniques.

(Thanks to Ted Howard for the link.)

Posted by Michael Mahemoff at 6:05 pm

4.2 rating from 29 votes