Waybeams

Wikipedia defines a waybeam thusly, “Across bridges, track is often laid on ties across longitudinal timbers (wheeltimbers or waybeams)”

Waybeams is a project that is attempting to bring at least some of the beauty, simplicity and elegance of Ruby on Rails to ActionScript, Flex and AIR development.

This is an application framework and library that is written in pure HaXe and was heavily inspired by experiences using the Ruby on Rails framework.

Guiding Principles

The fundamental principles that guide this architecture are as follows:

State is bad

Rich client systems are all flawed in that they force the developer to manage complex, nested state when in most cases, all they really need to be interested in is routing user gestures to the appropriate behavior. With the right system in place, complex state can emerge, without necessarily being managed by implementors.

The observation is that stateless client/server systems that communicate over HTTP are able to have massive complexity emerge from simple, singular, comprehensible request/response processes.

The theory underlying this system, is that one may be able to replicate the same client/server architecture within the context of a single rich client in order to alleviate many of the problems associated with complex state.

Duplication is bad

We have systems and architectures in the Flash/Flex world today that relegate us to almost copy and paste implementations of one boilerplate after another. If the only difference between a multitude of classes are their names, I say our systems are badly broken. The computer is a more appropriate tool for dealing with duplication. Let’s let the computer manage boilerplate and duplicate behavior with better architectural trade offs.

Strong typing doesn’t deliver on it’s promises

While this opinion is certainly contentious in some circles, in this architecture, it will be treated as a given. The problems that strong typing attempts to solve are more appropriately solved with better, simpler architectures, and the problems that strong typing introduces are often worse than the cure. I’d rather not get into all the murky details of this debate here, so if you’re interested in hashing it out, Wikipedia is as good a place to start as any.

The Roadmap

First thing is routing

One of the fundamental almost hidden features of Ruby on Rails is its routing architecture. The ability to transform simple, human-readable strings or commands into complex, predictable responses without forcing the developer to spend long, tiresome hours writing tedious, fragile glue and wiring code, is nothing short of amazing. This seemingly simple implementation decision is really what makes working with a Rails application such a pleasure.

Second is modeling

Boilerplate, duplicate code is at best tiresome and worst, a fragile place where bugs sneak into an application. While the model layer of a rich client usually does not map exactly to the domain on the server, we should work to minimize the amount of boilerplate required in our client system.

Third is the services

There is always a contentious problem around getting data into and out of a rich client. Formats, processes, patterns. These decisions all come into play. Ideally, our rich client models will speak RESTful HTTP, and integrate most seamlessly with Rails, but also play well with other servers.