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.