Bill Katz

30,000 feet view but occasionally we’ll drop down to earth.

Java and J2EE

Described as heavier than it needs to be, even by some of its advocates.

Although the argument usually moves to an enterprise-level versus prototype tool debate, I think enterprise-level reliability, if you choose an appropriate modern language, is more a function of maturity because all these languages are pretty good. PHP is being used in larger & larger web sites, and we have companies that will help that push.

Python and Zope X3

Although the Python world has a bunch of template languages for accessing data from views, embedding Python is more problematic because of the whitespace constraints. (Spaces at the beginning of lines are used to mark structure in Python code.)

Zope X3 was very tempting. It would have made two Writertopia features easier to implement: (1) Microsoft Word integration through OpenOffice.org UNO, and (2) subversion and CVS bindings. Plone 2 is a great, award-winning CMS built on Zope 2, and the developers may move it to Zope 3. Zope X3 features of interest to me include a deep security system, the integrated ZODB, and the fact that the entire underbelly of Zope X3, the Zope Server components, could be replaced by something as powerful as the Twisted framework. Zope X3 is a powerful framework that requires more of a learning curve and more code than Rails.

Kevin Dangoor decided on Python, and he has an interesting discussion on why he made this choice. Since I’ve only glanced at Python, both Ruby and Python pose the same small hurdle, and regarding community size, I have great faith in the ability of small numbers of excellent programmers to produce extensive frameworks. Call it the Jeff Bezos two pizza rule or the recognition that quality programming doesn’t scale. It doesn’t hurt hearing that folks like Martin Fowler and Dave Thomas love Ruby. If a required feature isn’t available in Ruby, e.g. the ability to easily convert Microsoft Word docs into web-friendly XML or viewable XHTML through OpenOffice UNO, I think I can call a separate app that handles that function. Worst case scenario, for me, is going back to C or C++ to hook that function in.

Seaside

Seaside is yet another interesting web framework, this one using Smalltalk. (This paper should be required reading to web developers, if just to open up new ways of thinking.) Its distinguishing feature is how it simplifies the programmers view of the interaction between user and web application. It abstracts away the page-centric mindset and lets you program the control logic of a component in one block, even if multiple “pages” are involved. For example, the entire control flow for a shopping cart can be modelled by a single method, from filling & confirming a cart to supplying addresses & payment information. It automagically handles all the problems that crop up with a web-based GUI. The session ID, in this context, is an unchanging identifier of your web thread or process.

When reading the paper, I ran across a Smalltalk routine that generated XHTML programmatically. My initial reaction was negative: doesn’t this put design work on the programmer’s doorstep, not the designer? So much for my Macromedia Dreamweaver. After reading on, though, I realized that generation of XHTML isn’t really design work. If done in a very web-standards way, the XHTML should simply define the content you want the user to see. The real design work is all through the CSS stylesheets, and Seaside’s development environment does provide an easy way of modifying those styles.

The development environment for Seaside looks great. There’s a nice interplay between the debugger and the web browser’s view. You can modify code without restarting the application. In development mode, “halos” surround each component, allowing you to drill down into the code or tune the CSS rendering.

I didn’t give Seaside the attention it deserved because of a few red flags that came up:

1) This is a great mousetrap, but what about the computational burden? The continuations (some of the the magic that makes Seaside go) reside in memory and there could be a scaling issue. A session should always be directed to the same server. The one nice thing about stateless HTTP communication is its ability to be redirected to different servers with each new request, depending on how you design your web app.

2) It’s in Smalltalk. Since I’m going with Ruby on Rails, I can’t say I’m averse to trying languages off the beaten path, but Ruby has momentum and a lot of people are beating down its path even as you read this long blog entry. Smalltalk? All the objections I counter when discussing Ruby have to be answered in duplicate here, although this could very well be just my ignorance of the state of the Smalltalk community.

3) It seems that the things Seaside does well may not be the things I need optimal solutions for. Writertopia needs to be simple to use, and although multiple control flows on a page seem like a good idea, I couldn’t think of my need for it when looking at my prototype. Maybe the constraints of traditional web apps have put blinders on me, so I’m going to think about this some more. Other Seaside benefits like handling backtracking should be approachable in Rails.

4) This may be superficial of me but if the Seaside home page had the slick PR, videos, and clear momentum of Rails, I’d worry less about the above questions; I’d think it more likely that people smarter than I would have bailed once they discovered the problems. Then again, maybe I’m not ready for Smalltalk and given the relative lack of documentation on Seaside, I’m just looking for excuses :)

RAILS

Jumping into Rails development is a bit like jumping onto a moving train, at least with the pre-1.0 momentum its gaining. It seems like every 3 or 4 weeks there’s a slew of modifications to the three packages: Rails, Active Record, and Action Pack. Developers keep fixing, simplifying, then adding to the framework.