G
G Matthew J
interesting "signal vs. noise" blog entry:
http://37signals.com/svn/archives2/whats_wrong_with_ajax.php
http://37signals.com/svn/archives2/whats_wrong_with_ajax.php
V
VK
what's wrong with ajax?
Nothing wrong with AJAX. After "MSXML" instability bug will be fixed,
it's going to be what it is: a good piece of code where a lot of
programming knowledge being expressed on a rather narrow space.
The "wrong" is with the idea of XMLHttpRequest as it was implemented by
Firefox and Co.
In Explorer MSXML / Microsoft.XMLHTTP pair is just an element of the
concept Microsft is pushing on the market. In this concept the rather
old idea of separate data/layout/styling/behaviors sources is brought
to its upper limit. So XMLHttp request is an integral part of the data
island technologies. In the perfect case (which is nor reached yet) you
just serve the XML *data* from the server, and this data will define
itself what layout/styling to use and what behaviors to attach
depending where did it appear (desktop, PDA, cellphone or even more
ecsotic places). And each node in this data knows which chunk of the
newly received information should replace the current node value. So in
the ideal you just need to get the data, and the actual page update is
up to the page itself (this is the whole idea of the "data island").
Firefox and Co either didn't understand this concept, or it's simply
not up to them right now. In their implementation XMLHttpRequest became
some kind of "new and cool" replacement for the old "hidden frame"
trick. So if you still load server data into a hidden frame, you're
lame. If you load it using XMLHttpRequest - you're cool.
I guess Microsoft people are laughing their heads off by watching all
wannabes organized this chiken run: who will implement first the
coolest and the most bug free replacement for the hidden frame.
Nothing wrong with AJAX. After "MSXML" instability bug will be fixed,
it's going to be what it is: a good piece of code where a lot of
programming knowledge being expressed on a rather narrow space.
The "wrong" is with the idea of XMLHttpRequest as it was implemented by
Firefox and Co.
In Explorer MSXML / Microsoft.XMLHTTP pair is just an element of the
concept Microsft is pushing on the market. In this concept the rather
old idea of separate data/layout/styling/behaviors sources is brought
to its upper limit. So XMLHttp request is an integral part of the data
island technologies. In the perfect case (which is nor reached yet) you
just serve the XML *data* from the server, and this data will define
itself what layout/styling to use and what behaviors to attach
depending where did it appear (desktop, PDA, cellphone or even more
ecsotic places). And each node in this data knows which chunk of the
newly received information should replace the current node value. So in
the ideal you just need to get the data, and the actual page update is
up to the page itself (this is the whole idea of the "data island").
Firefox and Co either didn't understand this concept, or it's simply
not up to them right now. In their implementation XMLHttpRequest became
some kind of "new and cool" replacement for the old "hidden frame"
trick. So if you still load server data into a hidden frame, you're
lame. If you load it using XMLHttpRequest - you're cool.
I guess Microsoft people are laughing their heads off by watching all
wannabes organized this chiken run: who will implement first the
coolest and the most bug free replacement for the hidden frame.
R
Razzbar
Hehe, let 'em have it, VK. That was a good post.
I was lame until about a month ago, and now I'm cool, if I'm reading
you correctly. This 'new AJAX thing' is something I'd been looking for
for quite some time -- a way to fetch something less than a whole darn
page from a server. I got the hidden iframe thing down pretty good,
except for the back button. The workarounds didn't work for me. Now,
with AJAX the back button isn't quite as broken, but hey, we're trying
to write -applications- here, not web -pages-. A back button is a
natural thing for an online catalog, but have you ever seen one on an
inventory update program?
What happens when you hit 'back' after entering data? Does the database
delete your previous entry?
My initial impression of developing with AJAX is that it seems to lead
to clearer code, it seems to be faster, but it's MUCH harder to debug.
With an iframe, you just don't hide it if you want to see what the
server is sending. I haven't found a good general, simple way to debug
an ajax server script -- yet.
AJAX is also not quite as flexible as an iframe, because you can load
up your iframe with all kinds of javascript, where with an AJAX
request, you get some text to deal with, and the eval(responseText)
trick seems like dirty coding to me.
But, I think I'll stay with it and see what I can come up with. I have
to admit I haven't caught on to XML, mostly because of the lack of
clear, simple examples that I can actually try. But I do like the
simplicity and directness of just calling the server for some data,
without having to pretend I'm not really getting a page and shuffling
stuff off to the parent.
I think we're going to see a LOT of ajax applications in the near
future. I expect it to be very, very significant.
I was lame until about a month ago, and now I'm cool, if I'm reading
you correctly. This 'new AJAX thing' is something I'd been looking for
for quite some time -- a way to fetch something less than a whole darn
page from a server. I got the hidden iframe thing down pretty good,
except for the back button. The workarounds didn't work for me. Now,
with AJAX the back button isn't quite as broken, but hey, we're trying
to write -applications- here, not web -pages-. A back button is a
natural thing for an online catalog, but have you ever seen one on an
inventory update program?
What happens when you hit 'back' after entering data? Does the database
delete your previous entry?
My initial impression of developing with AJAX is that it seems to lead
to clearer code, it seems to be faster, but it's MUCH harder to debug.
With an iframe, you just don't hide it if you want to see what the
server is sending. I haven't found a good general, simple way to debug
an ajax server script -- yet.
AJAX is also not quite as flexible as an iframe, because you can load
up your iframe with all kinds of javascript, where with an AJAX
request, you get some text to deal with, and the eval(responseText)
trick seems like dirty coding to me.
But, I think I'll stay with it and see what I can come up with. I have
to admit I haven't caught on to XML, mostly because of the lack of
clear, simple examples that I can actually try. But I do like the
simplicity and directness of just calling the server for some data,
without having to pretend I'm not really getting a page and shuffling
stuff off to the parent.
I think we're going to see a LOT of ajax applications in the near
future. I expect it to be very, very significant.
V
VK
But, I think I'll stay with it and see what I can come up with.
I do not encourage any one to "stay lame" with hidden frames!
I just 'd like to state that getting some structured/non-structured
server data via XMLHTTP is not the cutting edge of the progress. In the
reality it's just scraping the surface of something much bigger and
more complicated.
I also see two generic "unstability ussues" in AJAX and its incoming
clones.
(1) Memory clean up on unexpected termination (user closed the browser
window). With hidden frames this equals to the standard situation when
I started to load a page and later changed my mind. This situation is
such a trivia that it's bulletproof covered starting from the oldest
browsers. From other side internal XMLHTTP objects tends to show
instability in such situations.
(2) AJAX has no internal thread limitations (?). This encourage users
to think that they can open 100, 200 or 1000 threads (up to the
resource limits). In fact maxWorkerThreads in .NET is limited to 25
concurrent connections per processor (and .NET is the most generous one
in the comparison of HTTP). So if you say open 100 connections to your
server, you both cracking XMLHTTP and violating your license agreement
with Microsoft.
P.S. I really cannot imagine a need for even 2 concurrent connections
unless someone is sniffing my browsing history (using timed download).
In all other cases it's an indication of a very badly designed page
interface.
I do not encourage any one to "stay lame" with hidden frames!
I just 'd like to state that getting some structured/non-structured
server data via XMLHTTP is not the cutting edge of the progress. In the
reality it's just scraping the surface of something much bigger and
more complicated.
I also see two generic "unstability ussues" in AJAX and its incoming
clones.
(1) Memory clean up on unexpected termination (user closed the browser
window). With hidden frames this equals to the standard situation when
I started to load a page and later changed my mind. This situation is
such a trivia that it's bulletproof covered starting from the oldest
browsers. From other side internal XMLHTTP objects tends to show
instability in such situations.
(2) AJAX has no internal thread limitations (?). This encourage users
to think that they can open 100, 200 or 1000 threads (up to the
resource limits). In fact maxWorkerThreads in .NET is limited to 25
concurrent connections per processor (and .NET is the most generous one
in the comparison of HTTP). So if you say open 100 connections to your
server, you both cracking XMLHTTP and violating your license agreement
with Microsoft.
P.S. I really cannot imagine a need for even 2 concurrent connections
unless someone is sniffing my browsing history (using timed download).
In all other cases it's an indication of a very badly designed page
interface.
R
Razzbar
Memory cleanup and garbage collection has always been one of
Javascript's worse traits. It's a black box for JS coders, not knowing
whether unused objects are hanging around. I don't like mysteries in my
programs, and that's one of my dislikes about Javascript, not knowing
exactly what I'm dealing with in terms of types and references. The
memory cleanup question is by no means limited to ajax apps. It's a
nagging question any time you have an app that creates an unknown
number of objects.
I seem to recall a discussion somewhere on the net entitled "Javascript
leaks like a sieve". Not a lot a JS coder can do about it, though.
The second issue you mention doesn't seem likely to be a problem. My
current project has the user initiate a fetch of three blocks of
content at a time from the server. At first I used three seperate
request objects, but was too vulnerable to "stuff happens". I also
tried the eval trick, where you send some JS code that sticks the
content where it's supposed to go. Trouble with that is you have to put
the content into JS strings, which gave me problems with unterminated
string literals, and... and... that's when I discovered how difficult
it can be to debug an ajax black box.
So what I'm doing now is having the server join the three content
blocks, and then split them when they arrive, which hasn't given me
problems. The lesson learned is to not make more requests than you have
to. Also, if the objects you are fetching are interdependent, you have
an 'all or nothing' situation which is simpler to deal with if there's
a break in the conversation.
I could see a situation where you might want more than one connection,
e.g. if you're trying to make a really busy wannabee TV news page with
crawlers and scrollers and chatters and the like. In situations like
that, the programmer better come up with a good thread management
system.
The deal is, somebody (like me) might be so encouraged by the blazing
speed at first, that they forget to anticipate a user clicks on 'go',
and nothing happens, so they click on go again. Any ajax app is going
to need a traffic management system, and that's been a tough one for me
to come up with.
It is kinda funny how this technique has been available for a few years
already and it's just now the New Big Deal. I -knew- there had to be a
way to grab something from the server, but it seems that nobody had
documented it.
Javascript's worse traits. It's a black box for JS coders, not knowing
whether unused objects are hanging around. I don't like mysteries in my
programs, and that's one of my dislikes about Javascript, not knowing
exactly what I'm dealing with in terms of types and references. The
memory cleanup question is by no means limited to ajax apps. It's a
nagging question any time you have an app that creates an unknown
number of objects.
I seem to recall a discussion somewhere on the net entitled "Javascript
leaks like a sieve". Not a lot a JS coder can do about it, though.
The second issue you mention doesn't seem likely to be a problem. My
current project has the user initiate a fetch of three blocks of
content at a time from the server. At first I used three seperate
request objects, but was too vulnerable to "stuff happens". I also
tried the eval trick, where you send some JS code that sticks the
content where it's supposed to go. Trouble with that is you have to put
the content into JS strings, which gave me problems with unterminated
string literals, and... and... that's when I discovered how difficult
it can be to debug an ajax black box.
So what I'm doing now is having the server join the three content
blocks, and then split them when they arrive, which hasn't given me
problems. The lesson learned is to not make more requests than you have
to. Also, if the objects you are fetching are interdependent, you have
an 'all or nothing' situation which is simpler to deal with if there's
a break in the conversation.
I could see a situation where you might want more than one connection,
e.g. if you're trying to make a really busy wannabee TV news page with
crawlers and scrollers and chatters and the like. In situations like
that, the programmer better come up with a good thread management
system.
The deal is, somebody (like me) might be so encouraged by the blazing
speed at first, that they forget to anticipate a user clicks on 'go',
and nothing happens, so they click on go again. Any ajax app is going
to need a traffic management system, and that's been a tough one for me
to come up with.
It is kinda funny how this technique has been available for a few years
already and it's just now the New Big Deal. I -knew- there had to be a
way to grab something from the server, but it seems that nobody had
documented it.
V
VK
It is kinda funny how this technique has been available for a few years
Some times it's really difficult to see something right in front of you
The best sample would be the "204 No Content" trick. This HTTP response
header was in HTTP specs since the first release, but no one until
later 90's realized, that this way you can send data back to server w/o
reloading the current page. All server has to do is to responde with
"204 No Content" header. When one company first discovered it (one big
music portal, now gone with the bubble) they even tried to copyright
it. To copyright a header of a public protocol! That was crazy time
anyway. Most interestingly that if client supports PUT method, one can
still update its metadata (headers' values). So you can send data to
server (staying on the same page) from any of existing browsers. And
you could make full imitation of single-threaded XMLHTTP for say W3's
Amaya, Netscape Composer and (hold your breath) even NCSA Mosaic, if
the last would support any scripting language.
For the appearance of hidden frames and iframes the brains got "warmed
up" by the bubble era so people jumped on it right away.
And after they cooled off again by the after-Browser Wars times.
That would be an explanation I guess.
I'm getting floody though... Thank you for the conversation.
Some times it's really difficult to see something right in front of you
The best sample would be the "204 No Content" trick. This HTTP response
header was in HTTP specs since the first release, but no one until
later 90's realized, that this way you can send data back to server w/o
reloading the current page. All server has to do is to responde with
"204 No Content" header. When one company first discovered it (one big
music portal, now gone with the bubble) they even tried to copyright
it. To copyright a header of a public protocol! That was crazy time
anyway. Most interestingly that if client supports PUT method, one can
still update its metadata (headers' values). So you can send data to
server (staying on the same page) from any of existing browsers. And
you could make full imitation of single-threaded XMLHTTP for say W3's
Amaya, Netscape Composer and (hold your breath) even NCSA Mosaic, if
the last would support any scripting language.
For the appearance of hidden frames and iframes the brains got "warmed
up" by the bubble era so people jumped on it right away.
And after they cooled off again by the after-Browser Wars times.
That would be an explanation I guess.
I'm getting floody though... Thank you for the conversation.
Z
Zif
Razzbar said:
No doubt references were included to show where in the ECMAScript
Language specification the 'leaks' are defined?
If they aren't in the spec, then (if they exist) they are the fault of
the developer of the particular script engine, eh?
But of course, 'no names, no packdrill' ... hard to refute hearsay.
When your C++ programs swallowed all available memory, did you blame the
language or the shitty programmer who couldn't code any better?
And how, spefically, does JavaScript or AJAX have any bearing on why
your script can't read your XML? AJAX isn't a 'black box', it's a new
name for an old design paradigm. It isn't a thing, or a bit of
software, it's 4 words (or three words and an acronym).
[...]
And that is a new problem? It certainly isn't unique to AJAX (or any web
technology), though the web does present different issues.
Ain't that the truth. It's not new, it's not magic. It's just a new
name (wonder if Colgate Palmolive are happy that it's back in fashon).
V
VK
No doubt references were included to show where
Of course they are not defined! Where did you see an official language
specs with paragraphs like "And here guys it gonna leak no matter
what"?
You're right that memory leaks *very* rarely have anything to do with
the *language specs*. Unless it's a programmer fault (99% of cases),
it's usually caused by faults of a partucular engine
(interpreter/compiler).
A potential problem of ECMAScript is not that it *defines* some
numerous memory leaks. It doesn't.
What may be considered as irritating/spooky is that it *doesn't define*
any memory management obligations from the engine. So you're fully on
the merci of the engine constructors. It's not a problem and even very
convenient for daily trivia. In case of a chain creation of numerous
active objects it may be a problem.
IMHO ECMA should get a bit of dust out of their specs. Besides silently
ignored by everyone "ECMAScript for XML" (summer 2004) we'll still
living by the last century specs (Dec.1999) A lot of problems simply
were not presented at that time.
Of course they are not defined! Where did you see an official language
specs with paragraphs like "And here guys it gonna leak no matter
what"?
You're right that memory leaks *very* rarely have anything to do with
the *language specs*. Unless it's a programmer fault (99% of cases),
it's usually caused by faults of a partucular engine
(interpreter/compiler).
A potential problem of ECMAScript is not that it *defines* some
numerous memory leaks. It doesn't.
What may be considered as irritating/spooky is that it *doesn't define*
any memory management obligations from the engine. So you're fully on
the merci of the engine constructors. It's not a problem and even very
convenient for daily trivia. In case of a chain creation of numerous
active objects it may be a problem.
IMHO ECMA should get a bit of dust out of their specs. Besides silently
ignored by everyone "ECMAScript for XML" (summer 2004) we'll still
living by the last century specs (Dec.1999) A lot of problems simply
were not presented at that time.
J
Jim Stuttard
Yes, the developers of MS and Borland Windows compilers for a start. Is
ECMAScript supposed to provide automatic memory management? You seem to
imply it isn't?
Cheers
Jim
M
Michael Winter
On 06/07/2005 15:53, Jim Stuttard wrote:
[snip]
The specification doesn't mandate any memory management scheme, but it
would be an odd implementation that decided to never clear up after
itself until it was closed down.
Garbage collection typically works in the way you might expect, where
unreferenced objects are marked for deletion and cleared up at the
convenience of the host. However, IE has a known issue that involves
circular references and host objects.
If a host object (usually a HTML element) is involved in a circular
reference, JScript is unable to resolve the loop as non-native objects
are outside its scope. The only way to prevent a memory leak is to
either avoid the situation, or clear up manually at some point - either
as soon as you don't need the reference, or in response to the unload event.
Details can be found in the group archives, I'm sure.
Mike
[snip]
The specification doesn't mandate any memory management scheme, but it
would be an odd implementation that decided to never clear up after
itself until it was closed down.
Garbage collection typically works in the way you might expect, where
unreferenced objects are marked for deletion and cleared up at the
convenience of the host. However, IE has a known issue that involves
circular references and host objects.
If a host object (usually a HTML element) is involved in a circular
reference, JScript is unable to resolve the loop as non-native objects
are outside its scope. The only way to prevent a memory leak is to
either avoid the situation, or clear up manually at some point - either
as soon as you don't need the reference, or in response to the unload event.
Details can be found in the group archives, I'm sure.
Mike
R
Razzbar
Zif said:
Here's the story, which I haven't digested so won't comment on.
http://jgwebber.blogspot.com/2005/01/dhtml-leaks-like-sieve.html
When I write it, all the bugs are my own bugs. I always trust my
compiler unconditionally. It's just not possible for a compiler to
produce buggy code. They're written by professionals, after all.
Oh, it's harder, trust me. I'm so new at this I can only think of one
example, where typo in a server script generated an error message
instead of the JS code I wanted to eval(). Normally, I would have seen
the error message. In this case, it just didn't work. All the JS
console in FF would tell me was that it was an error in the function
that made the call. So I did it another way that didn't use eval().
"doc, it hurts when I do this"
"then don't do that"
"but then how am I gonna..."
Yes, and it's different from much of the past web programming
experience. Normally, when everything happens in a script on a page,
you can put debugging statements that e.g. pop up an alert() or
whatever. Normally, your server generates a page that you can examine.
This new thing (I don't like the term AJAX) is what I've always wanted;
to be able to request a chunk of content from the server, instead of a
whole document. It's an obvious thing to do. It's amazing it's taken so
long to be discovered.