Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Javascript Library

Reply
Thread Tools

Javascript Library

 
 
David Mark
Guest
Posts: n/a
 
      12-06-2007
On Dec 5, 5:02 pm, Randy Webb <(E-Mail Removed)> wrote:
> David Mark said the following on 12/5/2007 10:11 AM:
>
> > On Dec 5, 9:16 am, Randy Webb <(E-Mail Removed)> wrote:
> >> David Mark said the following on 12/5/2007 7:17 AM:

>
> <snip>
>
> >> innerHTMLFailed = true;
> >> window.onload=insertScript;

>
> >> function insertScript(){
> >> document.getElementById('scriptDiv').innerHTML='<s cript
> >> type="text/javascript">innerHTMLFailed = false;<\/script>'

>
> >> }

>
> > Aren't you missing the &nbsp; at the start of the string?

>
> 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.)

>
> >> And then in the function you could have this:

>
> >> if(innerHTMLFailed){
> >> //code here

>
> >> }

>
> > This is similar to what I did, but I don't test with a straight
> > innerHTML assignment as I use a wrapper for setting or appending HTML
> > that smooths out some of the issues with innerHTML. The wrapper uses
> > insertAdjacentHTML in a dummy DIV and then adds the nodes to the
> > target element. It seems it has identical issues with inline script,
> > including the need for the &nbsp; hack in IE.

>
> 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.

>
> >>> Thanks for posting. If you want the one-off version, let me know.
> >> Sure. Maybe the two together we can get something that is better than
> >> either of them alone.

>
> > You won't be able to run this as it makes numerous references to
> > wrappers and an object defined in another script. The feature testing
> > logic looks like this:

>
> 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.
>
> <snip>
>
> > There are two more clauses like this that have to run after the body
> > is parsed as they create and append a DIV to test the wrappers that
> > set inner/outerHTML. Worked for me, at least in the modern browsers I
> > use to test Ajax apps. Now that I switched the initial testing order,
> > it should work for iCab and those other odd Mac browsers that I don't
> > have here.

>
> 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.
 
Reply With Quote
 
 
 
 
beegee
Guest
Posts: n/a
 
      12-06-2007
On Dec 5, 10:40 am, David Mark <(E-Mail Removed)> wrote:
> On Dec 5, 9:47 am, beegee <(E-Mail Removed)> wrote:
>

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
 
Reply With Quote
 
 
 
 
David Mark
Guest
Posts: n/a
 
      12-06-2007
On Dec 6, 9:58 am, beegee <(E-Mail Removed)> wrote:
> On Dec 5, 10:40 am, David Mark <(E-Mail Removed)> wrote:> On Dec 5, 9:47 am, beegee <(E-Mail Removed)> wrote:
>

[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.

>
> > 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.


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.
 
Reply With Quote
 
Matt Kruse
Guest
Posts: n/a
 
      12-06-2007
On Dec 6, 10:39 am, David Mark <(E-Mail Removed)> wrote:
> > 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.


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.

> > 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.


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'm certainly not going to argue for jQuery
> > though. I was hoping to hear from someone as to what they perceive as
> > its value.

> 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

 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      12-06-2007
On Dec 6, 11:55 am, Matt Kruse <(E-Mail Removed)> wrote:
> On Dec 6, 10:39 am, David Mark <(E-Mail Removed)> wrote:
>
> > > 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.

>
> 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]

>
> > > 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.

>
> 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.
 
Reply With Quote
 
Matt Kruse
Guest
Posts: n/a
 
      12-06-2007
On Dec 6, 11:34 am, David Mark <(E-Mail Removed)> wrote:
> 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
 
Reply With Quote
 
Richard Cornford
Guest
Posts: n/a
 
      12-06-2007
Randy Webb wrote:
> Peter Michaux said the following on 12/4/2007 3:16 PM:
> <snip>
>
>> Some people strive for excellence and constantly improvement.
>> Others are happy with mediocrity because it is good enough
>> for everyone else.

>
> 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/roadm...d_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.

 
Reply With Quote
 
Richard Cornford
Guest
Posts: n/a
 
      12-06-2007
Matt Kruse wrote:
> On Dec 6, 10:39 am, David Mark wrote:
>>> 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.

>
> 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.

<snip>
> 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.

 
Reply With Quote
 
Rozzy
Guest
Posts: n/a
 
      12-06-2007
On Dec 6, 1:57 pm, "Richard Cornford" <(E-Mail Removed)>
wrote:
> Randy Webb wrote:
> > Peter Michaux said the following on 12/4/2007 3:16 PM:
> > <snip>

>
> >> Some people strive for excellence and constantly improvement.
> >> Others are happy with mediocrity because it is good enough
> >> for everyone else.

>
> > 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_...>
>
> ) 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 **** to say to me. You don't just join
this thread and start chiming in on other people's posts, that job is
taken.
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      12-07-2007
On Dec 6, 1:29 pm, Matt Kruse <(E-Mail Removed)> wrote:
> On Dec 6, 11:34 am, David Mark <(E-Mail Removed)> wrote:
>
> > 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.


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?

>
> > 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


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.

>
> > 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


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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Static library Vs. Dynamic library iceColdFire C++ 3 05-17-2005 06:16 AM
Dynamic Library or Static Library under Linux gouqizi.lvcha@gmail.com C++ 6 05-10-2005 03:16 PM
Re: Difference between Web Control Library and Class Library Alan Ferrandiz [MCT] ASP .Net 0 09-11-2004 01:51 PM
Re: Difference between Web Control Library and Class Library Mythran ASP .Net 0 08-24-2004 05:53 PM
Library in library... Sweep C++ 1 12-09-2003 04:12 AM



Advertisments