Future of the web happening now!

12.2.10

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.): http://eclipsesource.com/en/eclipse/eclipse-rap/. 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: http://asana.com/luna. 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: http://groups.inf.ed.ac.uk/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.

On scripting

20.2.09

About one-and-a-half years ago (wow – it’s been that long?) I was working on a semester project for the institute of signal communication at the university of Braunschweig, Germany (http://www.ifn.ing.tu-bs.de/) about scripting languages. While the details of the work do not matter, the more interesting part of this work is my evaluation of high-level versus scripting (dynamic) languages.

My basic point is that dynamic languages are easier and faster to program for than non-dynamic languages like C or Java, because they don’t concern the developer as much with syntax (as in variable types for example) or debugging. In essence, dynamic languages move effort (computation time) from the developer towards the compiler, because it has to spend more time inferring what the developer meant. In dynamic languages, the whole program runs inside a sandbox called a virtual machine, creating even more effort on the CPUs side which also helps the developer spend less time worrying about mundane things like memory management. Also, virtual machines help with debugging a lot because they provide a better idea of what went wrong, and can provide a generally better insight into the running program.

In essence, I think that dynamic languages are the future of programming because as CPUs get faster and faster this shift of effort will mean that development time in scripting languages goes down more rapidly as in other languages.

The paper and the defense can both be found in my slideshare slides here, beware they are both in German: http://www.slideshare.net/derDoc.

Update: I also uploaded my Master and at the same time Diploma-thesis as well as the defenses for it in both German and English to my slideshare account. As well as a poster for NSDI, all of which were made at UTEP, Texas, USA.

Reblog this post [with Zemanta]

A note on the webserver

8.2.09

Do we still need a complete webserver the likes of apache, for todays server-side dynamic frameworks? No – we don’t.

If you ask why, think about what a webserver is for (a good look at the HTTP spec and apache docu will do). It is responsible for content-types, authentication or help with caching and can also do name-mangling, load-balancing and more with the help of plugins. Now, which of these can a dynamic-language framework also do or even do better? Yep, that’s right, all of them.

The scripting language of choice decides everything for its own dynamic content: The content-type, caching-directives, how to handle each path and even which VM is least loaded for balancing. Authentication is in almost all cases not done through the primitive http-auth anymore, but with the help of the DB and sessions.

If a request for CGI content comes in, the webserver just passes it to the scripting language which takes care of everything itself and passes the result back to the webserver for sending to the client.

Let me emphasize that: The webserver is one more step in the loop, which we don’t need anymore for dynamic content.

Static content, like images, should be served from a different (sub-) domain anyway for easier  CDN distribution, and for that webservers are still the handler of choice.

That’s why frameworks like RoR come with their own lightweight webserver.

Reblog this post [with Zemanta]