ZK 3.5, the latest version of the server-side Ajax framework, is out with a raft of new features. Three of those features really stand out for me:
Server push via polling has been available in ZK for a while, and Comet in the ZK "Enterprise Edition," but now it is available to everyone. And it is pretty easy to use: "The implementation of server push is transparent to developers. ZK chooses which implementation to use according to the edition of ZK automatically, but it is configurable."
Customization of look and feel has gotten much easier. ZK has followed the example of a number of other frameworks in styling its widgets with predictably named CSS styles. Changing the look and feel of an application is now as easy as changing the ZK widget style sheet. Styles can further be overridden on a widget instance-by-instance basis.
Performance monitoring is perhaps the most exciting new feature. Client-side tools such as YSlow can guide optimization efforts and give you point in time performance snapshots. But critical applications need to be monitored and tracked end to end over their lifespan. With ZK 3.5, you now have the plumbing to instrument your application to capture five data points for each request:
ZKStudio 0.8.2
There's also a new version of ZKStudio for Eclipse out. The major change is that it now supports auto update via http://studioupdate.zkoss.org/studio/update
One of the reasons Dion is such an effective editor here at Ajaxian is his sense for filtering all of the available news from the Ajax community down to about three stories a day. Truth-be-told, with all the submissions we get and what we find on our own, we could easily post 10 stories a day. But in today's saturated environment, we find three stories is about the right number to keep from overwhelming our readership with too much noise. We hope you agree, and we're interested in hearing if you feel otherwise.
A consequence of this arbitrary filtering is that some of the lesser known frameworks and libraries simply don't get covered. We never try to be king-makers, nor do we have that kind of clout--we simply can't cover everything.
We enjoyed Six Revisions' recent round-up of 10 new/up-and-coming JavaScript frameworks, many of which we've never covered, like Midori, Archetype, JUNE, UIZE, Simple.js, and fleegix.js.
The adventurous among you should take a look! Not too long ago, an up-start named jQuery shook up the existing players... some of these may be next.
Ignacio Coloma has announced Loom 1.0 RC 1. Loom is an annotation-based java web framework that includes a ton of new features in this release. After some selective process, these are the bits that could be of most interest for Ajax developers:
Just give it a try at the demo. Try introducing invalid input, and check the sources by clicking the "View source" link at the top right of the page. Everything in the demo should work with javascript disabled, including multiple file upload.
The framework also includes a libraries repository which pulls debug/optimized javascript from the google CDN:
This snippet of code would translate into this, if development is disabled:
Or this if not:
More details about the framework are at the reference guide. Ignacio would be grateful for any feedback!
No matter how much Paul Graham talks about his Web success, we don't hear too often about Lisp-powered Web applications.
SymbolicWeb is offering up a new type of framework to help change that.
SymbolicWeb aims to create a GUI framework similar to GTK+ and QT for Common Lisp. It differs in that it uses the browser to render the UI elements.
There are a slew of examples, such as this simple echo chat program:
(in-package #:sw)
(defparameter *max-chat-pane-size* 100)
(defapp chat-app (empty-page-app)
((input (mk-text-input))
(chat-pane :allocation :class (mk-container nil))))
(defuri chat-app "chat")
(defmethod main ((chat-app chat-app))
(with-slots (input chat-pane) chat-app
(setf (on-enterpress-of input
:callback-data `((:input-value . ,(js-code-of (value-of input)))) ;; Include some data when the event fires.
:js-after (js-code-of (setf (value-of input) ""))) ;; Clear the input field after the event has been fired and sent.
(lambda (&key input-value)
(prepend (mk-span (escape-for-html input-value) :display "block")
chat-pane)
;; Don't let it grow too big; delete some chat history.
(when (> (length (children-of chat-pane)) *max-chat-pane-size*)
(dolist (span (subseq (children-of chat-pane) *max-chat-pane-size*))
(remove span)))))
(add-to *root*
(mk-span (who (:p "Type something in and press enter. New content is added at the top.")))
input
chat-pane)))
LtU pointed me to TileStack, the latest attempt to resurrect HyperCard and bring it back to the Web (they are closely related of course).
Running online there are going to be limitations about which stacks can be ported, which may reduce the usefulness and impact of this project, but maybe a standalone version will come later.
The system compiles Speak (the TileStack version of HyperTalk) to Javascript. If the result is not obfuscated, something I haven't verified, it may be possible to augment the output from TileStack with additional capabilities not supported or not yet implemented.
From the compatibility angle it is interesting to note that they renamed the language and seem to imply they are going to extend it beyond HyperTalk, without giving any specific guarantee about future compatibility. I'd suggest releasing the compiler that's as close to full HyperTalk compatibility as a separate product (or even, if they can bring themselves to do it, releasing it as open source).
What does Speak look like (remember, not Squeak!):
Speak is the name of the language that all TileStack's use to describe what should happen when someone interacts with a stack you've created. It is directly related to the HyperTalk language that was used by HyperCard for the same purpose.
It is in the same vein as the "kinda like English" languages like AppleScript, COBOL, BASIC, ...
set the name of card field 1 to \"My Field\" go to the next tile get the first word in field \"First Name\"
The team is working on being able to embed these Tiles anywhere on the Web (gadgets, etc).
I've been talking about event driven application design in JavaScript in January last year and inspired Caridy Patiño to write his Bubbling Library based on these ideas.
Caridy now upped the ante a bit by talking about decoupling using the bubbling library over on the YUI blog.
In essence, his solution allows you to have custom events on application modules and listen to them independent of execution order or availability. Simply using custom events can get you in a pickle if you make yourself dependent on their order. With the decoupling solution proposed by Caridy this becomes one less issue to worry about.
Now that DOMAssistant has a formal team behind it, the updates keep coming fast and furious. The team announced last night the release of DOMAssistant 2.7, with a host of new features and big improvements in CSS selector performance:
After a lot of hard work, we’re more pleased than ever to present the new version of DOMAssistant: faster, less code, better support and improved stability. And more features, of course.
While we have actually made the code file size smaller, at the same time we have added a number of useful features and improved CSS selector performance.
Along with several fixes, the team added a number of enhancements most notably strong support for Unicode and performance increases for Internet Explorer:
With this release, we wanted to target the world outside our English-speaking box, by adding Unicode support and a complete documentation in Chinese. When that was in place, improving CSS selector performance in Internet Explorer and adding well-needed and requested features was next on the bill.
Happily, we succeded as well as exceeded our goals!"
The newest features include:
DOMAssistant 2.7 is available for download via SVN or HTTP and is released via MIT license.
Echo has been known as a Java server side component framework, but with the release of Echo 3, they have added a way to build component applications using JavaScript:
Client-side Echo applications do not require an application server, and can also be run entirely offline.
With Echo3, the formerly server-side-only component framework has been recreated in client-side JavaScript. This was not a direct “port”, but rather a re-imagining of the framework with the ideals of JavaScript development in mind. For example, the client-side version of the framework takes advantage of JavaScript's object and array literal syntaxes to create a capability called "hierarchal component construction", where an entire hierarchy of components can be created in a single call. Such code winds up being extremely readable, as, when naturally indented, it resembles the component tree.
Core.js framework
A low-level framework, called “Core.js” was created to ease development of object-oriented and event-driven code in JavaScript. Core.js provides an inheritance model for building JavaScript objects using class-based (rather than prototype-based) inheritance. It additionally offers the capability to specify abstract classes and methods, and features “pseudo-private variables” where a class can reserve internal method/field names that cannot be overridden by subclasses. The framework includes utilities for managing events and listeners, and can register event
handlers on object instances.New Back-End / Rendering APIs
The “back-end,” which is responsible for rendering components within the web browser, has been re-engineered for Echo3. Instead of each component having its own client-server serialization code, Echo3's web application container simply serializes the state of updated components directly to the client, where JavaScript versions of the server-side components are then created and updated. This feature makes the component development process substantially easier and faster than it was in Echo2. The new approach also yields performance dividends when creating server-side Java applications -- Echo3 consumes less CPU and a mere fraction of the bandwidth of Echo2.
New and Improved Components
Many new components have been added to the framework and existing components have been enhanced in Echo3. WindowPanes, for example, will always stay on screen, even if the browser window or containing component is resized. Menus can be configured with opacity and fade-in effects. New components have been added to the Extras library including a RichTextArea and Tree/TableTree. New APIs for keyboard accessibility and focus management allow for mouse-less operation (note: still under development in some components).
Michael Grosser has created jQuerys testrunner in a way that makes it work with jsUnit, and also useful for libraries other than jQuery.
Here is a full example:
that produces:
Version 2.5 of the Yahoo User Interface Library (YUI) was released today. You can get all the details on the official blog post, but here's the "change log":
In addition to that, some of the components left beta status. These are the Get Utility to retrieve scripts and style sheets on the fly, the ColorPicker Control, the JSON Utility to validate JSON, the ImageLoader Utility to load images on-demand to increase page performance and the YUI Test Utility.
The really detailed report on all the changes is available on the YUI list/forum.
If you want to have a quick glimpse of what the Layout Control allows you to create, check out the demo application interface simulating simulating Yahoo Mail.
I had the opportunity to sit down with three fine gents from Aptana to discuss their recent launch of Jaxer, the "server side Ajax framework".
Paul Colton, Uri Sarid, and Kevin Hakman all sat with me to chat about things. I have already played with Jaxer, and created the Google Gears wrapper which can be used seemlessly for use cases such as "If the user doesn't have Gears installed, just do it on the server".
We discussed a lot in the twenty odd minutes including:
A lot of good stuff. Thanks to the crew for taking the time to chat with me. What other questions do you have for them?
We have the audio directly available, or you can subscribe to the podcast. We also have the video in high def here, or in normal def right below:
Marcello Bastéa-Forte has developed OnionML, a layout template language that uses server side JavaScript with Rhino and E4X on the back end.
The high-level goal of the template engine is to be something with utility not unlike CSS, but for intended layout and composition. The actual functionality is similar to XSLT, but with the design goal of being simple and easily extensible.
Onion ML is an XML template system designed with a bias toward modularity.
Onion ML lets you easily custom XML tags to make modular content design simple and easy to mix with HTML. It is somewhat comparable to XSLT and JSF, but intended to be easier to understand.
You define custom tags either as markup in XML files or as custom JavaScript functions which generate output.
Onion ML also provides several control flow methods necessary for dynamic content. Methods for iterating over data sets and conditionally displaying tags are core to Onion ML's functionality.
You end up building nested tag layouts. For example, you first define a tag:
<tag :copyright>Copyright <arg :all/> All rights reserved</tag>
and then you can use it:
You can also do the work directly in JavaScript:
onion.add(
<tag :anothertag>play the <mytag>tuba</mytag></tag>
);
onion.add("date", function() {
return new Date().toString()
});
Cross posted from my personal blog
Last week we posted about Jaxer which offers an approach of turtles all the way down where JavaScript is used on the client and the server.
Then, I got to interview Steve Yegge. Last year, Steve posted about Rhino on Rails, his port of Ruby on Rails to the JavaScript language on the Rhino runtime.
Ever since he presented on the 'Google Rails Clone' at FooCamp and he posted about the internal Google Rhino on Rails project, people have been curious to learn more.
jjs? Server side JavaScript generating client side JavaScript? Argh!And of course, the big questions:
When do I get to see it!
I happen to be in Seattle at the Google offices, so I was able to ask all of these questions and more. Steve was a fantastic host, and I really enjoyed chatting with him.
This is the kind of video I want to explore at Google. We have many great developers working on cool technology. I want to get them on camera, participating with the community when I can. Sometimes we can talk about products and APIs, but sometimes we will talk about fun ideas and projects that we are working on such as Rhino on Rails.
Anyway, give it a watch and let me know what you think:
This also lead me to the fun idea of Java and JavaScript flip-flopping:
John Le Drew has been working on a PHP framework for a few years, and has now packaged it as Simplicity:
The Simplicity PHP Application Framework is an advanced, scalable and extensible PHP application framework to aid developers in creating high traffic, high availability Web 2.0 online applications. Integrating a solid MVC framework with some of the best Open Source projects around Simplicity aims to assist developers with any amount of experience in taking their applications to a new level.
You can get to the code on the launchpad for the framework.
One important piece is the Ajax admin console, developed in Ext that allows a developer will be able to configure all aspects of their application via the Ajax interface, this includes database modeling and the creation of stub controllers, and even the addition of predefined actions to speed up development.
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.
With so many good JavaScript frameworks available, it's getting harder to decide in which direction to head. Brian Reindel offers some good advice to those looking to embrace a framework but aren't quite sure what to look for.
A JavaScript framework may not make you a better programmer, but it will make you more efficient. That alone should be reason enough to choose a JavaScript framework, or library if you prefer. Unless you decide to build your own, there are plenty of options available to developers. However, choosing the right framework can be tricky, and weeding through a mess of opinionated fanboys (myself included) is intimidating.
Brian targets such areas as browser support, project maturity, documentation, & community and how they can have a profound effect on your choice(s). While a lot of the material will be repetitive to many experienced developers, it's definitely useful to those that are just now looking at leveraging a framework.
My colleague Brian Dillard is just putting the finishing touches on the 0.6 beta release of Really Simple History (RSH). What's new and improved?
I've tried to be as ambitious as possible with this release: full support of IE7/Win, Safari/Win, Safari/Mac, Opera/Win, Opera/Mac. I've didn't quite get there, but I got close.
Features in the new version include:
- Full support for IE7/Windows (though my only Windows machines use IE7 Standalone, so I need help testing on "real" IE7 installs).
- Full support for Safari 2/Mac (though I'm still trying to eliminate the "infinite loading" bug before I push out the beta).
- Partial support for Safari 3/Windows (hampered by bugs in the current beta version of the browser).
- Full support for cross-platform Opera 9.22 (though you may need to hard-code an image into your markup).
- A totally revamped test page that allows you to play with the library in your browser of choice and see how it works behind the scenes.
As always, RSH works beautifully in Firefox 2 for Windows and the Mac. I hope to give it a good shakedown on Linux browsers in the next release.
What was the main source of difficulty in this release? In a word, Safari.
Plenty of people who've worked on Ajax bookmarking projects have
commented about this, but it only becomes clear once you've actually
seen it in action. Getting this thing to work in Safari 2 for the Mac
took a wildly disproportionate amount of time considering its market
share.
Hopefully these dusty corners of the browser world will get improved over time.
Supplementing GWT's basic set of widgets with wrappers around those of existing widget frameworks has become a bit of a cottage industry. There are wrappers for Scriptaculous, JsGraphics, TinyMCE (see the GWT Widget Library for these), Ext Js and many more. Now add Rialto to that list. (For a demo of the Rialto widgets, such as the interesting GridTreeView, see here.)

One shortcoming of Rialto's GWT wrapper, however, is that all of the widgets are subclasses of JavaScriptObject rather than Widget. A best practice that has emerged for wrapping other frameworks is to wrap a Widget adapter around a JavaScriptObject so that the wrapped framework's widgets can play nice and integrate with other existing GWT widgets. The Rialto wrapper doesn't do that and also implements a parallel set of event, clicklistener and other classes. This shortcoming needs to be resolved in order for this particular framework wrapping to be useful.
One of the enduring criticisms of ZK, the server-side Ajax framework, has been against its perceived slow performance. Critics have observed, and supporters have conceded, that applications written with ZK seem a touch slow. So it's no surprise that a major focus of the latest major release has been improved performance. The ZK team found two major bottlenecks in performance testing:
After a series of stress test and reviewing the kernel code, we found out 2 bottlenecks on ZK 2.4.1 and fixed them in ZK 3.0 RC.ZK 3.0 RC solves these 2 bottlenecks by using the renderer class and new cache mechanism. The test result shows ZK 3.0 RC is four ~ five times faster than ZK 2.4.1.
- The executing time is too expensive when rendering components. ZK uses templates to render components, and the EL is generally used in templates to simplify the variable access and templete maintenance. However, when the concurrent access rises to a large number, the overhead on rendering component with EL is too heavy.
- Threads spend too much time on waiting the synchronization when many threads access to the same cache under current cache mechanism.
I haven't validated these performance figures myself, but an initial comparison between some demo applications confirms a much more responsive user experience.
ZK 3.0 RC has also added a number of other new features:
Server push was already supported in ZK through use of the timer component, but the enhancements make it even easier (note: we're not talking comet, but rather client polling). Even more exciting for me is the dynamic loading of ZUML (the XML-based markup language for specifying ZK interfaces) pages dynamically from sources such as a database. That's very helpful if you want to allow non-developers to deploy interface changes without having to spit out ear or war files.
As usual, the ZK folks have done a good job documenting the changes and additions. It's too early to tell if 3.0 will solve all of ZK's previous shortcomings, but ZK is well on it's way to becoming my favorite server-side framework.
When I first saw an email from Dirk Jesse about YAML, I was instantly in Ruby mode. Then as I read I realised that he was talking about a totally different YAML, his own CSS framework "Yet Another Multicolumn Layout" (compareble to YUI Grids or blueprint) that is designed
for creating flexible float-based multicolumn css-layouts. YAML is
released under creative commons licence.
Dirk told us:
The framework is focussed on flexible layouts and offers column and/or
grid based design elements for flexible, elastic or fixed layouts. YAML
has grown over two and a half years now. Since YAML wasn't planned to
become a framework, things grew slowly and only with a german
documentenation. Thats I think, is the main reason, why it is almost
unknown outside Germany. This changed with the arival of YAML v3.0 july'07.YAML is very flexible, comes with a bilingual documentation (PDF, > 100
pages) and - my lastest baby - a builder, that allows visual configuration of the basic layout elements.
The building is a very nice Ajax app in its own right:
In the "I-can't-believe-it's-not-Flash" category, Robert Schultz pointed us to his amazing World of Solitaire website, implemented with YUI, MochiKit and PlotKit:
It's hard to single out a favorite feature, from it's ability to rescale the size of the cards when you resize the browser window to its impressive animations and smooth drag-and-drop. Definitely worth a look!
Robert gave an interview to the YUI blog that discusses implementation details.
Olav Bjorkoy recently launched Blueprint CSS, a framework that takes typography into account.
Why did Olav create it?
After reading an article by Jeff Croft on frameworks for designers, I started looking at the existing CSS frameworks, trying to find one that was right for me.
Never again was I to repeat the tedious task of creating a grid from scratch, defining default typography, or battling with inconsistent default browser CSS.
Features
Here’s some of the features Blueprint brings to the table (not
, mind you):
- An easily customizable grid
- Some default typography
- A typographic baseline
- CSS reset for default browser styles
- A stylesheet for printing
- No bloat of any kind.
Many people have gotten excited about it, includein Mark Boulton:
What a list! Now, if you just put the first point aside, the core features of Blueprint bring together some of the best typographic design thinking on the web over the past year or so. Eric Meyer’s reset code is in there, Richard Rutter’s Vertical Rhythm theory, Jeff Croft’s ideas on managing a CSS framework.
Going back to the grid—and this is what really interests me—Olav has used Khoi Vinh’s theories and practice on grid design to great, practical use. What is so important about this CSS framework to me is that it has been designed to solve a design problem, not a technical problem. As all great systems, it has been designed to help and guide the designer. As you can tell, I’m already a big fan.