AW Talk is the official development team blog for AribaWeb, the Open Source component-based web application development framework for creating rich, AJAX-enabled applications with the absolute minimum of code (and no hand-coded Javascript).

Announcing AribaWeb 5.0 (RC1)

The veil of secrecy is lifted: AribaWeb is going public! The AribaWeb team is proud to announce that today we are releasing the first (and likely only) release candidate before the GA release of AribaWeb 5.0: the first major Open Source release of AribaWeb!

To mark the occasion we've launched a much improved new website (

Here you can learn about what makes AribaWeb the premier full-stack component-based web application framework:
  • Auto Ajax
  • Instant App
  • Live Edit & X-Ray
  • Proven Full Stack
To bring it all home we, of course, had to create a new intro screencast!

You can get the full details on what's new in this release (and get the bits themselves) here -- suffice it to say that the focus of this release is performance, polish and (developer) productivity. Enjoy!

Way, Way Less Code

Could AribaWeb take 100x less code than Rails to create a basic database app??? If you've checked out our latest screencast you've likely taken note of this rather extraordinary claim (and seen that the AW app has much more functionality to boot).

Can this be true? How is it possible? And does it really matter?

Why Less Code Matters

In designing AribaWeb our goal is always to capture the developers intent as directly as possible. E.g. if you want all dates to be edited using a certain control just tell us that, once. If the password field should be kept "secure" just tell use that, once. Call it extreme DRY -- we strive to make your code a declarative statement of your requirements, rather than a (repetitive) encoding of their consequences.

Why does less code matter?
  • The less code you need to write, the faster you can try out ideas:

    Less code == More Creative.

  • The less code you write, the less code you need to test, debug, and maintain.

    Less code == Cheaper.

  • The less code you have encoding your requirements, the less you have to change when those requirements change.

    Less code == More Agile

So how does AribaWeb fair?

100x Less Code than Rails?!?

Both Ruby on Rails and AribaWeb make it easy to create a basic database application based on the definition of model object classes. Rails does this by way of generated "scaffolding", AribaWeb using "Instant App". To compare AW (v5.0) and Rails (v2.2.2), we created an app with three model classes (Issue, Note, and Category), each having a couple of fields. In the case of Rails this involved running:
rails MyApp
ruby script/generate scaffold Issue ...
ruby script/generate scaffold Note ...
ruby script/generate scaffold Category ...

For AribaWeb we ran aw create_project, selected the Master Detail (Groovy) template, and then added one more domain class in the resulting project.

Here's a look at the resulting applications:

And the code?

  • Rails: 90 Files, 10,505 lines
  • AribaWeb: 4 files, 90 lines
  • Difference: AW project has > 100x less code


How can this be?!?

The AribaWeb app contains three compact groovy files to declare the three domain classes, a short build.xml file, and an (empty) .oss rules files. The build file inherits all of its behavior from a parent build file in the AW distribution, and both the database schema and the application UI are derived on the fly at runtime from the domain class meta data.

In the case of Rails, it's 100x disadvantage come from three sources:

  1. Placeholder files

    Rails contains (virtually empty) template files (e.g. mime_types.rb) to prompt developers where to perform specific extensions of configuration

  2. Web Server Resources

    Rail duplicates all of the frameworks required client-side resources (e.g. prototype.js) into every app project

  3. Per-Domain Class Scaffolding

    Each class gets a slew of generated layouts, a controller, a helpers, a fixture, and a db migration.

The value of placeholder files (#1) is debatable (they provide nice prompting, but can become stale as the framework evolves), but these don't contribute significantly to the total spew. #2 and #3 are the real killers.

Having every project keep copies of the Rails web resources may seem harmless (as a developer you don't have to edit these files) but the violation of module encapsulation that it entails leads to maintenance costs down the road: As new versions of the framework are released (likely with dependencies on new or modified resources) app authors are required to manage merges upon every upgrade. The biggest issue, though, is category #3...

Per-Domain Class Code Size

To get a handle on the incremental overhead for each new domain class, we added another domain class to each project. Here was the incremental code change:
  • Rails: 11 Files, 256 lines
  • AribaWeb: 1 file, 17 lines
  • Difference: AW project added > 15x less code

So while AW simply added a single file for the domain class and got an updated UI for free, the Rails project saw the addition of all of these:


"But I didn't have to write this code. Does it really matter how much of it gets generated for me?"

Absolutely. Embedded in each of those files are the consequences of a set of assumptions about the kind of user interface you want for your application. Want to change the relative order of two fields? Edit all of those .erb files for that class. Want to change the component used to edit text? Edit every .erb file in your entire application.

AribaWeb is fundamentally different:

Want to change the order of two fields (in all forms)? Put this in your .oss file:

class=Post { password => email }
Want to make that change just on the creation form?
class=Post operation=create { password => email }
Want to change the control used to edit text everywhere in the application?
field type=String editing { component:MyTextEditor; }

And better still, with Live Edit you can actually make these changes on your running app, by dragging and dropping right on your running application UI.

AutoAJAX: 10x less code than GWT/JSF

AribaWeb's conciseness advantage isn't limited to model-driven database UIs.
Take for instance the case of a simple AJAX UI where a user-entered search triggers the placement of a marker on an embedded Google Map.

The authors of the ZK framework compare building this app in several different frameworks in these articles: ZK vs. GWT, ZK vs. Ajax JSF Components

A version of this mini-app built in AribaWeb is included in the Demo app in the AW distribution and can be found here.

Here's how AW stacks up:

  • JSF / ICEfaces: 3 files, 223 lines of code
  • Google Web Toolkit (GWT): 5 files, 190 lines of code
  • ZK: 1 file, 36 lines of code
  • AribaWeb: 1 file, 17 lines of code
  • AW Advantage: AW Project has 10x less code than GWT/JSF, 2x less than ZK


How does AW do it? The fundamental answer is declarative binding: where the ZK code needs to explicitly script pulling data from the text field and pushing values to the Google Maps component, AW handles this automatically through bindings on the respective components.

And speaking of components, its instructive to look at what it took to build the generic Gmap components behind used in these two examples. (The source for the AW version can be found here, the ZK source here.)

  • ZK: 55 files, 8537 lines
  • AribaWeb: 6 files, 442 lines
  • AW Advantage: ~20x less code:

The AribaWeb commitment to simplicity is more than skin deep: reusable components (the kind that application developers author all the time as part of building their apps) use the same Auto AJAX support, and same simple declarative binding model as other application pages.

Coming Soon: Release Candidate 1

Rumor has it that version 5.0 RC1 is just days away, with GA just around the corner.  This is an exciting milestone for the Open Source AribaWeb project!

Version 5.0b7 Released! (12/2008)

With just an hour or so left in 2008 it's time for a major AribaWeb update: AribaWeb-5.0b7.

As always there's a new screencast to show off some of what's new.

In this case we build a real app (an email-integrated bug tracker with full text search, user auth, etc, etc), and show that a basic AW project has 100x less code that its Rails equivalent (and does a lot more).

See below for the full list of new features, and check out our site at to pull the latest code.

I look forward to hearing what you think!

Start 2009 off right: Spend the 1st catching up on your AW Screencasts! :-)

- craig

  • AtIssue: a new full-featured demo app

    • email integrated lightweight bug/task tracker
  • Full Text Search support via Compass/Lucene (JPA / Hibernate integration)

    • automatically used in choosers and search panels
  • New AppCore framework:

    • Basic User, Group, Permission support
    • Login (local auth)
    • MailMonitor
  • New CSV Data Loader

    • Automatically initializes new schemas by loading integration/pkg.ClassName.csv files
    • Support relationship initialization (automatic foreign key lookup)
  • New project template for Master Detail apps

    • Creates app set up for AppCore, Compass, ...
  • New mail parsing / viewing support (AWMimeParsedMessage, MimeMessageViewer)

    • Mail Client example updated to use it
  • MetaUI: many enhancements

    • New compact field ordering (and trait application) syntax: e.g.
      zLeft => firstName => lastName; zRight => email#required => phone;
    • New wrapper style traits (bold, italic, heading, ...)
    • OulineBox layout
    • DataTable detail row rendering support
    • Generic support in MetaIncludeComponent for wrappers, named contents
      • Also, easily propagate full bag of bindings to subcomponents (awbindingDictionary binding support)
    • Merge of "traits" and "trait" property (only "trait" lives on)
    • Support for using parent context traits in rules affecting nested keys. e.g.:
      module-trait=CoolMode { field { editing: false } }
  • Bug Fixes:

    • Build fix: re-builds were creating nested build directories (and breaking app re-launch)
    • Some metaui Context exceptions (on nested value override chaining)
    • MetaUI rapid-turnaround (reloading) fixes
    • Rebuild of groovy app not rebuilding groovy classes
  • Updated Dependencies

    • Updated to Hibernate 3.3.1, JavaMail 1.4.1, log4j-1.2.15