AJAX web applications examples

A

Andy Dingley

For me, the jury is still out on AJAX.

The jury has already decided - maybe you don't agree.
I am finding very little advantage
over doing the same thing with Flash.

It's the difference between semantically-aware HTML and a <table> full
of text rendered as bitmaps. They both work, but one is an opaque pipe
that only works when connected to one particular endpoint. The other is
a transparent pipeline where you can swap components around in the
future.

One nice thing you can do with AJAX is to handle business logic with it.
You can describe business logic and run it on the server. Then you can
take this same description and use it to generate an AJAX client app
that emulates the same behaviour client-side. Or even better, you can
have a transparent client query the server from within the page, so as
to use the server to actually execute the logic. You could do this with
Flash (and friends) too, but you'd have to do three implementations.
 
A

Andy Dingley

Man, that game sure is network hungry.

A common problem with AJAX apps that aren't carefully designed to avoid
this. AJAX kills servers because it encourages round-tripping to the
server for the most trivial user events.
 
S

Samreid Hughes

(e-mail address removed) wrote in
FFS, when will people here stop being so bloody anal about this
stuff. The work that Woollymittens has submitted, because it may be
of interest, isn't compulsory reading. So, if the text is too small
for you, either do as he suggests and change the size in your
browser, or piss off to another site that uses 48pt Sans Serif.

Instead of smart arse responses like yours, why not make an effort
to read the content and offer some contructive feedback.

alt.html used to be a cracking group. Now it's degenerated in to
the slop that is/was CIWAH. A bunch of in-crowd know-it-alls that
are simply here to inflate their egos by stomping on others. I know
- I've done it too, but now it's tiresome.

Wow. And this just happened to be the second post I read in here for
quite a while. Thanks.
 
W

Woolly Mittens

Andy said:
A common problem with AJAX apps that aren't carefully designed to avoid
this. AJAX kills servers because it encourages round-tripping to the
server for the most trivial user events.

You're right at that. Like rSS feeds, AJAX isn't supposed to be more
efficient at anything. It's more convenient in some situations, that's
all. Until servers can push informations to clients, pulling updates
periodicaly is the only way.

Then again, this is a game, it's allowed to be hingry. The only thing
flying up and down is updates, not whole game states.

For instance. Every 4 seconds it asks the server for an update. And you
get the hit on your ships, your current money and any new chats.
Offcourse if you DO more, you get more replies.

One could argue that instead of getting 10KB worth of HTML at a refresh,
you're getting 10 times 1KB of updates. One can make it as heavy or
light as one wishes.

Woolly
 
T

Travis Newbury

Andy said:
On 26 Jul 2005 03:51:53 -0700, "Travis Newbury"
The jury has already decided - maybe you don't agree.

I am not making a judgement on the technology, only my use of it.
One nice thing you can do with AJAX is to handle business logic with it.
You can describe business logic and run it on the server. Then you can
take this same description and use it to generate an AJAX client app
that emulates the same behaviour client-side. Or even better, you can
have a transparent client query the server from within the page, so as
to use the server to actually execute the logic. You could do this with
Flash (and friends) too, but you'd have to do three implementations.

Why would you have to do 3 implementations? One of out best selling
Flash applications (a live or on demand training/simulation
application) is completely data driven to include the creation, size,
placement, and content of objects on the screen. The developers use a
(VB.net) application to describe what they want (both layout and
content), it creates the Flash configuration (either XML or a table in
the database depending on the needs). The Flash object when it opens
reads the configuration from the XML file or the database, configures
itself (look and feel as well as functionallity) then runs. Business
logic resides on the server where it belongs. We support
ASP/Access/SQL Server or PHP/MySQL

There is no timeline, no layers, and no objects in the raw Flash
object. Only actionscript. This has the additional advantage of being
VERY small (49K if you use Media player for your video, 79K if you use
FLV video) so a Dialup connection is not a problem even with a very
sophisticated training course. The FLV video version will also run on
ANYTHING that supports Flash-7.
 
T

Travis Newbury

Woolly said:
Because I can and you won't and the customer likes to hear that.

Actually I was commenting to Andy (I think) who said I would HAVE to do
3 different implementations if I did the same thing with Flash. I was
disputing the "HAVE TO" part.
 
W

Woolly Mittens

Travis said:
Actually I was commenting to Andy (I think) who said I would HAVE to do
3 different implementations if I did the same thing with Flash. I was
disputing the "HAVE TO" part.

Oh sorry... I'm getting flameblind, with all the pro/contra flash
propaganda flying around. Personaly, I really dislike developers who
aren't openminded enough to see fitting solutions on other platforms.

Here I am, working for a microsoft gold partner, developing a webgame
optimized for Firefox using AJAX instead of "callBacks", playing sound
from a flash plugin. Life couldn't be more complicated. =^.^=
 
A

Andy Dingley

Why would you have to do 3 implementations?

Three implementations - good.

Effort of doing three implementations - bad.

Lets see how we put the business logic in our three different places: on
the server at form submission time, on the client, and on the server and
being used interactively by the client (through AJAX).

Now you can do any of these through a Flash-based front end too (been
there, did that with XML-RPC a couple of years back). But the problem is
that you're writing new code for each one. The first is in J2EE (or
whatever), and the second is in pure Flash. There's no way to go from
one to the other without re-coding by hand. The third one is even more
awkward - you need to integrate the two platforms and you're all on your
own for how to do it.

AJAX is a defined route. No matter how I back end it (apart from .Net,
which will obviously get it deliberately wrong) then I'm looking at the
same AJAX platform. From my client-side code, I see the same tools and
interface to code to. From the back end I see an integrated path that
can migrate my business logic almost dynamically, on demand of the user
and their particular platform capabilities for that session.
 
H

hyweljenkins

For me, the jury is still out on AJAX.

Why? We've being doing this sort of stuff for 6 years.
 
T

Travis Newbury

Why? We've being doing this sort of stuff for 6 years.

Because I havent seen an advantage over Flash. My Expierience has been
that Flash applications are much more powerful, flexible, and portable.


YMMV
 
T

Travis Newbury

Andy said:
Three implementations - good.
Effort of doing three implementations - bad.
Lets see how we put the business logic in our three different places: on
the server at form submission time, on the client, and on the server and
being used interactively by the client (through AJAX).

There is where we disagree. Putting the business logic in 3 places.
 
W

Woolly Mittens

Travis said:
Because I havent seen an advantage over Flash. My Expierience has been
that Flash applications are much more powerful, flexible, and portable.

Why are we discussing this with a flash-only developer? And what is a
flash-only developer doing this newsgroup?
 
A

Andy Dingley

Why are we discussing this with a flash-only developer?

Because Flash developers are the experts and we might learn something.

Flash sucks if you rely on the HTTP submission mechanism. A new page
means potentialy having to re-load the Flash. So as a result, the Flash
community were some of the first to develop widespread use of asych
techniques in web-apps. Macs seemed particuarly commonly used for this,
with Flash and XML-RPC turning into "Visual Basic for the Web"
 
A

Andy Dingley

There is where we disagree. Putting the business logic in 3 places.

You have to have it on the server, because you need to validate the
final submission.

You also want to have it available on the client, because that improves
usability. There are two efficient approaches to this: one is to
describe the logic formally by some form of predicate calculus. This
then generates different code for each platform automatically, but with
equivalent function. The other way is to code a distributable object to
some standard interface, then run copies of it on each platform.

The third option, that of asynch validation on the server may also use
these techniques, but usually it's done by proxying onto the same logic
already done for the server. Again this proxy layer is automatcially
produced.
 
T

Travis Newbury

Andy said:
Because Flash developers are the experts and we might learn something.
Flash sucks if you rely on the HTTP submission mechanism...

Spoken as a man with little or no knowledge of Flash.
 
T

Travis Newbury

Andy said:
You have to have it on the server, because you need to validate the
final submission.
You also want to have it available on the client, because that improves
usability.

It only improves usability if you reply on client side code. I
personally thing that is, well dumb.
 
A

Andy Dingley

Spoken as a man with little or no knowledge of Flash.

Flash sucks if you rely on the HTTP submission mechanism - the same
mechanism that is the default way of working for HTML forms. That's why
Flash developers were early adopters of the whole asynch approach.

How often do you see a HTML page with a "Loading..." spinner ? Flash
takes a hit when you do a reload of it. If you're good, it's a small
hit, but it's still too slow for an interactive app.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top