The need for a new browser-server model – part 1

The dialog between the browser and the server is simulated

We are building complex web applications for years now, and the dialog between the browser and the server is well known and with very clear and simple rules. But did it ever occur to you that what for the browser and the server is a perfect and normal dialog, for the developers AND for the users (at least for those users that are able to see this) this is all just a very big and nasty simulation?

Huh?

Here is what I am saying: the browser requests a page, the server receives the request, then according to some configuration files (I am thinking now on  the Java platform, but this is similar to any other platform, be it C/C++, .NET, Ruby On Rails, whatever) it selects the piece of code to execute, lets the code to execute and then returns the result to the server. Cool, so what? As I said, this process is perfectly logical, and for both parties there is nothing simulated here.

But for the developer this dialog is OK and normal only if she/he creates a simple personal web page or some presentation site, similar to a Word document but with links between pages. For any web application that is just a little bit more complex, many simulations and workarounds and stuff that are not really normal must be performed.

The web was statical, now it is dynamic. It never was interactive

In the first moments of its life, the net was statical. Files were transferred on by user command, the documents that were serverd were statical. Then people introduced the dynamical documents, which were (and still are) generated according to some criteria, some user input and history of user activites. Database and repositories are now powering the web applications and are providing the data to populate the documents that are presented to the user. However, this is all the user gets: documents.

You will say: “wait a minute! This is not true, we have Ajax and JavaScript and interactive content and so on. We can create complex interactive applications, some of them looking just like desktop applications, with windows, dialogs, menus and so on“.

Bullshit, we don’t have it!. Ajax is just a dummy protocol to request a page behind the scene. JavaScript is just an interpreted language to make the browser move some DIVs in front of your face. This is not interactive content. This is the best we can do right now.

Simulation on the client side

Currently, when we implement a web application, we have to simulate multiple thigs. On the browser/client side, we have to implement the “interactive” part. Sure, we have many JavaScript libraries that are doing this for us, so that we don’t have to write so much imperative code (code that tells the browser how to do something) but more descriptive code (we tell the browser what to do, what we want to have (many thanks to Aurelian Popa, http://ronua.ro, for the imperative/descriptive code idea)). This is a very useful addition to any web application programmer toolbelt. But still this is not interactive.

The “window” that is opened is just a DIV panel opened on top of a bigger transparent DIV panel that forbids you from clicking on the background. The small panel can be moved (which again is a simulated movement, implemented by you directly or by the UI JavaScript library that you use) or not, the controls appear and disappear and so on. Everything looks pretty, just like a desktop application. Yes, true, the capital word here is “like”.

Next, we can discuss about the dialog with the server. Unless we use Ajax, everything is document-centric without any argue. You click a button, the screen goes white, and boom! you get the new document. Nothing interactive here. Ok, so we add Ajax. Behind the scene the browser does the same thing, but this time you click the button and the document remains displayed on the screen and only a small part of it is changed. Ok, changed, but how? By simply hiding a DIV panel and showing another one. Or by using the great myDiv.innerHTML property. Again, simulation top to bottom.

Simulation on the server side

After finishing with the client side, we move on to the server side. I will take the case of the JEE platform, since this is what I am most familiar with. On the server side we write servlets. Plain and simple. No no no, no JSF, Tapestry, Wicket, etc, just servlets. Any of these technologies must have a servlet. What happens after the servlet gets the request depends on the configuration files.

OK you say, so what if we have servlets? Is not like we have to deal with servlets anymore. No, indeed. Each technology has its own servlet, you just configure it in web.xml, and you’re set. From this point on you simply start implementing according to the rules (which are simple or complex, depending on the chosen technology) layed out by the respective technology. Ok, but think about this: you will always have to write 2 things: back code (beans, actions, action forms, page objects and so on) and HTML/JSP/JSF pages to compose the next page. So again, you are not doing anything interactive in your code, just compose documents. Documents to feed to the client. Dynamic documents, I agree, but still not interactive. Windows/Linux/Mac, when they are opening an window, can be called interactive, the web has never been interactive.

End of part 1

I will end here the Part1 of this post. In Part2 I will try to describe the new model that I think we should have, the model that might allow us to make the web really interactive. Of course, I am not saying that I discovered the Holy Grail of web working, but I just try to shed some light on the things that we consider normal simply because this is how we program today and this is what we (or ar least most of us) think the things should be.