Re: Attempt to de-mystify AJAX

dawn wrote:
Luke Webber wrote:

It's the nature of Javascript that repels me, 

and did me too, initially

and you're never going to
persuade me otherwise.


Hmmm.  I don't know why you would take a stance like that in this
profession.  OK, I won't try to convince you, but might comment for
readers who keep their minds open.

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.

From a rather negative standpoint, from a position of ignorance (book 
knowledge only), I dislike PHP at least as much as JavaScript.  I've
decided that I need to use both, however.  One question for me is how
complex the code will be for someone to learn it, read it, and maintain
it. I know it makes complete sense to people who are using a LAMP
approach that they would code a php document that includes html, css,
php, javascript, and SQL all in a single document of source code,
sometimes even a very small document.

Perhaps this approach only offends a sense of elegance that needs to be
transformed for today's software, but that sense is based on a desire
for maintainability.

Bingo. I'm not keen on the PHP approach either. In fact, even JSP offends me if its scriptlet features are overused. 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.

I choose to minimise the Javascript because
Javascript lacks all the advantages of true, compiled languages.


What in the world does compiling or not have to do with it?  DataBASIC
and Java are both "compiled" to byte-code.  Do they also lack all of
the advantages of "true, compiled languages"?  If you say that
JavaScript has performance issues, then we can address the issue.  If
you say that the source code is visible in the clear to anyone who
wants to steal your code, then we can address that.

Saying "it isn't compiled" as the big problem with it is making we
wonder if you have studied languages too much or not enough to have
such an aversion.  I'm curious which it is.

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.

No OO, 

I am just getting into JavaScript and did the research at the start of
the summer to figure out where it fits in the language landscape.
There are respected sites and people who say it is OO and those who say
it isn't.  You can find plenty of web pages with comments on how to
code JavaScript in an OO way.  My understanding at this point is that
it is a language with which you can write either procedural code or OO
code, which means to me that it isn't strictly OO.

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.

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

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

no rigour, 

Whether using C, Java, DataBASIC, Fortran, or COBOL, it is the
developer who brings rigour to the table.  I suspect you are referring
to the fact that it is loosely typed.  There are definitely good things
for a developer about compile-time type checking as found in Java, for
example.  But it isn't the only approach that yields good results and
hasn't shown itself to be a high productivity approach. If you say you
have Java code past the compile phase, it doesn't give me any more warm
fuzzies than if you have DataBASIC past the compile phase even though
you had to work harder to get the Java code there.

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.

no discipline. 

I wish.  Dang it, that code still insists on being written the way it
expects things and not always the way I write things.

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

<URL:http://www.mudcat.org/@displaysong.cfm?SongID=5509>

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.


Sure and if you are fine with missing the rich user interface in a
browser fad, feel free.  I'm telling you what others will -- there is
only one game in town if you want your browser application to react to
the user.  That is ECMAScript.

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?

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

JSP can only do the push thing that php and asp
do, and Java applications can be launched from a browser, but cannot be
BUI's.  Flash has its charm too, I'm sure, but doesn't make sense to me
to use for rich user interfaces of database applications (although if
someone with more knowledge or experience than I disagrees, I'd be
interested in hearing).

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.

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

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

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>

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>

but all I'm really saying is that AJAX is a lousy way
of doing things, and /that/ is a fad.


I will agree that I would prefer to use the same language at the front
end of an app as in the middle tier and back-end and that is not
feasible in today's environment.  I try to look into the future,
however, and the browser looks pretty solid as an application delivery
platform for many reasons, so I'm adopting is as the run-time
environment environment (operating system-ish) for applications.  I
need to write code that runs in that OS and, dag nab it, that means it
is a language that Microsoft, IBM, Sun, Netscape, Google, and other
players all go along with.  They aren't in discussions or agreement
about anything but ECMAScript related to the browser langauges.  It is
amazing we are this far and I won't hold my breath for another langauge
to operate in both Firefox and IE, for example.

Nor would I. In fact, as you may have gathered, I don't /want/ the browser to get any more powerful 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?

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.

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.


Been there, done that.  If you are satisfied with it, you're a better
man than I.


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

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 might be missing something since I have no production quality apps in
AJAX, but what is the downside of putting them in hidden divs?  I saw
code on how to load images in advance and it didn't include frames.  I
definitely would not want to use visible frames since I hate to use
them.  I will only use invisible ones if I can't get the job done
without them of it they are substantially easier to learn & maintain
than not using them.


Hmmm? Why is it that you "hate" frames? Closed mind? <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.

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.


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? Code that didn't execute because you forgot to test some obscure combination of circumstances, stuff that wouldn't get past compilation in a proper language.

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.

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> 

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.

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.

There ya go. Me being a curmudgeon again. Who'da thought it? ;^)

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


I can see that you are putting too much emotional energy into it.
Otherwise it isn't too hard to learn the DOM.  (smiles)

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

That's one I've perused in Barnes & Noble and it does look good.  I
have a handful of others on my shelf (The Visual Quickstart Guide:
DHTML and CSS books from Jason Cranford Teague, for example). Best
wishes.  --dawn

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.

Luke
.