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 »

Conclusion of the SOFEA series: Future of web-development/RIA


To summarize this series, I will shine the light on some of the more important points from the series.

I really believe, that at some point in the future, there will be an unified web-development environment (UWE) for the web which allow the developing of a whole, single application in one language which will then get broken up and compiled into the client and server parts by the compiler. So essentially the compiler decides where to draw the line between client and server – possibly with some help from the developer in the form of annotations, some description file or specific classes.

With this it is entirely possible that the program can be compiled into different representations, i.e. different languages for different deployments – for example a part for deployment on a server running struts and another one running ruby on rails, and client parts for a very thin – read restricted – mobile client as well as a very rich/powerful client. This naturally moves the break-up line between client and server which is why the compiler needs to be able to decide that at compile time.

What language the unified application is written in, does ultimately not matter since all languages that are Turing-complete can be crosscompiled. But since it is more complicated to compile from a non-VM language into a program that can be run in VM, it should be a VM language, even if it is one with strong typing like Java. The GWT is a very good step in this direction, and it shows that it is possible to write the client-side part in a different language (in this case Java, which is close enough to JS to make that easy) for easier development and debugging and then cross-compile it for running on the client.

I think that fusing GWT with a similar toolkit for the server-side, maybe based on struts or some other Java webserver and implementing a generator for the marshaling, can be an important first implementation of this unified web-development environment or toolkit. If somebody is interested in this, maybe it can be suggested as a project for the google summer of Code (SoC).