caboose

The rich web user interfaces of tomorrow will look, and act, like the desktop applications of yesterday, but the web programming tools that are currently in vogue, including Ruby on Rails, are ill-equipped to provide such rich modes of interaction. "A lot of web development, right now, gets done with practices that were good trade-offs 10 years ago," said Avi Bryant, creator of the Smalltalk-based Seaside web framework. "It is really important that we take a very critical look at those practices, and decide whether there might be better ways of doing things."

Talk of better ways of programming is abundant on the web, and often gets cast in the light of religious debate. But unlike religion, there is proof to be had in the realm of developer tools – proof in the form of the products they produce. Avi Bryant's Dabble DB, written in Seaside, stands as a shining example of a how a browser-based app can look and feel every bit as rich as a desktop program.

I spoke with Avi recently about the birth of Seaside and the state of web development. He shared with me the beauty of Smalltalk and the value of micro-communities. We talked about how the path to success often lies against the grain of industry groupthink, and where things seem to be going wrong: the problems with REST, how MVC is widely misunderstood, why JRuby lacks promise, and what's wrong with Ruby on Rails.

Much of the inspiration for Avi's work lies with WebObjects, another child of the pioneering work done at NeXT prior to its merger with Apple. WebObjects eschewed the HTML-centric, page-oriented mindset for a thoroughly object-oriented approach, where user interfaces are composed of stateful objects that send messages to each other based on user-generated events. "Apple's WebObjects was the first thing that I had seen that did things radically differently. It had this much richer notion of how you were processing events. It didn't explicitly deal with HTTP requests -- you would define callbacks, as you would in a desktop widget framework, and it figured out which of your methods got triggered when you clicked on a link or typed something into a form. It threw away the page as a unit of modularity and broke things down into components," said Avi.

This fundamental change in approach to web development means that the core HTTP request/response cycle provides a message passing mechanism, an RPC layer akin to REST, but managed automatically within the framework. So, the URL's and form input names, rather than being meticulously managed by the programmer, become tools that the framework uses to identify stateful context and map user interface events to method invocations on server-side objects. "There is an impedance mismatch between the REST approach to web development -- thinking that all of your URL's need to be meaningful, all of your form input names have to be meaningful, that every page in your application is presenting this external API -- between that and a [stateful] component model," said Avi. "I think it is very hard to have both. With Seaside I made a conscious decision that we were going to throw away meaningful URL's and, in return, get components."

While some programmers obsess over clean URL's, users are not phased over a few extra characters at the end of a URL in their browser's address bar. "I have not had one single person ever mention in Dabble DB that the URL's look funny. People are used to it. If you go to Amazon.com, the URL's have all kinds of opaque identifiers in them. It is just not something that the average user cares about. I think it becomes an obsession for developers to have this sense of having a clean API exposed by their web application, but I think you can have a clean API that does not have to include every single page in your app, and I don't think that every single page in your app has to be bookmarkable. I think that as long as a bookmark gets you back, roughly, to where you wanted to be, or for really crucial things to have permalinks, then you are fine."

When WebObjects was slated to move from Objective-C to Java, Avi saw the need to have the power of its component model married to a more dynamic language. "I have been interested in Ruby since late 2000 or so, and built a little framework in Ruby called Iowa. I think it was the first web framework done in Ruby, and I gave a talk on it at the first Ruby conference. At the same time and place as the Ruby conference, I was giving a talk at OOPSLA. That was the first time that I was exposed to Smalltalk and Squeak. OOPSLA had originally been a Smalltalk-centric conference, and even though the mainstream culture had shifted to Java and C# at the time, the Smalltalk people just kind of kept coming. Rather than participating in the mainstream conference, they setup in the hall with a projector and did some informal showing-off of their cool stuff."

"To me, there was just so much more excitement and energy coming from that world, and there was clearly a much deeper and richer history with object technology and dynamic language implementations -- it really sucked me in. So I started looking at what it would take to port the work I had been doing in Ruby over to Smalltalk. A lot of what I had loved about Ruby, and about Objective-C before that, had come out of Smalltalk. Once I started working in Smalltalk, I never found any reason to go back."

Was he concerned that Smalltalk, for all of its technical merits, seemed to be relegated to the province of a few very smart men with excessive facial hair? "Not really," said Avi. "I was looking for the thing that was going to be make me the most productive. I was heavily influenced by Paul Graham's old essays on building Viaweb, like Beating the Averages (http://www.paulgraham.com/avg.html), where he described using Lisp at a time when no one else was using Lisp, and he kept very quiet about it. You will find that Smalltalkers tend to do this as well. From his point of view, it was a competitive advantage that he was using this thing that no one else used, and that was really how I was seeing it when I started using Smalltalk. I could tell that this stuff was great. I could tell that this stuff has had a profound influence on all of the things in software development that I have an interest in."

"Extreme programming, Agile development and object-oriented programming -- all came out of the Smalltalk world. The refactoring browser and the notion of an IDE, as we are used to it now -- a lot of these things came out of, and are still, frankly, better in the Smalltalk world. There is such a rich experience there. The old graybeards in the Smalltalk world may not seem relevant, but if you ask them a question about ORM, they have been thinking about it for 20 years. Everyone else has only been thinking about it, maybe, for ten. There is such a wealth there to draw from that the fact that the community is small did not seem like a disadvantage to me at all. Often small communities with the right people can function better than large communities."

Nor, he feels, does building a technology base on Smalltalk mean compromising your ability to expand into the future. Despite its limited user base, Avi said, "I would argue that over the last ten years Smalltalk's influence has massively increased. If you look back at when Smalltalk was more in the public eye, the arguments were between Smalltalk and C++. The arguments were, from the C++ side:

Garbage collection? That's ridiculous. You can never write anything real that is garbage-collected.

Byte code? That is silly. You need to be compiling to assembler.

Just-in-time compilation? Give me a break. That will never be fast enough.

Pure object-orientation? Everything is an object? Yeah, right.

"Then, moving forward, each of these objections has gone away as [the functionality] has become a part of the mainstream. If you look at the Java VM today, it was adapted from the then-commercial Strongtalk VM. These technologies that came out of Smalltalk, that used to be considered a liability, are now just accepted. With Ruby rising in popularity, Smalltalk is continuing to gain influence indirectly. You can see that mainstream object-oriented programming is getting closer and closer to Smalltalk every year."

"I can see that Ruby is the direction that things are going. The one thing that Ruby is missing that Java and Smalltalk have is a modern VM implementation. Smalltalk VM's 10 to 15 years ago were way better -- and have continued get better -- than the Ruby interpreter is now, and that is a shame. How much of the language has to be implemented in C has an effect on how you can use the language, how performant the language is, and what tasks people think it is appropriate for. If we could see Ruby using some of the technology that Smalltalk has to make it a little more performant, a little more turtles-all-the-way-down -- in the sense of having much more of the language implemented at the Ruby level -- then I think that would be a huge win. And I think it is really easy. I mean, I think that it is almost a uniquely easy situation in that Ruby and Smalltalk, at the language level, are really identical. It is just a matter of libraries and syntax. All of the Smalltalk technology should be directly usable by Ruby, if someone takes the time to do it."

So, what about JRuby? "I don't think JRuby is very promising, because JRuby is never going to perform very well. I realize that the people who work on JRuby differ with me on this, but if you ask someone like Gilad Bracha, who was recently at Sun until he left to do a Smalltalk project, he'll tell you that the VM support just isn't there to make dynamic languages go fast. Strongtalk, which is very similar to the Java VM in other ways, doesn't have those restrictions. There is no question in my mind that Ruby running on top of Strongtalk would be able to massively outperform anything JRuby could ever do."

Bracha, formerly a Distinguished Engineer at Sun Microsystems and a co-maintainer and co-author of the JVM Specification, told me in an email that "Avi is absolutely right."

Charles Nutter, one of the JRuby core developers, admitted that the current bytecode layer is "in the way," but stipulated that a high performance JRuby "is nowhere near impossible. Future work on dynamic-language support in the JVM will likely make the process easier."

"I remember a time when a lot of very smart people were saying how Java could never be made to run fast," said Tim Bray, Sun's Director of Web Technologies and a major contributor to the XML and Atom specifications. "Ruby's going to be harder to make go fast than a lot of other dynamic languages. There's no free lunch; you gotta pay for open classes and other such goodies." Bray, who knows Avi well and is an investor in Dabble DB, said, "We think that JRuby will be as fast as, or faster than, CRuby."

At whatever speed, Ruby on Rails remains a focal point for web development innovation, and could benefit greatly from the addition of a stateful component model and looser coupling between layers. "Rails," said Avi, "talks a lot about DRY (Don't Repeat Yourself), and I think that there is a very narrow way in which that is interpreted. There are ways in which Rails is good at not repeating itself, but there are lots of ways in which Rails is horrible about repeating itself constantly: You have to use the name of a URL query parameter all over the place, in your templates and controllers, and you have to worry about what your URL namespace is from lots of different parts of the code. If you have got a piece of functionality that you want to use in multiple parts of your application, it is very difficult to do. I know there are partials, but ultimately there is no stateful component model that would let you modularize things to the point that you could reuse them, and not repeat them."

Thinking in components means inverting the practice of page-first template development in favor of components that emit their own markup. There is certainly nothing in Rails that prevents you from doing that on your own, but it is not the central model for Rails development. In fact, many developers mistakenly think that this would violate that Holiest of patterns, MVC. "There was a mindset for a long time that to have proper model-view separation, you needed to have the HTML in a template file that was modified by the designer that was linked in various ways to the code. You had your objects, you had your HTML template, and then you had a binding file that described how they are related to each other. Different vendors did that in different ways, but Seaside throws that away too, and says, 'No, we are going to have programmatic HTML generation. Each component is just going to be given a canvas and is going to spit out its own HTML, using that API.'"

"In the world of CSS, I would argue that that is the right way of doing things. We as developers should be putting out very bare-bones semantic HTML as much as possible. The job of the component is to display itself semantically, and it is the job of a good web designer to do the CSS to make that look good. We have had great experiences with that workflow [at Dabble DB]. Our web designer never touches a single line of HTML, and yet has total control over what the application looks like."

With a stateful component model, you don't focus on serializing and de-serializing parameters, or manually constructing and de-constructing state. You build with bigger blocks at a higher level of abstraction. "The degrees to which a stateful component system increases the modularity, and thus the maintainability, of your code base is huge. That means that the richness and sophistication of the applications you can build goes way up. There is just no way that we could have built something with the complexity of Dabble -- at least I couldn't have -- with a kind of stateless, REST-ful style of web framework."

"That components are not more widely used in web frameworks is something of a historical artifact. There are no longer any good reasons for it, even if there once were. Just as it used to be that Real Programmers would scoff at automatic garbage collection and bytecode languages, Real Web Programmers today scoff at stateful, in-memory sessions and generated URL's. Five years from now, I think things may be a little different."

Beyond traditional, page-oriented web development, Avi said, "there are other ways of doing things. They have trade-offs, but these days the trade-offs are less of a big deal than they might have been 10 years ago. So, it is time to start looking at those ideas again."

Mike Pence was a presenter at the first international Rails conference. He provides consulting services, focused on creating rich web interfaces with Ruby on Rails, from Boca Raton, FL. He can be reached via his blog and at mike.pence@gmail.com.