Javascript author extraordinaire David Flanagan released Canto.js recently, a lightweight wrapper API for canvas, introduced here and documented at the top of the source code. Example:

PLAIN TEXT JAVASCRIPT: canto("canvas_id").moveTo(100,100).lineTo(200,200,100,200).closePath().stroke();
 

Notice three things:

• canto() returns an abstraction of the canvas - a "Canto" object.
• As with jQuery and similar libraries, there's method chaining; each method called on a Canto also returns the Canto.
• lineTo() has been extended to support multiple lines being drawn in a single call.

Instead of setting the ink properties and then painting it, you can do it all in one step:

PLAIN TEXT JAVASCRIPT: canto("canvas_id").moveTo(100,100).lineTo(200,200,100,200).closePath().stroke({lineWidth: 15, strokeStyle: "red"});
 

And plenty more syntactic sugar - check out the API in the source code comments. Sweet!

Thanks @pkeane.

Over at the the YUI blog the team just announced the preview release of YUI 3.2.0. YUI3 now has some interesting new features that the team wants you to try and tell them if they work out for you. The changes to the already very powerful library are quite ambitious:

• Touch event support for mobile interfaces including flick and move gestures
• Browser capability loading - which means that every browser gets the least amount of code necessary to make it work
• Transition support for the animation module - meaning only browsers that don't support CSS3 transitions get the JavaScript animation fallback
• An update to the CSS grids to allow for more flexible layouts
• A ScrollView widget similar to the one in Apple iOS
• The uploader has been transitioned over from YUI2 to YUI3

So check out what is on offer and give the YUI team feedback on what would be nice to have and what is broken. In their own words:

The goal of a preview release is to make it as easy as possible for all of us in the community to evaluate progress of the upcoming release and provide feedback. Please take some time to test 3.2.0pr1 and let us know what you find by filing tickets in the YUI 3 bug database marked as “Observed in version” 3.2.0pr1. We’ll do our best to address preview-release questions on the YUI 3 Forums, too.

There are three ways to get started with the preview release: YUI 3.2.0pr1 is available on the CDN via the 3.2.0pr1 version tag — so you can reference preview-release files like http://yui.yahooapis.com/combo?3.2.0pr1/build/yui/yui-min.js. If you switch to this seed file for the preview release, all subsequent use() statements will continue to load YUI 3.2.0pr1. Or You can download the full YUI 3.2.0pr1 from YUILibrary.com, including source code and examples for all components. Or you can simply explore the functioning examples roster.

Interest in Canvas, as well as mobile apps, has led to a renaissance of old-school 8-bit graphics. Joe Huckaby of Effect Games has been playing around with color cycling, leading to some stunning effects.

Anyone remember Color cycling from the 90s? This was a technology often used in 8-bit video games of the era, to achieve interesting visual effects by cycling (shifting) the color palette. Back then video cards could only render 256 colors at a time, so a palette of selected colors was used. But the programmer could change this palette at will, and all the onscreen colors would instantly change to match. It was fast, and took virtually no memory.

There's a neat optimization going on here too: instead of clearing and redrawing the entire scene with each frame, he only updates the pixels that change:

In order to achieve fast frame rates in the browser, I had to get a little crazy in the engine implementation. Rendering a 640x480 indexed image on a 32-bit RGB canvas means walking through and drawing 307,200 pixels per frame, in JavaScript. That's a very big array to traverse, and some browsers just couldn't keep up. To overcome this, I pre-process the images when they are first loaded, and grab the pixels that reference colors which are animated (i.e. are part of cycling sets in the palette). Those pixel X/Y offsets are stored in a separate, smaller array, and thus only the pixels that change are refreshed onscreen. This optimization trick works so well, that the thing actually runs at a pretty decent speed on my iPhone 3GS and iPad!

JavaScript as a general-purpose "Turing-complete language" is illustrated - the example discussed in the first part of a series:  How a CPU can be emulated through JS, and how one might start building an emulation core for the GameBoy console. Looking forward:  How a game image can be loaded into the emulator over the Web. For now: Hello, Z80! Check out Ice Station ImRannazar!

The Dojo project continues to pump out goodness announcing version 1.5 of the Dojo Toolkit with a number of new and exciting features.

Dylan Schiemann had this to say about the release:

The JavaScript world is evolving at an intense pace. We're very pleased with this release of Dojo, which offers the stability needed for existing apps and browsers, while introducing some of the capabilities of building great apps of the future.

Some of the biggest updates came to the Dijit UI library with the addition of the new Claro theme which helps provide a nice desktop look-and-feel to web applications as well as improvements to the charting and drawing components of the library.

And Dojo team lead Pete Higgins added:

If you haven't seen the new theme Claro, you should. Julie Santilli and her awesome design team at IBM put some incredible design and style on top of an already stable and accessible UI library

The theme is incredibly clean. Check out some of the controls styled using Claro:

Other important updates include:

• Strong support for HTML5 & CSS3 features such as local storage, transforms and Canvas with fallback
• Implementation of dojo.Stateful
• Update to dojo.Deferred to leverage a new underlying Promises-based API

In addition, new initiatives are underway to provide solutions for the ever-growing and important mobile space:

• dojox.mobile: lightweight mobile web widgets
• dojox.mobile.app: mobile application development framework
• embedjs: Dojo API, optimized for mobile
• TouchScroll: scrolling layer for WebKit Mobile
• wink: mobile web app toolkit

This release continues the project's philosophy of modularity allowing developers to leverage the library for anything from simple DOM manipulation to full-blown RIA development. Dojo 1.5 is immediately available for download and sports impressive, updated documentation to get you started quickly.

Everyone's chomping at the bit to leverage new HTML5 and CSS3 features but with some older browsers not supporting them, hacks are still needed to make things work in a cross-browser fashion. We've seen libs that make things easier such as Remy Sharp's html5shiv and Modernizr and now we can add another one.

Jason Johnston's new PIE library makes it easy to rendering several of the most useful CSS3 decoration features within Internet Explorer versions 6 through 8. He took an interesting approach by using IE DHTML Behaviors to style the elements and provide the necessary functionality to emulate the CSS3 functionality. So to add rounded corners to an element, your CSS code might look like this in plain 'ole CSS:

PLAIN TEXT CSS: #myElement {
    background: #EEE;
    padding: 2em;
    -moz-border-radius: 1em;
    -webkit-border-radius: 1em;
    border-radius: 1em;
}
 

To add support in IE 6-8 using PIE, you'd add this:

PLAIN TEXT CSS: #myElement {
    ...
    behavior: url(PIE.htc);
}
 

PIE currently has full or partial support for:

• border-radius
• box-shadow
• border-image
• multiple background images
• linear-gradient background images

Unfortunately, there seems to only be one demo at the moment, which is border-radius rendering via the home page, but it's still seems like a good start with a lot of future potential.

I've never personally used IE DHTML Behaviors or HTML Components so I looked them up and found these intro links for those who might be interested in better understanding them:

Using HTML Components to Implement DHTML Behaviors in Script
Introduction to DHTML Behaviors

The week has been long. Much code has been written. There is much more to do, but Friday is for relaxing a little. Take some time, sit back and watch, as three fantastic videos are available for you:

French: Paul Rouget of Mozilla, shows you the future

Paul builds the best demos. ever. At the Mozilla Summit in Whistler, he shows off what you can do when you remix HTML5, CSS3, SVG, WebGL, and WebSockets. A must see.

German: Building an awesome social HTML5 engine

Paul Bakaus of Dextrose (and jQuery UI fame) recently launched the Aves Engine, a social gaming engine in pure HTML! Dextrose also joined forces with Effect Games to bolster its Web gaming might. Paul gave a talk at Google explaining the technology, and it just went live:

"Irish": Paul shows you jQuery c0de

Ok, Irish by name, and maybe a touch by nature.... but not by nationality. Paul Irish has been doing an amazing talk at conferences where he walks through the jQuery source code to teach you fun and frolics of JavaScript. He picked up ScreenFlow and did it again to reach you all. Paul is a gem in our community, and at 52 minutes.... you will still want more:

Have a great weekend!

Waltham, MA, July 14, 2010 – Telerik, a leading vendor of development tools and user interface components for .NET, today unveiled its Q2 2010 product release, featuring a number of essential new additions to its WebUI Test Studio in the field ...

The team at Jupiter IT have release Syn, a library which allows you to create synthetic events for use in testing. This standalone library is meant to assist in testing complex UI behavior by simulating user actions such as typing, clicking, dragging the mouse.

Testing rich, dynamic web applications sucks. At Jupiter, we've tried almost every testing solution available (qUnit, Quick Test Pro, Selenium, JsUnit, Env.js, TestCase) and all of them suffer from some fatal flaw.

Problems:

• Manual - A tester has to run the tests manually on every supported browser.  People are lazy. 
• Unit Tests Only - We need to test the app as a whole and complex UI behavior like drag-drop.
• Low fidelity - We need to make sure the tests are reporting accurate results.
• Difficult to write - We sling JS like a ninja monkey throws poo.  We want to write tests in a nice JS API.
• Expensive - A QTP license is 5k a person!  I'd rather buy a vacation.
• Support - We want to test Mac and Linux browsers.

We've solved all of these problems in our upcoming FuncUnit testing framework. It's a mashup of qUnit, Selenium, Rhino, and Env.js. But its core library, Syn, which does the work of simulating user actions with very high fidelity, is what we are releasing today.

So by using code like this:

PLAIN TEXT JAVASCRIPT: Syn.click( {},'hello' )
   .type( 'Hello World' )
   .drag( $('#trash') );
 

you can simulate clicking an element with id='hello', typing "Hello World", and then dragging your mouse from that element to an element with id='trash'.

Pretty cool stuff. Check out their demo to see how playback occurs.

Scripting Layer for Android (SL4A, formerly known as Android Scripting Environment or ASE) brings scripting languages to Android by allowing you to edit and execute scripts and interactive interpreters directly on the Android device. These scripts ha ...

In this JSF 2 fu installment, you'll find out how to combine JSF 2 with Contexts and Dependency Injection (CDI) to implement an Ajaxified wizard. You'll see JSF's templating and Ajax in action, and you'll learn how to use CDI's dependency injection a ...

For a while, there has been a struggle for the future of markup on the web, a struggle between the W3C's XHTML 2 and HTML5, developed by the major browser vendors under a separate organizational umbrella. First, the W3C took over HTML5, and now it re ...

Developing a rich application for manipulating large amounts of data used to be the exclusive domain of desktop applications. Now it can be done in a web application, and you don't have to be a JavaScript guru to do it. Learn how to use the Dojo tool ...

I can't believe none of us knew DOM2

This is how a tweet from @SubtleGradient, re-tweeted by @jdalton, has been able to steal my rest tonight ... and this post is the consequence ...

What's new in a nutshell

There is a W3C Recommendation about addEventListener behavior, which clearly specify the second argument as an EventListener.
The new part is that no library I know has ever used a proper EventListener interface, preferring the classic attached callback instead.

PLAIN TEXT JAVASCRIPT:

// this is how it is
document.addEventListener(
    "click",
    function (evt) { /* stuff */ },
    false
);
 
// this is how it could be as well
var listener = {
    handleEvent: function (evt) {

        this === listener; // true

        // and evt === classic event object

    }
};
 
document.addEventListener("click", listener, false); Benefits

The most common case that may disappear is well explained in this MDC addEventListener page.
Rather than bind inline or add anonymous functions to make our object call context preserved, we can simply add an handleEvent method to whatever object and pass it as EventListener.
Moreover, being close to full ES5 support and "use strict" directive where arguments.callee disappears, it may be more than handy to be able to perform such operation:

PLAIN TEXT JAVASCRIPT: document.addEventListener("click", {
    handleEvent: function (evt) {
        // 1 shot callback event example
        switch (evt.target.nodeType) {
            case 1:
            case 9:
                evt.target.removeEventListener(
                    evt.type,
                    this, // here we are!
                    false
                );
                break;
        }
    }
}, false);
  An opened door for custom listeners

As I have recently posted, custom listeners implementation can be truly handy when we are dealing with events driven applications, but as soon as I have read the tweet, I had to rewrite a fresh new way to create a listener. Please note that following code is assuming that the browser supports both DOM Level 2 and Array extras, which is true for all modern browsers, mobile oriented included.

PLAIN TEXT JAVASCRIPT: function createEventListener() {

    /*! Andrea Giammarchi for Ajaxian - Mit Style */

    // a function declaration reused internally
    function notifyEvent(callback, i, stack) {
        // use DOM Level 0 events strategy
        //  to stop the loop if necessary
        // checking if the result is exactly false
        if (callback.call(
            // the curent object as context
            this,
            // the classic event as first argument
            event,
            // the called callback (life easier)
            callback,
            // again the current context
            // if the callback has been bound
            this
        ) === false) {
            // if false, reassign the current stack ...
            eventListener["@"+event.type] = stack.slice();
            // ... and break the current forEach loop
            // (or, for the record, whatever Array.extras)
            stack.length = 0;
        }
    }

    var
        // local scoped object, reachable internally
        // usable as mixin so instances won't be polluted
        // with all possible event types
        // the type is prefixed in any case
        // so that name clashes should be
        // really rare however we use the object
        eventListener = {

            // we attach to a proper stack
            addEvent: function (type, callback) {
                var
                    // try to retrieve the stack ...
                    stack = (
                        // if already there ...
                        eventListener["@" + type] ||
                        // otherwise we create it once
                        (eventListener["@" + type] = [])
                    ),
                    // as addEventListener, don't attach
                    // the same event twice
                    i = stack.indexOf(callback)
                ;
                // so if it was not there ...
                if (-1 === i) {
                    // FIFO order via stack
                    stack.push(callback);
                }
            },

            // called via addEventListener
            // the "this" reference will be
            // the eventListener object,
            // or the current instance
            // if used as "class" mixin
            // or via Object.create / clone / merge
            handleEvent: function (e) {
                // retrieve the stack
                var stack = eventListener["@" + e.type];
                // and if present ...
                if (stack) {
                    // set temporarily the local event var
                    event = e;
                    // notify all registered callbacks
                    // using current this reference
                    // as forEach context
                    stack.forEach(notifyEvent, this);
                    // let the GC handle the memory later
                    event = null;
                }
            },

            // how we remove the event, if any ...
            removeEvent: function (type, callback) {
                var
                    // try to retrieve the stack ...
                    stack = eventListener["@" + type],
                    // find the index ...
                    i
                ;
                // if the stack is present
                if (stack && ~(
                    i = stack.indexOf(callback)
                )) {
                    // remove it
                    stack.splice(i, 1);
                }
            }
        },

        // I could have called this variable tmp
        // but it's actually the current event
        // once assigned ... so ...
        event
    ;

    // ready to go!
    return eventListener;

}

Here a usage example:

PLAIN TEXT JAVASCRIPT: var lst = createEventListener();

/** mixin example (add a slash before this line to test)

function MyEventListener() {}
MyEventListener.prototype.addEvent = lst.addEvent;
MyEventListener.prototype.handleEvent = lst.handleEvent;
MyEventListener.prototype.removeEvent = lst.removeEvent;

lst = new MyEventListener;

// */

document.addEventListener("click", lst, false);

lst.addEvent("click", function click(e, callback, object){

    alert([
        callback === click, // true
        this === lst,       // true
        this === object,    // true
        e.type === "click"  // true
    ]);

    // test that furthermore this
    // callback won't be fired again
    this.removeEvent("click", callback);

    // add delayed a callback
    // without any valid reason :-)
    setTimeout(function (self) {
        // test addEvent again
        self.addEvent("click", function () {
            alert(2);
        });
    }, 0, this);

    // block the current notification
    return false;
});

// the event fired only the second click
lst.addEvent("click", function () {
    alert(1);
});

/** de-comment the mixin example to test
//   that no @click is attached ;-)
for (var key in lst) {
    alert(key);
}
// */
  Advantages

• both evt.stopPropagation() and evt.preventDefault() are not able to break the current notification of all attached listeners, if added to the same node, and while the FIFO order gives to the node "owner" or creator the ability to pollute the event object with some flag such evt.pleaseDontDoAnyOtherActionHere = true, not every library, script, or framework, may respect or understand this flag. With custom events we can adopt better strategies to actually avoid any other operation if this is what we meant, because we arrived before over the node and we may like to be that privileged
• being custom, we can also decide which argument should be passed for each callback, simplifying most common problems we may have when dealing with listeners
• we can better decouple DOM and listeners, being able to remove whatever amount of callbacks simply calling once node.removeEventListener(evt.type, this, false); inside any kind of notification
• being based on standard and modern browsers, we can use native power, in this case provided by forEach and indexOf operations, so that performances will be best possible
• thanks to automatic context injection, we can still reuse callbacks for different listeners, through bind, or simply considering the current context once called (or in this case the third argument by reference, if the context is different)

Last but not least, if we would like to fire an event we can bypass DOM initialization using handleEvent directly, e.g.

PLAIN TEXT JAVASCRIPT: lst.handleEvent({
    target: document.querySelector("#myid"),
    type: "click",
 
    // custom properties
    pageX: 0,
    pageY: 0,
 
    // stubbed methods
    preventDefault: function () {},
    stopPropagation: function () {}
});
  Compatibility ?

Apparently both W3C behavior and provided examples are compatible with every modern browser with DOM Level 2 support, and I believe this is great.
The only one behind here is IE9 pre 3, but again @jdalton has acted at speed light, thanks!

It floors me what young, talented developers are building these days. Kit Goncharov, who only recently turned 17, just cranked out Quilt, a JavaScript preprocessor written in JavaScript.

Quilt is very similar to the Sprockets JS preprocessor in that it allows you to improve code organization by logically separating your code into multiple modules within their own specific directories. Instead of having one massive JavaScript file with all your source code in it (increasing the potential for errors and complications), you can break out your code into separate physical files and at build time, allow Quilt to roll it all up, line by line, into a single file, ready for deployment. Via support for directives, you can tell Quilt about dependencies to ensure your builds are structured the right way.

In addition, if you use third-party frameworks in your code, Quilt allows you to specify a "load path" or "search path" which tells the preprocessor where to look for your specific lib. Then, when you build the final concatenated output, the library is included right in the source code.

Although Quilt was heavily inspired by Sprockets, it does have several significant differences. Perhaps the most obvious is that it's written in pure JavaScript (as opposed to Ruby) and runs on Rhino. This means it's very portable and easy for JS developers to understand. Quilt also uses a slightly different syntax than Sprockets for including files (for instance, it allows single-quoted pathnames, and uses backticks instead of angle brackets for specifying third-party code), and can strip multi-line comments as well as single-line ones.

As our client-side applications continue to grow, these types of solutions are becoming increasingly important for having a well-structured and maintainable codebase and it's great to see that the future development leaders are taking that into consideration. Be sure to check out Quilt along with Kit's other projects on GitHub.

Charles Jolley: "I started working in SproutCore almost 5 years ago because I believe the future of software development lies in native-style apps in the web browser. It is the platform of the future and when that shift change happens, I want to be there with the technology. Now, I believe that time is almost finally upon us. It’s time to double down, and that is why I am leaving Apple."

Congrats to Charles as he starts a new adventure. At Apple, he lead the charge on the open source SproutCore framework which powers Mobile Me and a bunch more.

He recently showed off SproutCore Touch and with it a killer demo. Instead of just saying "the Web can do as good a job as 'native' apps for some purposes" he showed it. He and SproutCore folk were there with two iPads. One had the native iPad NPR app, and the other had a *week long* port to SproutCore Touch. The funny thing.... the touch version performed better and even had a nice hidden feature. If you are listening to NPR and go to another app, it kept playing! Who knew!

For anyone wondering what the new company means for SproutCore, Charles makes it clear:

First, SproutCore is now and will always be totally free and open source. I think this business of charging for a commercial license is not an effective way to grow a project. Sure you make a little cash, but at what expense to the community? My goal is to make SproutCore and all of the developer tools that surround it totally free to everyone. All I ask is that you participate in the community somehow to make things a little better for those who come after you.

Second, now that I am no longer held back by big-company legal restrictions, I am going to be much more involved with the platform. Very soon I will post some new example code. Some others are working on new documentation and build tools to ease that pain as well. Starting this fall, my new company will also start to offer online and in person training and mentoring courses to your team get up to speed quickly. We can also finally get started in that book.

My goal is that by the end of the year, any average developer can pick up SproutCore, build, and deploy a basic app without feeling lost. This is open source and I can’t usually guarantee timelines but at least now we can do what we need to make it happen.

With Strobe he wants to revolutionize "digital publishing". Put your thinking hats on to noodle on that one. One thing is for clear... it isn't just about making SproutCore Inc (as he discusses above).

Congrats Charles!

The Lebowski framework is a test automation framework for applications built on the SproutCore framework. Compared to unit testing frameworks that are perfect for testing individual objects and functions, Lebowski is an automated test framework desig ...

In the spring of 2005, the two of us gave our first Ajax talk together. The subject of the talk was DHTML, but Jesse James Garrett had just coined "Ajax" a few days previous, so we sprinkled the term throughout the slide deck. We needed a place to put some source code that accompanied the talk--an RSS reader was called "RSS Bling". Ajaxian.com was born.

Here's a random picture someone took of us right before we gave that first talk:

(Surely we're just reviewing the slides in this pic, not hurriedly hacking together something at the last minute.)

Because the Ajax space was moving so quickly, we wanted a place to track the fun hacks, great libraries, and fantastic showcases that were coming out daily, so we started using Ajaxian to post Ajax news and very occasionally, an editorial. It's fun to think back to those early times; the web world was drunk with new possibilities and no one was really quite sure how the draw the boundaries.

After a few months, things were moving so fast we thought it would be great to get the emerging Ajax community together. With help from Jay Zimmerman of No Fluff Just Stuff and Chris Haven, we put together the first Ajax Experience show in San Francisco. It was incredibly fun seeing so many of the folks in person we'd been covering on the site, and sharing with the broader developer community what was now possible.

Our little Ajaxian blog grew over time--we still remember with awe when someone compared the traffic Ajaxian sent them to Slashdot--and we've gone on to co-produce several more Ajax Experience shows. It's been a thrilling ride.

Now, years later, it's time for us to formally hang up our Ajaxian hats. We've always juggled the site with our full-time jobs (various start-ups, Google for Dion, Mozilla, Palm, and now HP), and posting daily while balancing families and work can wear on you after a while--we can't do it all anymore. TechTarget (the company that has owned Ajaxian.com for some time) will take on editorial ownership of the site. We will still carry on posting every so often--it's in our blood--but it won't be on a regular schedule.

This transition comes at an important time for us. Palm was an opportunity to show the world that an OS based on the Web can be fantastic, but now, with HP's resources behind Palm, there's an even bigger opportunity ahead that will require all of our focus and energy. Oh, and it's summer, too. :-)

Thanks for being there for us over the years. We look forward to the next series of adventures. With HTML5 continuing to build steam and browser innovation hotter than ever, it is going to be a great time for us Web folk.

As always, you can keep up with us on Twitter: Ben and Dion.

All the best,

Ben and Dion

A whole lot of people seem to be moving from web page development to building RIA-s these days. But while the emergence of the new client side technologies is easy to notice, with names like Flex, Silverlight or JavaFX appearing more and more often i ...

Bridgewater, New Jersey, June 30, 2010 — RadView Software Ltd. (OTCBB: RDVWF), announced today the availability of WebLOAD Professional 8.5. This new release enables the creation of a complete load testing scenario with parameterization, correl ...