An eclectic-pencil blog

At curlr.org Steve Adams has a page on AJAX with Curl 5.

AWAX or Async Web App’s without JavaScript using XMLHttpRequest can also be found at AJAX Anywhere and java-based ZK

AJAX Anywhere deals with JavaScript by using eval() which puts it beyond the pale with most JavaScript developers. ZK is touted as AJAX without JavaScript but it is really a way to avoid raw JavaScript or to script with alternative scripting languages. Like GWT, ZK promoters suggest that JavaScript is the problem facing RIA. Why should that be so?

The first advantage of Curl over JavaScript is that Curl is modular with java-like packaging. In some alternative frameworks, such as Mozilla XUL, the JavaScript and the CSS are kept separate by a directory naming and structuring convention. JSAN, the JavaScript Archiving Network, is an effort to bring order to the world of the Rhino book and the Howler cookbook that otherwise can only be had by adopting Prototype or Dojo or the like. A library is needed as soon as unobtrusive JavaScript is used for creating XMLHttpRequests across browsers and handling errors along with browsers with JavaScript disabled. The very justification for GWT and GWT tools is a problem with the quality of JavaScript code in programming-in-the-large. This is no longer ad hoc “we’ll have somone script a cool page for us.” Traditionally, libraries have been our attempt to address code quality in re-use. And not without a price.

One way of looking at a ‘Smalltalk’ prior to packages and namespaces is to see such a Smalltalk implementation as an IDE framework which stands in place of a file/include hierarchy. But when it comes time to build runtime bytecode ‘images’, file load dependencies have been a Smalltalk headache. Granted, those headaches look minor compared to edit-compile-link cycles in a ‘C-type’ language which is not using continuous integration to ensure build consistency and success. In the case of Smalltalk, it is very clear what the tool – as – the – environment offers because (proxies and such aside) all code lives in a single class hierarchy. All testing and object inspection is done ‘live’ and ‘in-place’ as is all code-versioning ( my pet peave is that code versioning [control] is so often confounded with build versioning [a deliverable], something libraries can escape.) With a very few exceptions from academe, most production Smalltalk projects have little to teach about how to branch and merge (no flames, please … apostasy or no)

What is so striking in RIA code in Curl is how elegant the code is at the level of use (i.e., when programming-in-the-large.) This is one of the pleasures of RAD in Smalltalk. The kind of clever JavaScript effects achieved by script.aculo.us are so simple in Curl. Take these multi-tab ‘accordion’ sliding-window panes from the ‘live’ Curl documentation applet for example.

{MultiTabAccordion
    tab-orientation = "horizontal",
    {TabPane
        label = "- 1 -",
        tab-button-tooltip = "first tab",
        {TextFlowBox font-size = 28pt, "1"}
    },
    {TabPane
        label = "- 2 -",
        tab-button-tooltip = "second tab",
        {TextFlowBox font-size = 28pt, "2"}
    },
    {TabPane
        label = "- 3 -",
        tab-button-tooltip = "third tab",
        {TextFlowBox font-size = 28pt, "3"}
    }
}

One of the selling-points of Smalltalk for GUI development back in the days of VermontViews, X11 and earlier Windows MDI GUI’s was that Smalltalk arrived with the ‘library’ and the ‘tool’ in place. Of course with no standard and multiple implementations, only add-on tools such as that from current GWT vendor Instantiations offered any degree of portability. Code ran on multiple OS’s that would not run under multiple Smalltalk’s. The French have an expression for such secrets that are no secret at all. The irony is that JavaScript in the browser has been almost as exasperating through no fault of the language design and in spite of a standard.

Curl5, much like Rebol, is a single vendor language ( Rebol3 will be so only at the core and alternate Rebol implementations have arisen.) This does not seem so restrictive if you are considering a single-source framework, open-source or otherwise. Curl comes with a quite complete CURL.XML.SOAP package for SOAP over HTTP, but currently is not shipping with XMLHttpRequest classes. The sadXMLHttpRequest and sadXMLDom examples at curlr.org have the kind of elegance and simplicity that you expect in a web content language when creating a request, sending a request and responding to changes in request status. Any framework for async messaging which will get any use in the frontlines of development has to have this elegance (witness the heavy-handed callback coding for Windows in VisualProlog – barely one step above coding in C.)
Some frameworks for complex callbacks which relied on IDE’s failed: IBM VisualAge was one. But out of that failure came the Eclipse IDE framework. Now we are returning to complex callbacks in RIA and it is not clear what lessons have been learned. The very need for the GWT and the Eclipse plugins for GWT are alleviating a symptom and risk being mistaken for a cure.
The next nostrum will be Groovy and Grails for Java6 ‘Mustang’. Everything that made inner classes in Java awkward for understanding callbacks in an application of any UI complexity has an apparent cure in Groovy. But as a functional language with closures, Groovy is every bit as rich as JavaScript. It is not clear that a controller in Grails is more limpid than a controller in Struts. At least in Smalltalk we seldom mucked-about in the controllers when out in-the-large.
It was usually enough to know how to send a “who’s the current controller” message.

Curl is also a functional language with closures. But it has a different strategy: as a domain-specific language, it does not set out to separate content from presentation. That is not its model. And just as Smalltalk MVC has to take a grotesque twist to be a face for the web in Java JSP’s, any framework for separation of concerns in rich web applications may be trying to solve the wrong problem.
In this regard, Curl has a great deal in common with Rebol. More on that to come …
PS
I think that the closest thing to Curl in the way of sliding Web ‘panes’ and such is script.aculo.us in Seaside for Smalltalk – and ever so ‘cool’ because any ‘debugging’ occurs in the ‘live’ environment of the page itself ( Curl requires the page to re-load the applet – still not as bad as a web server restart.)