Attempt to de-mystify AJAX

#41

"dawn" <dawnwolthuis (AT) gmail (DOT) com> wrote

Quote:

Luke Webber wrote:
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.

To me this has been the most major concern of putting any form of logic on

the client. To me any client side logic must be presentation only. I've
personally seen sites of my clients get hacked because they gave into
temptation to put the validation in the browser instead of safely on the
server. So once the user got into the page source they were able to twiddle
the variables to whatever they liked. This cost our clients quite a bit of
money to resolve. Fortunately we did not provide that software to them.

-Bob Coleman/PDX OR

#42

Luke:

Just a few comments embedded. :-

"Luke Webber" <luke (AT) webber (DOT) com.au> wrote

[snipped]

Quote:

I try to keep my mind open, but not so wide open that things keep falling
out. I have long experience with Javascript; I've learnt the pitfalls and
experienced the pain. I'm not arguing from ignorance or prejudice. You
might call it "postjudice" - an acquired bias.

It's amazing how often I seem to be picking my thoughts up off the ground
lately. :-)

[snipped]

Quote:

Refer to my response to Chandru's post. Compilation pereforms a lot of
useful functions, not the least of which is to point up syntactical and
typing errors. And languages which require declaration of variables also
eliminate a lot of the more egregious errors before they can bite you.

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.

As we all know, discipline is what each of us use to ensure quality.
However, discipline in computer languages is nothing more than a technogeeks
demand the rest of us do what we're told. Computing has turned into a great
deal of cludges and work-arounds!

How often is a basic understanding of principles useless when attempting to
solve computing problems; most important seems to be our direct experience
with a particular issue we're attempting to resolve or trial-and-error (we
explicitly know what to turn off and on in what order and what checkboxes to
check and which functionality to turn off with which equipment). This tells
me most of these protestations regarding OO, compilation, etc are beside the
point.

What is the point? To minimize costs of development and maintenance and
maximize stability. Multiple languages, platforms, middleware, hardware,
etc don't help. Using one piece of middleware over another is not the
answer because this simply replaces one set of problems with another.

Why is it that the check we write to pay our utility bill clears the right
bank and credits the right bank account? Cobol, maybe. In this instance,
none of us would suggest this stable software be re-written to use OO
techniques, multiple tiers, new operating systems and languages, etc. :-)

[snipped]

Quote:

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.

I used to have a colleague who persistently used a variable name of
DELIMETER (not the misspelling). It has not been a joy for me to maintain
his code, because I am a naturally good speller. Usually, I have to do a
global replace just to claw back some sanity, but if he was still working
on the same code, we'd be at cross purposes. I'd never know when my good
spelling or his bad spelling would result in an undiscovered back, lurking
in wait until a specific set of circumstances raises an error during live
running.

Learning how to type is probably the single most beneficial step to take to
reduce coding errors. This, of course, assumes the typist knows the
language they're working with.

[snipped]

Quote:

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.

Because everyone's got one. I'll say no more. :-)

[snipped]

Quote:

But seriously, one thing has been missing from this discussion. Whatever
happened to security concerns here? 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

A typical example of the cart before the horse. :-) Again, we'll probably
get more cludges and work-arounds!

[snipped]

Quote:

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.

IMHO it is logical, as a lot of mvDbms solutions exemplify, to validate
fields. To do otherwise, e.g. waiting until a form submission, says a lot
about the environment's limitations. Of course, there's always someone who
feels limitations are advantages; but let's get real about this.

[snipped]

Quote:

I'm not satisfied with anything. I'd be worried if I was. ;^)

It seems rational people agree on most things. :-)

[snipped]

Quote:

Hmmm? Why is it that you "hate" frames? Closed mind? <g

See the following:
http://www.useit.com/alertbox/styles_vs_frames.html
http://webdesign.about.com/cs/styleofframes/

It seems the general reasons for frames falling out of favor are: a) search
engine optimization, b) navigation issues, and c) accessibility problems
they can cause. Supposedly they are also more temperamental when it comes
to positioning on screen. Of course, we can always question "another"
technology.

[snipped]

Bill

#43

dawn wrote:

Quote:

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. ;^)

Quote:

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>

Quote:

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]

Quote:

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.

Quote:

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.

Quote:

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]

Quote:

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.

Quote:

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.

Quote:

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?

Quote:

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]

Quote:

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]

Quote:

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]

Quote:

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.

Quote:

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]

Quote:

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.

Quote:

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>

Quote:

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. ;^)

Quote:

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!

Quote:

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.

Quote:

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]

Quote:

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.

Quote:

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

Quote:

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]

Quote:

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>

Quote:

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]

Quote:

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.

Quote:

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.

Quote:

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]

Quote:

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.

Quote:

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]

Quote:

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

#44

Luke Webber wrote:

Quote:

dawn wrote:
Luke Webber wrote:
dawn wrote:
Luke Webber wrote:
[snip]

Oh crap! JSF? No wonder you think Javascript is OK by comparison.

I did jsp sans jsf before checking out JSF. There are things about it
that I like better than struts. The number of not-quite-great options
for a Java UI are embarrassing: awt/swing, swt/JFaces, struts/jsp,
jsf/jsp, and now ajax/dwr/struts (IIRC). Looking it over, I'm hopeful
that the last one will pan out for Java (google is doing that as one of
their options, for example). I'm sad to leave Java behind for a bit,
but there are reasons to do so, methinks.

Quote:

I
dodged that bullet by the simple expedient of early adoption of servlet
technology, then JSP. But /not/ JSF.

I was hopeful when it came out, but, ah well.

Quote:

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.

yikes

Quote:

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

Breast feeding must have been a whole lot easier for you than it was
for me. Don't you recall when the baby bit you when teething? Did you
use tea bags to keep from getting cracked nipples?

Quote:

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?

I've avoided it for many years while Chandru was getting the experience
I should have gotten too. I have flipped that bit now so that I can
now move forward with JavaScript. The other options all pale in
comparison for a rich UI with the amazing distribution and usability of
the web browser. You just have to flip your anti-JavaScript bit and
you'll be there too. Or you can dig your heels in for longer. You
don't have to buy into PHP, but I'd suggest using JavaScript with the
AJAX DWR Java libraries (IIRC) and Java.

Quote:

[compiled vs script]
snip
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.

Then just be sure to declare your variables. Sorry my mind wandered to
the related issue of declaring and typing. The lack of declaration
hasn't bugged me, oddly enough. I just declare them.

Quote:

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.

I think that if you dance with it a while longer and write it with an
OO approach to the extent feasible, you will start liking the
flexibility, the available libraries, the objects that are just
associative arrays (I think that is a very elegant approach), and even
the weak typing. I kicked and screamed my way to this spot, so it
isn't easy defending it, but now I'm wishing I had gotten here sooner
-- I'm not anywhere near being an expert, just at the point of being
willing to move forward.

Quote:

[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. ;^)

Sorry, my mistake. I'm more accustomed to the B-word however (I mean
"Boss") [reminds me of the time a young employee was asked quietly by a
friend of his "Who is that lady?" when pointing to me and my employee
said "That's no lady, that's my boss"]

<snip>

Quote:

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.

True of every language, however. In one of my email in-boxes is
someone trying to argue with me that the TNIV (Today's New
International Version of the Bible) is of the devil (or something like
that). His arguments and yours are starting to blend together. Men
are so emotional about language. Hmm.

Quote:

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

XHTML, CSS, JavaScript, PHP, and PICK = a lot of different languages
for me to learn with no guarantee I'll catch on enough to make great
UI's, but we shall see. I now have access to openQM (thanks to Tom
DeL), so stay tuned.

Quote:

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'm biting the bullet and you could too, or you could be a hold-out --
your choice. There is more than one way to write an app, but you know
there is some good logic behind my strategy, which is why you are
arguing about it. I set out to determine how to do rich UI in a
browser sans any SQL in the app and this is where current the landscape
directed me even when looking through a telescope.

<snip>

Quote:

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?

I want to use what makes sense for others to use too, taking on a bit
of an "industry analyst" role too. I want big bang for the buck
solutions that are also very easy to adopt. I think the easiest way to
write excellent, scalable software happens to include non-1NF, 2VL data
structures end-to-end. That is where I'm planting my stake in a way
that might be different from the rest of the industry. In other areas,
when it makes sense, I like to think I can be a follower too (doesn't
come easy, but I'm working on it).

Quote:

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.

Yes, I think that sucks big time. There is server JavaScript, but it
doesn't appear worth looking into right now. JavaScript was written
for what the browser needs to do.

Quote:

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?

I might pass it back and forth in JSON instead (is that the right TLA?)
-- array of tag-values.

Quote:

[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?

Now we are getting to the crux of the problem. I was where you seem to
be a short three months ago. A little meditation and rolling with the
flow might be in order ;-)

Quote:

[snip]

[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.

I did too until about a year ago, but the delivery by browser is just
too good to pass up IMO.

Quote:

Then "the back" is just a bunch
of components that can be called either directly by the client, or
hosted on the server.

snip
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?

Absolutely. You can use whatever search engine you want, but
old-fashioned "lookup" is going to be supplemented by searches across
data.

Quote:

Not going to matter, is it? RSS? I don't see the relevance.

You will, she says, not knowing if she believes this yet. Think of A9
(Amazon), RSS, atom as approaches to data management, not just document
metadata. If I ever know why I think these are relevant, I'll let you
know.

<snip>

Quote:

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!

You watch.

Quote:

[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.

I sortof forgot about all that now that I'm using FireFox.

Quote:

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?

No, mon. I could, for example, just quietly turn something red that
needs to be addressed and the user can come back to it when they want
to.

Quote:

I call that annoying. But perhaps I'm just easily annoyed. <g

It does sound like that is the case.

Quote:

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?

The round trips won't hold anyone up since they are done in the
background. I'm not an XML purest. JSON as a lighter weight way to
move things around might be better. I won't ignore performance.

--dawn

#45

Thanks for reasoned responses. As you know, I never been accused of
softpedalling my opinions!

"Luke Webber" <luke (AT) webber (DOT) com.au> wrote

Quote:

murthi wrote:
Oh come on Luke, you're going WAY overboard. embedded:

Ah, I remember the days when I was considered the firebrand of cdp. I pass
the flame to you, Chandru. Guard it well. <g

As always, these things are a matter of taste and opinion. Potato, potato,
etc.

"Luke Webber" <luke (AT) webber (DOT) com.au> wrote in message
news:436bd47e_2 (AT) news (DOT) melbourne.pipenetworks.com...
[snip]
It's the nature of Javascript that repels me, and you're never going to
persuade me otherwise. I choose to minimise the Javascript because
Javascript lacks all the advantages of true, compiled languages. No OO,
no rigour, no discipline. These have been hard-won benefits for me after
the laissez-faire days of MV BASIC, and I won't relinquish them to build
houses of cards, just because people now think that everything has to be
done client-side in the browser. It's a fad, and it too shall pass.

So what does it matter if it's a true compiled language or not? Not one
damn bit. Now if you said that it runs faster it is compiled, ok. If you
said it has a poor interpreter, ok. But to say that a language is somehow
deficient because it's interpreted is rot, as the British would say.

Several reasons. First, a compilation phase gives you the chance to
identify syntactical errors before the code is executed, and (wonder of
wonders) even to pick up /all/ of the syntactical, declarative and similar
errors in a piece of code in a single pass. Compare and contrast with
Javascript, wherein an error can lurk, unknown, until a rare circumstance
arises which causes the erroneous code to be executed. Now /that/ is rot
for you.

Compilation: Yes, But the disadvantage is the additional cycle time of
compilation. I can get into a rhythm of several windows, one changing the
javascript, the other checking it out immediately. Works for me.

The lurking code I'm not sure about. For instance, a typical run-error is
object/property unassigned. Since you can assign properties to an object
on-the-fly, there is no way of checking for an unassigned property at
syntax-check time. imo, this would be the same as for a compiled lang. True?
Most if not all common errors are caught by the JS syntax checker. I know if
you have a TRUE scripted lang a-la Pick-PROC, you WOULD have lurking syntax
errors, But JS is syntax-checked on loading. Are you somehow assuming the JS
is not syntax-checked before run?

Luke, just noticed your other post "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.'

eh?
How could you determine if line 3 is correct in compilation? Or is this not
legal in compiled langs?
var newproperty = 'my_very_own_property';
object[newproperty] = 1;
[3] if (object.my_very_own_property.value == 1 ) { .........}

Quote:

Javascript is NOT OO? What are you talking about? It's got objects, its
got properties, its got methods and all that rubbish that objects carry
around (instantiation , for example and all those new words I will not
use). (you do mean object-oriented, don't you? Or am I again barking up
the wrong tree?) Or is there some "computer science" rigid definition of
OO that js does not meet? Actually I'm sure there will be...

To borrow a term coined by Micro$oft, Javascript is "object based", but
not OO. You can use the defined objects available (the DOM), and you can
create new objects with their own properties. But in Javascript, you can't
extend existing classes (inheritance), nor can you deal with one object as
if it was another class of object (polymorphism).

Suppose you want to create a number of forms, all of which share similar
layout, toolbars, menus, buttons and what-not. In a truly OO language,
you'd build the essential elements into a superclass and then make all of
your concrete forms into subclasses. The result is a consistent look and
feel, and if you want to change it, you only have to modify a single piece
of code. You don't even have to compile the descendant classes.

Compare and contrast with Javascript. I'm frankly astonished that you dare
even try. Truly Chandru, I have a great deal of respect for you, but if
you're going to call Javascript OO, you're making it abundantly clear that
you have no real understanding of the meaning of the term.

Well, I will cop to not knowing OO very well, so I tend to shoot from the
hip about its characteristics.

Mea culpa, too, its because I do have a healthy disrespect for the
complexities imposed by modern programming langs. (Bill H: "However,
discipline in computer languages is nothing more than a technogeeks demand
the rest of us do what we're told. Computing has turned into a great deal
of cludges and work-arounds!") Great deal of truth in that. Coming from a
non-computer-science mindset, and having been thrown into the Pick OS at a
time I didn't even know what assembly language was, I like a wide-open
approach. I'm not interested in the let's save the poor programmer from his
own misdeeds approach. If you have a good programmer, you'll get good code,
be it in assembly or OO.

The issues of theoreticians do not always mesh with the requirements of
practicality (vide next). imo, we got along quite well for decades without
the restrictions of "true" OO (sort of like getting along without the
restrictions of true database, see the parallel) and now that its the
standard, we all have to abide by it. That's why I like JS - it has some of
the practical features of OO but is quite non-restrictive. (I'm in Dawn'
camp on liking JS because it provides somewhat of the best of both worlds.)
I like the "limited inheritance" and other features and use them all the
time, and, up to this point, have not missed what's not there

For instance, JS allows you to redefine functions, since they are objects,
n'est pas? Probably true of all modern languages, no? Well, this leads to
screw-up when you include files which happen to have a buried function that
is the same name as one of yours. So is this a good feature? or not? Just
means you have to be fully aware of its "limitations". And you can take
advantage of it.

Quote:

Yes, it does not have typing. but it you could give me ONE SUBSTANTIVE
reason a variable has to be typed, other than computer-scientist's
distaste for it and other than trying to sometimes prevent poor
programmers from using poorer programming practices, I'll buy you a
drink.

That term "substantive" tends to be rather subjective, but I'll venture a
shot nevertheless.

Just today, I ran a newly-minted MV BASIC program nearly to completion,
only to have it fall down when it was in the final phases. It took a few
hours to get to the point of failure, too.

So, what was the problem? A simple typo. I initialised a variable under
one name, then tried to use it with a slightly different spelling. Hours
of runtime wasted on an error which would not have occurred if all
variables were required to be declared.

But it gets worse. Suppose this wasn't a simple, straight-line process,
but a complex program with a lot of conditional logic. You could test the
bejesus out of the thing, but still not find the typo until a chance
combination of circumstances arose under live circumstances. Result? Data
corruption, downtime, possible disaster. Or maybe just a runtime warning.
Who knows?

When Micro$oft first released Visual BASIC, they chose to provide for
implicit variables without declaration. Fortunately for the language, they
brought in the OPTION EXPLICIT meta-statement in version 2. In version 3,
OPTION EXPLICIT was the default, and good thing too.

I can construct a bad-case scenario as well. Why is this any different than
if you actually DECLARED two similar variables (happens all the time) and
then misused them? Obviously, the UV style "variable has not been assigned"
would help in many cases. So would a simple variable assignment checker
(known as the X option on old mv). The point is, there'll always be bugs and
variable typing doesn't help much. Btw, I said variable "typing" not
"declaration", so your example would have to be changed a bit (a typed lang
would catch misuse of a number into a string due to a typo, otoh, it
wouldn't catch the typo, obviously, if both were the same type). So I say
this is moot.

Quote:

House of cards??? I have some of the most complex programming I've ever
done over the last three years that's been running flawlessly (and if
you're somehow going to reference anything I said before, I still don't
LIKE javascript because I don't LIKE any modern language that has the
weirdities of methods, properties et al, and I still don't LIKE the
occasional lack of rigor, ok). But what modern language does not have
flaws??

So you want to argue the benefits of Javascript over other modern
languages even though you hate them all? I'm not going to argue that
modern languages don't have flaws, but I'm going to stick my neck out and
say that Javascript isn't really a modern language at all. It's just a
souped-up scripting language that is (usually) tied to a browser. It's the
browser integration that make it so pervasive, not any particular feature
or advantage of the language. Blame Netscape.

Lack of discipline? I can write bad code in any language, and I can write
good code in any. It's nothing to do with the language.

I tend to disagree (surprised?). A language which enforces certain
disciplines without getting too much in the way can be a real boon to
productivity, and Javascript is not that language. I used to do some
surprising things with Visual BASIC version 1, 2 and 3, but that doesn't
mean that I was blind to its obvious faults.

Now somebody is going to interpret that to mean that I've predicted the
demise of the Web, but all I'm really saying is that AJAX is a lousy way
of doing things, and /that/ is a fad. If you really need that much
client-side control, you should be considering a thick client. There are
mechanisms available today to keep a thick client up to date via HTTP,
without all of the installation and upgrade headaches we've all come to
know and hate. Java WebStart springs to mind.

We need that control and Yes, it's MUCH easier to do things client-side!
At least for me. And I like the fact that I can actually tell what the
code is that I'm running because it's scripted. Since you call .net a
'black box" I assume you're wary of such, and therefore find it puzzling
that you prefer another level of installation software and procedure,
with all its attendant possible failures and errors, to the simplicity of
javascript.

Javascript may be simple, but it's not a silver bullet. For me, server
side Java and JSP are greatly to be preferred. Even ASP or ASP.NET is
preferable. Even PHP (though I have my own reasons for disliking PHP).
Again, this is a matter of opinion, and that's mine, for the reasons
already stated.

Never said silver bullet, just simple and useful.

Chandru Murthi

#46

Hi Luke,

My apologies first for not having digested this whole thread. I hope
that my haste and skimming have not caused misunderstandings but
something that struck me in this message. Also please forgive the top
posting.

It is my assumption that you use one of the PICKlike systems else you
wouldn't be here?

It seems that the bulk of your dislike for javaScript (and I infer PHP)
consists of the weak typing, lack of variable declaration requirements,
mixture of data and display, lack of enforced validation and so on.

The list seems almost note for note to match the litany of objections
that the Relational Database folks have to MV environments.

My objections to javaScript are centered on two dislikes, one trivial
and one not:

I don't like javaScript having its guts hanging out in the browser.
(trivial)

What really bothers me about javaScript is the fact that I can't know
in which interpreter my programs will be run. A little like writing
BASIC programs without knowing if (or when even) they will be compiled
with the QM, D3, U2 or ??? compiler. We have all done that at different
levels but what a pain ...

javaScript as a language shares some things with my choice of languages
for most of these tasks: PHP. They both also have similarities to
MV/BASIC in the very things that you seem to dislike. To me those are
strengths - the conceptual similarities (for me at least) make it much
easier to use two languages together.

Guess we each have our likes and dislikes: for me the baggage needed to
run Java for the simple programs required by these technologies far
outweighs any advantages in 'rigor and discipline' it may offer.
-Tom

Quote:

dawn wrote:
Luke Webber wrote:

Not a PHP man myself, but I'm with you on minimising Javascript and
maximising the server side.

Because there are things you simply cannot possibly do that many
developers will want to do in a browser interface today or very soon,
there is very little choice but to use javascript. Once you bite that
bullet, you just might be better off reducing the server-side scripting
complexity or you could end up with the worst of both worlds.

It's the nature of Javascript that repels me, and you're never going to
persuade me otherwise. I choose to minimise the Javascript because
Javascript lacks all the advantages of true, compiled languages. No OO,
no rigour, no discipline. These have been hard-won benefits for me after
the laissez-faire days of MV BASIC, and I won't relinquish them to build
houses of cards, just because people now think that everything has to be
done client-side in the browser. It's a fad, and it too shall pass.

Now somebody is going to interpret that to mean that I've predicted the
demise of the Web, but all I'm really saying is that AJAX is a lousy way
of doing things, and /that/ is a fad. If you really need that much
client-side control, you should be considering a thick client. There are
mechanisms available today to keep a thick client up to date via HTTP,
without all of the installation and upgrade headaches we've all come to
know and hate. Java WebStart springs to mind.

Well yeah, it probably does, given the cost of round-tripping. More to
the point, the real advantage of Ajax is that it doesn't do a full page
refresh, and I guess that's significant for some applications. But I
prefer to skirt around the issue by using frame sets.

OK. That still works. I only watched from the side with the hidden
frame approach and would prefer to not have to work with frames.

But frames have all sorts of advantages. You don't want to go reloading
boilerplate stuff like menus, page headers, logos and other artwork when
you can just stuff them in a frame and keep them there! I generally go
for a side frame with the menus, a top frame with the page banner (if
needed), and a central frame where the real work takes place. Then, if
the user wants to get a designer involved, I can tell them "You can play
with THIS frame or THIS frame, but hands off the big one in the middle,
because that's MINE". <g

And because the central frame just has real working data in it, it's
relatively fast to reload.

Somebody in this thread said something about frames acting differntly in
different browsers, but I've never seen that problem, and I'm a
full-time Firefox user these days. IE only gets used for testing.

Javascript can work fairly well, but if you're writing it by hand,
productivity is likely to be pretty low. Generated Javascript can do the
job handily as well,

If the code that is going to run is javascript, I would much rather
code it directly than have it generated in a non-round-trip fashion.

Among Javascript's many other shortcomings, it's near-impossible to
reliably debug. 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.

The reason I mentioned generated Javascript is that at least you might
have a chance of putting together something that doesn't have built-in
bugs. Something like the way that ASP.NET does its (black) magic.

but I have trouble learning to love it.

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

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. ;^)

Then you need to learn the DOM, of course, which doesn't take too much.
http://www.w3schools.com/js/ was helpful. --dawn

It takes too much alright. The DOM is as ugly as aa hatful of monkeys'
bums. OTOH, I find this very useful in dealing with it...

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

Cheers,
Luke

#47

Hi Luke,

Wishing that I had seen this before but another couple of quick
comments:

<SNIP>

Quote:

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.

And I missed this, sorry. Dawn mentioned jslint, isn't that workable
for those requirements? Virtually all modern languages have some sort
of lint-like.

Quote:

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.

If you need to do stuff in the browser it is sort of the only required
blessing.

<snip>

Quote:

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

Agreed.

<snip>

Quote:

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?

{Sigh} Seems that all of the side show side tracked the idea for the
original post: de-mystifying (and debunking) the AJAX method. In that
post I attempted to point out:

Quote:

A BIG note: Part of the mystification of this method seems to be the
XML part. I don't know whether you noticed but there is NO XML code
or
data whatsoever invloved in this example.

The reason that XML is even part of the name is that the javaScript
method used is XMLHttpRequest() - a method developed for XML use. We
can use it just fine for HTML or just plain text.

In all of my use of AJAX (which includes some fair sized applications)
I have never used XML, Usually the scripts involved simply output the
text that they acquired from the database. The client-side scripts then
simply stuff that text into a formatted space in the 'html' document.
It is really very simple.

Chandru likes javaScript and uses it for much more (data manipulation,
formatting and such) ... I am not fond of it so just use it where I
have to.

<snip>

Quote:

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.

<snip>

Quote:

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.

And here we are probably talking apples and bowling balls. Most of my
work in this area is specifically for the public web. It is simply not
possible to pass our thick clients to each visitor. Even if I could (MM
Flash?), just forcing people to download something chases most of them
away.

<snip>

Quote:

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

Another reason that I like to have PHP doing the bulk of the work. But
that may only be due to my having more experience there.

Thanks for your input,
-Tom

#48

Tom deL wrote:

Quote:

Hi Luke,

My apologies first for not having digested this whole thread. I hope
that my haste and skimming have not caused misunderstandings but
something that struck me in this message. Also please forgive the top
posting.

It is my assumption that you use one of the PICKlike systems else you
wouldn't be here?

It seems that the bulk of your dislike for javaScript (and I infer PHP)
consists of the weak typing, lack of variable declaration requirements,
mixture of data and display, lack of enforced validation and so on.

The list seems almost note for note to match the litany of objections
that the Relational Database folks have to MV environments.

I've noticed that a well Tom. It does play in to my preferance for PHP over
other tools on the server side of web apps. Your PHP to QM hooks make it
all the more a preferable tool. I have not had the chance yet to use
these in production yet.

But PHP string handling tools are far less tight than the MV functions.
MV has a couple dozen. PHP has *too many*. I find I need to write a
small PHP function (for strings) to get a simple MV string handling
Command functionality. LOCATE, FIELD, etc.

That said compared to how javeScript handles these..... PHP ain't bad.

Quote:

My objections to javaScript are centered on two dislikes, one trivial
and one not:

I don't like javaScript having its guts hanging out in the browser.
(trivial)

What really bothers me about javaScript is the fact that I can't know
in which interpreter my programs will be run. A little like writing
BASIC programs without knowing if (or when even) they will be compiled
with the QM, D3, U2 or ??? compiler. We have all done that at different
levels but what a pain ...

Amen.

Patrick <;=)

<snip>

#49

"Luke Webber" <luke (AT) webber (DOT) com.au> wrote

Quote:

dawn wrote:
I recognize this is now way to long and not too pretty, but I'll click
send anyway.
[SNIPP]
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?

My 2+ cents. 1) Don't see how you can avoid coding in several languages. For
my part, I have server code in UV Basic, and JS. There is obviously some
other layers in between but it's so minimal it's basically static code. Ok,
so how can we possibly improve on 2 languages? There are also a couple of
ActiveX objects but I just use 'em, and they've been pretty static too.

2) All the concerns about mixing UI/business logic and what have you. In
reality, how critical is this? Now, I hardly ever write any end-user
applications in our product, but the product itself is probably the most
complex application, so I've plenty of experience with that. So do I worry
about the distinction between where and what language to code in? No. If
it's server side stuff like almost all of it is, it's coded in Basic. Almost
all of the JS is control stuff, with some obvious exceptions, client-side
validation being one. When I say control stuff, I mean UI for the most part.
Btw, application programmers are discourged from JS, but they code plenty of
snippets when they need to.

3) we don't pass stuff back and forth in XML, unless there's a layer I'm not
aware of. Showing my deliberate ignorance, I will state that the clientside
submit JS seems to pass name/value pairs of data. This magically appears in
the gateway Basic program as (guess what) a dynamic array (there is a little
C glue code somewhere), so you pick off the value of a variable by a Locate
on the name string.

How much more easy than that can it get? The data set is comprised of
control information (typically static, so while it's a couple of dozen
name/value pairs now, it could be reduced to one or two, since the session
handle can lead you to all the rest server-side). And the actual data,
which, as I've mentioned before, is only user changed data to keep the
traffic low. While at present the changes are cumulative till Save or Cancel
(kinda like an incremental filesave), it could just as well update state on
the server on every server call, thereby further minimizing traffic (since
only the changes from the last submit would then be submitted).

So I read all this stuff : worries about browser technology, fears about
obsolescence, the relative merits of different languages, etc and wonder why
it's been so easy for me (so far).I really see a "theoretical" concern here
that's hard to see in reality. Sort of like worrying about which cell phone
to buy, because if you worry too much you'll never get one because it's
outdated. Also, if there's concern about multiple languages,what's with the
endless speculation about new ones?

Quote:

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.

Totally agree with Dawn here.

Quote:

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?
See above.

Quote:

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

Examples, please. Other than the obvious non-typed vars (which imo don't
lead to any "more" errors), and declaring vars (which may).

Quote:

And the more Javascript you have, the harder it
is to guarantee cross-browser support.

If you KIS, javascript will run on any browser. It's not the JS that's the
problem,. it's the html - layers vs divs, different referencing mechanisms,
different rendering techniques, etc etc. Also not mentioned so far in this
thread is the biggest bugaboo of all when using browsers- the user's
preferences. You have to watch out pretty closely to not use a feature that
can be negated, or test for it at least.

Chandru Murthi.

#50

(latimerp) wrote:

Quote:

Tom deL wrote:
What really bothers me about javaScript is the fact that I can't know
in which interpreter my programs will be run. A little like writing
BASIC programs without knowing if (or when even) they will be compiled
with the QM, D3, U2 or ??? compiler. We have all done that at different
levels but what a pain ...

Amen.

I picked this up from the jScript helpfiles

function GetScriptEngineInfo()
{
var s;
s = ""; // Build string with necessary info.
s += ScriptEngine() + " Version ";
s += ScriptEngineMajorVersion() + ".";
s += ScriptEngineMinorVersion() + ".";
s += ScriptEngineBuildVersion();
return(s);
}

I believe there are similar functions for other browsers, and along
with the logic to checked for the type of browser, you can also
interrogate the engine if you really need to. However, within the
context of this thread (ie:relating to AJAX) a certain baseline
functionality could be assumed & coded to (ie: you are NOT going to use
IE3 & AJAX) with relative ease, and if you look at practical examples
of what you REALLY need or want to do on a day to day basis, rather
than obscure, theoretical cases, I believe you will find that it
probably doesn't matter what version of jScript you are using, because
the subset works everywhere - though your own high level functionsmay
be platform optimized

BTW Tom,if you google this group you will see that Luke does have a
passing interest in MV (though I note that he has just lost his top
poster ranking to TG to this group..... and considering the average
length of Tony's posts, that IS a mammoth effort !)