So I've left Laszlo to pursue my fortunes as an independent software developer and consultant. When I tell people this, there's usually an understanding nod and then a conspiratorial "Why?"

Unfortunately I don't have juicy gossip for the pages of fuckedcompany. Laszlo is going strong, and I'm as optimistic about its potential as a business and as a technology as ever, and I've been pretty optimistic. The main thing is that I was there for a long time and I'm ready for something new. The other thing is that I like being independent. I consider the (long) time I spent at Laszlo to be the anomaly, and I'm getting back to the natural direction for my career.

I have to admit that it is somewhat liberating to change my point of view from the narrow perspective of if-it's-not-Laszlo-I'm-not-interested to the broader technologies and trends of Web 2.0. I still think that OpenLaszlo is the best way to deliver rich app functionality, but I'm more convinced than ever that the best solutions will use rich client technologies in limited and specific ways. I think that a lot of what's happening with AJAX right now is fragile and overly complicated, and that it's a fad. When the dust settles, I expect most apps to rely heavily on the server to manage state and interactions between objects, and to use the client to render these objects and interactions.

I recognize that this is a bit of a departure from other points of view I've expressed on these pages, but my work on Webtop sensitized me to the issues around validation, data integrity, and business logic. In my experience, client code ends up being hard to debug and test. This is partially caused by real performance constraints, but also by the fact that the client is necessarily messy — it's the human window into an otherwise highly ordered, abstract world of data and logic, and as such it will always have weird exceptions tucked into dark corners and complicated, hard-to-follow logic flows.

I'd like to see a better way of structuring abstract server objects so that they can render themselves on the client. I expect many of these objects to rely on simple HTML for this, but for some to use more complex renderers like a component written in OpenLaszlo or a Google Map. When I described this idea to a friend, he nodded and said, "XWindows for the browser." That's a decent high-level description.

A lot needs to happen in order to realize this vision. There's no existing framework client framework for this. I'm talking about a lightweight system for organizing client-side display atoms that are tied to server objects. But this, arguably, is the easy part.

More importantly, all is not well in server-land. Even though I have developed a grudging respect for Java, I still have a lot of problems with the way that the various frameworks employ it. I'm working on a project pitching in on a big struts app right now, and I'm finding it pretty frustrating. Struts is essentially an extra XML programming language (or a couple if you're using tiles) but it's not expressive enough to do everything you want. So when you go to track down a bug you have to look in the struts XML files, in the Action classes, and in the JSPs. Worse yet, all these things are linked together with extra-lingual string attributes in JSPs and XML that aren't recognized by my editor because the source tree has an unusual project structure.

I suspect that these issues are familiar to most Java programmers. For once, this isn't actually a knock on Java itself. It may be cumbersome and bulky, but in general if you have a module with decent unit test coverage — itself a provable fact — then it's likely that you have a decent module. Still, there are huge gaps to fill. One thing that's stunning is that a lot of the Java code out there runs really slowly! For all its laborious typing and JITing and hoo-hah, it seems that the vast majority of Java apps are slow and leak.

So here are my TODOs: Make yet another a lightweight component framework for the browser. Build a super-lightweight, very fast Java framework that addresses it. Make or package some complex renderers that interoperate with the framework. No problem right? I've got nothing but time. Anyway, I'll try to keep this site updated with my thoughts and progress.

A bit of housekeeping. Here's the website for my consulancy: Elastic Process. You can still reach this blog through the old URLs, but, here's a link to the official Elastic Process blog, which is what you're reading ;) If you're a potential customer, by all means drop me a line. If you're an independent developer, please get in touch — I'd love to hear about what you're doing.