Declarative Programming

Is declarative programming going to become more important for the richer client web? I've been playing around with Ajax programming. It's easy, but one thing keeps coming up: the coupling of front and back-end. I see it as a possible source of duplication. It's not like it's a new problem either. I've seen several projects where the client and server validation code was duplicated. It's insane to write the same code in two or more languages! Why not just one?

Well, there is already some help already out there. There are a few implementations of Javascript engines out there (for example, Rhino for Java, which I have used on several occassions, is excellent). Why not write your validation code in Javascript? You can then execute the same code on the client as you do on the server. We've just removed duplication, but then you must decide where to draw the line. And if you're not careful about what goes in Javascript and what doesn't you can end up in the same boat as before. But, running Javascript on the server for validation is a possible solution. But, Ajax will bring even more code to the client.

This is where I think DSLs and declarative thinking will shine. Why? Well, I can create a language that is intepreted on the server sid, and is used to generate the client side Javascript code. Tt will be more readable, faster, and closer to the user's language. Ruby and Smalltalk make DSLs a snap. I used a simple use of DSL for generating my Javascript code in my Agent program. I simply used polymorphism and exchange the real Agent object with one that generates the Javascript code. No duplication.

I think much like we have OO-relational mapping frameworks (and we don't have to deal with SQL in only limited contexts), we'll have server-client code mappings that will take care of the Javascript code for us. So, we can stay mainly in one language and not duplicate code. I've worked on a small Ruby framework to serialize Ruby objects as Javascript objects (it was very simple and just a proof of concept), but we also need to transfrom methods to Javascript as well (like the validation rules). A DSL will help in making that job easier. Much like in a OO-relation mapping framework, we make the distinction between storable/non-storable objects.

Ajax is simple to program, but I can see the complexity rising in any project of sizeable length. Much like we don't have to think about SQL with great frameworks like ActiveRecord, TopLink, Hibernate, and Glorp, I think a new breed of frameworks will emerge for Ajax that will make us not have to worry about Javascript as much. it's not that Javascript is bad (I love the prototype dynamic nature of it), but having duplicated code/definitions are the enemy here.

Of course, I wouldn't be suprised if people were not already working on them. I was thinking of playing with some implementations (for example, writing rules with blocks and using the rules for code generation of Javascript and intepretation on the server side). But, we'll see. It'll be a lot of fun to watch! Especially since Ruby On Rails already has Ajax support (but, I don't know how far they go). Rock on!