Re: Attempt to de-mystify AJAX

dawn wrote: 
I recognize this is now way to long and not too pretty, but I'll click
send anyway.

Don't sweat it. By no there's nobody reading but you, me and maybe Chandru. But I'll snip hard, just in case. ;^)

Luke Webber wrote:
dawn wrote:
Luke Webber wrote:
[snip] 
Bingo. I'm not keen on the PHP approach either. In fact, even JSP
offends me if its scriptlet features are overused.


I agree!
I jumped into Java Server Faces (JSF) because you could supposedly use
it without JSP, using straight java code for everything.  But, alas, no
one had (or has) written the necessary components to make that work and
I wasn't up for being the first, so I did JSF with JSP.  I did learn it
to a very shallow depth, but it really was difficult to learn and then
you had JSF with JSP with tag libraries and all.  And, of course, you
need a servlet container in which to run it. And since it is still an
approach to client event handling on the server, it is suggested to
incorporate javascript where needed.  Ugh!

Oh crap! JSF? No wonder you think Javascript is OK by comparison. I dodged that bullet by the simple expedient of early adoption of servlet technology, then JSP. But /not/ JSF. Definitely a bridge too far.
I recently asked a question about JSF in one of the Java NGs, and one respondent said that his tests showed that, using Apache MyFaces, he saw a performance decrease of the order or 60 to 200 times a straightforward JSP solution.

Taglibs? Also not interested. Puts me in mind of the Tower of Babel. You write markup using elements that nobody except another Strusts developer can understand. And to be perfectly honest, even most Struts developers only understand a small subset of the tags, so you're pretty much boned from the outset.

But that's the way it is these days. The cycle of complexity has bitten deep. I recall with affection my old CP/M PC, and even my original IBM PC-XT (cost about AU$11,500, but it was /simple/). The crystal set. The teddy bear. Gotta snap out of this before I start getting nostalgic for my breastfeeding days. <g>

I like to hive the
real work out to JavaBeans and minimise the curious admixture of markup
and "real" code. In particular, I insist on keeping my business rules
and data access code in classes where they can be generally useful. I
don't want to mix my business rules in with a bunch of presentation
cruft. And even data validation properly belongs in the domain of
business rules.


Again, agreed.  It sounds like we have similar taste when it comes to
Java designs.

I knew you were a fellow traveller, Dawn. Now how do you do that with Javascript?

[compiled vs script] 
You can run jslint on your javascript, although I haven't used that.
Actually running the codes gives you your syntax errors in your
javascript console.  There are several tools to help test including
jsunit (if you are a junit user -- I'll confess I have only dabbled
with it and dismissed it at the time).  It looks to me like the tools
are in reasonable order to prepare tests, to write javascript with many
of the benefits of OOP, to use a debugger and several debugging tools
and even to run a syntax checker in advance if desired.  There is a
huge base of current developers which has grown in a big way this year
with the AJAX hype.  If it were only hype, I would not be one of those
who is setting Java on the shelf (alas) for a spell to work with PHP
and JavaScript.  IBM has some folks doing that too and they are big
time into Java.

IBM? Et tu, Brute? But then, IBM are also known for their commitment to RPG. And I've coded in C for OS/2 (writing Btrieve DLLs to be called from RPG - don't ask). And if OS/2 had had a funeral, I'd have been there, dancing.

And languages which require declaration of variables also
eliminate a lot of the more egregious errors before they can bite you.


There are pros and cons to strong typing.  If you took a stance against
it, I'd argue for it, but the thing I like about weak typing is the
agility / flexibility / productivity both in development and
maintenance of applications.  The downside is that it is easier to
write so that non-professionals or poor coders can write bad code fast
and deploy it just as quickly.  There is a lot of lousy java code out
there, but I'm sure there will be a lot more lousy javascript code.

Oddly enough, I wasn't even talking about strong typing. For all I care, you could declare all your variables as Variant. Just so long as you have to declare them.

Hell, with Javascript, if you reference a property that doesn't exist,
you get "undefined". In a proper, disciplined environment, you wouldn't
be able to get beyond the first compilation without fixing errors like that.

Yup, agreed. Again, pros & cons.

So tell me some pros. The only pro that I know is that the stuff runs in the browser, and I still think of that as a mixed blessing.

[snip] 
OK, I've just done a quick search and discovered that I'm a little out
of the loop. And I owe an apology to Chandru (sorry Chandru!). It
appears that Javascript does now possess some features that make it
/arguably/ OO.


Yes.  Those who are extreme in requiring OO are simulating things that
aren't very Java-like, such as inheritance.  I have been coding with
private instance variables and getters and setters.  I'm still catching
on to the prototype property.  After doing the little JavaScript I have
done, I'm starting to think I might enjoy it even more than Java.


Heretic. Infidel. Apostate. Witch. ;^)

But seriously, I enjoy that (non-existent) crystal set more than Java as well. And the teddy bear. My nearly 14YO daughter has a teddy bear named Barney. He's not pretty, but we all love him. If we ever lost him, it would be a life-changing event. Barney is comfortable and ugly-cute.

Java will never be like Barney. Java is big and complex. I prefer Barney, but Barney knows his place.

OTOH, Javascript also lacks a great deal that comes with most OO
languages. In particular, I don't believe that Javascript's inheritance
extends to existing classes that are part of the DOM. Nor is it
particularly useful in defining, for example, a standard form with all
menus, toolbars, buttons and other widgetry, which can be inherited by
all of its children. 

I'm still looking at the various design patterns being employed.  One
approach is to simulate Java-like inheritance by having the inherited
properties copied to all sub-classes.  I figure picking up a new
language is like moving to a new building.  Your office might be
further away from the rest room, but have a better view.  There are
trade-offs.  Java doesn't run in the browser and interact with the DOM.
 JavaScript does.

I work from home. For me, shifting to AJAX would be like moving my office into the bathroom. Convenient for some purposes, but otherwise less than optimal.

Javascript isn't going to get you a consistent L&F. CSS helps, but it's still not the answer.

I can also build myself a textbox which does data
validation on (for example) dates, or a GUI table which takes its data
from a SQL query, or from an XML stream. And /then/ I cn subclass my own
classes to provide other specific behaviours. These are powerful
features, and their lack must be felt.


yup

I any case, Javascript's other shortcomings have me firmly convinced of
the folly of trying to use it to develop full-blown applications. A bit
of syntactical sugar isn't sufficient to alter my world view that far.


I might need help from Chandru and others who have gone before, but I
intend to be successful with it.

I sincerely hope that you will be. And Chandru too. Though the curmudgeon within me argues otherwise. Hard to resolve such a conflict, isn't it?

I've become
intimate with both procedural and OO langauges and each has its charm.
At first I thought that JavaScript provided the worst case where you
had to understand objects without the benefit of enforcing OO.  As I
get into it more, it feels much more like I get the best of both
worlds.  The use of functions as constructors for objects is really
very nice.  Some aspects of inheritance seem painful, but the use of a
prototype object is also quite intuitive.

Ugh. We'll clearly have to agree to disagree here. 

I had to go through my own brand of therapy to get to the pont where I
could roll with it.  I'm coming from Java too.  I would MUCH rather be
able to code java in the browser and in the middle tier.  I could do so
in the middle tier if I were to switch ISPs and pay for a virtual
server environment or so in order to use tomcat.  But PHP is available,
so hopefully I'm not too old to learn some new tricks.

Dawn, you're an IT pro. Why not build your own server or find a new web host that supports the technology you /want/ to use?

In any case, this raises another argument that I have against the browser as a pervasive platform. You have to code stuff both in the browser and back on the serve, in two different languages. You're pretty well doubling the workload. And you're passing stuff back and forth in XML, which is far from being the most efficient data representation known to man. What's with that?

[snip] 
I gave Chandru the example of a program that I ran yesterday. It ran for
several hours before falling over because of a simple typo. That was in
MV BASIC on D3. Under jBASE or U2 I'd have got a compiler warning, but
not D3. And not in Javascript either.


If you are motivated to do so, you might try www.jslint.com. I haven't
tried it.


Ah, but you know that the motivation is absent. don't you?

[snip] 
Heh. Metaprogramming is the answer. Writing code that never has to run
anywhere. <g>


I'm trying to move from the "if you can't code, teach" phase back to a
"can code" phase.  Writing code on a white board with "..."
occasionally does have some advantages over having a machine talk back
to me.


Don't do what I say! Do what I /want/! <g>

[snip] 
Not really. Of course, a great deal depends on the nature of the app. In
any case, while there are certain things that can be done on the client,
there are always also going to be things that have to be done on the
server. You can validate dates, money amounts, social security numbers,
credit card numbers un so weiter, but you can't validate that a given
part number exists or is in stock. In effect, ECMAScript/Javascript is
only a partial solution at best, so what really is the point?


Separation of the front and back is the point.  Put the UI in
JavaScript and prepare your middle tier services in Java, PHP, Ruby,
Python, Perl (DataBASIC?) etc.  But don't mix 'em all up IMO.

And I agree with you, except that I consider "the front" to be better done as a fat client, not on a browser. Then "the back" is just a bunch of components that can be called either directly by the client, or hosted on the server.

> I wish that Java could do it, but Java

applets can't cut it, 

Actually, though it's unfashionable to say this, for the most part they
can, but again, you still need server-side logic.


I advised a Java instructor (I'm not teaching it right now) to teach
the UI with applets talking with JavaScript instead of with swing or
servlets.  It is a very cool way to learn Java, I think.  That adds
another language to the client.

I've done that before, but I'm not sure it was the smartest thing to do. Sometimes I think that LiveConnect was a very bad idea.

[snip] 
I've said it before. The whole BUI thing has been blown out of
proportion. Why does every new rich UI have to be browser-based? The
only answer is "fashion", and that's a damned stupid answer.

NO, NO, NO. Deployment, access, google, rss, etc.

Deployment isn't such a bother with JWS, and that covers access. Google? For a working, data-driven app that (usually) requires a secure login? Not going to matter, is it? RSS? I don't see the relevance.

> Fashion is not by 
any means the only answer.  I could speak for hours on this topic, but
I'll stop with that.


Thanks. <g>

Now somebody is going to interpret that to mean that I've predicted the
demise of the Web,


it sounds more like you are hoping for the demise of the browser.  I've
wished for something other than ECMAScript too, but now that I'm trying
to roll with it, it really isn't the awful language it appeared to be
at first glance.  I suspect that you were thrown in the water, you
could both learn to swim and enjoy some aspects of the sport.

You underestimate my grumpiness. ;^) 

We might have to put you through yoga classes too then.  Perhaps a
little zen.


Yoga makes me cross. Zen irritates me. ;^)

As for the browser, I love the Web. As an information tool, it's bloody
wonderful. As a pervasive platform for development and execution of
applications? Well, just "include me out".


Applications are all about information, brother.  Users don't want to
search on a particular field -- they want to google their data for
values, and have you (google) tell it what the metadata is where it
found the value.  Expectations for data delivery have changed.


Google as part of a live application? Spare me!

The Web should be for casual users to view your products and services,
and submit the odd order or email request. Or for in-house distributuon
of information. It should never have gone so far as to become a
full-blown application delivery vehicle. The Oracle Has Spoken. Amen. <g>


HUGE disagreement sir oracle.   [I've deleted several clever sentences
here -- sorry.]

I've seen these waves come and go. I'll ride it out. Not that I'm ignoring the Web, by any means. Webber by name, Webber by nature, that's me. I just like to keep it in its box, rather than letting it roam wild and eat my roses.

But seriously, one thing has been missing from this discussion. Whatever
happened to security concerns here?


I thought I did mention that.  Yes, there are such.

When I drop by a site and see that
it's doing a lot of heavy lifting inside my browser, I must admit that
it alarms me more than a little. The more powerful these tools become,
the more I feel like turning them all off and listening to my crystal
set instead. <g>


I don't have enough handle on JavaScript to know that someone couldn't
just use something like GreaseMonkey and change my source code,
altering the application in a very bad way.  More opportunities to
learn, I guess.  ugh.


Pass.

[snip] 
Nor would I. In fact, as you may have gathered, I don't /want/ the
browser to get any more powerful

well, you lose.

Frequently. But here I'll make a Prediction. One fine day very soon, there is going to be a massive backlash against the rising wave of adware and spyware. A great many people are going to start turning off Javascript along with ActiveX and even Java in their browsers. That's gonna hurt.

or complex. And that's not just because
I want it to go away, either. If that happened, how would I read
Doonesbury, Dilbert and Monty?

I must be reading too much tech stuff 'cause I don't now Monty. 

It used to be called Robotman...

http://www.comics.com/comics/monty/index.html

If you really need that much
client-side control, you should be considering a thick client.


It isn't "control" but usability and responsiveness at issue.  I've
been working with thick clients and I'm abandoning it because finally
it is feasible to get a similarly good user experience within a
browser.


Within strict limits, and not without the sacrifice of a lot of skin,
maybe. Although it's also possible to write AJAX code that is /less/
responsive, if you insist on performing field-by-field validation even
where that validation requires a round trip back to the server.

The asynch part makes that an OK thing to do, I suspect.

Nuh-uh. It'll make it /worse/. When the user types into a text box, then tabs and starts entering data into the next control, you're going to suddenly wake up and produce an error and drag him back to the previous control? I call that annoying. But perhaps I'm just easily annoyed. <g>

And let's not forget that you're shipping all this data around using XML. How many round trips do you really want to make with all that extra bloat?

[snip]
Hmmm? Why is it that you "hate" frames? Closed mind? <g> 

Ignorance, bad experiences, and a desire for simplicity.  If they work
better than something else, I can be flexible ;-)

They've always stood me in good stead. Frames and I go together like grace and poise. <g>

The beauty of frames is that you an let the browser do all the work. No
mucking about with hidden chewing gum, scripts or XML. Just toss the
request to the server and get the response back as HTML. The way God,
Nature and Tim Berners-Lee intended.

So why are people moving away from that approach? Original sin? 

Just wait till the Big Boy gets wind of it. You're all gonna catch Hell. <g>

[snip] 
Among Javascript's many other shortcomings, it's near-impossible to
reliably debug.


I am concerned about that, which is why I found the debuggers, even
though I haven't used them yet.

What's the bet you'll get runtime errors in production?

The exact same % chance as with any language I've ever coded in.

I happen to believe that JS actively encourages such errors, but perhaps jslint will go some way towards dealing with those issues.

Code that didn't
execute because you forgot to test some obscure combination of
circumstances,


so you do know me.  But the debuggers do permit changing values and, in
theory, I should be able to test all the code.  But I'll do a risk
assessment on that, I'm sure.

stuff that wouldn't get past compilation in a proper
language.


you are going to let me know if jslint takes care of this concern for
you, right?


I don't exactly have a vast library of Javascript to test it on, you know.

If it wasn't for the vast amounts of memory in modern
PCs, I bet that half the pages out there would be falling over with
memory leaks and other problems. Can't debug it, can't profile it, can't
do /anything/ with it. And the more Javascript you have, the harder it
is to guarantee cross-browser support.

As more people write it, it gets better as a developer environment.

Spare me. Silk purse, sow's ear. Compare and contrast. Discuss. 

I live in the biggest pork producing county in the USA and as a sow's
ear myself, I resent that.  OK, my real answer is that JavaScript can
be beautiful man.  Be one with it.


In a pig's ear. ;^)

[snip] 
me too, but I'm getting there.  I'm starting to like it more now that I
figured out (without reading this anywhere -- it was driving me nuts!)
that every object in JavaScript is an associative array (an array of
name-value pairs, where the values can be functions or properties).
Maybe it is stretching it, but you can then think of each javascript
object as a pick record/item with associated dictionary.

Surprisingly, that makes me like it /less/. <g> 

It seems to provide the agility of a procedural language, with objects
being a central concept PLUS the objects are all easy to understand
because they are just associate arrays.

Syntactic sugar. Colour me unimpressed. 

I meant "associative".  Not at all sugar. It feels simpler than (other)
OO languages.

"Simpler" is probably the correct word. Sometimes simple is good, other times, not. You can guess which I think it is with Javascript.

So, if you haven't mastered OOP yet, it gets you some of the way there
with a weakly typed procedural yet object-oriented-ish language.

Um, no. Not really. No, not at all. ;^) 

I don't know what is "not really".  If you have done your time with
OOP, you might appreciate being able to move faster.  If you haven't
and you only "believe in it" then there is nothing I can say, I'm sure.


I've apologised above, though in a typically qualified and curmudgeonly
fashion. Apparently JS does have some features which approximate to OO.
Must have missed them due to a combination of poor reference materials,
ennui and disaffection with other aspects of the language.


I understand. I think more of the OO-like work has been done more
recently as the Java crowd as moved into this territory.


This member of the Java crowd isn't getting involved.

[snip] 
Oh, I'd fight like a tiger if you tried to take my copy of _Dynamic
HTML: The Definitive Reference_...

http://www.oreilly.com/catalog/dhtmlref2/index.html

But I didn't find it until after I'd lost all my hair. 

I haven't exactly aged gracefully, but I'm hoping I don't have that
happen too.  I don't wanna buy another DHTML reference, so I can borrow
yours, right?  Take care.  --dawn


Well OK, but wash your hands. I don't want you getting ham all over it. <g>

Luke
.