Browser Blues and EB Green

Over twenty years ago, I was introduced to a modern wonder of the world, EB Green. I was in the Navy, assigned to a ballistic missile submarine, the USS Alabama, during its construction at Electric Boat (EB) shipyard in Groton, CT. EB Green was green duct tape on steroids. It was stronger than epoxy glue. Rumor had it EB Green stopped leaks in submarines at maximum depth. I’m not making this stuff up. And it was ubiquitous. Everyone had at least one roll of EB Green stowed away somewhere and another within arm’s reach. It was common knowledge EB Green kept afloat the American Navy.

I didn’t much like the Navy; it nearly drove me crazy. But like so many other people when they reflect on times of adversity, I tend to remember the good things, like EB Green. In twenty years, I hope I can look back at this time with some amount of fondness, because developing web applications drives me crazy.

I thought I was the only one driven to the brink by the complexity of web development until I attended a No Fluff, Just Stuff conference in Des Moines, IA. Looking over the agenda, I was numb-struck when I read the synopsis for one of Glen Vanderburg’s sessions:

We’ve been writing web applications now for 10 years, and they’re still no fun. They’re awkward and clumsy to write. Internally, they’re overly complicated (which almost invariably means that they’re buggy). Meanwhile, they’re usually too primitive externally. To put it another way: the web programming model is so cumbersome for programmers that the users pay—through reduced features, clumsy interaction, bugs, and poor performance.

I can’t tell you what a relief it was to discover I wasn’t the only one thinking this. Since then, I’ve read more. It’s not uncommon to hear a little battle fatigue in many writers, such as this appeal for elegance by Paul Ford:

Ftrain [Paul’s website] is built using a custom XML schema, XSLT (which is actually two languages, the transformation language XSLT and the document-tree-access language XPath), a Makefile, XHTML1.1, which defines the structure of a given page, CSS, which defines the appearance of the XHTML1.1, and Javascript, which defines some of the interactive features of the page. It will eventually export to RSS0.91, RSS1.0, RSS2.0, Atom, and an entire copy of the site will be output in RDF. It contains Java applets, sound files in RealAudio and MP3 format, JPGs, GIFs, PNG files, text files, Python scripts, Perl scripts, PHP pages, and a search engine.

That’s one web site, for one person. Too much.

And he doesn’t mention many of the technologies used in large web applications: JSP, JSTL, Struts, JDBC, Jakarta Commons, and other AAI (Acronyms Ad Infinitum.) The technology is complex and that makes the process complex and that makes for an inferior, expensive product. It’s a kludge of square pegs and round holes put together with eccentric ingenuity—that is to say, it is not intuitive. It is programming disguised as quantum physics. It’s all piled on top of HTTP Post and Get and held together with EB Green. It works (barely,) but do you really trust its watertight integrity?

There must be a better, elegant, intuitive way. A fresh start, from scratch, would be ideal. Okay, I’ll give you TCP/IP. Pragmatically, I like the idea of thinking outside the box that is the browser. I’m invigorated by recent news that IE 7 won’t pass the Acid2 test. Ditch the browser and what are the alternatives? A rich, browser-independent client is very appealing once venerable deployment issues are resolved. The bottom line is that almost anything has to be better than what we have.

Somebody out there smarter than me get this ball rolling. Please. I want to have fun again.

Explore posts in the same categories: Uncategorized