<XMLToday/>

Editor Note: This was first publishing Nov. 23, 2009.

And no. I'm not going to start out with "It was the best of times, it was the worst of times". But I will tell you what kind of time it was.

It was a big damn Gold Rush.

As gold rushes tend to do, it made a mess of a lot of things; some got rich and most didn't, and those who were already wealthy figured out how to take advantage of the situation. And there's one other major thing that gold rushes do: they tend to tilt balances.

What this one tilted was the balance between two concepts of the Web and how to use it, two bodies of thought, two models of what the Web is. One of these Webs was bolstered, promoted, sanctioned by standards bodies, lavishly funded. It achieved a lot, spawned great big powerful toolsets and frameworks, and won the great majority of mindshare. The other Web has been neglected, and its key capabilities poorly developed. The things it could be doing for us are weakly done, or going undone altogether.

Not only that, but the Gold Rush is pretty much worked out. The Web that won is mature, and has colonized all of the problem spaces it can (and some that it barely can, because it's there, and familiar). Nowadays, the interesting opportunities for advancing the art of Web Programming reside mostly on the Web that was starved.

But us? The practitioners of the art and science of Web Programming? We're still partying like it's 1849. Well,1999. Those interesting opportunities are still being neglected.

Trying to describe those opportunities, and their proper place in the scheme of Web Programming generally, is surprisingly difficult. The best approach I've come up with is to compare and contrast the two Webs, just to establish a framework of concept and terminology.

Process and Resource

I don't know how many "Webs" one could legitimately identify, coexisting within and atop the World Wide Web. Probably a lot of them. The two under discussion here are the Process Web and the Resource Web.

The Process Web is very Object-Oriented. Web Servers are conceptualized as encapsulated data stores, fronted by encapsulated business objects, which expose server-specific idiosyncratic methods (you may have heard of these; they're called "Web Services") for extracting or modifying data. In this model, information tends to be treated as property. This Web sees itself primarily as a mechanism for executing processes - mainly business processes, since that's the kind of entity that picks up the tab for most work. Its characteristic organizing principle is stateful SOA, and its architectural style favors SOAP over REST (although REST does operate well in the Process Web, courtesy of HTTP POST). Servers are active, and clients are usually designed to work with only a single server - in fact, in almost all cases the client is downloaded from the server and executed within the User Agent. Although the client initiates a transaction, the server remains responsible for session state. HTTP serves as little more than a transport layer.

The Resource Web is the Web of information access. This Web sees itself as a distributed architecture of information structures. Since it's about structure rather than process, there's not very much to encapsulate: servers are mostly passive, not active. Their job is to present information, rather than digest it and conduct complex back-end operations with it (in other words: information is treated more as a responsibility than as property). Idiosyncratic operations are the exception, since GET, PUT, and DELETE cover most necessary interactions with information resources (hey, if you ever need some flexibility, there's always POST.) The characteristic organizing principle of the Resource Web is hypermedia. The Resource Web's architectural praxis favors REST of course - SOAP cannot be invoked through hyperlinks, and Resource Web clients don't want to have to negotiate SOAP's one-off contractual protocols. Clients are usually much more powerful and autonomous than those in the Process Web, and they are wholly responsible for any required state persistence. The two most notable examples of Resource Web clients are the Browser itself, and the Web Crawler. HTTP, rather than being a transport utility, is the essence of the Resource Web.

There are two reasons that I've described the Process Web in terms of its characteristics, and the Resource Web much more in terms of how it deviates from Process Web ideas. First, the Process Web is very successful and well-understood, much more mature and fully formed in terms of praxis, tools, and concepts. By comparison, the Resource Web is not very clearly conceptualized. Second, the Process Web is what we think of when we say "Web Programming". It's the ordinary, the norm, the expected.

This predominance of the Process Web was laid down in that Gold Rush I was talking about.

The Gold Rush of 1999

In the late 1990s, the Web had reached a tipping point in technical maturity. A lot of client/server application developers suddenly noticed what it could do, and suddenly made the lunge. When we did, it changed the face of the Web, and the discipline of Web Programming, in ways that are still very much with us. I say "we" because I was one of that unmannerly horde.

My introduction to Web programming was less than ideal (although admittedly fun as hell). It was a very rapid port of a complex production client-server app to use the Web. I was working at one of those tiny start-ups in which the President was also the Lead Developer, and I was the Other Developer. We were accustomed to grueling workweeks (true story: one day we realized that we had only worked about 70 hours/week for two weeks in a row. My boss said, a little uneasily, "I don't know... maybe we should have a barbecue or something?") and insane levels of productivity. We ported the app in two months, and that two months included walking the learning curve of HTML-client programming. Doing it in two months was possible because the server didn't need many changes - mostly just needed an HTTP-based front end. Looking back, the number of gross fundamental errors we made is pretty humiliating; but we got it running, and after that experience I never looked back. I never wanted to write non-Web clients anymore.

I'm describing this, not because I think you will find it the story particularly interesting , but actually because I don't think you will. I think it was ordinary for that time. And it's the ordinariness that is the point: it's how we did, and, as things turned out, it's how we all still do.

Anyway: there we were, vigorous, well-funded, riding the Internet bubble to effervescent heights, and supported by an optimistic crop of new languages and server engines. And we brought our mindset with us. We saw the Web as a mechanism for executing Process, rather than a distributed architecture of Resource access.

Consider these characteristics of the Gold Rush:

• Client/server thinking and architecture made the jump with us. Developers switched directly from client-server programming to Web Programming, mainly treating the Web as just a better way to build clients. Not better in terms of capability - clearly, a desktop Java or VB or Delphi client could run rings around early primitive browserhack clients in terms of functionality and power - but better because you didn't have to update the installed desktop client whenever you wanted to fix a bug or add a feature. At one stroke, one of the biggest headaches of client-server programming just went away. The clients were thinner and messier, but that was a tiny price to pay. The back end was still SQL RDBMS with OO program logic, and that combination was easily powerful enough to take up the slack. The client-server paradigm still worked, and we were deeply grateful that it did, and that became the only kind of Web Programming that we ever did.
• When we made the switch, most of us did it in a big damn hurry. In other words, we hacked anything and everything. Our focus was not on published specifications (particularly HTTP) at all. It was on using whatever worked in the browser du jour (and this was during the Browser wars, so things were a right mess.) These implementations were partial - still are, dammit - and tended to be wrong. We didn't care. We just needed to make things work.
• The HTML was so ugly. We didn't use XML at all, or even think about it. Markup was there to make the browser show some things and do some things. The entire concept of structured content was irrelevant.
• Javascript was there to paper over the cracks. It was more or less mature and capable, and let us build some active behavior into the interface. Without Javascript, the thin and dorky Web clients we managed to cobble together would probably have been rejected by the users. It also gave all of us a tolerable substitute for the desktop OO languages, further reinforcing the client-server model.
• More than anything, O.O.R.E.A.M. ("Object Orientation Rules Everything Around Me".) Fresh off the introduction of Java (which avoided many of the offputting features of C++) and the publication of the Gang of Four's excellent advice on how not to screw up at the design level, we thought we had all of the principal answers. We were pretty strongly of the opinion that OO was the only way to build any nontrivial application. To the extent that other paradigms had any sort of toehold in the web space, we replaced that with the bland assumption that Web Programming could, should, and would consist largely of distributed objects. These objects would conduct well-behaved conversations and transactions. It was pretty obvious.

After the Gold Rush

In the subsequent decade, Web Programming has exploded as a discipline. Better standards, more reasonable Browser implementations, the intensely welcome (well, at least for some of us) rise of XML and its attendant technologies, SOAP/WSDL, SOA, the huge proliferation of Web-bound application frameworks, the proliferation of Web Programming languages (PHP, Java 1.4+, .NET, Python, Ruby), large expressive datamodels like the NIEM, the emergence of AJAX and its many imitators so we can write clients that are vastly more powerful than anything we could do at the beginning... Just writing that sentence, I'm taken aback by how much has been done, and how quickly it came about. 10 years.

And yet, even given the startling advances, it's easy to see that Web Programming still has much of the basic Process Web shape that we client-server developers put on it in the late 90s:

• Client/server architecture still governs most everybody's thinking about Web Programming.
• Program flow and logic still reside on the Server. Clients, even powerful AJAX-enabled clients, remain mostly in the business of invoking serverside logic; and a client is usually the wholly owned subsidiary of the server.
• Encapsulated objects working against hidden data, exposing nothing but SOA-style Services, is still the way Web Programmers manage a lot of information on the Web.
• Although XML has emerged as the preferred representation of data in Web Programming, it's mostly used for message interfaces in distributed processes. (HTML is better now, but not nearly as good as XML; and the HTML5 standards body seems to accept weakly formed markup as an inevitability.)
• Javascript continues to dominate browser-side coding, and looks like it will continue to do so.

In short, the Process Web is firmly in the saddle. Its thinking and paradigms have pretty much prevailed. It's what we think of, when we think of Web Programming.

And you know? That approach has been awfully practical, and made an awful lot of us pretty comfortable. Certainly it's been a benefit for the deep-pocket enterprises, because their most eminent needs (or at least, the needs they best understand, which is kind of an interesting distinction) are process-type needs: complex message patterns, transactions, stateful distributed interactions, one-off contractual information interchanges. The ability to extend business operations across the Web has certainly worked out well for the enterprise, and for those of us who get hired to do their work.

Now, don't get me wrong: this wasn't a bad design decision. In many respects, for many purposes, the Process Web remains an ideal way to conduct the business of enterprise Web Application development. Even setting aside its huge advantage in mindshare, the substantive benefits of this kind of thinking and building are considerable. It solved the remote object problem (something that CORBA and COM and even Java RMI couldn't do very effectively.) And that was a necessary solution. In general, the more complicated the business problem, the better Object-Oriented Analysis and Design looks.

So What's Wrong with Process Web?

Nothing. As I said, it works great in a lot of ways. And although it would probably be fun to deliberately throw a provocation or two, I'm not going to misrepresent these concepts just to stir the pot.

I'm not complaining about the Process Web. What I am criticizing here is the predominance of Process Web praxis and paradigms, without any countervailing support for the way the Resource Web does business.

Nor, by the way, am I saying that the Resource Web is always a better way to go about solving problems. Clearly it's not. In the end, I am trying to argue two things:

1. Both of these Webs are tremendous assets in the information world.
2. We will be hard pressed to make good decisions about which Web to use as long as the Resource Web remains underdeveloped and underrepresented in our professional work.

It's a hard case to make. Web Programming is so flexible that we can accomplish a lot (and often earn more than we actually accomplish </snark>) by misusing the tools that we know. And so there are lots of professionals ready to jump up and down and pound on the table to try to forestall any moves in the direction of unfamiliar technologies or thinking. (Upton Sinclair: "It is difficult to get a man to understand something, when his salary depends upon his not understanding it!")

This post has already gone long enough, and contains a fair amount to chew on. Later posts in the series will look at the different problem spaces the Resource Web is good for, and different actual programming practices and designs that can help us dig in and get something done.

SPOILER ALERT: It's gonna have a lot to do with XRX.