Prev: GHD limited edition colour collection
Next: FAQ Topic - What does the future hold for ECMAScript? (2010-07-20)
From: Alan Gutierrez on 24 Jul 2010 09:42
Gregor Kofler wrote:
> Am 2010-07-24 06:47, Alan Gutierrez meinte:
>
>> http://www.w3.org/TR/XMLHttpRequest/
>>
>> Then you'd return JSON from your PHP script and evaluate the response.
>>
>> This would be the way to do it with raw JavaScript. A library like
>> Prototype or jQuery could also be very helpful, but people on this
>> newsgroup do not like them because they leak memory on older browsers.
>
> This could be *a* reason. For the above problem, say 50 lines of "raw"
> JS would suffice (the cross-browser issues of XHR are a mild problem at
> best). In addition one would know what his or her XHR JS routines are
> doing. Any of the mentioned and not-mentioned libraries heap a bunch of
> abstraction layers on that along with plenty of unnecessary code.
>
> I suppose you already knew that, and just wanted to throw in some
> trolling comment, to fire up David again.

The position taken on libraries is not self-evident. Any production
language has a lot of code that is unnecessary code that I don't use. I
can build a web application in Java, and the JDK I use includes AWT and
Swing. This is not going to lead me to create my own bundle.

While there is a cost for the library to download, there are going to be
a lot of cases where I'm find with the cost of bandwidth because my time
is more important.

And then there is the prevalence of the libraries, the demand for people
who know them, and successful applications built with them.

> Besides: This memory leaking can be a *real* showstopper. I got involved
> with a huge project doing some sort of traffic monitoring, polling data
> via XHR. The customers were *all* on IE and the application was running
> 24/7. Or rather /should/ run 24/7, since it frequently crashed IE and
> Win after 10 to 12 hours. The page was ridden with libraries - I can
> recall jQuery and Spry.

Sounds awful, but this comes down to a platform choice, or lack of
platform choice. Another strategy would be to dictate the browser and
choose one that doesn't leak and treat JavaScript as a if it were a
garbage collected language, which it is. (Yes, you can still leak memory
in a garbage collected language.)

--
Alan Gutierrez - alan(a)blogometer.com - http://twitter.com/bigeasy
From: Gregor Kofler on 24 Jul 2010 11:12
Am 2010-07-24 15:42, Alan Gutierrez meinte:

>> Besides: This memory leaking can be a *real* showstopper.

> Sounds awful, but this comes down to a platform choice, or lack of
> platform choice. Another strategy would be to dictate the browser [snip]

It rather boils down to "bad quality of libraries" (at least in some
important departments), and lack of understanding of JS and browser
internals of both the library authors and the people who put together
the web application. The latter ones are hard to blame, when they are
frequently advised to use "a library to make things easier".

Gregor


--
http://vxjs.gregorkofler.com
From: David Mark on 24 Jul 2010 16:19
On Jul 24, 9:42 am, Alan Gutierrez <a...(a)blogometer.com> wrote:
> Gregor Kofler wrote:
> > Am 2010-07-24 06:47, Alan Gutierrez meinte:
>
> >>http://www.w3.org/TR/XMLHttpRequest/
>
> >> Then you'd return JSON from your PHP script and evaluate the response.
>
> >> This would be the way to do it with raw JavaScript. A library like
> >> Prototype or jQuery could also be very helpful, but people on this
> >> newsgroup do not like them because they leak memory on older browsers.
>
> > This could be *a* reason. For the above problem, say 50 lines of "raw"
> > JS would suffice (the cross-browser issues of XHR are a mild problem at
> > best). In addition one would know what his or her XHR JS routines are
> > doing. Any of the mentioned and not-mentioned libraries heap a bunch of
> > abstraction layers on that along with plenty of unnecessary code.
>
> > I suppose you already knew that, and just wanted to throw in some
> > trolling comment, to fire up David again.
>
> The position taken on libraries is not self-evident.

Then you didn't read that recent post I sent you to (at least not
carefully). The point was not that jQuery leaked memory (though that
is certainly not a good thing).

> Any production
> language has a lot of code that is unnecessary code that I don't use.

We aren't talking about a language but silly little scripts that have
been demonstrated to be of grade Z quality (e.g. jQuery and
Prototype).

> I
> can build a web application in Java, and the JDK I use includes AWT and
> Swing. This is not going to lead me to create my own bundle.

You notice nobody uses Java on the client side anymore. For one it
was too bloated.

>
> While there is a cost for the library to download, there are going to be
> a lot of cases where I'm find with the cost of bandwidth because my time
> is more important.

That assumes it takes less time to write an app with a dubious third-
party library written by people who demonstrably lack experience and
proficiency in browser scripting. Doesn't really follow does it? But
that's been their sales pitch.

>
> And then there is the prevalence of the libraries, the demand for people
> who know them, and successful applications built with them.

What does the demand for "people who know them" have to do with the
quality of an application (or lack thereof). Or are you more
concerned with your future employment possibilities than your clients?

In any event, there is far more demand for those can write HTML/CSS/JS
in competent fashion than those who pretend to.

And success is *relative*. Show me any "successful" site written by
jQuery cargo cultists and I will show you a site that could have been
so much better. ;)

>
> > Besides: This memory leaking can be a *real* showstopper. I got involved
> > with a huge project doing some sort of traffic monitoring, polling data
> > via XHR. The customers were *all* on IE and the application was running
> > 24/7. Or rather /should/ run 24/7, since it frequently crashed IE and
> > Win after 10 to 12 hours. The page was ridden with libraries - I can
> > recall jQuery and Spry.
>
> Sounds awful, but this comes down to a platform choice, or lack of
> platform choice.

A platform choice? It's just another example of a site gone wrong due
to using jQuery (and the like) as crutches.

> Another strategy would be to dictate the browser and
> choose one that doesn't leak and treat JavaScript as a if it were a
> garbage collected language, which it is.

I see. So rather than doing a competent job for your client, you
would seek to limit end-users to a browser that exposes less holes in
your application. Regardless, you can't do that on the Web. Some
users can't/won't change their browsers to suit your site.
From: Wenguang Wang on 25 Jul 2010 01:40
Very helpful! I used AJAX to send the query, and parsed the received
JSON output generated by php, and got it working. Thank you very
much!

One thing is that I don't know what event of the select box I should
use to trigger the ajax event. When I use the OnFocus event, it is
acting funny that sometimes it does not refresh the list. So now I am
using OnMouseOver. May not be very efficient, but it works. I hope I
could get an event right before the drop down box is shown so I can
fill the list in that event. Is this possible?

Thanks!

-Wenguang

On Jul 23, 9:47 pm, Alan Gutierrez <a...(a)blogometer.com> wrote:
> Wenguang Wang wrote:
> > Hi,
>
> > My web page has a dynamic combo box which contains some dynamic
> > information queried from the database.  Currently I am using php to
> > generate such a page with the dynamic information.
>
> > However, I want it to be more dynamic: when I click the combo box,
> > before the combo box shows me all options, it should query the
> > database and get the latest results.  Otherwise, the user has to
> > manually click the refresh button.
>
> > Is there a way to achieve such thing using combo box?  If not, what
> > control and what technique should I use?
>
> The select element has a DOM interface that allows you to add and remove
> options. I assume you mean "SELECT" since there is no real combo box in
> available in the DOM.
>
> https://developer.mozilla.org/en/DOM/select
>
> To get the information, your going to need to fetch it using XMLHttpRequest.
>
> http://www.w3.org/TR/XMLHttpRequest/
>
> Then you'd return JSON from your PHP script and evaluate the response.
>
> This would be the way to do it with raw JavaScript. A library like
> Prototype or jQuery could also be very helpful, but people on this
> newsgroup do not like them because they leak memory on older browsers.
>
> --
> Alan Gutierrez - a...(a)blogometer.com -http://twitter.com/bigeasy

From: David Mark on 25 Jul 2010 02:16
On Jul 25, 1:40 am, Wenguang Wang <wenguang.w...(a)gmail.com> wrote:
> Very helpful!  I used AJAX to send the query, and parsed the received
> JSON output generated by php, and got it working.  Thank you very
> much!
>
> One thing is that I don't know what event of the select box I should
> use to trigger the ajax event.  When I use the OnFocus event, it is
> acting funny that sometimes it does not refresh the list.

Nothing funny about that. You do realize that an XHR call may take a
while to finish, right? It's not as if you can block the SELECT from
doing its thing in the meantime. Well, you could block a click, but
you'd have no (standard) way to force the SELECT to show its wares
after rebuilding the list.

> So now I am
> using OnMouseOver.  May not be very efficient, but it works.

No it doesn't; though perhaps it seems to in your limited testing.
Besides, think of keyboard users.

> I hope I
> could get an event right before the drop down box is shown so I can
> fill the list in that event.  Is this possible?
>

Nope. Re-think your design.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: GHD limited edition colour collection
Next: FAQ Topic - What does the future hold for ECMAScript? (2010-07-20)