9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: <grfgguvf@gmail.com>
To: cnielsen@pobox.com, 9fans@cse.psu.edu
Subject: Re: [9fans] web apps
Date: Sun,  6 Nov 2005 21:42:19 +0100	[thread overview]
Message-ID: <8413367b0511061242v478a4ca3i2630ec35ec5a454e@mail.gmail.com> (raw)
In-Reply-To: <20051106074115.GD80710@cassie.foobarbaz.net>

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 network
   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-server
   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 requests.
-> 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 bare
 hardware

-- VARGA Peter


  parent reply	other threads:[~2005-11-06 20:42 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-06  7:41 Christopher Nielsen
2005-11-06  8:10 ` Sergey Zhilkin
2005-11-06  9:27 ` My internet2 (was Re: [9fans] web apps) Sascha Retzki
2005-11-06 20:10 ` [9fans] web apps Lyndon Nerenberg
2005-11-06 20:36   ` Wes Kussmaul
2005-11-06 21:26     ` Skip Tavakkolian
2005-11-07  2:51       ` Wes Kussmaul
2005-11-07 19:00         ` Christoph Lohmann
2005-11-08 16:51           ` "Nils O. Selåsdal"
2005-11-08 18:19             ` Skip Tavakkolian
2005-11-17 15:28   ` Victor Nazarov
2005-11-17 15:51     ` Moritz Kiese
2005-11-06 20:42 ` grfgguvf [this message]
2005-11-07 10:09   ` Charles Forsyth
2005-11-07 13:31     ` Wes Kussmaul

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8413367b0511061242v478a4ca3i2630ec35ec5a454e@mail.gmail.com \
    --to=grfgguvf@gmail.com \
    --cc=9fans@cse.psu.edu \
    --cc=cnielsen@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).