Today, after many months of work and a ton of source code inspected, traced and evaluated, we released Piggy Bank 2.1.0.

I’m very proud of this work and very happy to be part of it: it is, to me, the first significant step into a bright future and it got me closer to the mozilla architecture, which, I have to admit, is a pleasure to work with (especially now that we found a way to write XPCOM components in java and therefore we have a ton of existing libraries to use pretty much for free).

Just before last weekend, during my final Piggy Bank wrap-up’s, I sent an email to the Cocoon development mailing list airing my concerns: the web is slowly but surely changing. Some call it the Web 2.0, some call it Ajax, some call it “told you!” and some call it “so what?”, but the truth of the matter is that web services are coming and their impact has very little to do with what protocols or architectural decisions you make, but the amount of people you manage to catalyze.

Sylvain was the only one that explicitly uncloaked my intent: Cocoon is clearly not obsolete and it won’t be for a while, but it’s fat and sleepy, kinda watching TV (if you allow me) instead of going out exercising. Before I move on, I wanted to trigger a wake up call.

At the heart of Piggy Bank, there is a web server running inside your web browser. It’s running a servlet, a minimal RESTful framework that David wrote call Flair (modeled after what Mark did for Longwell 1). It’s so simple it’s actually (to my web framework architect’s eyes) embarrassing, yet it does the job: Piggy Bank’s webapp (actually Longwell 2) is fully RESTful, no session, no state, no continuations, everything is passed back and forth urlencoded and urldecoded (yes, this creates issues, but that’s another story).

Since we know that Piggy Bank runs only on Firefox, we can go crazy with DHTML and know that it will work. Ajax is used as client side include, and you can even do templating and XML pipelining directly on the client. With Firefox 1.5, even the need for graphics on the server side is gone, SVG and canvas are embedded, scriptable and fully merged with the browser, no need for the amazing SVG->PNG functionality cocoon offers… also because, guess what, David cloned it with a little servlet called Picto that we now use to have our own color-coded Google Maps placeholders.

All of this, in a fraction of the space and complexity: the entire Piggy Bank, web server + database + full text indexer + webapp framework + template system + RDFizing framework + firefox extension + icons is 4.5Mb… and it’s not even stripped down (if I really wanted to, I could get it down to 1.5mb by using ProGuard but I really don’t see the reason for it).

One thing that I miss with cocoon is the sitemap, but the cost (in terms of megabytes and complexity) of that is way too high, besides, since we use Jetty’s own APIs and not the Servlet web.xml (yes, I know, you think I completely lost my mind at this point, being one of the people that designed that Servlet API web.xml in the first place) we were able to reuse a lot of Jetty’s internals as a web server, reducing the need for what we have to handle.

So, in short, all REST, state is never temporary saved but always transferred until persisted, AJAX pretty much everywhere, a minimal servlet that translates a request into a different action handler doing the urlencoding and decoding (the controllers, one per command, in java), RDF as the model and velocity templates as the view. No pipeline, No multimodality, no XML awareness, no continuations, no sessions. Piggy Bank has, on the server side, the architectural appeal of a CGI-BIN and yes, 7 years spent designing web application frameworks, I know that to be an insult.

But the overall result is incredible: light and simple on the server, light and simple on the client. Very easy to learn, very easy to adjust incrementally (once you polish up all the memory leaks and fine tune the database indexes for performance, as we now did).

Like many on the (long) thread that started on dev@cocoon.apache.org mentioned, pretty much nobody has the luxury today of owning both the client and the server in a web application. But with Piggy Bank, we do! and, let me tell you, not only it feels great and refreshing, but it makes you rethink about the entire web, a web where the ability to influence the clients is not locked in some vault in Redmond.

Yeah yeah, sure, IE is long to be gone, and so is Microsoft, but it’s not just the Mozilla Foundation and radical web standard activists pushing for Firefox anymore, it’s already in the radar of too many web sites, forcing IE to compete. And competition is good, especially when there are players like Yahoo, Google, Amazon and eBay that will not just stay at the window on the battle for the new web-service-powered ‘man in the middle’.

Netscape’s plan of transforming the browser into a desktop, making the operating system basically an obsolete concept, was called “constellation“. Many believe this plan was what made Microsoft kill Netscape with all possible means. When the mozilla developers decided to rewrite Netscape Navigator from scratch, many thought they were crazy in building their own browser inside the HTML rendering environment itself. The ultimate flexibility syndrome.

But today, years and thousands of bugs later, mozilla is a platform capable of delivering a client side tool used by millions. I can’t think of another client side application framework that was able to achieve such tremendous success if not MFC. Java JFC (aka Swing) failed long ago to deliver that promise on the client (its look and feel is awkward, unreasonably slow and massively overdesigned) and Eclipse RCP needs to take the Mac seriously before anybody will start using it for real (and yeah, the JVM needs to go to the gym with cocoon too!). Cocoa is great, but it’s another lock-in and the only reasonable answer to who gives kids sigarettes for free today is “No, thanks”, especially since Apple will very likely kill the need for your little cool app in the next release of the OS anyway, and, no, you don’t get a piece of that money.

So, what does it mean for the future of the web?

I honestly don’t know, that thread was just a way to shake people up. All I know is that I’m proud of what I did for the web, first on JServ for Java and Servlets, then on Cocoon for XML and web frameworks that could deliver the web promise and scale to the number of people involved, and now for SIMILE and the semantic web, of which, if you ask me, this Web 2.0 buzz is just the very beginning.

When people ask me what I do for a living, I say that I research what the web of the future could be. At that point, they ask me to give them an example of what that would mean for them. My usual reply is “if we are successful, the only difference you’ll perceive is that you won’t feel as constantly lost as you feel today”. At that point they smile, happy to meet a technologist who thinks it’s his fault, not theirs, if they can’t do something with his software.

No matter what technology or platform we build the future of the web upon, we need to learn how to write the software that delivers those smiles: anything short of that will be a failure.