third-party libraries

R

RobG

On Aug 26, 11:10 am, "Richard Cornford" <[email protected]>
wrote: [...]
| --jquery-1.1.4.js:1604---------------------------------------------
| // check if target is a textnode (safari)
| if (jQuery.browser.safari && event.target.nodeType == 3)
| event.target = originalEvent.target.parentNode;
But why only when the browser
is safari? If event.target's being a text node is a problem on safari
shouldn't it also be a problem on any browser where it is a text node?

Good question. I will raise some of these questions to the developers,
because I am curious to know the reasoning as well. Surely they are
not perfect and would be open to code improvements.

Early versions of Safari returned a text node if that was the node
that started the event, other browsers don't.


[...]
No - if a user configures their browser to lie about what it is, then
they should expect unpredictable results. In the absence of users
trying to purposely confuse the code, I've been extremely happy with
the cross-browser capabilities of jQuery and I've yet to come across a
real-world situation where it failed to work as expected.

I find programmers who can't keep their browser sniffing up-to-date to
be a much bigger problem. eBay keeps telling me to update my browser
when I visit using Safari 3 (but not with version 2). I've repeatedly
asked them to what verison, they don't respond.

The use of browser sniffing is becoming more prevelent, its inclusion
in popular libraries only encourages bad programming.

My ISP uses browser sniffing to deliver totally different pages to
different browsers, significant portions of the site are degraded if
you use a browser they've decided not to support. Banks are starting
to do the same again too after many years of reducing its incidence,
I've even seen sites attempting to detect "mobile Safari", and
detection scripts up to 500 lines (there are probably much longer
ones) that fail to recognise many reasonably popular browsers.

It is a return to the bad old days, we really shouldn't need to go
back there.
 
J

Jeff North

|
| > Wanting to do things in a generalised way is itself a decision that
| > introduces available problems, and there are very few real-world
| > situations (beyond the questionable wisdom of attempting to create
| > general libraries) that are general.
| >
|
| A very generalized statement, ironically.
|
| Conceptual reuse is what language itself is based upon.
|
| Creating a sentence, or a program statement is general knowledge.
|
| Building a kitchen. Imagine, what if the builder had a mistake and put
| the toilet next to the refrigerator!
|
| In the code world, we have great things like frameworks. Now in Java,
| there is Spring. Spring is great.
|
| In JavaScript, we have a lot of libraries. They're all buggy.
|
| My only problem with them is that they are all proprietary.
|
| Can you use Yahoo event system with jQuery Ajax transport with a Dojo
| widget?

http://docs.jquery.com/Using_jQuery_with_Other_Libraries
The jQuery library, and virtually all of its plugins are constrained
within the jQuery namespace. As a general rule, "global" objects are
stored inside the jQuery namespace as well, so you shouldn't get a
clash between jQuery and any other library (like Prototype, MooTools,
or YUI).

| > That is precisely what using browser detection renders impossible. The
| > best that could be achieved is multi-browser, as we see here in this
| > JQuery code.
| >
| > > Only in fringe cases (often where the
| > > user is deliberately trying to create a problem) does it
| > > usually fail.
| >
| > <snip>
| >
| > You are trying to blame the user for the unreliability that results form
| > a script author using a technique that is technically baseless and
| > self-evidently flawed? It may be a convenient excuse for incompetence,
| > but it does not really excuse it at all.
| >
| Typical.
|
| > Richard.
|
-- -------------------------------------------------------------
(e-mail address removed) : Remove your pants to reply
-- -------------------------------------------------------------
 
T

Thomas 'PointedEars' Lahn

In JavaScript, we have a lot of libraries. They're all buggy.

They are not.
My only problem with them is that they are all proprietary.

Pardon? There can be no standard interface for script libraries, as all
of them serve a different purpose. I welcome the diversity, as long as
reason had a part in creating the underlying code.
Can you use Yahoo event system with jQuery Ajax transport with a Dojo
widget?

Yes, you can.


PointedEars
 
T

Thomas 'PointedEars' Lahn

Jeff said:
http://docs.jquery.com/Using_jQuery_with_Other_Libraries
The jQuery library, and virtually all of its plugins are constrained
within the jQuery namespace. As a general rule, "global" objects are
stored inside the jQuery namespace as well, so you shouldn't get a
clash between jQuery and any other library (like Prototype, MooTools,
or YUI).

However, that is completely ignoring the fact that ECMAScript 3
implementations have no concept of a namespace, and that any
user-defined object or property may be overwritten at any time.

Please trim your quotes.


PointedEars
 
M

Matt Kruse

In JavaScript, we have a lot of libraries. They're all buggy.
My only problem with them is that they are all proprietary.

I don't know what exactly you mean by "proprietary", but check out
base2:
http://code.google.com/p/base2/

Dean's goal is to merely correct for browsers bugs/quirks and to
implement missing functionality so that you can code javascript to the
standards and have it work even in browsers that don't support the
standards. It's an interesting approach, but it doesn't offer the
convenience or simplicity of higher-level libs like jQuery.

Matt Kruse
 
T

Thomas 'PointedEars' Lahn

Matt said:
"Mostly"? It does considerably more than XPath.

If that is so, then that is only one more reason not use it.
All-purpose libraries are a Bad Thing.

Not following the standard recommendation by using `$' as an identifier for
code that is not machine-generated is another reason why not to use it.

But what I mean is that AFAIS it re-implements XPath incompletely with
barefoot programming, and uses that approach, even when there is no need for
it. You won't find any call of document.evaluate() there, for example.


PointedEars
 
M

Matt Kruse

All-purpose libraries are a Bad Thing.

That's a fundamental difference of opinion and has been argued to
death. Needless to say, your opinion is in the minority, even among
experts.
Not following the standard recommendation by using `$' as an identifier for
code that is not machine-generated is another reason why not to use it.

That's a ridiculous criticism, especially considering that '$' is just
an alias of the jQuery object put there for convenience. You never
have to use '$' in your jQuery code anywhere if you don't want to. In
fact, one of the rules of writing plugins is to never use $ because
the user may also be using another library like Prototype.

Matt Kruse
 
J

josh

What more do you want to know? Going to jquery.com and also finding
the Interface plugin/examples should be all anyone needs to get going
if they are interested.

Matt Kruse

.... when I posted this topic I done it because I'm in a difficult
moment. My boss told me:

Sincerely I'd choose YUI because it seems very good and because it
seems can give more guarantees
that in a future it will be largely used... but why W3C does not make
an API set????????
it seems like programming in C++. What GUI, REGEX, ecc. library must I
use?????

Help me!!!!!
 
R

Richard Cornford

^^^^^^^^^
Should have been "avoidable" (literally and in retrospect).
A very generalized statement, ironically.

It is neither generalised not ironic. It is a general statement that is
trivially true. It is also an important statement because there are
browser scripting problems that are insoluble (or can never be complexly
solved, or for which the solution is non-viable (mostly fare too big and
slow to use) generally, but can be solved in the majority of known
contexts because in those contexts sufficient aspects of the general
problem can be observed to be absent that what remains can be handled.
Conceptual reuse is what language itself is based upon.

Your point being?
Creating a sentence, or a program statement is general
knowledge.

Creating a programming statement is general knowledge? Knowing the
capital of Jamaica is general knowledge, creating a programming
statement is very specific knowledge.
Building a kitchen. Imagine, what if the builder had a mistake
and put the toilet next to the refrigerator!

In the UK that is not a mistake, it is a violation of the building
regulations (at least two doors must separate a toilet from a food
preparation area).

But what is your point? I don't see how you are ever going to be able to
interact with this group well enough to learn to become a decent
javascript programmer if you cannot express you thoughts more
effectively than this.
In the code world, we have great things like frameworks.
Now in Java, there is Spring. Spring is great.

And if every time you wanted to use Spring you were asked to download
and run the Java runtime environment, the code for a Java application
server and the Spring code itself wouldn't you be questioning whether
you really needed all of that generality for the single task in hand.
Server criteria, and desktop application criteria, to not transfer well
to browser script design decisions.
In JavaScript, we have a lot of libraries. They're all
buggy.

The general statement that all javascript libraries are buggy is going
to be very difficult for you to demonstrate. And is somewhat subjective
without a clear and precise assertion of how such a library is supposed
to behave.
My only problem with them is that they are all proprietary.

That would be truly bizarre criticism to level at javascript libraries.
You are not saying that they use proprietary features of browsers
themselves (which is an argument used, if not a particularly good one),
but that the libraries are themselves proprietary. What precisely is it
that a library would have to do in order that you knot think it
proprietary?
Can you use Yahoo event system with jQuery Ajax transport
with a Dojo widget?

Me personally, or in general? It sounds like the sort of thing that
could be done, but almost certainly should not be done.

What is typical? That I think that when a user does something that is
within their rights and does not violate any applicable technical
standards (HTTP 1.1 in this case) but problems result from a programmer
doing something that is technically base-less, unreliable, and
unnecessarily then for the programmer to be blaming the user's actions
for the consequences of their poor design decisions says more about the
competence of the programmer than anything else? Yes that is typical of
me, responsibility where it is due.

Richard.
 
R

Richard Cornford

RobG said:
On Aug 26, 11:10 am, Richard Cornford wrote: [...]
| --jquery-1.1.4.js:1604----------------------------------------
| // check if target is a textnode (safari)
| if (jQuery.browser.safari && event.target.nodeType == 3)
| event.target = originalEvent.target.parentNode;
But why only when the browser is safari? If event.target's being
a text node is a problem on safari shouldn't it also be a
problem on any browser where it is a text node?

Good question. I will raise some of these questions to the
developers, because I am curious to know the reasoning as
well. Surely they are not perfect and would be open to
code improvements.

Early versions of Safari returned a text node if that was
the node that started the event, other browsers don't.

As safari's code is based upon Konquerors' code, and Safari development
is feeding back into Konqueror development, that is unlikely to be true.

And there is nothing wrong with an event's - target - being a text node,
it should even be expected. The DOM level 2 events document says "The
EventTarget interface is implemented by all Nodes ... ". That is Nodes,
not Elmeents. And the - target - property of the Event interface refers
to an object implementing the EventTarget interface.
[...]
No - if a user configures their browser to lie about what it
is, then they should expect unpredictable results. In the
absence of users trying to purposely confuse the code, I've
been extremely happy with the cross-browser capabilities of
jQuery and I've yet to come across a real-world situation
where it failed to work as expected.

I find programmers who can't keep their browser sniffing
up-to-date to be a much bigger problem.

Keeping browser sniffing up to date is one of its inherent problems.
Even if a browser can be identified there never has been any guarantee
that the next version of that browser will exhibit all of the
significant behaviour of its predecessors. The result is high
maintenance code that requires ongoing work, which it may or may not get
(or get in a timely manner, assuming constant vigilance (and implied
constant testing) from those responsible).

Perversely we sometimes encounter people here who will reject idea of
using code proffered to them precisely because it has not changes in
many years. Obviously people who are acclimatised to an environment
where constant tinkering with code is required just to keep up, and
unaware that well designed/tested code does not need maintenance in
order to keep working.

The bigger problem with browser sniffing is the implied need to know
about all possible browsers. Where the greatest confidence in the
viability of browser sniffing is possessed by those with the narrowest
recognition of web browsers.
eBay keeps telling me to update my browser when I visit
using Safari 3 (but not with version 2). I've repeatedly
asked them to what verison, they don't respond.

Obviously the people you complain have no influence over the technical
aspects of eBay, but are too embarrassed by the self-eventide
incompetence of those that do to say anything.
The use of browser sniffing is becoming more prevelent,
its inclusion in popular libraries only encourages bad
programming.

It is a slightly unexpected trend, given that browser sniffing was
recognised as non-viable nearly a decade ago. We suffer a bit from the
fact that the javascript books (and most notably "JavaScript: The
Definitive Guide") still show browser sniffing code in various forms
without stating that it is absolutely the wrong thing to do. That
combined with a perceived need in management to use "web 2" (i.e. ever
more javascript on the browser) resulting in more people being asked to
write javascript, without any regard for the abilities of those people
to do it well.

It is a return to the bad old days, we really shouldn't
need to go back there.

Did we ever actually leave those 'bad old days'. You can get a skewed
perspective from this group. Here you can see a parade of demonstrations
that reliable, low maintenance, cross browser and cleanly-degrading
browser scripts can easily be created without any browser sniffing, and
discussions of the techniques employed and principles applied. But in
the meanwhile, out there on the Internet, the majority of scripts being
broadcast to browsers have still been utter garbage.

Richard.
 
T

Thomas 'PointedEars' Lahn

Matt said:
That's a fundamental difference of opinion and has been argued to
death.

Fair enough.
Needless to say, your opinion is in the minority, even among experts.

Are we back to ad hominem again? You cannot even prove that, no matter your
definition of "experts".
That's a ridiculous criticism,

It isn't. It shows a pattern.
especially considering that '$' is just an alias of the jQuery object put
there for convenience.

I know. And that convenience is disregarding the standard.
You never have to use '$' in your jQuery code anywhere if you don't want to.

But the library itself defines it, and it defines and uses more properties
that begin with `$'.
In fact, one of the rules of writing plugins is to never use $ because
the user may also be using another library like Prototype.

JFTR: You are defending one piece of junk code with the possibility of using
another one.


PointedEars
 
T

Thomas 'PointedEars' Lahn

Richard said:
As safari's code is based upon Konquerors' code, and Safari development
is feeding back into Konqueror development, that is unlikely to be true.

Not as unlikely as you may think. According to the KHTML people (I don't
have the reference anymore), Safari WebCore is actually based on a very
small subset of KHTML code, and has been extended much by Apply since. And
the feed that gets back from Apple WebKit developers to KHTML developers was
described, and maybe still is, sparse at best.

See for example http://www.eweek.com/article2/0,1895,1826096,00.asp


PointedEars
 
M

Martin Honnen

RobG said:
Early versions of Safari returned a text node if that was the node
that started the event, other browsers don't.

Old versions of Mozilla also do.
 
R

Richard Cornford

josh said:
... when I posted this topic I done it because I'm in
a difficult moment. My boss told me:
more productivity! Does exist a Javascript toolkit
that speed-up your job and make your code more
reusable? Ok prepare me a comparative draft....... >>>

Well there is the thing; if you cannot judge the answer for yourself
then your boss' "you know javascript" was a false assumption on his part
(or a false claim on yours).
Sincerely I'd choose YUI because it seems very good and
because it seems can give more guarantees
that in a future it will be largely used...

What would YUI being more "largely used" have do with your productivity
or your ability to make reusable code? Are you in the same business as
Yahoo?
but why W3C does not make
an API set????????

They are working on a standardised API for web applications. Are you in
the business of writing web applications?
it seems like programming in C++. What GUI, REGEX, ecc.
library must I use?????

Comparing apples and oranges will not help. The best approach to writing
computer application code (the existence of numerous and comprehensive
pre-written and standardised libraries) is not automatically the best
approach to writing web browser scripts.

Richard.
 
J

josh

Well there is the thing; if you cannot judge the answer for yourself
then your boss' "you know javascript" was a false assumption on his part
(or a false claim on yours).

well I explain me better! I use Javascript and related web
technologies by a lot time
but because of the objects cross-browser incompatibility (thanks to
Microsoft for which the W3c standards are nothing....) every
program take long time to end (also if it ends well and also if I
write some generics functions). Now my boss have seen that the web is
evolved and he wants that we write applications like if we was writing
in Java or C++ (that is my first background). Than
I must explain him that it is not so simple because Javascript is not
proper an OOP language and
so on...but at least if I can use some high-level library...
Obviously I can study each API and make me a personal opinion but my
SIMPLE question was
to know if someone had already used some APIs...on the road...and can
give me some ideas of his experience!
Are you in the same business as
Yahoo? No!

They are working on a standardised API for web applications. Are you in
the business of writing web applications?

Sorry, here, I don't understand what you want to say
Comparing apples and oranges will not help.

the concept I express does not concerns apples or oranges but to make
some standard API to help
programmer and this is the same when I want to program a GUI with the C
++

josh
 
J

Jeff North

| Jeff North wrote:
| > [...] "(e-mail address removed)" [...] wrote:
| >> | Can you use Yahoo event system with jQuery Ajax transport with a Dojo
| >> | widget?
| >
| > http://docs.jquery.com/Using_jQuery_with_Other_Libraries
| > The jQuery library, and virtually all of its plugins are constrained
| > within the jQuery namespace. As a general rule, "global" objects are
| > stored inside the jQuery namespace as well, so you shouldn't get a
| > clash between jQuery and any other library (like Prototype, MooTools,
| > or YUI).
|
| However, that is completely ignoring the fact that ECMAScript 3
| implementations have no concept of a namespace, and that any
| user-defined object or property may be overwritten at any time.

I think that you are completely ignoring the fact that the people at
jQuery weren't using namespace in the context of the ECMAScript (non)
definition.
| Please trim your quotes.

....and get abused for misquoting or trimming too much?
| PointedEars
-- -------------------------------------------------------------
(e-mail address removed) : Remove your pants to reply
-- -------------------------------------------------------------
 
M

Matt Kruse

Are we back to ad hominem again? You cannot even prove that, no matter your
definition of "experts".

It's an obvious conclusion, IMO, if you just spend time reading the
web and following the advances in the javascript world.
But the library itself defines it, and it defines and uses more properties
that begin with `$'.

Only as an alias for jQuery. Using $ as an identifier is perfectly
acceptable to everyone except standards zealots anyway. If you can't
come up with an argument against using it other than "a standards
document written by someone recommended it be used for a different
purpose" then you have a weak argument, IMO.

But, the question of $ has been debated endlessly as well, and there
is no need to go further. It's obvious that most of the javascript
community has no problem with it, so there's really no reason for me
to argue about it.

Matt Kruse
 
M

Matt Kruse

It is neither generalised not ironic. It is a general statement that is
trivially true. It is also an important statement because there are
browser scripting problems that are insoluble (or can never be complexly
solved, or for which the solution is non-viable (mostly fare too big and
slow to use) generally, but can be solved in the majority of known
contexts because in those contexts sufficient aspects of the general
problem can be observed to be absent that what remains can be handled.

One common argument in favor of some browser sniffing is that a
generalized test to check for a browser quirk or misbehavior may be
quite long and complex, even though the problem is known to only exist
in a single browser or a single environment. Why write extensive extra
code to solve the general case when it's never been shown that there
is a problem outside of the very specific case?

Relying on browser sniffing and some object detection would surely be
shorter, faster, and just as compatible. Although it wouldn't cover
the case where some other browser develops the same problem, why worry
about a situation that can be demonstrated as not existing? If it pops
up in the future, why not generalize it at that point if necessary?

Matt Kruse
 
R

Richard Cornford

^^^^^^^^^
Should have been "completely".
^^^
"far"


One common argument in favor of some browser sniffing is that a
generalized test to check for a browser quirk or misbehavior
may be quite long and complex,

Aren't we a few posts down stream of code showing a browser sniffing
based test that is more complex than it could have been precisely
because of the browser sniffing (that is, a test where the subject
should have been the type of the Node, not the type of the Node plus
whether the browser was Safari)?

It also would not be much of an argument in the face of examples of
browser sniffing code that includes and executes 500+ lines just for the
browser sniffing, and regardless of whether or not the results are ever
used.

Still, to date you are the only person who has mentions this "common
argument" to me. Obviously I must be not taking part in enough browser
sniffing and feature testing related debates.
even though the problem is known to only exist
in a single browser or a single environment.

How would it be "known" that the problem only existed on a single
browser? Logically haven't you got to positively verify that the problem
does not exist on _every_ other browser in existence before you can know
that? Given that the people who put most effort into collection web
browsers are the least convinced that it is possible to possess all web
browsers isn't that supposed 'knowledge' practically unachievable?

Without that knowledge you are in the area of surmise and assumptions.
Why write extensive extra code to solve the general
case when it's never been shown that there
is a problem outside of the very specific case?

You don't write browser sniffing code because it is imposable to write
such code so that it will accurately identify browsers or their
versions. Thus you could not know that there was a certain relationship
between the results of such tests and the condition that was the
purported reason for the test. While the principle of feature detection
that a good feature detection test tests a condition that has a
one-to-one relationship with whatever it is that the test is supposed to
determine, if achievable, guarantees the relationship of the test with
the need for a test.
Relying on browser sniffing and some object detection would
surely be shorter, faster, and just as compatible.

In some cases shorter and faster (but not in all cases by a very long
way), but just not (and never) reliable. Remember that browser sniffing
is predicated on treating something that is not supposed to be treated
as a source of information is if it was a source of information.
Reliable outcomes cannot be achieved in that way.
Although it wouldn't cover the case where some other browser
develops the same problem,

Or already had the same problem but had gone unnoticed by whoever
designed the browser sniffing code.
why worry about a situation that
can be demonstrated as not existing?

How were you planning on "demonstrating" that no unknown or unrecognised
browser has the issue in question? Trying a test-case on all browsers
may represent such a demonstration, if achievable at all, but it is
hardly realistic to propose such an extreme action as a prerequisite of
something that is purported to be "shorter and faster".
If it pops up in the future, why not generalize it
at that point if necessary?

Isn't the cost of ongoing maintenance to be considered? Haven't there
been enough examples of browser sniffing needing to be modified at each
release of a new browser, and of positively silly outcomes following
from author's falling to keep up with developments in browsers? How can
it ever make sense to be telling someone using the last version of a web
browser that they need to be upgrading to a newer version?

One of the greatest practical advantages of feature detection tests is
that if you get the test right it keeps on being the right test
regardless if whether the issue being tested for is fixed, crops up
somewhere else, or is accidentally re-introduced.

Richard.
 
T

Thomas 'PointedEars' Lahn

Jeff said:
On Mon, 27 Aug 2007 15:06:28 +0200, in comp.lang.javascript Thomas
'PointedEars' Lahn <[email protected]>
<[email protected]> wrote:

There is no need to replicate this much header information in the message
body. The attribution should be short so that it fulfills its purpose as
to indicate merely who wrote what of the quoted text.
| Jeff North wrote:
| > [...] "(e-mail address removed)" [...] wrote:
| >> | Can you use Yahoo event system with jQuery Ajax transport with a Dojo
| >> | widget?
| >
| > http://docs.jquery.com/Using_jQuery_with_Other_Libraries
| > The jQuery library, and virtually all of its plugins are constrained
| > within the jQuery namespace. As a general rule, "global" objects are
| > stored inside the jQuery namespace as well, so you shouldn't get a
| > clash between jQuery and any other library (like Prototype, MooTools,
| > or YUI).
|
| However, that is completely ignoring the fact that ECMAScript 3
| implementations have no concept of a namespace, and that any
| user-defined object or property may be overwritten at any time.

I think that you are completely ignoring the fact that the people at
jQuery weren't using namespace in the context of the ECMAScript (non)
definition.

You are missing the point. The concept of a namespace implies that
something defined in that namespace cannot be overwritten by other
pieces of code because of that namespace. Using an object as a
pseudo-namespace certainly can help to avoid conflicts when using
different libraries, but anything more is just a wild guess that
can not be backed up by features of the used programming language.
...and get abused for misquoting or trimming too much?

Abused? Not by me, or only by trolls, if you use common sense.

http://www.jibbering.com/faq/faq_notes/clj_posts.html


PointedEars
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,479
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top