Re: Attempt to de-mystify AJAX
- From: "dawn" <dawnwolthuis@xxxxxxxxx>
- Date: 5 Nov 2005 06:05:31 -0800
Luke Webber wrote:
> 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 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.
>>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.
> 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.
> 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. 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.
> 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.
> 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.
> 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. I wish that Java could do it, but Java
applets can't cut it, 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).
>
> 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.
> 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.
> 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.
> 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.
> >>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.
> 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.
> 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.
> 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.
> > 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.
> > 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
>
> Cheers,
> Luke
.
- Follow-Ups:
- Re: Attempt to de-mystify AJAX
- From: Luke Webber
- Re: Attempt to de-mystify AJAX
- From: Glen
- Re: Attempt to de-mystify AJAX
- References:
- Re: Attempt to de-mystify AJAX
- From: Luke Webber
- Re: Attempt to de-mystify AJAX
- Prev by Date: Re: Attempt to de-mystify AJAX
- Next by Date: Re: How do we get there from here?
- Previous by thread: Re: Attempt to de-mystify AJAX
- Next by thread: Re: Attempt to de-mystify AJAX
- Index(es):
Relevant Pages
|
