BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News DHH Responds to Stateful Web Applications Row

DHH Responds to Stateful Web Applications Row

Bookmarks

In the wake of the Giles Bowkett's article questioning the real technical innovation of Ruby on Rails, Mike Pence published an interview with Avi Bryant, the creator of the web framework Seaside, explaining how his positive experiences with Apple's WebObjects led him to advocate for a stateful component model approach in web development. According to Avi, current web development tools, including Ruby on Rails, are not ready for the future desktop-like web applications. Three Seaside design choices were presented to demonstrate that such a model improves modularity, therefore reusability and maintenability:

  • HTTP used as simple RPC layer (unlike REST meaningful URL's) throws away the page as a unit in favor of higher level components.
  • components are even more DRY (Don't Repeat Yourself) than Rails' partials.
  • programmatic HTML generation is more flexible than template files and doesn't no violate the sacrosanct MVC pattern if CSS style sheets are properly leveraged.

Avi Bryant also answers why Seaside is implemented in Smalltalk instead of Ruby:

To me, there was just so much more excitement and energy coming from that world [Smalltalk], and there was clearly a much deeper and richer history with object technology and dynamic language implementations. [...] 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.

In his interview article, Mike Pence retorts that the limited user base of Smalltalk, the Smalltalk language itself and small developer community could be a brake to Seaside's expansion. Avi argues that:

  • old criticisms of the Strongtalk VM (e.g garbage collection or byte code) are now functionalities in the Java VM
  • "mainstream object-oriented programming is getting closer and closer to Smalltalk every year."
  • the size of a community is not a problem as long as it has the right members

Asked about the growing Ruby popularity, Avi points out its lack of a modern virtual machine and claims that Ruby's VM technology is 10 to 15 years behind Smalltalk's. But instead of scoffing at Ruby, Avi calls for a bridge to be built between Ruby and Smalltalk:

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. (...) 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.
Of course, the conversation then moves to JRuby. Avi is more than sceptical about JRuby's performance, even in the long run, because the Java VM has not enough support for dynamic languages. Once again he pleads for running Ruby on top of Strongtalk, a virtual machine designed for a dynamic language. In conclusion, Avi Bryants restates his motto: there are other of ways of doing things.

 

To get a Rails perspective on the controversy, InfoQ caught up with the creator of Ruby on Rails, David Heinemeier Hansson to share his views on Smalltalk, Seaside and the Avi Bryant's opinions.

First of all, what's your Smalltalk background? Are your familiar with the Seaside framework created by Avi Bryant?

I've merely dabbled with Smalltalk, never used it for a real application. But I've learned a fair bit about object-oriented programming by reading the works of various Smalltalkers. Most importantly Smalltalk: Best Practices by Kent Beck.

I've been following Seaside since the beginning. Avi is a smart cookie and it's been a joy to witness his defiance of traditional web application approaches. I don't have to agree with the choices made in Seaside to respect neither it nor him.

Avi argues that Smalltalk is as rich as Ruby and even more mature (e.g. the VM). When you started implementing the Rails framework, did you choose Ruby over Smalltalk or any other langages? If yes, why?

To me, Ruby was just a better fit. It felt like a more pragmatic choice. A language that choose to live in the world already here rather than to invent its own. It seemed to cherry pick many of the best features from Smalltalk without requiring you to jettison everything else you already knew. It was more evolution than revolution.

Additionally, I strongly preferred the Ruby aesthetics. Smalltalk is by no means an ugly language. And it's one that I greatly respect. It just didn't fit my brain the way Ruby does. No harm in that. That's why we have all these wonderful languages. Some just click better than others for different people.

In many ways, I see Rails relating to Seaside as Ruby relates to Smalltalk. Rails is more evolution and polish than revolution and rebellion.

Avi Bryant "throws away" meaningful URL's, arguing that HTTP should be use as an RPC layer managed by the framework itself. But his real point is that stateless applications do not leverage the modularity offered by a stateful component model. So even if it's clear that Rails 1.2. is embracing REST, do you think RoR would benefit from a stateful component model?

I guess it depends on the kind of applications you're working on and what your aspirations are. I don't wish for the web to be a perfect copy of the desktop. I actually prefer the web in most instances. Thus, I'm not of the opinion development of web applications would be bliss if only it was more like desktop applications. Including the focus on stateful components.

I'm also not a big fan of high-level components as the nirvana of reuse. I tend to see high-level components as something to chase when development is painful. When there's no way to escape boiler-plate duplication. I'm simply not feeling those pains working with Rails.

But in some ways it's also just a different architectural approach, which obviously appeals to some people. That's great. We don't all have to build web applications in the same way. Actually, it would be rather dull if we did.

Do you simply not recommend Rails for highly stateful applications? Do you even not recommend "stateful" at all, aside from performance considerations?

I don't think we have a useful enough definition of what a "highly stateful application" is to decide whether Rails is a good fit for that or not. I know that I often create sections in web applications that have some kind of state, but I choose to store it on the client side in form of HTML rather than on the server side in a session.

But as I said earlier, that's also due to my perception that web applications are not inferior to desktop applications. They're just different. I'm not trying to aspire to desktop applications as some sort of ideal. Once you stop that inferiority complex, I think you'll start to appreciate the so-called limitations of the web as liberating factors.

There is no doubt that Rails is a major breakthrought in web development, but do you think Rails is ready and suitable for the "next desktop-like web user interfaces"? Avi doesn't think so, and claims that some revolutions should happen to take up such challenges.

Again, this hinges on the assumption that all web developers really want to be desktop developers and that all web applications would be better if only they were more like their desktop counterparts. I don't accept that assumption. I love working with the web as it is. I love the architectural patterns offered by HTTP and REST.

So in many ways, I see chasing a desktop-like view of the web as chasing the past, not the future. Dividing different architectural styles into past/future doesn't seem to be a terribly helpful tool for evaluating their usefulness. It does help journalists write VS stories more easily, though :).

But sure, there's a certain class of applications that undoubtedly fit better with a desktop-like approach and will benefit from an application framework that tries to bring that feeling to the web. I don't see it being all that prevalent, though. But that's perhaps merely informed by the fact that I personally don't work on that type of applications and have no intentions to.

With Rails, I'm merely trying to improve my own situation working on my own applications. There's no guarantee that the result will map to your particular situation. It seems as though it does map to quite a few developer's situation, though. Considering the take up so far.

I don't see it as an either or, however. The web is wonderful enough to allow many architectural patterns. And even though I really like the patterns promoted by the HTTP protocol and the REST approach, I don't think Avi is doing something bad by choosing a different path. He's simply using HTTP as an underlying protocol for a different approach. How nice that HTTP can be bend and repurposed like that.

Obviously David is not worried about the future of Rails and the current web development model. He feels no urges to reinvent. Choice is a good thing, and Avi's views are welcome.

However is it not too late for Seaside and Smalltalk? The fast-pace growing popularity of Ruby and Rails, the massive investments and support of big companies like Sun in Ruby are huge obstacles to overcome. No matter how great and fast would be Ruby on top of Smalltalk. Are there actually any volunteers for implementing SRuby?

Rate this Article

Adoption
Style

BT