DHH Responds to Stateful Web Applications Row
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.
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?
Rich Internet Apps + REST
RIAs will become the norm and frameworks that abstract HTML/JS for a richer developer experience will replace existing ones. I expect REST style services to be the backbone for these RIAs and frameworks.
Smalltalk.rb and Rubinius
but the effort seems to have fallen asleep.
Frankly, the whole Ruby on Strongtalk effort has the big problem of relying on a creaking, ancient code base that isn't really maintained and Windows only. Strongtalk might have impressive benchmark figures,
but that's the only thing it has going for it right now, unless someone brings it up to shape, makes it available on other platforms, ports the Ruby standard lib to it, etc etc.
Ryan Davis started some work on a Ruby2Smalltalk - see the last comment for this post:
but I haven't heard much about this yet. He used ParseTree and the accompanying s-expr tools for this,
which solve the whole business of getting a nice AST from Ruby code. I don't know which Smalltalk he wanted to target - Squeak is probably the only real option (and it can get fast using Exupery, a Smalltalk JIT).
I guess the most promising effort on getting a Smalltalk-ish Ruby implementation is Rubinius, which takes its design ideas from Squeak Smalltalk (a selfhosting Smalltalk).
Is that not similar to the question we asked about Rails a year ago, saying it couldn't make in-roads against J2EE and so on with all the big backing that had?
Not Actually Such A Huge Rails Critic
A bit of perspective on my blog:
Regarding MRI speed (slightly OT)
What is it that Lua guys did right that Ruby community is having such a hard time with? I say this because there are so many implementations and the main reason for most, except perhaps for JRuby is the speed and age of Matz' Interpreter. Is it because most people attracted to Ruby just don't want to deal with C or any "portable assembler" kind of languages? or is it that Ruby just doesn't have the critical mass of low level language implementation experts?
Just wondering out loud here.
Re: Not Actually Such A Huge Rails Critic
"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."
I have no beef with Smalltalk (nor with Rails). I echo DHH's sentiments that this is not an either-or, and I am interested in seeing how Rails and stateful components could play together.
Re: Not Actually Such A Huge Rails Critic
don't get me wrong. My article is a summary note of yours. As such I do my best to not alter tone and opinions.
By the way I don't see any violent criticisms of Rails in both your articles.
And James Robertson seems to agree:
It's a reasonable, balanced discussion, with a lot of mutual respect. Well worth reading.
My point is absolutely not to engage any fruitless debates between two great innovative ideas, and I bet it's not yours too.
Re: Regarding MRI speed (slightly OT)
Re: Regarding MRI speed (slightly OT)