May 04, 2006

The Rumour Starts Here!

Salacious rumour suggests the next version of Javascript will have tail recursion. We can neither confirm nor deny this rumour, but we can rock an old style w00t!

Posted by Noel at 11:01 PM | Comments (0)

February 20, 2006

More on the next Javascript

Brendan Eich writes on Python and JavaScript. The first part discusses his plans to add generators and array comprehensions to Javascript. But that's not the real news! It comes later:

I'm happy to announce that we are now working with Dave Herman, a fourth year graduate student at Northeastern, of PLT and lambda-the-ultimate renown, whom I invited as an expert to help ECMA TG1 develop sound specifications for critical parts of ECMAScript Edition 4 (ES4), also known as JavaScript 2 (JS2).

Go Dave!

Posted by Noel at 09:52 AM | Comments (0)

January 27, 2006

Ajax: I Fold!

Ok, I fold. It's time to admit I agree with what Matt has been saying: Ajax is an immature technology. To save Matt some effort I'll list the things that most annoy me with the current state of the art:

Matt's already mentioned the (lack of) type system and poor debugging support, so I won't go into them.

Memory leakage is perhaps the biggest obstacle to creating long-lived Ajax applications. The reasons for memory leaks are discussed here and here. These leaks are a result of a flaw in the implementation of (to my knowledge, all) existing browsers. This puts us back into the bad old days of manual memory management. Either we be very careful in our programming, or our long lived application will eat memory till the browser crashes.

Browser incompatabilities and inconsistencies, admirably documented at Quirks Mode, are a major hassle. We have to worry about both browser and version — my code works in Firefox 1.0.4, but will it work in Internet Explorer 5.0 (probably not)?

With the benefit of experience Javascript could be improved in a number of ways. Javascript's crazy scoping rules are just bad; there's no way of getting around that. Javascript would really benefit from coroutines for writing all those animation loops (or heck, let's get full continuations). Javascript's syntax is unnecessarily hard to parse, mostly due to the semi-colon insertion rule .

Finally, current implementations of Javascript are slow and resource hungry, a major impediment to creating really featureful applications.

Ok, so where does this leave us? We still want to build great Internet applications, but the tools are a bit suck. There are three paths forward:

• Build libraries. Requires the least amount of time, but offers the least return.
• Build a better Javascript. This has already started. Just wait two years for the standardisation committee to finish, and then another five Internet Explorer to catch up.
• Use the existing language as the target, but build a better language that compiles into Javascript. Less effort than standardising Javascript, but more effort that writing libraries, this option has some attractive benefits.

So which path are we going to follow? Tune in next time!

Posted by Noel at 02:01 PM | Comments (0)

December 22, 2005

printf in AJAX? Sorry, that's not debugging.

This post is one in a continuing series where we internally debate the merits of the over-hyped promise of AJAX...

Debugging Ajax Requests in Prototype:

How do we debug our Ajax applications? The Rails Weenie has taken the Ajax Responder feature in Prototype...

I'd like to remind Noel that the distance of the Atlantic and business of the Christmas holidays are not going to keep me from pointing out that AJAX is an immature and dangerous platform to build a business on. Yes, I'm glad that GMail is there... and I suppose the Yahoo! Mail beta. However, these are fragile technologies to build upon.

How do we debug things written using the Prototype framework? printf. I mean, I'm glad that with AJAX and Rails I can whip something up quickly that "just works." However, it doesn't "just have test cases," or "just get internationalized", or "just stand up under load." They're rapid-prototyping tools, certainly nothing more. AJAX breaks usability standards, pushes data and computation to an unreliable substrate (the client's web browser), and as the post above provides some evidence for, there are no good debugging or tracing tools available for developers working in heterogeneous browser environments in Javascript.

So, Noel, riddle me this: why should developers be willing to take eight steps backwards and be shafted with printf as their primary debugging tool when working with AJAX?

Posted by jadudm at 08:06 PM | Comments (0)

November 04, 2005

Rich web clients

Matt likes to provide the dissenting Ajax voice here on untyping.

As overhead on Slashdot:

'Zimbra's chief executive, Satish Dhamaraj, says that when he started his company in December 2003, "I really thought that Ajax was just a bathroom cleaner." Now his San Mateo, Calif., business has amassed $16 million in funding from venture-capital firms including Accel Partners, Redpoint Ventures and Benchmark Capital, the firm that famously funded eBay Inc. Peter Fenton, an Accel partner, says Ajax "has the chance to change the face of how we look at Web applications" and could boost technology spending by corporations, because Ajax is also being used to develop software for big companies, not just for consumers.'"

Ajax is a dangerous and immature technology. It is, in fact, a hack---a kludge---to provide rich-client functionality in the browser.

While I'll acknowledge that Javascript was intended from day one for interacting with the DOM, building entire applications that are predicated on dynamic, untyped tree-transformations is suicide (at best) without significant software development experience and rigor. With that rigor, it's just dangerous.

What do I mean? Pretend that every HTML element has a shape. If that's the case, then a document with a series of paragraphs might look like:

In this picture, the octagon represents the body tag, and the circles represent the paragraphs. If emphasis tags look like a small square, then (zooming in) our picture might look like:

Unfortunately, to make Ajax work, you have to constantly reorganize this tree. The tree is everything: it is the UI, it is the content, and it is the data for the program you are writing. And, I can casually replace any one node with a new node of a different type, or I can insert whole, new subtrees.

Anywhere. Anytime. And, without any validation or safety. So, I can take my first picture, and insert an entire copy of it anywhere I like:

The only problem with this is that, if the octagon is a body tag, this is completely invalid HTML. But that's not the worst of it; the tree representing all of my interface, content, and data is a massive, and complex, piece of state. So, after part of my program modifies the tree, I have to forever remember that the state has changed. Keeping track of state is already a dangerous part of programming; it is the cause of crashes in unithreaded programs (memory leaks, for example), and a source of huge problems in multithreaded programs (via problems known as deadlock, livelock, race hazards, etc.). This is why Google Mail and other Ajax-y applications are a miracle of hackery: the fact that they run, without completely buggering up constantly, is a nothing short of a holy intervention on the part of some higher being.

Given that the compiler does nothing to check your typing, and that you have almost no run-time debugging support, Ajax (as currently exemplified by Javascript and XML over HTTP) is certainly only version 0.5 as tool or solution for web-based development goes. Or, perhaps it is just part of a space of tools, where some produce very portable/accessible applications, while others allow the developer to produce richer, more interesting applications (while sacrificing portability).

It may be that Ajax is just the most portable, and least rich/safe way to develop applications for end-users at the moment. Rich clients, like OpenLaszlo, represent a greater level of safety, as well as a much richer set of tools. Widgets, like Apple's Dashboard and Yahoo's Widgets (formerly Konfabulator, an excellent, cross-platform predecessor to Apple's Dashboard) provide some of the ease of development of the WWW with much of the richness of the desktop---yet there is a run-time engine that provides a modicum of protection and safety for the end-user. And, of course, desktop applications: they sacrifice portability, but give you the full power of the host machine.

I started this post with a quote about people investing millions in Ajaxy technology. People investing millions in Ajaxy startups scare me; they're sheep, following the herd. However, Ajax (as exemplified by Javascript and HTML) will mature, and we'll see tools and frameworks develop that will make application development "safer" and less hack-and-slash. Or, it will be abandoned, the <BLINK> tag of the new millennium.

Then again, PHP exists, and it's a large, steaming turd of a language that grabbed significant market share entirely too easily. So, what can you do?

Posted by jadudm at 11:46 AM | Comments (0)

September 15, 2005

The Birmingham Course: OpenLaszlo to the Rescue!

We needed to deliver a prototype on-line exam quickly. Despite their simple appearance, on-line exams can have some complex interaction modes that are annoying to deal with in a client/server model. OpenLaszlo provided an excellent framework for quickly going from idea to solution.

The Birmingham Course approached us with the idea of placing online a mock exam for their MRCPsych course. While the time constraints were tight, we thought there was an interesting opportunity in the project, and enjoyed the enthusiasm that The Birmingham Course brought to the table.

I would have liked to do some paper prototyping, and work through the issues that might arise before starting. However, we also wanted students currently enrolled in the course to trial an on-line version of the mock exam. This left us in a bit of a pickle: can you, in one-and-one-half weeks, go from concept to implementation for an on-line examination, and get it right? (I live far enough away from Birmingham that I didn't have the ability to take a day or two and go up there to meet with the client.)

The mock exam had no data gathering requirements, nor were there any concerns with authentication and identifying users. Therefore, some of the trickier aspects of web-based application development were not concerns. However, we still needed to deliver 133 True/False questions, and 30 multiple-choice questions in a stateful way, so students could easily "go back" and change their answers, as well as get their end-of-exam score.

While there may be AJAX gurus out there who think this would be a piece of cake, I do almost all of this development work in Scheme, and have no particular expertise in HTML/CSS/Javascript interaction on twelve different browser platforms (that's why I run with a team). I certainly don't have a lot of patience for developing code in an unstructured and unsupportive environment. Put another way, I think the browser makes a lousy run-time environment; I want my compiler to check for obvious problems up front, and I want my runtime environment to be rich enough that I can go about debugging a running application. Your typical AJAX app fails on these counts far too readily for me to think that any AJAX code I develop in a hurry will be reliable. (I'd like to point out that I've never even given AJAX enough of my time to decide if my biases and opinions are right; I've only read code and stories from others, and I don't like what I see.)

Enter OpenLaszlo. It has a compiler, that tells me when I make silly mistakes. It has a rich run-time environment, which includes an interactive debugging REPL. I can create a window as easily as saying

<canvas><window>Hi there!</window></canvas>

It uses JavaScript 1.5 as it's scripting language, and has a really sweet little constraint engine built in. The upcoming 3.1 release has some very swish enhancements on the way as well.

I was able to quickly prototype ideas for the customer, push them to the WWW, and let them interact with the application. While it is possible to do all kinds of RPC from OpenLaszlo, I chose to employ another really nice feature of the environment: SOLO application deployment. If you're willing to give up some (not all) connectivity with remote hosts, OpenLaszlo apps can be compiled to a single, static Flash file. This means that any user with Flash 6 or better can interact with a very rich net-based app, and get a very desktop-like experience.

The end-product of a one-week mad dash can be seen online; I was quite pleased with it. I know I made some choices that were less than optimal, but the code can be refactored and improved in a future iteration of the project. I was also happy working with OpenLaszlo as a development tool---putting together GUIs was no more complex than writing a webpage, the event model and constraint system are both well-behaved and useful, and being able to deliver a static Flash document as an application means I don't have to worry about a timeouts on client/server interactions, nor do I have to wonder if IE4/IE5/IE6/Opera/Firefox/Mozilla/Safari is going to choke on my particular choice of HTML, CSS, and Javascript idioms. If you're some kind of "purist" who abhors Flash, then... I can't help you. But it's widely deployed, and much better behaved than a gaggle of browsers.

Food for thought. Point is, I liked it. And the customer loved it; the app behaved just the way they wanted. I don't know what else I can say.

Posted by jadudm at 09:14 AM | Comments (0)

August 18, 2005

A little OpenLaszlo lovin'

No doubt I'll be playing with this technology more in the future, so I thought I'd introduce it now.

OpenLaszlo, released unto the world by Laszlo Systems, is an interesting combination of languages and ideas. It is an XML-based language for specifying the layout and behavior of rich internet applications. For example, I wrote a tabbed slideshow for photographs that you can find on my personal weblog, here....

No doubt I'll be playing with this technology more in the future, so I thought I'd introduce it now.

OpenLaszlo, released unto the world by Laszlo Systems, is an interesting combination of languages and ideas. It is an XML-based language for specifying the layout and behavior of rich internet applications. For example, I wrote a tabbed slideshow for photographs that you can find on my personal weblog, here. I think it would be difficult to write in JavaScript and CSS. Consider:

1. When you open a slide, audio begins playing.
2. When you switch slides, the current audio stops, and new audio is started.
3. I can layer objects (and remove them) over the photo content quickly and easily, when and where I want them.

I imagine this is all possible in JavaScript/DHTML, but... I don't know how. And, I don't feel I need to; the OpenLaszlo crew has provided a powerful platform for me to work from---a compiler, GUI toolkit, RPC mechanisms, and more. It seems to me that the whole JavaScript/CSS/AJAX thing is nothing more but a poor reinvention of the technology that OpenLaszlo provides. Granted, for full RPC-functionality, OpenLaszlo currently requires a servlet container, whereas AJAX-apps just need a browser with a JavaScript engine. However, you don't get much support from the compiler or run-time for debugging AJAX applications, whereas OpenLaszlo apps have a compiler and run-time debugger. That's worth installing a server to me. (It was a double-click operation on my Mac.)

If I forgo the OpenLaszlo server, I can statically compile my applications; although RPC is no longer available, I can still do HTTP POSTs, and that's enough to do something RESTful. But, instead of a webpage, I can create a very rich, interactive GUI-based environment that can be delivered to any browser that is Flash-capable. I hear Macromedia has pretty good penetration, and generally things Just Work within that environment, regardless of whether you are on Windows or Mac, IE or Firefox, etc.

So, I think it's a cool technology. I've been poking at the edges of it on-and-off for a few weeks now, and will follow up with some more about what I've been doing with it. My tutorial builder/photo slideshow demo just met a need I had; I think OpenLaszlo is capable of much, much more.

Posted by jadudm at 10:14 AM | Comments (0)

August 10, 2005

Transferring Transferring Behaviour with Javascript

Gordon Weakliem references Patrick Logan who references Philippe Bossut who references Alex Russell's OSCON talk on AJAX. The little tid-bit that gets me excited is the quote "Best data type to return: JavaScript instead of XML". I want to add an emphatic "yes!" to that. Only a crazy fool manipulates XML on the client-side when manipulating Javascript is so much easier. And, yes, I also want add another link to this long chain of attributions.

Posted by Noel at 02:15 PM | Comments (0)

August 04, 2005

Lisp in Javascript

If you're a Lisp head, like us at Untyped, when you look at Javascript you get an itch to add back all the parentheses (and fix its silly scoping rules, but that's another post). Unsurprisingly we're not the only ones. There is this Lisp to JavaScript Compiler I found via LtU, and also ParenScript. These are pretty cool. Of the two ParenScript is more practical, though the translation remains fairly direct. I'd like to see these languages go further and add features not present in Javascript. I think ParenScript gets the scoping rules correct, so next on my list would be coroutines to make coding animations easier.

Posted by Noel at 01:49 PM | Comments (0)

June 30, 2005

Aspects in Javascript?

I just read about an interesting library for using CSS selectors to apply Javascript behaviours, courtesy of a link from Ajaxian. The idea is simple: use CSS selectors in Javascript code to specify DOM nodes that Javascript event handlers should be bound to. This abstracts the event handling code away from the HTML. This gives cleaner code, though I'm not sure how useful it will be in practice, for two reasons:

• It will be slower than just writing the event handlers directly in the HTML. How much slower I haven't measured, so this may not be a problem.
• I don't write much Javascript directly (except when trying out new ideas). Instead I tend to generate it (along with HTML) from other sources, so achieving a separation between Javascript and HTML isn't an issue for me.

However I don't want to give a negative view of this library. I think it is really neat, and it has interesting similarities to Aspect-oriented programming (AOP). In AOP you change code by specifying places to add extra functionality. This library is changing HTML by specifying places to add extra functionality. If you squint the right way HTML and Javascript merge into one, so there seems to be a relationship here. I don't know enough about AOP to know if this analogy opens up any interesting new directions, but I know people who do, and I hope they're going to comment on this. :-)

Posted by Noel at 03:13 PM | Comments (0)

June 29, 2005

Achieving Closure

Todd Ditchendorf advocates the benefits of anonymous classes:

While the XMLHttpRequest class is certainly a major step forward for JavaScript in the browser, you have to admit… this API is crap … Instead of passing a function reference to [the XMLHttpRequest object], why not pass a reference to a JavaScript object? … Notice how [anonymous classes] allow you to package instance properties (fields, variables, attributes, whatever) and instance methods along with the actual callback method … Sure … you don’t need this kind of functionality … you can always just define a bunch of global functions and global variables to be used by your callback function, but, then you lose all the benefits that OO offers with regard to combining state and behavior into a single, encapsulated entity!

While I agree with his statements — the XMLHttpRequest API is crap — the alternative to anonymous classes is not a mess of global variables and functions, thanks to a feature in Javascript known as closures. It seems many Javascript developers don't know about closures, as they come from the functional, not object-oriented, line of languages, so I thought I'd highlight them here.

Javascript allows functions to return functions, and I think most Javascript developers will be familiar with that. However, some may not know that such a function can reference variables defined in it's parent function, even after the parent has returned. This means you can write things like:

function makeSayHello(name) {
  var sayHello = function() {
    alert("Hello " + name);
  }

  return sayHello;
}

var noel = makeSayHello("Noel");
var matt = makeSayHello("Matt");

noel();  /* Says "Hello Noel" */
matt();  /* Says "Hello Matt" */

Notice that noel and matt refer to the arguments to makeSayHello even after makeSayHello has finished executing. This is very useful when writing callbacks, as it allows you to setup the callback with the parameters it needs avoiding a mess of globals. For example:

function makeCallback(arg1 arg2) {
  return function() {
    doSomething(arg1);
    doSomething(arg2);
  }
}

You'll see this pattern used a lot in our demos. It's a neat trick and deserves to be better known.

Posted by Noel at 05:18 PM | Comments (0)