"Extreme JavaScript Performance" (from JSConf.eu, November 7)

Take a look at the slides from Extreme JavaScript Performance, a presentation by Thomas Fuchs, creator of the script.aculo.us JavaScript library, collaborator on the book Agile Web Development with Rails and one of the people behind FailCamp. He gave the presentation last week at JSConf.eu in Berlin.

In the presentation, Thomas looked at six simple things you can do to boost the performance of your JavaScript:

• Use inline functions instead of function calls.
• Embrace the language – using the language’s conventions yields unexpectedly faster code. Instantiate arrays using var myArray = [] instead of var a = new Array, and instantiate objects using var myObject = {} instead of var o = new Object.
• Unroll your loops! (A trick so old that we covered it when I was in school!)
• Cache globals. If you’re going to access a global object, store a local reference and use that instead.
• Tune your boolean expressions: in logical “AND” (&&) operations, make the operand most likely to be false the first one.
• Watch out for slow constructs such as with blocks, try/catch and features that JIT compilers don’t support well.

The presentation includes benchmarks for the four most common JavaScript engines:

• SpiderMonkey (Firefox 3.5)
• JavaScript Core (Safari 4)
• JScript (Internet Explorer 8)
• V8 (Google Chrome)

And yes, he does warn you – at least twice – of the dangers of premature optimization.

JavaScript Performance Rocks

If you liked Extreme JavaScript Performance, you’ll love the ebook Thomas co-authored with Amy Hoy, JavaScript Performance Rocks! Actually, it’s more than just a book – it’s four books and a profiling tool:

• Book 1: Understanding and Measuring Performance (or: “Dude, Where’s My Performance?”) – “In which our brave hero or heroine (that’s you!) apprentices to the cryptic-but-charming Master (that’s us) and learns how to get into the enemy’s head—the better to eat it alive, my dear.”
• Book 2: Loadtime (or: “The Land of Unicorn Tears”) – “Loadtime is a sad time, a time of of enormous, slow-loading assets; of maxed-out request queues; of bloated, waddling DOMs. Of limp white screens. Most of the world’s worst web performance woes? They live and breed in Loadtime. That’s why it’s the Land of Unicorn Tears, because unicorns hate slow web apps just as much as the rest of us. And they have magical horns. So there.“
• Book 3: Runtime (or: “’Cuz Tuning Loops is Hardcore”) – “The vast majority of the problems that the vast majority of apps will have can be solved with loadtime fixes of various stripes. But just in case you’re unique, and special, and have particularly intractable issues—or are just a glutton for punishment—we have written a third booklet, all about speeding up code when it runs.”
• Book 4: Interface Coping Strategies (or: “If You Can’t Fix It, Fake It”) – “Come across a performance problem that you really can’t fix? Long-running calculations? Slow server you can’t tune up? If you can’t make it, fake it. You can make your app feel faster to your customers, even if you can’t fix the underlying problem. And, let’s face it, that’s what your customers care about.”
• The DOM Monster profiling tool.

JavaScript Performance Rocks! isn’t your ordinary ebook, with material laid out for a dead-tree book simply cast in PDF form. It was designed from the ground up for onscreen reading, written in an entertaining way to keep you amused and your mind ready to learn, and written in a fun, irreverent way so that you don’t zone out. I know Thomas and Amy personally and have seen them teach; trust me – you want to learn from them.

JavaScript Performance Rocks! usually sells for US$49, but there’s a special deal right now – the first 500 books are selling for 10 dollars less — US$39. You’ve got two good reason to buy immediately: first, there’s this $10 discount, and second, the US/Canada exchange rate’s pretty good right now (as I write this, the PayPal exchange rate is CAD$1 = US$0.92).

I’ve already ordered my copy.

This article also appears in Canadian Developer Connection.

While following the exercises in the book Teach Yourself ASP.NET Ajax in 24 Hours – one of the few books I’ve been able to find on Ajax for ASP.NET 3.5 – I found an error in the “Hour 9” chapter in the example that covers client-side error-handling (it starts on page 137). I’ve reported this error to the publisher and with any luck, they’ll post a corrected version on their support web page for the book.

I’ve done some searching and haven’t found anything covering this error so I thought I’d cover it here. Better still, I’ll also cover the fix, which turns out to be quite simple. If you’ve been trying out the code in the book and wondering why it doesn’t work, relax: at least in this case, it’s not your fault.

In the course of covering the error and how to fix it, I’ll also talk about how ASP.NET handles exceptions raised by asynchronous postbacks and how you can make use of it to make better user interfaces. Even if you don’t have a copy of Teach Yourself ASP.NET Ajax in 24 Hours, you should find this article an interesting introduction to client-side error handling in ASP.NET Ajax.

Unhandled Exceptions and Asynchronous Postbacks

In ASP.NET Ajax, if an exception is raised during an asynchronous postback and isn’t handled on the server side – that is, in the code-behind – it gets passed along to the client side. What happens on the client side depends on which version of ASP.NET you’re using:

• In ASP.NET Ajax 1.0, the server-side exception object is serialized into JSON. The JSON is sent to the client, which displays the exception’s message property in an alert box.
• In ASP.NET Ajax for .NET 3.5, the server-side exception is still serialized into JSON and the JSON is still sent to the client. However, instead of displaying the exception’s message property in an alert box – a presumptuous design decision, if you want my opinion – the client throws the exception, which gives you the opportunity to handle it on the client side as you please.

(In this article, I’ll stick to covering ASP.NET Ajax for .NET 3.5.)

This is quite different from most other web application frameworks, where an exception raised as the result of an XMLHttpRequest call to the server results in some kind of “error” page from the server (or a blank page, if you’re suppressing error reporting).

To illustrate this, let’s put together a simple ASP.NET Ajax application. It’s a single page with a single button, that if clicked, throws an exception.

Here’s the code for the page layout. It’s pretty straightforward:

Listing 1: Default.aspx – Layout for the page of our simple ASP.NET Ajax application.

<%@ Page Language="C#" AutoEventWireup="true"
CodeBehind="Default.aspx.cs" Inherits="WebApplication1._Default" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
    <title>Error Handling Demo 1</title>
</head>

<body>
    <form id="form1" runat="server">

        <div>
            <asp:ScriptManager ID="ScriptManager1" runat="server" />
            <asp:UpdatePanel runat="server" ID="UpdatePanel1">
                <ContentTemplate>
                    <asp:Button runat="server" ID="Button1"
                    Text="Click Me" OnClick="Button1_OnClick" />
                </ContentTemplate>
            </asp:UpdatePanel>
        </div>

    </form>
</body>

</html>

Some notes about the code:

• The ScriptManager control at the top of the form enables Ajax by ensuring that the JavaScript needed to support ASP.NET Ajax on the client side is downloaded to the browser.
• The UpdatePanel control determines the controls that trigger asynchronous postbacks and defines the region of the page that can be updated via Ajax.
• Button1 is the button control that we want to throw an exception when clicked. We’ll set it to call the Button1_OnClick method, which will contain the exception-throwing code.

The code-behind is very simple. In it, we define a single method: the event handler Button1_OnClick, which is called in response when the user clicks Button1. All we want it to do is throw an exception that uniquely identifies itself:

Listing 2: Default.aspx.cs – Code-behind for the page of our very simple example app.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace WebApplication1
{
    public partial class _Default : System.Web.UI.Page
    {
        protected void Button1_OnClick(object sender, EventArgs e)
        {
            throw new Exception("Click!");
        }
    }
}

Running with Debugging vs. Running Without Debugging

Listing 1 and 2 give us enough to make our simple app work. It’s time to take it for a spin.

Here’s something that doesn’t get covered in Teach Yourself ASP.NET Ajax in 24 Hours: what happens when you try to run this app with debugging (starting it by hitting F5 in Visual Studio or “Start Debugging” under the “Debug” menu)?

Here’s a screenshot of what happened for me:

With debugging on, the unhandled exception thrown in Button1_OnClick is caught by the debugger. Normally, this sort of error-catching behaviour is welcome, but in this particular case, it gets in the way of what we’re trying to achieve: having an exception on the server side and passing it along to the user’s browser to handle.

If we run the same app without debugging, we get the effect we want: the exception is raised on the server side, but the server-side part of the application doesn’t halt with an error message. Instead, the client shows the error message.

Here’s a screenshot. Note that the error message includes the string “Click!”, which is the argument in the throw statement the Button1_OnClick event handler. Thanks to this, we can be pretty certain that the error message is the result of our deliberately-thrown exception:

Now that we have the exception that we threw on the server side being handled on the client side, let’s do something with it. 

Handling Exceptions Passed from the Server on the Client Side

Let’s do something simple – let’s catch the exception caused by the button click, and instead of having a JavaScript error box pop up, let’s make a couple of changes to the button:

• Change its text to “This button has been disabled for your safety.”
• Disable it.

To handle exceptions on the client side, we need to write some client-side JavaScript. Luckily, this is made simple by the number of handy utility classes defined in the scripts downloaded to the client by the ScriptManager component. In this case, we’re going to make use of the Sys.Webforms.PageRequestManager class to deal with the exception because it provides us with the following:

• The endRequest event, which is raised after an asynchronous postback has completed and control is returned to the browser.
• The add_endRequest method, which specifies a method to call when the endRequest event is raised.

Here’s the JavaScript, which we’ll put in a file called ErrorHandler.js:

Listing 3: ErrorHandler.js — Client-side error handler for our very simple example app.

Sys.WebForms.PageRequestManager.getInstance().add_endRequest(EndRequestHandler);

function EndRequestHandler(sender, args)
{
    if (args.get_error() != undefined) {
        $get('Button1').value = "This button has been disabled for your safety.";
        $get('Button1').disabled = true;
        args.set_errorHandled(true);
    }
}

The script performs the following:

• It registers the method EndRequestHandler as the method to call whenever the endRequest event is raised.
• It defined the method EndRequestHandler, which does the following:
  • If an exception did occur during the asynchronous callback:"
    • The button’s text is changed
    • The button is disabled
    • The error is reported as handled, which allows the application to continue

Now that we have this client-side code, we need to get it to the client. We do this by using the Scripts section of the ScriptManager to send this file to the client. The listing below shows the updated layout code for our simple application. I’ve highlighted the change in the listing below:

Listing 4: Revised Default.aspx – Layout for the page of our simple ASP.NET Ajax application.

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="WebApplication1._Default" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
    <title>Error Handling Demo 1</title>
</head>

<body>
    <form id="form1" runat="server">

        <div>
            <asp:ScriptManager ID="ScriptManager1" runat="server">
                <Scripts>
                    <asp:ScriptReference Path="~/ErrorHandler.js" />
                </Scripts>
            </asp:ScriptManager>
            <asp:UpdatePanel runat="server" ID="UpdatePanel1">
                <ContentTemplate>
                    <asp:Button runat="server" ID="Button1"
                    Text="Click Me" OnClick="Button1_OnClick" />
                </ContentTemplate>
            </asp:UpdatePanel>
        </div>

    </form>
</body>

</html>

The Scripts section of the ScriptManager lets us specify scripts to be sent to the client along with the page, with each script specified in a ScriptReference tag.

When we run the app (remember, without debugging on) with these changes and click the button, here’s what we get:

In a later article, I’ll look at other ways of using client-side error handling in ASP.NET Ajax in .NET 3.5.

The Error in Teach Yourself ASP.NET Ajax in 24 Hours

Here’s the page layout code for the error-handling example in Teach Yourself ASP.NET Ajax in 24 Hours. The code-behind for the page and the client-side JavaScript are fine, it’s this code that has the error. See if you can spot what’s amiss:

Listing 5: Default.aspx — Page layout of client-side error-handling example in Hour 9 of Teach Yourself ASP.NET Ajax in 24 Hours.

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="WebApplication1._Default" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
    <title></title>
</head>

<body>
    <form id="form1" runat="server">

        <div>
            <asp:ScriptManager ID="ScriptManager1" runat="server" />
            <asp:UpdatePanel runat="server" ID="UpdatePanel1">
                <ContentTemplate>
                    <asp:Button runat="server" ID="Button1"
                    Text="Click Me" OnClick="Button1_OnClick" />
                </ContentTemplate>
            </asp:UpdatePanel>
        </div>

        <br /><br />

        <div id="Message" style="visibility: hidden;">
            <asp:HyperLink ID="HyperLink1" runat="server"
                           Font-Bold="true"
                           Text="Error Occurred..."
                           Font-Italic="true"
                           ForeColor="red" >
            </asp:HyperLink>
        </div>

    </form>
</body>

</html>

Just for kicks, here’s what happens when you click on the button in the app using the code straight from Teach Yourself ASP.NET Ajax in 24 Hours:

The mistake is simple: although there is some error-handling client-side JavaScript in the app, it’s not referenced in the ScriptManager tag, which means it’s not sent to the client. Without error-handling code on the client side, the exception is thrown, there’s nothing to catch it and the user is presented with the standard error dialog box.

The fix is equally simple: reference the script in the ScriptManager tag’s Scripts section:

<asp:ScriptManager ID="ScriptManager1" runat="server">
    <Scripts>
        <asp:ScriptReference Path="~/ErrorHandlingScript.js" />
    </Scripts>
</asp:ScriptManager>

Once that’s done, the program works as promised.

The major map APIs provide a “zoom” feature that lets you zoom the map in or out if you position the cursor over the map and use your mouse’s scroll wheel. Sometimes you want this function enabled, sometimes you don’t. David Janes, over at his Code Blog provides the JavaScript code for:

• Enabling and disabling the mouse wheel zoom for Google Maps and Microsoft Virtual Earth
• Disabling the mouse wheel zoom for Yahoo! Maps (it’s enabled by default, but there doesn’t seem to be a way to re-enable it once disabled.)

Links

• David Janes’ Code Blog: How to enable/disable Mouse Wheel actions on your map

Tim “Ongoing” Bray’s Take

Tim Bray posted a blog entry on what drives adoption of a language in which he included some tables such as the only below:

	Flawed Founders	Polished Successors
Procedural	FORTRAN, COBOL, PL/1	C
Object-Oriented	C++	Java
Higher-Level	Perl, TCL	Python, Ruby

This table of his should inspire a monkey knife fight on a number of blogs:

	Flawed Founders	Polished Successors
Web-Centric	WebObjects, ColdFusion, ASP.Net, Struts, etc., etc., etc., PHP	Rails

Here’s an interesting one. What will JavaScript’s successor be? My guess for the short-term (by that, I mean “the next half-dozen or so years”) is “the next version of JavaScript”.

	Flawed Founders	Polished Successors
Mobile-Code	JavaScript	?

The one about concurrent programming is a little more up in the air. Although there are other languages designed with concurrent programming in mind (either from the ground up or with concurrency retrofitted onto an existing language) and there have been for a while (I used Concurrent C in a course back at Crazy Go Nuts University in the early ’90s), Erlang is getting a lot of the attention these days since it has both a success story at Ericsson under its belt as well the clout of a Pragmatic Programmers book behind it. There is a feeling among some programmers (Bray included) that it isn’t going to be the language to turn concurrent programming from arcane art into mainstream practice:

	Flawed Founders	Polished Successors
Concurrent	Erlang	?

Shelley “BurningBird” Powers’ Take

Shelley Powers disagreed with Tim’s assessments in her posts Flaws are in the Eye of the Beholder:

I find it fascinating when a person marks as ‘flawed’ the languages that have, literally, defined not only the web but application development of all forms. Perhaps the metric shouldn’t be on syntax, form, or function, but on usability.

Here’s her own table on languages:

	'Perfect', but barely used	'Flawed', but simple, approachable, powerful, popular
Higher-Level	*Ruby (every time I see 'Ruby' I mentally add, Mama's precious little…) *I’m giving Python a slide because Python has fairly widespread use today.	Perl
Client side code	(The to-be-created scripting language that will take a nice, clean, easy to use language and morph it until it satisfies the purists, while breaking faith with the millions of users just trying to do a job)	JavaScript
Object Oriented	Java (bloated beyond recognition with senseless additions and overly complex infrastructures)	C++ (which can kick Java's ass performance and resource wise)
Web-Centric	Rails (you know that thing they used for the one application?)	Cold Fusion, ASP and ASP.NET, PHP

Those of you who recall Bjarne “C++” Stroustrup’s line “There are just two kinds of languages: the ones everybody complains about and the ones nobody uses” or the essay Worse is Better (or the essay that led to it or Jamie Zawinski’s commentary on it) should be feeling deja vu now.

As for Shelley’s table, I’d probably have put “PHP” where “Perl” is right now.

My Own Take

I think that right now, the “scripting languages” are stuck in something akin to “Three Stooges Syndrome”. That’s the disease where Mr. Burns from The Simpsons, being so old and frail, has so many diseases trying to get at him at the same time that they’re all “stuck in the door”. The doctors illustrated the syndrome with a model, shown below:

And since Tim and Shelley have their tables, I thought I’d make one too:

Possibly inspired by articles like Tim O’Reilly’s State of the Computer Book Market (here are parts one, two, three and four of the Q1 2007 edition of this series) posts on the O’Reilly Radar blog, Antonio Cangiano decided to do a little research of his own:

Technical books are a topic that interest me a lot. From book sale figures and trends we can attempt to better understand where developers are putting their money, not only their mouths. For this article I decided to perform a small experiment, by collecting some interesting data. I considered 23 fairly well known programming languages, and searched for the top selling book (according to Amazon) for each of them. The Amazon sales rank allows us to compare the success of books representative of each language, and indirectly compare the popularity of the languages themselves.

The Top Ranking Languages

According to Antonio’s research, here are the best-selling programming language books are for these languages, listed starting with the best seller:

1. JavaScript (JavaScript: The Definitive Guide, Amazon rank 1,227)
2. Java (Head First Java, Amazon rank 1,799)
3. Ruby (Programming Ruby: The Pragmatic Programmers’ Guide, Amazon rank 1,881)
4. SQL (Sams Teach Yourself SQL in 10 Minutes, Amazon rank 1,929)

To see the top 23 programming languages based on Amazon ranking, go visit Antonio’s blog entry.

A commenter on the article wrote:

Actionscript would rank even higher than JavaScript, since the book Essential ActionScript 3.0 by Colin Moock currently is at sales rank #346.

Interesting Languages

There are some interesting languages on this list. Although they get mentioned on Reddit and a number of developer blogs, they’re not quite mainstream yet. In spite of that, they’ve placed quite well based on Amazon’s ranking system:

• Erlang (Programming Erlang: Software for a Concurrent World, #12 on the list, Amazon rank 8,609)
• F# (Foundations of F#, #15 on the list, Amazon rank 21,273)
• Lua (Programming in Lua, #16 on the list, Amazon rank 23,052)
• Haskell (The Haskell Road to Logic, Maths and Programming, #18 on the list, Amazon rank 1,929)

[Cross-posted to the Tucows Developer Blog]