Re: Attempt to de-mystify AJAX

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
.

Relevant Pages

  • Re: Attempt to de-mystify AJAX
    ... 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. ... 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. ... 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. ... But I prefer to skirt around the issue by using frame sets. ...
    (comp.databases.pick)
  • Re: Attempt to de-mystify AJAX
    ... >> there is very little choice but to use javascript. ... So what does it matter if it's a true compiled language or not? ... > client-side control, you should be considering a thick client. ... >> frame approach and would prefer to not have to work with frames. ...
    (comp.databases.pick)
  • Curious IE 6 SP2 error.
    ... The portal works using frames, with one frame remaining on the portal ... The server side page does some processing (in this case adds ... The javascript is all dead. ... What's more if you refresh the page everything works fine. ...
    (microsoft.public.windows.inetexplorer.ie6.browser)
  • Re: Attempt to de-mystify AJAX
    ... the real advantage of Ajax is that it doesn't do a full page ... >> frame approach and would prefer to not have to work with frames. ... > Aside from everyone's attempts to say here that the old hidden/iframes ... >>> Javascript can work fairly well, but if you're writing it by hand, ...
    (comp.databases.pick)
  • Re: how to put in an HTML element the content of a txt file?
    ... Then you read the content of the .js file, that is not javascript more than I am an elephant, but a text, and then you in some tricky way put it where you want in the page. ... -when submitted, a form (targeting another frame), asks something to the server, and there goes the answer from the server: it's a javascript function that fills the array ...
    (comp.lang.javascript)