From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <8413367b0511061242v478a4ca3i2630ec35ec5a454e@mail.gmail.com>
Date: Sun,  6 Nov 2005 21:42:19 +0100
From: <grfgguvf@gmail.com>
To: cnielsen@pobox.com, 9fans@cse.psu.edu
Subject: Re: [9fans] web apps
In-Reply-To: <20051106074115.GD80710@cassie.foobarbaz.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <20051106074115.GD80710@cassie.foobarbaz.net>
Cc: 
Topicbox-Message-UUID: a71ed072-ead0-11e9-9d60-3106f5b1d025

On 11/6/05, Christopher Nielsen wrote:
> as possible. that said, web applications aren't going away. why
> not develop something using a similar architecture to AJAX but
> using technologies that have a more elegant approach, e.g.,
> s-expr,

S-expressions are indeed more compact than XML but other than that
there isn't much difference.

> the first question that comes to mind is how do you replace
> javascript? does it make sense to write a limbo interpreter
> plugin for browsers? does it make sense to design a better
> language and write a plugin for that? is there something else
> entirely?

IMHO there is nothing wrong with JavaScript the language; it's
relatively well-designed. It's just abused a lot.


Looking at it from a distance, the current "AJAX" approach is not very
different from the original vision of Java: Creating portable
applications that can be downloaded from the net and execute on the
client host (communicating back to the server).
It's just based on already-established technologies/standards and is
thus is easier to adopt. The model inevitably seems like the future of
the "web".

This direction is, IMHO making web-servers the equivalent of
file/cpu-servers in Plan9; and web-browsers the (somewhat) equivalent
of a Plan9 terminal's kernel:
AJAX: the browser downloads the .html, .js, .css, .gif, ... via HTTP
-> Plan9: the terminal downloads the kernel via TFTP and configures it's ne=
twork
   via BOOTP
AJAX: the user authenticates and the server sets a cookie in the browser
-> Plan9: the user authenticates and the terminal connects to the file-serv=
er
   via 9P
AJAX: the client-side "AJAX engine"[1] loads the main UI (download
some .xml files
 via HTTP, inject them into the DOM). The browser may cache the HTTP reques=
ts.
-> Plan9: the terminal boots, loading files from the file-server.
Requests may be
   cached if cfs is used.
[...]
AJAX: the user types in a mail into an <input> box, possibly with some wiki=
-like
 markup or JavaScript "rich-text editing"
-> Plan9: the user types in a mail to Acme,
AJAX: he pushes the [Send] button, the "AJAX engine" sends an .xml to the
 server in a HTTP POST request
-> Plan9: the user clicks on Put and the kernel writes the file to the
file-server
   via 9P
[The user may now close the browser/switch off the terminal...]

As you see, AJAX lends most of it's power from the use of XmlHttpRequest's.
You may think: But there is a lot more than that to it. Well, we are
special; I believe the "average user" spends 98% of their computer
time in the browser and the office suite. And "office" could easily be
replaced with an AJAX-based application, in fact Microsoft is already
working on something called Office Live[tm].

I wouldn't be surprised if, in some years, all the bloat below the
browser which we call operating system would become pretty much
useless... What does the future hold? Possibly the the essential parts
of consumer OS's will be integrated into the browser which will be
able to run on bare hardware (think handhelds...). A similar trend is
possible for server OS's, now they are almost only used to run the
httpd[2].

[1]: The "AJAX engine" is essentially a JavaScript application running
in the browser
 modifying the DOM and communicating with the HTTP
  server (via XmlHttpRequest's)
[2]: V2_OS was possibly the most famous attempt at a httpd which runs on ba=
re
 hardware

-- VARGA Peter