About Brix

Recently I’ve been working on a framework called ‘Brix’, which may interest those who saw my rather hastily-prepared LRUG talk last year. It’s another Ruby web framework – I know, I know – why yet another? Here’s an idea of the philosophy:

  • Ruby needs a component-based web framework, to compete with the likes Tapestry, Seaside and WebObjects
  • Separation, composability and loose coupling of components are more important for agile application development, than rigid separation of View and Controller
  • Components have lives on the client-side as well as the server side, and the server-side needs to handle javascript and css includes, and the instantiation of client-side javascript objects, with the minimum of hassle. The client-side widget tree, in turn, needs to know how to update itself and manage its state.
  • Components take parameters. Components may be nested inside other components. Components may be requested on their own (an Ajax update?) or as part of a bigger component tree. This has big implications for the routing component of a framework.
  • Trying to adhere too religiously to what is typically a muddled interpretation of MVC, is often counter-productive
  • REST is wonderful for APIs, but it is the wrong paradigm for modular web application user interfaces in general. (It copes OK for a CRUD-style UI structure which is closely coupled to the data model, but this isn’t typical of more dynamic web applications in my experience)
  • The back button, and bookmarking, need to work!
  • It would be nice if Google can spider the application, in addition to DHTML clients

The good news is that I’ve found that it’s been relatively easy to get started on, thanks to some of the great tools the Ruby community already has available. I’m only reinventing the parts of the wheel that were creaking badly – for the rest, I’m relying on:

  • Haml (take the hour’s time to learn this, it’s really clean, and especially well suited to programmatic generation of small chunks of DOM tree)
  • Rack ontop of Mongrel
  • ActiveSupport
  • for the time being, ActiveRecord (this is due for the chop once I find something closer to the relational model, or heck, something which can do Class Table Inheritance in something resembling an elegant fashion)
  • Bits cheekily stolen from Merb. I was close to building this entirely ontop of Merb, but I ran into some nasty segfaults on Leopard, it didn’t seem to play well with ActiveSupport, its Router would have needed replacing, and Merb’s controllers, while more lightweight than rails, still got in the way of entirely component-based dispatch. But I’m still really impressed with Merb – It’s like Rails done right – leaner, faster, without the cruft, and with the benefit of hindsight. Easier to extend, too.)

Leave a Reply

You must be logged in to post a comment.