Javascript Library

[David Mark]

David Mark said the following on 12/5/2007 10:11 AM:



Not in that one. That one is designed to catch browsers that will
execute scripts inserted via innerHTML. The only browser that needs the
leading space is IE and it doesn't execute them so it isn't needed
there. Meaning, IE is going to ignore it either way so it doesn't matter.

Makes sense, assuming that IE is the only one that has that issue
(which wouldn't surprise me.)

I was trying to keep mine as simple as I could. The fewer "tricks" you
use to try to do it, the better your chance of success. Or that was my
thinking anyway. Doesn't make me right though

You are correct. The reason I made a wrappers for inner/outerHTML has
to do with other issues (like losing events when adding HTML, setting
the HTML of TBODY and SELECT elements, etc.) So it makes sense for me
to test against the functions I use. For a gp test of the innerHTML/
script issue, it makes sense to keep variables to a minimum. So far I
haven't seen any difference between the two sets of test results, but
then I haven't tested in as many browsers.

else
{
if(isIE)
{
newScript.text = d[x].text;
}
This is where mine differs. I create an array of functions to try,
based on testing the text and canHaveChildren properties of a created
script element, then try them in turn. The first one that works is
the one used in the innerHTML wrapper. I try the text property first,
which may or may not be good idea. Does that property throw errors in
any agents that support createTextNode? If so, I will have to change
the testing order.
iCab, Safari2/Mac and some other fringe browsers error if you try to set
the .text property of a script element but using createTextNode works in
those two browsers. The main reason I used the isIE is because IE is the
only browser I am aware of that doesn't support createTextNode and the
idea was to use createTextNode and only use .text for IE.

I switched the order of testing to try createTextNode first.

As an afterthought, I am not sure what will happen in them if you try
if(scriptElement.text) to test the property. The results page doesn't
attempt any feature detection at all because I wanted to know if the
browser supported the feature itself by trying to set it instead of
testing for it. That is how I found out about createTextNode and IE. It
will pass a feature detection test for it but falls down when you try to
use it.

I see. Perhaps the order wouldn't have mattered as the text property
may not be defined in those odd Mac browsers. Then again, it probably
is, otherwise I can't see it throwing an error.

I have it marked so I can look at it more in-depth when I have time.
Right now trying to get out of town again for the weekend.



It has gotten to the point where it is more of a mental exercise now. I
don't have either of them. The test results I have are from other people
(mostly RobG, Richard and Peter). I don't think that either one of them
is going to fall down with an AJAX application because you have to worry
about AJAX support first and just about any AJAX-capable browser should
be able to handle setting the .text or .src of a script element.

One would hope. Then again, any browser that can instantiate an
ActiveX object is a potential Ajax client. It seems like that would
include even IE3. Probably not in reality, but I am not sure what
would stop it. Unlike IE4, I do have a working IE3 installed here.
I'll have to try that some time.

 

[beegee]

Their tree widget is bloated
and uses nested tables IIRC. And certainly there are decent stand-
alone menu and "dialog" (assuming you mean centered elements with
backdrops) scripts out there that don't require half of the YUI
framework to function. By coincidence, I posted examples of both here
recently. They are both available from the Google Code repository
(search the group for my name + Google and you should find the links.)

The YUI tree view is certainly not without problems but despite the
deficiencies in it's internal implementation, the API is solid and
when one is dealing with trees and models that feed them, it is much
more important to have clean and maintainable application code than
the perfect library (I've seen and used quite a few of them).

Thanks, I will look for your examples on menus and dialogs. I have
looked at LightBox and other spinoffs. Once again, the internals are
faster and optimized but the APIs are lame and not genericized at
all. The "gold" in YUI is that the YAHOO engineers know how to write
an API (and document it too).

What sort of strategy is that? Terrible code leads to terrible
Websites. There's no benefit in that. Not to mention that the
greatest perceived benefit of jQuery is its CSS selector queries,
which are largely useless and lead to ridiculous code that constantly
creates and discards objects, fails to test if queried elements
actually exist and generally shields the author from ever learning
anything about competent browser scripting. It's fool's gold.- Hide quoted text -

The strategy is to:
a. reduce the time taken to code repeating tasks.
b. make the site maintainable by other developers.
c. separate data from ui so that a and b are easier to do.

Yes, terrible code leads to terrible websites. So does great code
that nobody understands. I'm certainly not going to argue for jQuery
though. I was hoping to hear from someone as to what they perceive as
its value. You are preaching to the choir but thanks for the link.

Bob

 

[David Mark]

[snip]

The YUI tree view is certainly not without problems but despite the
deficiencies in it's internal implementation, the API is solid and

The API can only be as solid as the code. No matter how robust and
well-documented it may be, it won't be reliable if the internal
implementation is wobbly.

when one is dealing with trees and models that feed them, it is much
more important to have clean and maintainable application code than
the perfect library (I've seen and used quite a few of them).

A well thought out API is always nice and will typically yield concise
and readable code. Still, if the code interfaced breaks down, you
have bigger problems as you will have to debug the library code or
file a support ticket and wait for somebody else to do it.

Thanks, I will look for your examples on menus and dialogs. I have
looked at LightBox and other spinoffs. Once again, the internals are

Forget LightBox. It uses Prototype + Scriptaculous (sp?), so it is
incompetent by association. Every time I visit sites that use that
pair on a lesser PC, processor usage spikes, the fan revs up, etc.
Not to mention that together they add over 100K to your page. Add the
lightbox script and you are looking at around 120K to center an image.

faster and optimized but the APIs are lame and not genericized at

There is nothing fast or optimized about any script that relies on
Prototype and its plugins. I can't comment on the API's as anything
that uses those is dismissed out of hand as unworkable.

all. The "gold" in YUI is that the YAHOO engineers know how to write
an API (and document it too).

It is their ability to write script (and markup in the case of the
tree) that is in question.

The strategy is to:
a. reduce the time taken to code repeating tasks.

That saved time goes out the window as soon as something breaks. As
we were discussing jQuery, that could easily be a daily occurrence.

b. make the site maintainable by other developers.

Same problem. There is nothing easy to maintain about jQuery. It
will always be a disaster waiting to happen.

c. separate data from ui so that a and b are easier to do.

I'm not sure what you mean by that, but certainly data shouldn't be
tangled up in your interface scripts.

Yes, terrible code leads to terrible websites. So does great code
that nobody understands. I'm certainly not going to argue for jQuery
though. I was hoping to hear from someone as to what they perceive as
its value. You are preaching to the choir but thanks for the link.

I can save you some time there. It has no value. As a liability, it
is worse than having nothing at all. If you do hear from someone that
perceives it has value (few in this group), you can safely dismiss it
as delusion.

 

[Matt Kruse]

That saved time goes out the window as soon as something breaks. As
we were discussing jQuery, that could easily be a daily occurrence.

Hypotheticals are fun, but of little practical value. Until you have
real examples of things breaking regularly because of using jQuery,
you're just trying to incite fear using scare tactics. Surely if you
are so convinced that the maintenance of anything that uses jQuery
would be a nightmare you would have _some_ experiences of yourself or
others to point to.

I should check other groups for your posts. Surely you're arguing
somewhere that planes will start falling out of the sky, because they
are really heavy, and everyone knows that heavy things fall, so a
disaster is just waiting to happen once the wind patterns change a
little bit in a way that wasn't accounted for. It's so obvious. Anyone
who thinks otherwise is delusional. Duh.

Same problem. There is nothing easy to maintain about jQuery. It
will always be a disaster waiting to happen.

If this isn't the mantra of a zealot with no ability to see beyond
what he knows and uses, I don't know what is.

I can save you some time there. It has no value. As a liability, it
is worse than having nothing at all. If you do hear from someone that
perceives it has value (few in this group), you can safely dismiss it
as delusion.

Blah, blah blah.

Ignore reality in favor of the fantasy world that you create to make
yourself feel better. You should start a religion while you're at it.

Matt Kruse

 

[David Mark]

Hypotheticals are fun, but of little practical value. Until you have
real examples of things breaking regularly because of using jQuery,

You apparently learned nothing from this lengthy thread.

you're just trying to incite fear using scare tactics. Surely if you
are so convinced that the maintenance of anything that uses jQuery
would be a nightmare you would have _some_ experiences of yourself or
others to point to.

The only experience you should need to know that there are major
problems with jQuery is to look at its code. Much of it forked based
on a meaningless value, which its author thinks indicates MSIE.

[snip nonsense]

If this isn't the mantra of a zealot with no ability to see beyond
what he knows and uses, I don't know what is.

Apparently you don't know anything about browser scripting. That much
is clear. Ironically, you took many of my arguments against jQuery
and ran with them, resulting in recent patches. Far too few patches
of course, but that says something about the value of my input and
your perception of it. The contrast between your arguments here and
your input to the jQuery developers would seem to indicate a split
personality.

[snip more nonsense]

Seek professional help.

 

[Matt Kruse]

The only experience you should need to know that there are major
problems with jQuery is to look at its code. Much of it forked based
on a meaningless value, which its author thinks indicates MSIE.

Which doesn't necessarily correspond to problems in use or
maintenance, which you are claiming.

Where is your personal experience or anecdotes from others that show
what a maintenance hell jQuery is? Oh, wait, you have none? Because
it's all speculation, and you're crossing your fingers just hoping
that something bad does indeed happen. I'm sure it bothers you that
you have no real cases where the use of jQuery has caused lots of
problems, but you can find _many_ real cases where it has provided a
lot of value to a lot of different people. Including small mom-and-pop
operations like Google.

Ironically, you took many of my arguments against jQuery
and ran with them, resulting in recent patches.

I'm not aware of the patches, but I did look over the code that you
critiqued and offered my own version of it. There were obviously some
similarities in our criticisms, and most of your criticisms were
obviously very valid. Good job. I agree with much of your technical
analysis of javascript, but I disagree with many of your conclusions.
I'm fine with that.

The contrast between your arguments here and
your input to the jQuery developers would seem to indicate a split
personality.

Not at all. I still use jQuery and I find it extremely valuable in the
cases where I use it. It needs to improve, especially if I am to use
it on public sites. I am confident that it will improve over time and
come closer to the standard I think it can reach. I have no plans to
abandon it.

Seek professional help.

Thank you for your valuable input.

Matt Kruse

 

[Richard Cornford]

Peter Michaux said the following on 12/4/2007 3:16 PM:


I think you failed to catch the sarcasm and irony in it.

And of course sarcasm is a much better contribution to debate than
reasoned argument. Not least because it puts a layer of camouflage over
its asserted 'truths' that could keep them form being subject to
specific examination for their validity.

The implied 'truths' in the sarcastic expression are:-

1. That JQuery works in 99% or all browsers. Which would be a difficult
position to sustain independently given the issues with browser
statistics in general and the very large numbers of 'browsers' that are
known to exist.

2. That creating cross-browser code is significantly more expensive than
not doing so. Which is a judgment best made by people who can create
cross-browser code (as anyone else will be guessing at what would be
involved and/or factoring in the cost of their learning how to undertake
the task).

3. That John Resig is an "expert", regardless of how amateurish his code
looks, how outdated the techniques he uses are, how uninformed his
design decisions appear to have been, or how incapable he appears to be
to state reasoned justifications for the actions he has taken.

4. That "huge corporations" like Microsoft, Google, Enron or IBM could
never do anything wrong, presumably by virtue of their being "huge
corporations".

5. That individual who "practically invented the language" (whoever they
were intended to be in this context) must then know how to use it. The
real truth of which was highlighted when I visited Berendan Eich's (this
individual who literally invented the language) ES4 roadmap updates page
yesterday (

<URL:
http://weblogs.mozillazine.org/roadmap/archives/2007/11/es4_news_and_opinion.html >

) to be presented with IE 6 popping up its error dialog containing the
words "line: 260, Char:1, Error: Syntax error". In javascript/browser
scripting terms that is about as bad as it gets. (Granted I doubt that
was Berendan Eich's personal fault/responsibility (rather a general
f**k-up in the script authoring/QA for the blog software), but still
there it is).

Richard.

 

[Richard Cornford]

Hypotheticals are fun, but of little practical value. Until
you have real examples of things breaking regularly because
of using jQuery, you're just trying to incite fear using
scare tactics.

It may seem like a good argument to dismiss possible future changes in
browsers as hypothetical and call for real examples but that does suffer
a bit from the (unknown and somewhat unpredictable) nature of future.

I have been reading some discussion about the use of - eval - in the
(proposed) ES4, and observing a strong opinion in favour of changing
the - eval - definition so that where ES3 says it MAY throw an
EvalError, ES4 WILL throw an EvalError (it is a proposed closing of a
security loophole, and so quite likely to be acted upon given that ES4
is intended to improve script security). Those of us who have looked at
the ES3 spec and concluded that it would only be rational to assume that
ES3 implementing will throw EvalErrors whenever the spec says they may
will not have a problem with that change.

However, JQuery (and Prototype.js) have been written with the assumption
(based on observing the behaviour of a small set of existing ES3
implementations rather than reading the language's spec) that the
EvalError will never be thrown. In the case of Prototype.js that is an
'across the board' assumption, while where I have observed that
assumption in JQuery it is only applied to Friefox/Mozilla/Gecko
browsers. But, for very obvious reasons, Firefox is extremely likely to
be the first browser that has an ES4 implementation, at which point a
piece of JQuery code that is fine today will promptly start throwing
exceptions, and all third party code that uses that particular piece of
JQuery code will break.

Now that is hypothetical. ES4 may not turn out the way it is currently
proposed, or it may never come to fruition at all. But that particular
future is not as unlikely as many, and it will break (at least some)
JQuery and Prototype.js related code, and it will break them as a direct
consequence of bad (and avoidable) design decisions on the part of the
authors of those libraries.

There will be no real examples of the introduction of ES4 breaking
existing code until that happens, but that does not mean it will not
happen, or could not be avoided.

Surely if you are so convinced that the maintenance of
anything that uses jQuery would be a nightmare you
would have _some_ experiences of yourself or others to
point to.

But there are hundreds of examples. We know JQuery uses User Agent
string based browser sniffing and we know that that has caused
maintenance issues throughout the years. For example, when g-mail used
browser sniffing to exclude Opera browsers because they could not do XML
HTTP requests, and Opera 8 introduced XML HTTP requests but it still
took someone at Google to go into the g-mail code and modify it so that
it would work with Opera 8. We know that feature detecting was a long
way from being unknown at the time, and that it could and would have
avoided that maintenance, but we know that it happened anyway.

I should check other groups for your posts. Surely you're
arguing somewhere that planes will start falling out of
the sky, because they are really heavy, and everyone knows
that heavy things fall, so a disaster is just waiting to
happen once the wind patterns change a little bit in a way
that wasn't accounted for. It's so obvious. Anyone who
thinks otherwise is delusional. Duh.

Is that a "straw man" or a "slippery slope" argument?

Aeroplanes do fall out of the sky. Mostly they do so when they loose
propulsion or when significant parts fall off. Quite a bit of design
work goes into making sure that that sort of thing does not happen. The
general attitude is not "we don't have to worry about what may
hypothetically go wrong until we have observed it going wrong", because
with aeroplanes that sort of attitude will get people needlessly killed.

Changing wind patterns could potentially impact on fuel use, and so be
extremely significant in, for example, cross-ocean flights because if an
aeroplane consumes all its fuel before its journey is over it will fall
out of the sky.

Blah, blah blah.

Ignore reality in favor of the fantasy world that you create
to make yourself feel better. You should start a religion
while you're at it.

Who here is appealing to blind faith?

I bet people get very religious while their aeroplanes are falling into
the ocean.

Richard.

 

[Rozzy]

And of course sarcasm is a much better contribution to debate than
reasoned argument. Not least because it puts a layer of camouflage over
its asserted 'truths' that could keep them form being subject to
specific examination for their validity.

The implied 'truths' in the sarcastic expression are:-

1. That JQuery works in 99% or all browsers. Which would be a difficult
position to sustain independently given the issues with browser
statistics in general and the very large numbers of 'browsers' that are
known to exist.

2. That creating cross-browser code is significantly more expensive than
not doing so. Which is a judgment best made by people who can create
cross-browser code (as anyone else will be guessing at what would be
involved and/or factoring in the cost of their learning how to undertake
the task).

3. That John Resig is an "expert", regardless of how amateurish his code
looks, how outdated the techniques he uses are, how uninformed his
design decisions appear to have been, or how incapable he appears to be
to state reasoned justifications for the actions he has taken.

4. That "huge corporations" like Microsoft, Google, Enron or IBM could
never do anything wrong, presumably by virtue of their being "huge
corporations".

5. That individual who "practically invented the language" (whoever they
were intended to be in this context) must then know how to use it. The
real truth of which was highlighted when I visited Berendan Eich's (this
individual who literally invented the language) ES4 roadmap updates page
yesterday (

<URL:http://weblogs.mozillazine.org/roadmap/archives/2007/11/es4_news_and_...>

) to be presented with IE 6 popping up its error dialog containing the
words "line: 260, Char:1, Error: Syntax error". In javascript/browser
scripting terms that is about as bad as it gets. (Granted I doubt that
was Berendan Eich's personal fault/responsibility (rather a general
f**k-up in the script authoring/QA for the blog software), but still
there it is).

Richard.

Who is this douchebag? That sarcastic statement was nothing more than
a bunch of words thrown together by a professional bullshitter as bait
for David Mark, and it worked hook, line, and sinker. Refer to the
subsequent verbal attacks and the eventual backing down of David the
pussy.

And who are you? You don't have shit to say to me. You don't just join
this thread and start chiming in on other people's posts, that job is
taken.

 

[David Mark]

Which doesn't necessarily correspond to problems in use or
maintenance, which you are claiming.

Of course it does. All of its browser sniffing does. Where have you
been for the last ten years? You claim to have spent at least some of
that time scripting browsers. Have you learned anything from the
experience?

Where is your personal experience or anecdotes from others that show
what a maintenance hell jQuery is? Oh, wait, you have none? Because
it's all speculation, and you're crossing your fingers just hoping
that something bad does indeed happen. I'm sure it bothers you that

I couldn't care less what happenes with jQuery or any other library,
unless it happens to be running the current page in my browser.

you have no real cases where the use of jQuery has caused lots of
problems, but you can find _many_ real cases where it has provided a

Go read your own re-hashing of my arguments in the jQuery developer
group as you have apparently forgotten everything you said.

lot of value to a lot of different people. Including small mom-and-pop
operations like Google.

How many times are you going to use Google as an example? Everybody
knows they employ some of the worst Web developers in history. The
quality of their JavaScript is notoriously bad. What makes you think
they make good decisions in that area?

I'm not aware of the patches, but I did look over the code that you
critiqued and offered my own version of it. There were obviously some
similarities in our criticisms, and most of your criticisms were

That's an odd way to put it. You took what I posted and ran with it.
By your own admission, you were happily using this library for however
long, completely oblivious to its time bombs. You likely would have
continued using it until one day, Firefox or Opera or one of the other
two browsers the stupid thing supports updated and broke some or all
of your applications.

obviously very valid. Good job. I agree with much of your technical
analysis of javascript, but I disagree with many of your conclusions.
I'm fine with that.

You just seem to struggling to accept the conclusions as they
invalidate many of your own mistaken beliefs. Some fragment of your
personality gets it, else you wouldn't have argued tirelessly to have
various bits of browser sniffing (among other things) removed from
jQuery. BTW, you have a long way to go if you really want to salvage
that derelict. Good luck.

Not at all. I still use jQuery and I find it extremely valuable in the
cases where I use it. It needs to improve, especially if I am to use
it on public sites. I am confident that it will improve over time and

But you and others like you are constantly recommending it to people
who build public sites. Do you not see why that is inappropriate?
That's one of my biggest complaints about the jQuery muppets. They
argue that they designed something for three browsers and don't care
about the others, but fail to understand that such a design falls way
short of what a public Website requires, recommending their
monstrosity to anybody and everybody, with an almost religious zeal.

come closer to the standard I think it can reach. I have no plans to
abandon it.

Great.

 

[dhtmlkitchen]

ironically, you took many of my arguments against jQuery

I would have liked to have seen more discussion for detecting support
for computedStyles; the bug John mentioned.

When adding a hack for something like getComputedStyle, it would be
good style to add a comment:

if( cantGetComputedStyle( element ) {
// XXX: Safari 2 returns null when element has display: none;
...
// XXX: Safari 3 returns empty strings for getPropertyValue...
}
@John

Considering that IE is going to be backwards compatible for, most
likely, many many years to come, I'm not worried. When the year 2031
arrives, jQuery can, and will adapt.

Providing a case where the code expects a browser to have incorrect
behavior makes it hard for that browser to change. It also makes the
code require more frequent maintenance for user-agents that change. IE
needs a reason to change; a failure case. Chris Wilson talks about
this. Microsoft can't break the web by neglecting current sites.

 

[dhtmlkitchen]

you took many of my arguments against jQuery

I would have liked to have seen more discussion (did I miss it?) about
getComputedStyle feature detection.

Capability-detecting failure of getPropertyValue chould be addressed,
and this should definitely be in a comment if it is done:

if( !document_implementation_hasFeature_CSS ) {
// XXX: Safari 2 returns null for getComputedStyle when element has
display: none;
...
// XXX: Safari 3 returns "" for getPropertyValue when element has
display: none;
}

XXX comments are informative and the code begs to be removed
obscenities.

An approach might be to try and set some value (like voiceFamily, or
even something completely bogus, like computedStyleWorkaroundTest:
true; ). Use insertRule and then read it back.

The thread kind of fell apart, but had a lot of good stuff early on.

Considering that IE is going to be backwards compatible for, most
likely, many many years to come, I'm not worried. When the year 2031
arrives, jQuery can, and will adapt.

Providing a case where the code expects a browser to have incorrect
behavior makes it hard for that browser to change. (it also makes the
code require more frequent maintenance for user-agents that change).
IE needs a reason to change; a failure case. Chris Wilson talks about
this. Microsoft can't break the web by neglecting current sites.

 

[dhtmlkitchen]

Of course it does.  All of its browser sniffing does.  Where have you
been for the last ten years?  You claim to have spent at least some of
that time scripting browsers.  Have you learned anything from the
experience?




I couldn't care less what happenes with jQuery or any other library,
unless it happens to be running the current page in my browser.


Go read your own re-hashing of my arguments in the jQuery developer
group as you have apparently forgotten everything you said.


How many times are you going to use Google as an example?  Everybody
knows they employ some of the worst Web developers in history.  The
quality of their JavaScript is notoriously bad.  What makes you think
they make good decisions in that area?





That's an odd way to put it.  You took what I posted and ran with it.
By your own admission, you were happily using this library for however
long, completely oblivious to its time bombs.  You likely would have
continued using it until one day, Firefox or Opera or one of the other
two browsers the stupid thing supports updated and broke some or all
of your applications.


You just seem to struggling to accept the conclusions as they
invalidate many of your own mistaken beliefs.  Some fragment of your
personality gets it, else you wouldn't have argued tirelessly to have
various bits of browser sniffing (among other things) removed from
jQuery.  BTW, you have a long way to go if you really want to salvage
that derelict.  Good luck.





But you and others like you are constantly recommending it to people
who build public sites.  Do you not see why that is inappropriate?
That's one of my biggest complaints about the jQuery muppets.  They
argue that they designed something for three browsers and don't care
about the others, but fail to understand that such a design falls way
short of what a public Website requires, recommending their
monstrosity to anybody and everybody, with an almost religious zeal.


Great.