Issues with my Web 4.0 design


So, I have been thinking some more about my design and been reading some interesting papers the nice people at UCI gave me when I visited the other day to seed my literature review. I realized, there is a huge issue which I have overlooked so far: delay and asynchronicity.

On a side note, it seems that neither links nor Luna concern themselves much with this particular problem, but it has been brought to the attention of one of the developers of Links after a talk he recently gave, cf. here.

Read the rest of this entry »

Future of the web happening now!


As it turns out, I am not the only one to notice (obviously) the apparent complexity of writing large-scale applications for the web today. Moreover I am also not the only one trying to do something about it. There are at least 3 different projects that I got aware of recently.

  1. The first is an eclipse project called Rich Ajax Platform (RAP) that was born out of RCP and uses the same model (OSGi etc.): It can compile both a stand-alone desktop application as well as web-application that look similar from the same source. I think it looks promising and is a very good first step.
  2. Both the second and the third take a completely different approach in that the idea is to write everything in a functional language. I learned about Luna a couple of days ago, when I got a link on twitter about it: It has a C-style syntax but allows you to write everything in a monolithic way and pretend you have full access to say, the DB in a template. It supports JS-escaping similar to asm{} blocks in C, as well as XML and CSS as top-level constructs in the language syntax. I have to say that it looks very cool, and almost too easy to write a web-application that way (look at the example on their page, to see what I mean).
  3. The third is almost the same idea but from a research lab in the UK, started about 5 years ago, called links: I found that link in the comments on the luna blog 😉 The syntax is a little more functional but the underlying idea is the same, and has some of the same features, ie. XML top-level construct, monolithic single-sourcing etc. It is written on top of Caml.

The next-generation Web or Web 4.0


Last night I was thinking about the future of the web (again) and what points I might have missed during my SOFEA series. In this post I am going to fill those gaps.

In the traditional client/server paradigm, the standard most of the time only defines a ‘protocol’ and how the software (both client and server) behaves externally, also called the side-effects, but not how it does it internally, or how to look while doing it. This applies to most if not all Internet standards so far, and for HTTP as well, though HTML does define the look of the static content (not of the browser).

The current browser model is almost 20 years old by now and based on the traditional client/server paradigm with only static content. This was fine and dandy back then since machines were not very powerful (even servers) and runtime compilation/interpretation wasn’t even invented yet, but after 20 years of Moore’s law today’s cell phones are more powerful than a room full of hardware in those days and I think it is time to rethink that model. Read the rest of this entry »

MVC applied to web-apps


The MVC pattern also fits a client-server application. The only difference is that there are now two pieces that both have their own MVC parts.

Let’s start by defining the two extreme ends of the spectrum (the corner cases):

  • Everything runs on the server, and only a static rendering of the model is transmitted to the client and ultimately, the user. This is the model of Web 1.0. Technically there is still a tiny fraction of the V running on the client (the browser) that renders the HTML, as well as of the C that reacts to links. Note that this is commonly referred to as fat server/thin client or ‘terminal server’ approach. Here an update of the GUI always involves a whole round trip to the server. This is depicted in figure 1:                            MVC server Read the rest of this entry »

Webapp, webapp on the wall, what are you, after all?


I think, todays webapps are closer to real, full-blown desktop applications than they are to the linear, static, book-like presentation-flows of the early web.

That insight has a number of important effects. Application-state and with it the ability to bookmark and history-navigation is one of them.

If you think of the early web as a better book, static “pages” of text and pictures, that you can browse and jump around in to different pages by the use of links, it makes sense to be able to “bookmark” certain pages and also flip back and forth through your history of visited pages.

Now think of a typical desktop-application. Does it make sense there? Can you ‘bookmark’ a certain point in the app’s state, or go back to it? No, it does not make sense. The only part of a desktop app that a ‘state’ can sensitively be applied to is the model. Think about apps that manipulate some kind of data (most do). You have an undo-redo history to quickly take back any modifications to the data that you made.

You might even be able to ‘bookmark’ a certain chain of actions, sometimes called actions or macros. In desktop apps, bookmarks for specific model-states only make sense in a particular context, thus the need to execute the whole macro to get to a specific state of it. Think about it: Does it make sense, even if you could, to jump to one particular point (that is state of the model) in an action without executing all the steps before it? No, mostly it does not.

Now, why would you want to be able to do bookmarking in a web-app, if it does not make sense even in a desktop app? Because it is a remnant of the early days of the web? Because browsers support it, and users simply expect it?

There is the other issue of URLs. Even if you wanted to create a link to specific state in the app, bookmarks only save the URL. How can an application encode a possibly very complicated state in a single URL? Read for a discussion of this.

Where does that leave us? My view is that web-apps should limit navigation-history to changes of the model, similar to undo-redo in desktop apps, and allow bookmark creation only at feasible points in the app when there is still not much state involved – e.g. right before login, the landing-page etc. Most current web-apps already do that: change the URL on creation time by hooking into the event or keeping the path sent to the browser static. GWT lets programmers do that already and also allows to hook into the browser’s history tracking for the same reason.