Adjusting to the Web was hard. I first came to the Web from HyperCard, so I remember looking at the Web and thinking "wow, this does a lot less hypertext than I'm used to." It took some substantial adjustment to get over that, and in some ways I'm still rebuilding the toolkit I had in HyperCard.

After I had adapted to the Web's implications for my hypertext projects, I realized that the Web had unpleasant implications for a group of developers with very different interests from mine. Client-server developers found themselves seething over the limitations of the Web as their programs and approaches were abruptly dumped by companies who saw promise and cheap software in replacing expensive custom clients with Web-browser front-ends.

The client-server people, who after all represented a much more mainstream set of programming understandings, weren't entirely cut out, as there was still plenty of work to do on the server side, and middleware continued to explode as a category. The Web quite neatly slashed the explicit bonds between the back-end data stores and the front-end client, forcing them to "make do" with interfaces that weren't nearly up to early standards and an approach that delivered information to the client, not a detailed understanding of what to do with it.

The Web really was (and perhaps still is) different. HTML has been, pretty much from the beginning, a means of conveying information. Instead of facilitating, say, function calls across networks, HTML facilitated the presentation of information in fairly large chunks connected by hyperlinks. The HTTP infrastructure was built around those assumptions from the beginning, evolving over time to support optimizations like caching and greater interaction with users.

"Less is more" still doesn't go over well with a large sector of the development community, especially when it comes to separating information from instructions for processing it. While markup-centric communities, whether HTML, SGML, or XML, focus on separating content from presentation and processing, this separation is quite alien to a lot of programming practice, notably object-oriented development. Markup and OOP have very different notions of flexible reuse and graceful degradation.

It's plain that practitioners of the programming practices so gracelessly evicted by the Web now think they've learned enough from the Web to have ambitions of the same kind of success. While they reuse Web infrastructure and even Web consortia, they have little patience for "fairy tails" of Web practice that might get in their way.

Reusing Web infrastructure gives Web Services access to widely-deployed, well-understood, and often sophisticated network libraries, letting its advocates claim that it's cheap. In the meantime, questions about the appropriateness of the toolkit they're proposing, both in general and specifically in relation to how well or poorly it fits on the Web are shoved aside because "everybody's doing it."

I guess that's progress of a sort, for all those oppressed programmers who can't bear to represent their information separately from their plans for processing it. A lot of the Web Services visions I'm hearing lately sound a lot like client-server, circa 1994.