Web Info & Tutorials

I’ve long been a proponent of server-side Ajax frameworks — frameworks that store state on the server and use an Ajax engine in the browser to drive the display. The advantages: state and control logic stay on the server, so security compromises that exploit client-side state and logic are more difficult to pull off; developers can work in one language and, for the most part, ignore the fact they are writing a web application. The disadvantages: the server retains a large amount of state, so scaling your application can be problematic.

There’s one other large disadvantage to these open source server-side frameworks: for every 100 Java developers who use the framework, there is only 1 of them that can do serious JavaScript development. That means that the lifeblood of these frameworks — the development of new and cool JavaScript widgets — is sluggish at best. That has certainly been the case with the best known 3 frameworks: Echo2, ZK and ThinWire (though ZK does wrap a number of Ajax widget libraries, such as Dojo).

Back when GWT was introduced, it struck me that this would be the perfect way to write the client-side engine, to let the other 99 Java developers join in. I had the good fortune of being seated next to Joonas Lehtinen, IT Mill’s CEO, at the GWT Conference in SF this past week and was blown away when he demo’d  IT Mill Toolkit 5, his server-side Ajax framework (dual Apache 2.0 and commercial licenses) that, yep you guessed it, uses GWT for its client-side engine.

One important thing to consider is that IT Mill has extended the default GWT widgets so that they can be fully "rebranded" with CSS. They do provide an extensive reference manual that will guide you through developing your own custom components and integrating them with the server side.

I’d like to see the other server-side frameworks follow IT Mill’s lead in using GWT for the client side, but given the amount of effort that they have put into building their client-side engines, that may be a ways off.

Simon Willison just doesn't stop. This time he has added a way that details the technique of unobtrusively mapping microformats with jQuery.

Simon puts together jQuery, microformats, and the Google Maps API to grok hCard and show maps of any hCard data that is found, ending up with:

You see the finished code at work.

Jacob Rus keeps the run of great content on Comet Daily by talking about the the future of Comet: Part 1: Comet Today. Jacob discusses the hacks that we use for Comet, compared to the server-sent events and event-source specs that are finally getting implemented. He then goes through the current trade-offs behind current solutions:

• “Forever-frame” iframe streaming
• htmlfile ActiveX object
• XHR multipart
• XHR streaming
• XHR long-polling
• Script tag long-polling (“CometP”)
• Flash and other plugins

With this impressive list of transports, we can cover all recent browsers (IE 5+, Safari 1.3+, Firefox 1.0+; Opera 8.5+ as described next time) without unseemly side-effects, using our choice of streaming or long-polling, and can support browsers back much further than that, with a few usability niggles. Unfortunately, however, this requires careful implementation of our server code and browser-side JavaScript, which must coordinate to agree on a transport. This coordination problem, along with browser’s cross-domain security policies, prevent us from using real-time sources in the kinds of mashups built from other web services. The barriers to entry for Comet are much higher than for non-real-time content, and success relies on loopholes in existing browser objects. Wouldn’t it be nice if every browser used the same mechanism, which could stream events across domains securely and efficiently, and web authors could in turn write straight-forward HTML and JavaScript, and send but a single format from the server? Stay tuned for part 2, which plots a course to such a future.

Joshua Marinacci, of Sun, has been activity with JavaFX Script. As a artefact to see the newborn module he developed:

Writing this mettlesome rattling taught me the Buddhism of JavaFX Script (hmm… sounds same a beatific aggregation title). I ofttimes hit to fisticuffs my procedural Java instincts and instead ingest protection and triggers wherever possible. It’s rattling a assorted artefact of thinking, fireman to Lisp or Prolog (and modify a taste of SQL), but quite powerful. I’m trusty I didn’t intend it amend and I look I could writing it in a some more months using a meliorate style, but this is a beatific start.

So I’d same to deal with you my prototypal actual JavaFX Script application. It’s a ultimate teaser mettlesome where you utter installation cells to invoke soured the light. As you utter apiece radiophone the conterminous cells fling as well. You get the mettlesome by motion soured every lights (hence the study .

You crapper download the code and verify a extreme at the newborn language:

Flash (via Flex or AIR) allows developers to open connections to servers (binary sockets), much like XHR in Web applications. And, just as frameworks like DWR and JSON RPC allow for remoting objects via XHR, a number of frameworks allow for remoting objects in Flex. One of the most popular has been Flex LiveCycle Data Services, but it's also a commercial product with a big enough price tag to cause many developers to steer clear.

Not anymore.

Adobe just announced that they are open-sourcing the remoting and HTTP messaging features of Flex LiveCycle Data Sources in a new product called Blaze DS, which will be LGPL licensed. In addition, they are taking a page from Comet and making it easy to create a persistent connection for "server push" functionality for the HTTP messaging. The "data management" features (i.e., keeping a client and server model in sync) remain payware.

In addition, they are publishing the spec to their object remoting protocol (AMF), making it easy for others in the community to create remoting servers (previously, folks had to reverse-engineer the protocol). This opens the door for other non-Java platforms to provide middle tiers in the Flex stack (i.e., Flex doesn't include any public database drivers, so you have to write a middle-tier to transfer data to Flex apps, and right now Java is the only first-class option).

Many folks wonder why Ajax developers don't just use Flash; as Adobe open-sources more and more of their stack, it's going to be very interesting to see the reaction of the community. We at Ajaxian aren't in the "Open Web or Else" crowd, but a fully open Flash stack would sure make the world a touch more interesting.