A trip down the AJAX memory lane
Warning: This post is extremely self-congratulatory.
The recent IBM developerWorks thread on revising Domino's handling of HTML generation has me thinking about an evening I spent with a laptop and a bottle of chardonnay almost four years ago. It was during part of the "dark years" for Lotus' product line -- when all the buzz was about switching to J2EE platforms and it seemed like those of us in the DominoSphere were going to be out of a job in a few months. I was working at a client looking to shift from Domino to Websphere on several major projects, and was continuously frustrated by the fact that these new platforms simply weren't delivering any NEW value. So I sat down one night and came up with an idea on how Lotus could leapfrog the competition by making the Domino server able to deliver a powerful client-oriented browser application experience.
Little did I know that I was talking about AJAX. Oh, nobody CALLED it AJAX then, of course. I'm not sure "Web 2.0" had been coined either. But having worked on some extremely complex application designs for browsers, I knew that what I was thinking of what a way to combine DHTML & XML and push more of the evaluative intelligence to the browser -- just like AJAX designers are doing now. And I knew that the model of only moving presentation & logic down the wire when necessary, and trying to move data alone for transactions, was what Notes itself ALREADY DID.
So, now that Web 2.0 is all the buzz, I thought I'd go dig out what I said in Sep 2002, and see how much it matches up with what people are trying to do. It's not perfect. And it was clearly written with more passion than forethought. But I'll stand behind the point of it just as much today as then, and point the fine folks at IBM to these ideas once again as a way to address their latest challenges. Maybe in the Domino community have already done just that on their own.
From 28 Sep 2002...
I love the Notes/Domino platform. I just want to be clear on that, because sometimes I catch heat about being too hard on Lotus. It's a tough love, I suppose. I can't really hug a division of IBM. I can give them an occasional pat on the back, but it's just not the same. Like a parent scolding her child in the grocery store, observers only see the negative feedback, and miss out on the smiles and laughter on all the other aisles. So let me be very clear: I love Notes -- and I owe its creators more than I'll ever be able to repay.
Now that that's out of the way, on to the spanking. (Insert Monty Python reference here.)
I'm really worried that IBM's missing the boat. I've been publically critical about the whole Garnet/WebSphere thing for quite some time, so my concerns in this arena are pretty widely known. Indeed, addressing those concerns was a major motive in the start of this site. But even if JSP and servlet support were delivered in the most beautifully engineered and integrated package that any of us could hope for, and it was free, and had an instant learning curve, and could run efficiently on a 286, I'd still feel like IBM was missing the boat. They would just have a really kick-ass canoe.
The problem with the entire J2EE initiative -- and to be inclusive, .NET, too -- is that it focuses on the wrong problem. It focuses on building bigger and better web services farms, componentizing the hell out of everything (a programming model with a long and dubious history, we should note) and providing beautiful diagrams of the separation of presentation from logic from data. By trumpeting standards, it chases the integration brass ring. We all hear about best-of-breed tools and "n-tier architecture." CIOs look at pretty graphs and rearrange entire departments in response. Developers claw each others' eyes out in ASP vs. JSP and Java vs. C# throw-downs.
I say it's all trivial.
The real sea change isn't to be found in the back office. We've been building systems to integrate disparate data sources for web delivery for years. Getting real-time inventory data is not a technical challenge -- it's a business process challenge. Building the data link is a no-brainer compared to the effort of keeping it up to date, and there's nothing about J2EE or .NET that makes it easier to convince a warehouse manager to take daily inventories, except maybe cheaper bar-scan devices. Bringing out new technology to cut $3 million projects to $1.5 million projects is not a revolution. Cutting costs and cycles by 50% is good and important and ultimately... boring.
The revolution is in the bandwidth. More specifically, it's in finding ways to more effectively produce a positive and consistent user experience without consuming absurd amounts of bandwidth. And it's here that the latest and greatest web services strategies from the leading enterprise software vendors provide, well, nothing. In the end, they generate HTML and send it over the wire.
They're widely compatible, marginally innovative. Big whoop.
I want to see the new technology that changes the user's experience. Not by providing them with real-time inventory data, but by being 5 times faster, 10 times more responsive and available from anything from a web-enabled watch to a Beowulf cluster on an OC-196. And at this point, that can only come from one thing: a smarter client.
Browsers suck. Anyone who's ever built a web site can tell you that. We accept them, because they're everywhere and they do a lot of useful things and they don't really require much training and everyone's grandma understands anchor links and input boxes at this point. But they still suck. They have poor interoperability, they're riddled with bugs, they're hard to upgrade, they have lousy security models, and worst of all, they're really dumb.
Being stuck with dumb browsers leads to two basic approaches to complex user experiences on web sites. Developers either 1) write huge amounts of version-branching DHTML code that's drenched in string parsing and TABLE tags; or 2) have small incremental screens that move data back and forth to the server over and over again where all the behavior logic is carried out. Both of these approaches stink, the first because it wastes huge amounts of bandwidth by sending a lot of unnecessary bits over the wire (see www.yahoo.com for a good example -- look at the source code), and the second because it wastes huge amounts of bandwidth by forcing a lot of incremental transactions between the client and the server. But at the moment, they're the only way to create any user interactivity on the web.
Recently, we've started to see the inklings of a new way to build interactivity. By using client-side XML/XSLT approaches, some developers are consuming very little bandwidth while getting a very high degree of interaction. Content is separated from presentation in the purest sense, by sending a presentation interpreter independently of the underlying XML data. What's generated is ultimately HTML, but it's HTML as determined at the far end of the pipe, so it leverages the processing power of the remote user and minimizes the bandwidth needed to produce a highly interactive result.
What we could and should have are new web development systems that leverage that client capability. The J2EE model draws diagrams that go: data server -> business logic server -> presentation server -> client. Bah humbug. I want a server that sends presentation, business logic and data ALL to the client, and let's the local processor there do all the work of putting them together. That way, when there's a repeat transaction, all I'm sending again is the data. If there's a branch in the business logic, the client handles it, and no information exchange is needed. If the user's running in a smaller window size or a giant resolution, the client handles the layout management according to the rules I sent in the first place. When the transaction is ready, I want a tiny SOAP transaction returned to my server, not some fat HTTP POST request that gets thrown into my CGI interpreter.
That's a revolution, and it doesn't have squat to do with servlets and blade configurations. It makes increased scalability of servers irrelevant, because the amount of logic processing and data massaging done by the server is almost nil. The only thing you need a server to do at that point is handle security and validation of transactions. We ask for more work than that out of our cell phones.
How does this relate to Domino? Well, it so happens that Notes has been taking this approach for over a decade. When you use the Notes client to open a document, you are requesting both the document data, and the form design from the server. The form itself is delivered as a separate transaction and it handles -- wait for it -- presentation and business logic! That's why it has controlled access sections, encrypted fields, validation & translation, events, rich text layout, color controls, and all those other great things you can do with a Notes form. And it's even cached! So requesting the next document simply results in a transaction of the simple data in the document, not a reinterpretation and redelivery of all that logic by the server. That's one of the reasons Domino is more scalable to native clients than browser clients. Views and other design elements behave very similarly.
Domino 6 now has all this wonderful XML integration. It's got 3 different transform classes for both Lotusscript and Java. It's got it's own DTD for Domino design and data. It's even got &OutputFormat=XHTML for reading individual documents. And as a result, it's frighteningly close to being able to start the revolution. All we really need is a dynamic mechanism to turn the business and presentation logic of a form or a view into XSLT. Then we can send the straight DXL for a document or view contents down the wire and let that $2000 PC at the other end earn its keep!
And you know what? J2EE, JSPs, RBDMS and servlets don't have a darned thing to do with that. Domino can become the premier interactive web application development tool in one fell swoop, and it won't have a thing to do with corporate politics or the MS anti-trust trial or the open source movement. It's just a better mousetrap. And since we're really talking about turning a DXL design source into an XSLT file, we're only talking about -- you guessed it -- a transform.
Okay, so I'm exaggerating a little. There are a few more things that have to happen. Right now, the only browser with a ubiquitous deployment of a local XML transform engine is MS's Internet Explorer. It's had the ActiveX object built-in since version 5. All the concepts I'm describing would, today, only function on an IE client. That has to change. The Mozilla team is working on the TransformMiiX module, but from what I can tell, it's not done. IBM has a gazillion developers around -- go work with these guys and finish the thing. Mozilla is a Linux-client browser so you can take it out of the $1 billion you allocated. Then get it done for Opera, too (another Linux browser). And make it better than Microsoft's so they have to play catch-up again.
Some type of server fallback layer is needed for clients that can't be smart enough. WAP phones, Blackberry systems, ATMs, whatever -- there's still a large number of relevant clients out there that will remain HTML dummies for a long time. Which means that some facility to manage the transform at the server level will probably need to still exist. Fortunately, this is already there with the transform capabilities of the Domino server. We just need the HTTP server to have some directive intelligence on certain kinds of requests.
Lastly, we need way better presentation/logic control for the web in Designer. If the words "width" or "height" are associated with it, it should be in pixels. If it has a tag associated with it, I should be able to control CLASS, STYLE and ID through Designer, and I should be able to use @function language to do it. We need more intelligent facilities within Designer to handle rudimentary logic tasks -- for example, field validation from the web has not gotten one iota easier since R4. The only thing I don't have to do manually is type onBlur=". We need a unification of basic business rules between the client and the browser and we need some no-brainer presentation of it. (ie: if I set a field to Editable Number, you shouldn't be able to type anything but a number into it in the first place; give me a checkmark on the field properties for "cannot be left blank."; etc.) Otherwise, you'll have to give us some kind of XSLT source editing model that will be a complete hack and end up creating version conflicts.
Forget "contextual collaboration in an n-tier architecture" for Domino 7, Lotus. That's all real neat sounding, but continuing to deliver large-source, high-transaction solutions is not going to put you at an advantage. It's just going mean you ship tools that are too complex for most organizations to grasp (like you do now.) What we need is a rethinking of the way we get information to the client that will make simple things be perceived as simple. I'm not the only one that thinks so. You might recognize this guy, this guy, or this guy. Call it "end-tier architecture" if you want a catchy name.
It's a revolution, and they always start with a shot. How fast are you on the draw?
Comments
Posted by Mark Vincenzes At 05:02:18 PM On 07/17/2006 |
and only a couple of days back I had a person in the Partner Forum ask whether ODF would replace rich text some day.
Posted by Ben Langhinrichs At 01:53:35 PM On 07/17/2006 |
Only a few people seem to understand that we really do need this kind of revolution to happen in order to get the web we all want.
I have discussed these kind of things with friends, and the only people who seem to at least understand what I am talking about are Notes/Domino developers.
One can only hope that this kind of thinking gets more spread, and that IBM/Lotus will create a future web platform (and I do mean Domino) that supports a technology that focuses on the grunt of the work being done by the web browser.
Posted by Kenneth Haggman At 09:33:45 AM On 08/27/2006 |