Re: AJAJS - thin client web app using mainly XMLHTTPRequest and eval()

Hi,

On Sep 26, 7:21 am, timsamshuij...@xxxxxxxxx wrote:
I was wandering what the Javascript/Ajax community think of a rather
unusual
method I am using to develop my new web app. At least I think it is
unusual
because I have not yet found much about this exact method on the
internet.
My web app uses no HTML templates and neither does it use any CSS
files.
It is totally JS/Ajax driven, and there are totally no page fetches/
reloads
(single page interface). My initial page looks a bit like this (the
only html
code in my whole app!):

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
<title></title>
<script type="text/javascript" src="./js/init.js"></script>
</head>
<body>
</body>
<html>

On request, I'm writing one of these sort of pages now (and it is a
lot of fun!) It is for a back-end tool that requires login for IE6+/
FF2+/O9+/S2+ only with images, CSS, and JavaScript enabled.

The page I am writing is _not_ something for general Web consumption
where users may/may not have images/CSS/JavaScript and may have
various levels of support for each of these.

The init.js is a small script that starts it all up. It does a
XMLHTTPRequest
to a server-side application that only outputs JS code.

This means the JS code is probably not cachable. That's bad for
performance. Better to have a build system that just puts the
JavaScript init.js call directly in init.js itself. Then you can play
caching games like name the file init-23456436.js where the number is
a timestamp of the last build. You can have the server set far-future
cache expiration.

ALL returned
content
is passed into eval() (I actually do not need to call eval() directly
because
the Content-type is "text/javascript").

Ajax doesn't autatically call eval() if the Content-type is "text/
javascript". Who calls eval() for you? Are you using a JavaScirpt Ajax
library like Prototype? If so that is something to change pronto.


The first JS code that is
returned
builds up the whole page, loads some simple libraries, and registers
some
events to observe. From then on, ALL events (except for simple things
like
resizing) are sent to my server application which then outputs more JS
code
that get executed back on the client. For example, a user clicks on a
button,
the request is sent to the server which then returns some JS code to
build
a message dialog and register the corresponding message handlers, and
so on.

This sounds like Rails RJS. This style is fine for some applications
but some folks here will say that this tight coupling by using
language response is bad and a data response is better. If the server
never reuses the templates that build up the JavaScript response, then
it may be more flexible to send the data back to the client and the
client decides what to do with that data.


Therefore, for every event, the browser "asks" the server what to do,
and the
server tells the browser directly what to do with a snippet of
Javascript.

If these events need to interact with the database then you must
contact the server. Only pester the server if there is the event
handler needs some information you can't reasonably load into the
browser. Looking up phone number, for example. You can't load the
phone book into the browser in a reasonable time period.


This has great advantages for me as I now have all my layout, model,
business
logic, etc. in one place.

"One place" isn't the important concept in the DRY principle. If you
write your server-side in JavaScript then you can share code with the
client, have a thicker client and still be DRY. This is what I'm
shooting for eventually.


It is like "lazy loading", but an extreme
form.
One might think that it could run quite slow because it connects to
the server
for every user-action, but the returned pieces of code are small
pieces of
code, so the speed is actually quite impressive. This setup results in
an
extremely thin-client. I am very pleased with the first results, and
it makes
the whole development experience much like my original profession:
building
client/server desktop applications.

With caching tricks you can make the second load of the page very
fast. I wouldn't worry so much about how thick the client is because
even a relatively thick client like GMail loads sufficiently fast for
me given how long I keep the application open.


This is probably a sort of controversial method because I noticed that
there
are mixed opinions about using the eval() function to execute code.

A lot of fuss is made here about that. The recent comp.lang.javascript
archives are full of discussions. Search for "Randy Webb script
insertion" or similar.


Ofcourse,
the returned code comes from my own server (same origin policy), so no
major
reasons for concern. Another point of criticism is possibly the fact
that I
do not use any (X)HTML templates or CSS files.

Don't use XHTML for the Web if Internet Explorer is involved.

http://www.thewebcreator.net/2007/04/16/why-you-should-be-using-html-401-instead-of-xhtml/

http://www.webdevout.net/articles/beware-of-xhtml

This aspect is
something I
actually like very much, as I can now build and position all
components with
code, instead of looking all these things up in HTML and CSS files
(great
for website design, but not for desktop-like application development).

So, my questions to you all are:

- what do you think of this strategy?

I think having empty body tags and building the whole thing with
JavaScript is fine.

I only transmit data to and from the server.

Make sure you take advantage of browser caching to make second page
loads fast.

Use JavaScript on the server-side so you can share code and stay DRY.
Using JavaScript server-side is something I'm just starting to explore
now.


- If this strategy has already been discussed before, then what is it
called?
(I am calling it AJAJS for the time being (not AJAJ which is JSON
oriented)).
- Where can I find more information about this?
- Are there already existing frameworks based on this?

In the Rails world it is RJS. Also search google for "Dan Webb ejs".


- Do you think that browsers will continue to support eval(), and not
depreciate
it in the future for security reasons?

I'd guess eval() is not going away since it is part of the ECMAScript
standard. There are other options that you'll find in the "Randy Webb"
threads.

Peter

.

Relevant Pages