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
Analysis
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:
Placeholder files
Rails contains (virtually empty) template files (e.g. mime_types.rb) to prompt developers where to perform specific extensions of configuration
Web Server Resources
Rail duplicates all of the frameworks required client-side resources (e.g. prototype.js) into every app project
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:
./app/controllers/posts_controller.rb
./app/helpers/posts_helper.rb
./app/models/post.rb
./app/views/layouts/posts.html.erb
./app/views/posts/edit.html.erb
./app/views/posts/index.html.erb
./app/views/posts/new.html.erb
./app/views/posts/show.html.erb
./db/migrate/20090115233219_create_posts.rb
./test/fixtures/posts.yml
./test/functional/posts_controller_test.rb
./test/unit/post_test.rb
"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
Analysis
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.
Posts
