Steppin Out

* - *

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

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 href="">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 href="">other points of view
I've expressed on these pages, but my work on href="">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

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: href="">Elastic Process. You can still reach this
blog through the old URLs, but, here's a link to href="">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.


I won't be snarky and claim

I won't be snarky and claim that the XML languages cropping up around Java are an example of Greenspun's Tenth Rule. However, whenever you create a language (powerful or not) outside of your main implementation language, you're leaving behind a lot of infrastructure: editors, debuggers, static analysis tools, etc. That's why I'm suspicious of frameworks in general: they lack the semantic rigor of programming languages while foregoing the hacker-years of effort that go into useful tools.

What Dan said. The beautiful

What Dan said. The beautiful thing about a really expressive language (yes, like Lisp) is that you don't need *another* language to express a given concept -- you can create a domain-specific language right there using hygienic macros or what have you. (Actually, I don't think Lisp quite captures the best story, but nothing since has matched it, so...)

My dream language would support DSLs, would be unified across compile- and run-time, and would be unified across client and server (and server...).

We don't have that language yet, but the pieces are there in the DSL department, and in the compile/runtime staging department, if not yet completely in the client/server department. (And no, I don't think that any UI of particular interest can be automatically generated from server-side information. It doesn't work that way.)


Congrats...I think ;) Happy

Congrats...I think ;)

Happy Hacking!

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

More information about formatting options

This question is for testing whether you are a human visitor and to prevent automated spam submissions.
Copy the characters (respecting upper/lower case) from the image.
* * *