I’ve recently become quite interested in improving the client/server integration with the intention of building web applications more easily. Developing “msgpad”:http://msgpad.com has been a great case study so far.

Google’s solution is GWT, Microsoft apparantly have something in the works (script#). You can find a bunch of java frameworks “here”:http://ajaxpatterns.org/Java_Ajax_Frameworks (the Echo 2 framework is perhaps the most interesting). If you follow the links at the top of that page you’ll find frameworks for a bunch of other languages.

It’s interesting that Google and MS have opted to go the way of translating the more traditional desktop paradigm to the web. What’s so good about the desktop paradigm? I believe that it’s advantage is that people are familiar with developing in that way. For a big company, this is desirable. Here’s another hidden reason why I think they’ve stuck with this paradigm - because Java and C# push you that way. It’s *hard* to create another language using Java and C#.

I would rather _declare_ my interface than code the thing. Declaring is a nicer way of visually illustrating than coding. But, coding is better to illustrate logic. Let’s see… Desktop paradigm Vs. Web paradigm:

(hypothetical) Desktop paradigm:

b = Button.new ‘click me!’
document.body.appendChild(b)

Web paradigm:

The desktop paradigm is unnatural - whether you’re developing for the desktop or the web!

(I’m thinking out loud from here…)

*Extending HTML*

So if declaring is the way forward, where do we go from here? I think a good solution is to build on HTML. You could code something like:

Heading!

Hello World!

Then translate that in to HTML and end up with something like:

Heading!

Hello

World!

As you can imagine, that’s not very hard to accomplish. But, these toolkits like GWT, Script# are offering a way to blend behaviour with the elements. This is a _critical_ addition to minimize the complexity (E.g. Ruby+CSS+HTML+JS Vs Ruby+CSS). I’ve said more about that “here”:http://alexpooley.com/articles/2006/05/25/web-stew.

*Adding Behaviour To HTML*

HTML already caters for attaching behaviour to elements with their on* attributes. Presto! By extending HTML instead of providing an alternate interface you get behaviour attaching for free. As for actually coding the behaviour, that requires JS. But, that doesn’t mean you have to code JS!

*Supplementing Javascript*

For some reason, when most developers think of providing an interface they think of building a walled garden and opening windows where they see fit. The argument for this is generally to protect the user through encapsulation. You know what? I guess I’d be safe in a padded cell with a straight jacket… but no thanks. *Build me a room without walls*, and augment my view where it’s to my advantage. Unforunately, the mainstream languages make this hard.

I want and need access to Javascript when I’m coding, but I don’t want to code Javascript. I don’t want to have to climb over a wall every time I need to access Javascript the class author didn’t think was important.

At first glance, “msgpad”:http://msgpad.com looked like a pretty simple app. In terms of functional screens, there’s really only one - the chat screen. How wrong I was…

*Renaissance Man*

During the renaissance period it was typical to aspire to be both artistic and scientific. This romantic ideal has lost way to our more modern specialised lifestyle. In the computing world at least, we have specialised roles ranging from tech support, to graphic design, and from grunt coder to CTO/CEO. In building “msgpad”:http://msgpad.com I had to try to be _all_ of these roles. To be honest, it was really easy to be either scared of learning something, or ignorant of things that didn’t interest me. I’ve had to learn a fair waft of Javascript since starting “msgpad”:http://msgpad.com and I’m really glad I learned it. However, it was a conscious and calculated decision to learn Javascript, and a decision I wasn’t entirely happy about.

*Schedule*

The “artwork” on “msgpad”:http://msgpad.com took about a week to create, slice up in to HTML, and style through CSS. One bloody week out of eight full time weeks so far! In my mind I had boxed the graphic design up as ‘graphic design’ and shelved it as “something” that had to be done rather than “something” that was going to take me five days to get done.

The only true functional screen in the app, has so far taken something like a month, easy. It’s only one screen! Browser bugs, technical limitations, architectural and technical re-work account for the bulk of the time. In a perfect world you would understand the problem entirely before starting, but that only happens in student math books.

On the up side, I’ve realised that ALL of these problems are giving “msgpad”:http://msgpad.com its intellectual property. The fact is that if “msgpad”:http://msgpad.com were simple, then I would arguably be wasting my time.

Here’s a tip: When talking about chunks of work in a project, talk in “weeks” and not “hours”. I’ve found it gives the appropriate fuzziness to feel your way through, without losing the power of a deadline.

*Technical Limits*

I’ve ranted about the state of web application tools previously. Think of a web application as simply an application and you will better see the hurdles that we as a global society are currently facing. Race conditions due to asynchronous calls+network latency, working with HTML, CSS, JS, Ruby at the same time, integration of those technologies, hosting challenges, and more.

_Race Conditions_

Did you know Javascript is single threaded? But guess what, once you call out to the network you’re no longer single threaded because different queries take different lengths of time to execute, and don’t forget about the unpredictable network lag. This becomes a problem when your performing non mutually exclusive operations. If I look at “msgpad”:http://msgpad.com and generalise, then “any application with simultaneous requests that returns state containing a time component could create a race condition”. The way I’m controlling this is with a multiplexer component as a gateway to the network. I’ve quickly illustrated below how it looks when I’m querying my server from the client through the Internet.

_Development Technologies_

Ruby On Rails and Prototype only take you so far. A long way mind you, but definitely not far enough. In my opinion, the biggest problem web applications face right now is the complexity created by combining some server side language (Ruby in my case) with Javascript and HTML. Ruby sits server side, while JS and HTML sit on the client side. But, the Ruby creates the HTML that the JS interacts with. Without any doubt in my mind, until this problem is solved web applications will continue to remain trivial. Some may argue that update_page or RJS have provided a solution, but they really only provide a partial solution.

*Conclusion*

Well, there’s plenty more I could say about my experiences so far but I won’t, I have an application to build. I will say that the very fact that I am finding these problems gives me a lot of happiness. These are big problems that the edge of the Internet is facing right now. With problems come opportunities.

If you’re interested in following my adventure on the edge of the Internet I encourage you to signup to this blog by either entering your email in the subscribe box to the top-right of this page, or via RSS. “msgpad”:http://msgpad.com is a web chat application capable of operating on any device with a browser (computers, mobiles, TVs, Nintendo DS/Wii)! You may like to subscribe to “msgpad”:http://msgpad.com also. I’m currently looking for beta testers to play with the application on different devices and operating systems.

This blog and msgpad have been down for a bit over a day. As you can see, the blog is back, but msgpad is still on it’s way.

I’ve just changed hosting provider from Dreamhost to “Site5″:http://www.site5.com, ironically, in the hope of decreasing down time.

Once the hosting change over is complete, I hope to invite a few more beta testers.