Javascript Best Practices Document v1.0

[Matt Kruse]

Richard, perhaps you missed this followup...

You had asked for me to be clearer about what I meant by 'general' and
'exhaustive' and 'partial solution'.
I was curious if you had a response after I made things clearer?

Matt

Let's clear things up...

And I was writing about Matt's specific problem. In theory he has the
problem of the general. Ideally he wants to create something that can
be drooped unaltered into any web page context at all and will then
successfully function as expected.

'Ideally', yes, that would be nice. Realistically, no. That's not the
goal. The goal would be able to have code which works when dropped
into the majority of typical situations.

And his expectation is that the
person doing the dropping will not have any technical understanding
of what they are doing and so will be incapable of doing anything
about it when his products do not work as expected.

If they have a case not covered in the generalized solution, they can
provide a test case and ask for the condition to be covered in the
code. If it is likely that the condition is common to more than just
a single situation, then it could be considered for addition.

That means either Matt's code takes into account all the factors
pertinent to its being dropped into any web page context or it cannot
be dropped into any web page context.

Perhaps you used wrong words, but that is not true at all.
Even if all factors are not considered, it might work correctly in the
majority of contexts.
Your point, I assume, is that unless all contexts are considered,
then it could not be dropped into ALL web page contexts. Which is, of
course, true. But since that is never my goal, I have no problem with
that.

With the latter case suggesting
that Matt should state the restricted contexts in which the code can
be successfully used, and that the individual employing the code
should be able to recognise whether those restrictions are satisfied
in their particular situation

It's impossible to list every context where such a generalized
solution will work. It might be possible to list all the conditions
that are considered in the code, although I don't think most people
would find value in that. Instead, it would be best to list the
contexts where the code does _not_ work, so a user can identify if
such a context exists in their case.

When 'providing general solutions' uses general to mean no more than
non-specific and solutions may be 'partial' the whole thing looks
like a marketing exercise rather than the altruistic contribution to
the betterment of the web development world he sometimes makes it out
to be.

I've thought about definitions a bit, and I offer this...

A specific solution is only useful in a single case. For example, if
you have an IE-only app and you want to get the color applied to an
object, you could use:

function getObjectColor(obj) {
return obj.currentStyle.color;
}

This solution is not generalized at all. It returns the value of one
attribute, and only in some user agent(s).

The term 'general' is relative. A 'more general' solution would take
into account multiple user agents:

function getObjectColor(obj) {
if (obj.currentStyle) {
return obj.currentStyle.color;
}
else if (obj.document && obj.document.defaultView &&
obj.document.defaultView.getComputedStyle) {
return
obj.document.defaultView.getComputedStyle(obj,'').getPropertyValue('color');
}
return null;
}

A even more 'general' solution would consider the case of a null
object, etc, but I will not list that here for the sake of brevity.

An EVEN MORE 'general' solution could take the property as an
argument, so the method could be reused for obtaining any style
attribute:
function getObjectStyleValue(obj,property) {
if (obj.currentStyle) {
return obj.currentStyle[property];
}
else if (obj.document && obj.document.defaultView &&
obj.document.defaultView.getComputedStyle) {
return
obj.document.defaultView.getComputedStyle(obj,'').getPropertyValue(property);
}
return null;
}

An EVEN MORE 'general' solution might take into consideration some
specific browser quirks, or NN4, etc.

I would consider the improved 'getObjectColor' function to be a
general method of obtaining the color of an object. But the
'getObjectStyleValue' method is even better, since it's a general
method to obtain any style value.

None of these are 'exhaustive' solutions, however. There are
certainly cases and browser quirks which are not considered. However,
these functions in their finished form would surely provide the
desired functionality for most people in most contexts, so they could
be presented as a 'general' solution.
The goal of building 'general' solutions is to provide functionality
that works in the majority of contexts that arise in typical
development. The goal is never to build an exhaustive solution which
covers all possible situations. That's not possible in most cases.
(In cases where it is possible, it is certainly a good goal!)

Your insistance that a 'general' solution must be 'exhaustive' is
incorrect (or at least, not the typical opinion). I've checked with a
number of other developers in a forum I participate in, and they all
agreed that they do not necessarily consider a 'general' solution to
address every possible need which might arise.

So, when I attempt to build a 'general' solution for finding the
position of an object, for example, I'm attempting to address the
majority of typical contexts in which it would be used. So most
people, under most conditions, _could_ in fact drop the library into
their code and have it work correctly. In other libraries, I have
built in functionality which will be used by some people but not
others, because I thought that the need for the functionality was
typical enough to warrant inclusion. In other cases, people have made
specific requests that I did not include because I didn't think most
people would ever have the need for the feature.
If exceptions happen (and they will) then I would hope that the person
finding it would tell me details and provide a test case so I could
determine if the need is typical enough (in my own opinion) to be
included in the general library and should be fixed, or if their
context is so specific to their situation that they would need to
write specific code for their case. Of course, when people such as
yourself claim to find an exception and refuse to provide details or
a test case, that doesn't help to make the general routine more
solid. In fact, since you refuse to provide any evidence, I'm not
sure I even believe you. It's easy to make empty claims. *shrug*

A 'partial solution' is valuable because it solves a specific case
and can be used in a more general solution. For example, the code
using currentStyle to find the style applied to an object is a
'partial solution' because it does solve the problem for a subset of
all cases. Combined with other 'partial solutions' they form a more
general solution which is more valuable.

A 'partial solution' can also be a library in itself. For example,
finding the position of an object. By itself, it provides no
functionality to the user. It must be used with other code to achieve
some bigger goal. But it can be used as a black box to solve the
problem of finding the position of an object, so the coder doesn't
need to go into detail programming that portion of the bigger picture.

<snip about my 'advertising' and supposed real motivations>

Nothing will change your opinion of my efforts, Richard, so what I
write won't even matter.

But, the truth is that when I direct people to my stuff, it's always
because it _specifically_ addresses their needs, and I think they
will benefit from it. I don't advertise. If you have specific code
which solves their specific problem, you may post it. If I have
already written a solution which solves their problem, I may direct
them to it.
I happen to offset the cost and development time with donations and
google ads, although I certainly do not 'come out ahead' in the game.
If I were trying to make a profit, I would be charging for my work
rather than giving it away with almost no useage restrictions. My
goal is to provide solutions which help average web developers
perform complex tasks which they may not be able to do themselves. I
get personal satisfaction knowing that I've helped thousands of
people solve their problems when people like you would have told them
that they didn't even deserve to be helped. If I'm ever seen as
'promoting' my stuff, it's because I want people to be made aware of
packaged solutions which can solve their problem, rather than being
faced with people telling them how stupid they are, or resorting to
finding terrible code at some copy-n-paste javascript site.
If you don't believe me, that's fine. I don't care.

 

[Richard Cornford]

Richard, perhaps you missed this followup...

Give me a chance, i have had a lot to do recently.

Richard.

 

[Richard Cornford]

Let's clear things up...



'Ideally', yes, that would be nice. Realistically, no. That's not
the goal. The goal would be able to have code which works when
dropped into the majority of typical situations.

Then why do you talk about your code being general when you are only
asking it to be braod?

If they have a case not covered in the generalized solution, they can
provide a test case and ask for the condition to be covered in the
code.

If the person doing the dropping has no technical understanding of what
they are doing then they are unlikely to be able to create a test case,
and more likely to go off an look for alternative code that seems to
better suite their situation (although the 'low hanging fruit' attitude
among the authors of such code means that they are likely to be
unsuccessful).

I've thought about definitions a bit, and I offer this...

A specific solution is only useful in a single case.

Th concept of 'specific' might be the harder one to pin down. With this
definition it may become necessary to consider how singular a single
case is.

For example, if you have an IE-only app and you want to get
the color applied to an object, you could use:

function getObjectColor(obj) {
return obj.currentStyle.color;
}

The singleness in this case being a browser implementing a single
feature. While:-

function getObjectColor() {
return document.getElementById('anId').currentStyle.color;
}

- applies to a single element on a browser implementing a single
feature, and so is more specific.

This solution is not generalized at all.

Because the first is less specific than the second it is also more
general.

It returns the value of one
attribute, and only in some user agent(s).

As opposed to the return value of one attribute on one element and only
on some user agents.

The term 'general' is relative.

You haven't precluded the possibility of 'general' being an absolute.
Being able to talk of 'more general', 'less general', 'more specific'
and 'less specific' certainly doesn't achieve that. Consider a row of 11
glasses; the first is left empty, the second has 10% or its volume
filled with water, the third 20%, the fourth 30%, and so on until the
last has 100% of its volume filled with water. It is possible to pick
any two glasses and say this one is 'more full' than that one, and that
one is 'more empty' that this one. But still only one glass _is_ empty,
and all the rest are _not_ empty, and one glass _is_ full and all the
rest are _not_ full.

It is a characteristic of the concepts of full and empty that you cannot
make a glass 'more full' than full and you cannot make a glass 'more
empty' than empty. (Granted someone might quibble that an empty glass
was full of air and insist that a glass in a vacuum was more empty, but
they would still have to accept that there is a point where that glass
could not be rendered more empty).

A 'more general' solution would take
into account multiple user agents:

Above you stated "if you have an IE-only app and you want to get the
color applied to an object", which states, if imprecisely, the problem.
This "'more general' solution" is not a more general solution to that
problem (the solution you had was as general a solution to that problem
as is needed). This is a possible solution for a more general problem.
This second problem may be expressed as:-

Retrieve the currently applicable (non-normalised) value of the CSS
'color' property as a string from any Element whenever that information
is available or a distinguishable alternative when it is not available.

function getObjectColor(obj) {
if (obj.currentStyle) {
return obj.currentStyle.color;
}
else if (obj.document && obj.document.defaultView &&
obj.document.defaultView.getComputedStyle) {
return
obj.document.defaultView.getComputedStyle(obj,'').getPropertyValue(
'color');
}
return null;
}

Disregarding the technical flaws (the use of obj.document instead of
obj.ownerDocument and the failure to verify that the computed style
object implements a - getPropertyValue - method) and the broken
presentation, that is very close to being a general solution to the
problem I stated above. The only environment permutations it does not
exploit are the possibility that where the - getPropertyValue - method
is not implemented on the computed style object the value may still be
available as the - color - property of that object or may be
reconstructed through the use of the - getPropertyCSSValue - and the -
CSSValue -interface (if available).

The sense in which this may be regarded as a more general solution is
that it is a solution to a more general problem, that happens to
encompass the originally stated problem. It can be applied to the
problem of retrieving the color of an element on IE, because IE (al
least IE 5+) is a browser where the information is available. It won't
do the job any better than the original (because it won't do anything
differently) and might be regarded as a worse solution because of the
need to download code that will never be executed in the context of the
IE only problem.

A even more 'general' solution would consider the case of
a null object, etc,

Again that is not a more general solution to the problem it is a
solution to a more general problem. Specifically, instead of stipulating
that the parameter should be an Element the problem now asserts that any
parameter must be handled (suggesting that some verification that the
parameter actually is an Element happen before passing it to the -
getComputedStyle - method), or that the parameter be and Element or null
(much easier to test).

Design wise I wouldn't bother. Better to have the code that calls this
function verify the parameter before the call as it is likely to still
have an interest in the Element-ness of the object when it gets the
return value.

but I will not list that here for the sake of brevity.

An EVEN MORE 'general' solution could take the property as an
argument, so the method could be reused for obtaining any style
attribute:

Or it is a solution to the more general problem:-

Retrieve the currently applicable (non-normalised) value an arbitrary
CSS property as a string from any Element whenever that information is a
vailable or a distinguishable alternative when it is not available.

function getObjectStyleValue(obj,property) {
if (obj.currentStyle) {
return obj.currentStyle[property];
}
else if (obj.document && obj.document.defaultView &&
obj.document.defaultView.getComputedStyle) {
return
obj.document.defaultView.getComputedStyle(obj,'').getPropertyValue(
property);
}
return null;
}

The nice thing about this more general problem is that once it has been
solved its solution also negates the problem of retrieving all specific
CSS property values. However, in the event that the problem in context
is the retrieval of the 'color' property the actual solution to that
problem is calling this function with 'color' as its parameter.

But what happens if this more general problem cannot be solved? Can the
function that only returns the CSS color property be regarded as a
'partial solution' to this more general problem. We know that it will
return a correct and useful value for a subset of possible parameters.
Would it become a 'partial solution' when that subset became the
majority of possible parameters?

Or if we use it in a context where the majority of CSS property
retrievals are for 'color' and so we mostly get the correct answer. Does
that make it a 'partial solution' to the more general problem?

And if we use it in a context where the only CSS property we are
interested in is 'color'? The results will be no worse than would be
expected from the solution to the more general problem. Does achieving
the same results in a restricted context make retrieving the color alone
a 'partial solution' to the problem of retrieving any arbitrary CSS
property's value?

I don't think that there is such a thing as a 'partial solution', just
poorly identified/defined problems. The solution to a more general
problem may be regarded as a more general solution because it will
negate a set of related but more specific problems, but the solution to
any subset of those more specific, related problems are never a less
general solution to the more general problem. They are a failure to
solve the more general problem (even when the more general problem
didn't actually need solving and the solutions to some of its more
specific related problems are enough to get the job done).

An EVEN MORE 'general' solution might take into consideration
some specific browser quirks, or NN4, etc.

(Netscape 4 is a browser quirk

Which is actually a 'better' solution to the problem of getting the
value whenever that information is available, as it recognises that
there are some other places where the information may be available.

I would consider the improved 'getObjectColor' function to be a
general method of obtaining the color of an object.

It is certainly close to being as general a method as any could be.

But the 'getObjectStyleValue' method is even better, since
it's a general method to obtain any style value.

None of these are 'exhaustive' solutions, however. There are
certainly cases and browser quirks which are not considered.
However, these functions in their finished form would surely
provide the desired functionality for most people in most
contexts, so they could be presented as a 'general' solution.

The ability to present anything as a general solution is not in doubt.
How justified that assertion would be is a different matter. Given how
wrong the output of that function will be in some contexts it does not
seem reasonable to consider it general just because it will behave as
expected in most contexts.

The goal of building 'general' solutions is to provide
functionality that works in the majority of contexts that
arise in typical development.

No, that is the goal of providing functionality that will work in the
majority of contexts that typically arise in development.

The goal is never to build an exhaustive solution
which covers all possible situations.

Never? Why not? If it is trivial to produce exhaustive code then that
satisfies a requirement to provide code that works in the majority of
contexts that typically arise.

That's not possible in most cases. (In cases where it is
possible, it is certainly a good goal!)

Precisely. But these confusions and contradictions on your part appear
to stem form applying woolly thinking to the task of identifying the
problem that is to be solved.

Your insistance that a 'general' solution must be 'exhaustive'
is incorrect (or at least, not the typical opinion).

Typical of who exactly?

I've checked with a number of other developers in a forum
I participate in, and they all agreed that they do not
necessarily consider a 'general' solution to address every
possible need which might arise.

So you are not alone in your woolly thinking. But you present no
evidence that the question asked was applicable, or that the answers
given, if any, are accurately reported here.

So, when I attempt to build a 'general' solution for finding
the position of an object, for example, I'm attempting to
address the majority of typical contexts in which it would be
used. So most people, under most conditions, _could_ in fact
drop the library into their code and have it work correctly.

So abandon describing the result as "general" and assert that the
results are a solution to the problem that you are really trying to
solve.

If exceptions happen (and they will) then I would hope that
the person finding it would tell me details and provide a
test case so I could determine if the need is typical enough
(in my own opinion) to be included in the general library
and should be fixed, or if their context is so specific to
their situation that they would need to write specific code
for their case.

An unrealistic expectation given your assertion that the developers in
question can be expected to have little understanding of the technology
they are using.

Of course, when people such as yourself claim to find an
exception and refuse to provide details or a test case,
that doesn't help to make the general routine more solid.
In fact, since you refuse to provide any evidence, I'm not
sure I even believe you. It's easy to make empty claims. *shrug*

And listing the CSS properties (most of which are not applicable to IE)
and that the browser in question was IE was not enough for you to
experiment for yourself?

A 'partial solution' is valuable because it solves a
specific case and can be used in a more general solution.
For example, the code using currentStyle to find the style
applied to an object is a 'partial solution' because it
does solve the problem for a subset of all cases. Combined
with other 'partial solutions' they form a more general
solution which is more valuable.

There is a difference between asserting that something is a 'partial
solution' and recognising that it may be part of the real solution. The
problem is not solved until there is a solution.

Nothing will change your opinion of my efforts, Richard,
so what I write won't even matter.

My opinion could be changed if you exhibited behaviour that was
inconstant with my beliefs about your motivations. For example, my
beliefs suggest that you will remain unwilling to make a public
statement that answers my previous (and repeated) question as to whether
you believe that the clients of a professional providing technical
and/or design services has a reasonable right to expect that
professional to have an understanding of the technologies they use. A
public expression of support for caveat emptor would not be good PR for
you (or anyone else for that matter).

But, the truth is that when I direct people to my stuff, it's
always because it _specifically_ addresses their needs,

That is just not true. In the majority of the cases I have seen there is
just not sufficient information available for anyone to be in a
po9sition to know the specific needs of an OP, except possibly that OP.

and I think they will benefit from it.

If you took the time to ascertain specific needs then that may be true.
But since you actually promote your code when you perceive it
potentially applicable your motivations seem other than your altruistic
assertions.

I don't advertise.

Posting URLs in signatures of Usenet posts is considered an acceptable
form of advertising (within the recognised limits).

If you have specific code which solves their specific problem,
you may post it. If I have already written a solution which
solves their problem, I may direct them to it.

Without ascertaining what the real specific problem is?

I happen to offset the cost and development time with
donations and google ads, although I certainly do not 'come
out ahead' in the game.

But you would make that claim even if that income represented a
significant contribution to your income, because voluntary contributions
are more likely when the recipient seems altruistically motivated.
People are more willing to give money when they can feel good about
doing so.

If I were trying to make a profit, I would be charging for
my work rather than giving it away with almost no useage
restrictions.

That doesn't follow. Given that when you sell something the purchasers
have expectations about what they get (fitness for the task, support,
ongoing development, etc) and you have to get involved in all the legal
stuff that goes along with running a business (keeping accounts, paying
sails tax, etc) it is entirely possible for a business model based on
voluntary donations to produce greater returns for the effort.
Especially when promoted as an altruistic enterprise where any donations
will act for the greater good.

My goal is to provide solutions which help average web
developers perform complex tasks which they may not be able
to do themselves.

Which brings us back to the point of the 'teach a man to fish' cliché;
helping the average developer to understand how to perform complex tasks
for themselves so obviously is going to be doing them more good in the
long run that questioning your asserted motivations seems reasonable
when you spend your time actively discouraging the 'average web
developer' form even recognising a need to understand what they are
doing.

I get personal satisfaction knowing that I've helped
thousands of people solve their problems

That certainly would be easier to live with than recognising all of the
harm done to clients (and users) by all of the needless and avoidable
introduction of javascript dependencies that will have resulted from
your actions.

when people like you would have told them
that they didn't even deserve to be helped.

Would people like me have told them that?

If
If?

I'm ever seen as 'promoting' my stuff, it's because I want
people to be made aware of packaged solutions which can
solve their problem,

Well, we have seen how imprecisely you identify problems.

rather than being faced with people telling them how stupid
they are,

I only recall one of us asserting that the 'average web developer' was
incapable of understanding what they were doing.

or resorting to finding terrible code at some copy-n-paste
javascript site.

And heaven forbid that anyone should find a pre-packaged 'solution' on a
copy-n-paste javascript site

If you don't believe me, that's fine. I don't care.

Another case where behaviour doesn't appear to correspond with
assertions.

Richard.

 

[Matt Kruse]

Then why do you talk about your code being general when you are only
asking it to be braod?

Because we have a difference in terms. By a "general solution", I am meaning
a solution to a more general problem. If you want to call it 'broad' that's
fine.

If the person doing the dropping has no technical understanding of
what they are doing then they are unlikely to be able to create a
test case

Don't be so obtuse. Your logical reasoning (or lack thereof) makes you draw
all these incorrect conclusions about statements I've made.

I said one of the goals is for someone with limited technical understanding
of javascript to use the libraries. That does NOT mean that everyone using
them will be in this category. There are certainly very skilled developers
who can build test cases and point out specific flaws who are using these
libraries. And then there are people who can barely write html who drop them
in and use them. The audience is varied, although you want to pigeon-hole
them all into being 'stupid users'.

You haven't precluded the possibility of 'general' being an absolute.

I've implied it, if not stated it outright. 'General' is relative.
'Exhaustive' is absolute. Your 'glass' example is pointless.

[snip nit-picking about the problem definition in my posted code examples]

You're just being argumentative. The functions I posted were an example of a
function progressing from less general to more general, in order to
illustrate the point. It was not meant to be a perfectly-stated problem or
perfect solutions. I thought that was obvious.

Again that is not a more general solution to the problem it is a
solution to a more general problem.

Which to me says the same thing.

But what happens if this more general problem cannot be solved? Can
the function that only returns the CSS color property be regarded as a
'partial solution' to this more general problem. We know that it will
return a correct and useful value for a subset of possible parameters.
Would it become a 'partial solution' when that subset became the
majority of possible parameters?

IMO, yes. In the cases where a correct value isn't returned or can't be
returned, it should either attempt to arrive at the values in a different
way or return a consistent result, or at least note the known conditions
where it will not return the correct value.

I don't think that there is such a thing as a 'partial solution', just
poorly identified/defined problems.

Perhaps 'partial solution' is a bad term, I don't know. To me, a 'partial
solution' is a solution which solves the general case for a subset of all
possible permutations, but solves that subset exhaustively. So it's known
that the solution isn't general enough to be used in every context. But when
used in the contexts where it applies, it can be regarded as an exhaustive
solution.

No, that is the goal of providing functionality that will work in the
majority of contexts that typically arise in development.

Semantics games! I stand by my original statement.

Typical of who exactly?

The web developers I've come into contact with in the last decade or so.
Shall we do a worldwide poll?

An unrealistic expectation given your assertion that the developers in
question can be expected to have little understanding of the
technology they are using.

Again, your erroneous logic assumes that because *some* developers have
little understanding of the technology, then *all* developers must. This is
not the case.

And listing the CSS properties (most of which are not applicable to
IE) and that the browser in question was IE was not enough for you to
experiment for yourself?

No, because it could be a waste of my (limited) time. I know there are some
quirks in IE, as noted at the top of the page. So if you set an object's
position to 'relative' and saw it fail, that wouldn't surprise me at all,
since I already noted that. I know that other problems may exist. I haven't
fully tested it yet or built enough test cases. That's why it's not
'released' yet, and I'm still gathering feedback.

you will remain unwilling to make a public
statement that answers my previous (and repeated) question as to
whether you believe that the clients of a professional providing
technical and/or design services has a reasonable right to expect that
professional to have an understanding of the technologies they use.

Yes. A professional providing technical services should have an
understanding of the technologies they use.
In an ideal world, that would always be the case.
However, reality is never an ideal case.

For example,

1) You can pay $200/hr for an expert, and you can hire a college kid for
$15/hr. Your expectations about their level of understanding of the
technologies would certainly not be the same in both cases. Sometimes you
don't expect perfect results or great code, because you know you can't
afford it!

2) Someone can pass themselves off as an expert but in fact not deliver
expert results. This is extremely common! A _lot_ of coding is done to poor
standards by supposed 'experts' who actually ship the work off to India or
some group of inexperienced developers.

Furthermore, since my libs are not targeted exclusively at professionals who
should understand the technology themselves, it seems odd to even make this
point. Even if you think that professionals being paid for their work
shouldn't use libraries, why do you also believe that casual developers or
volunteers should also not use them?

That is just not true. In the majority of the cases I have seen there
is just not sufficient information available for anyone to be in a
po9sition to know the specific needs of an OP, except possibly that
OP.

Because you don't believe in general solutions, you always require more
information from the OP and specific requirements.
Since I write general solutions, I can reasonably deduce that my solution
will fit the OP's needs without having specific requirements, because I know
it can handle most common cases that arise. If it didn't look like the OP's
situation would fit into my solution, I wouldn't recommend it!

Which brings us back to the point of the 'teach a man to fish' cliché;
helping the average developer to understand how to perform complex
tasks for themselves so obviously is going to be doing them more good
in the long run that questioning your asserted motivations seems
reasonable when you spend your time actively discouraging the
'average web developer' form even recognising a need to understand
what they are doing.

That's an incorrect characterization of my point of view. I will always
encourage people to learn the skills needed to write things on their own. I
would never discourage someone from learning to solve a problem from scratch
to enhance their understanding of it. I just realize that this is not always
practical or necessary in a given situation.

That certainly would be easier to live with than recognising all of
the harm done to clients (and users) by all of the needless and
avoidable introduction of javascript dependencies that will have
resulted from your actions.

a) I do plan to write more about the javascript dependencies introduced by
each of my libs as I revamp my site.
b) I do plan to provide more examples which 'degrade gracefully'
c) I don't think that introducing javascript dependencies is a bad thing
d) I don't think your view of the web is in line with every 'intelligent'
developer out there, as you seem to think.
e) If I've done so much harm, why do I not get hundreds of emails a day
telling me so? Oh, that's right, because nobody understands like you do. It
must be rough to be at the top, eh?

I think 'unobtrusive javascript' is a great thing, but I also think that
many sites and developers are happy to require javascript for some
functionality. The need to 'degrade gracefully' is not absolute, as you
imply. There are plenty of contexts where such a need doesn't exist at all.

 

[Thomas 'PointedEars' Lahn]

[...]

Matt, yours was a 201-lines response to Richard's 446-lines response to
your 189-lines response to Richard's 146-lines Response, where apparently
the subject discussed is no longer restricted to JS programming but instead
deals with what to call how properly in terms of software development.
I think it is highly unlikely subscribers of this (JS) newsgroup will
benefit from what is supposed to be a 500-lines response from Richard,
and I think we are well beyond the point where the discussion should
move to another, perhaps more general newsgroup, or to private e-mail.
Please, let's call it a thread, shall we?


PointedEars

 

[Randy Webb]

Thomas 'PointedEars' Lahn said the following on 11/13/2005 11:26 AM:

Matt Kruse wrote:

[...]

Matt, yours was a 201-lines response to Richard's 446-lines response to
your 189-lines response to Richard's 146-lines Response, where apparently
the subject discussed is no longer restricted to JS programming but instead
deals with what to call how properly in terms of software development.

Welcome to Richard, Matt and clj

I think it is highly unlikely subscribers of this (JS) newsgroup will
benefit from what is supposed to be a 500-lines response from Richard,
and I think we are well beyond the point where the discussion should
move to another, perhaps more general newsgroup, or to private e-mail.
Please, let's call it a thread, shall we?

Huh? And miss all this fun? You are kidding, right?

 

[VK]

Matt, yours was a 201-lines response to Richard's 446-lines response to

your 189-lines response to Richard's 146-lines Response, where apparently
the subject discussed is no longer restricted to JS programming but instead
deals with what to call how properly in terms of software development.
I think it is highly unlikely subscribers of this (JS) newsgroup will
benefit from what is supposed to be a 500-lines response from Richard,
and I think we are well beyond the point where the discussion should
move to another, perhaps more general newsgroup, or to private e-mail.
Please, let's call it a thread, shall we?

I guess they are well covered by the foggy thread subject ("Best
practice" can encompass anything). But truthfully I'm enjoying the
matter of this discussion - but yes, it's getting too multiwordy.
Lesser reasonning - more proofs.

Overall as I see it - this is a reflection of two schools: Academic one
that consider JavaScript (or programming at whole) nearly as a way to
the internal perfectness and the right recognition of the world.

The other one takes JavaScript (or programming at whole) as a much more
humble *practical* matter. You may guess what side I am.

About libraries vs. "know everything yourselve" - just a little sample:

I order to make IE's FileScriptingObject to work as documented I had
(including but not limited to):
1. Use Enumerator class wrapper as file/folder collections are not
accessible via for...in loop.
2. Create predefined literals for file operation modes (ForReading,
ForAppending etc.) because Microsoft has documented them but has
forgotten to implement.
3. Make char stream setting monitor to fix double interface glitch for
new files (because expected encoding is set twice independently in the
File object and in the TextInputStream object.

And that was only for Microsoft. I'm just starting with Gesko but I bet
my head against your hat what there will be a bunch of similar
surprises there too.

Why should we force everyone to go throu this process over and over
again instead of using a library?
Why skipping on finding and fixing 3rd party implementation errors
should hurt anyone?

 

[Randy Webb]

VK said the following on 11/13/2005 1:04 PM:

The other one takes JavaScript (or programming at whole) as a much more
humble *practical* matter. You may guess what side I am.

About libraries vs. "know everything yourselve" - just a little sample:

I order to make IE's FileScriptingObject to work as documented I had
(including but not limited to):

A better question for you would be, other than a good exercise, what
good is a web-based File Manager? Really, the only place its going to
work is on Windows based systems and then Windows has a built in FM that
has more features.

After that, the library is of little use. Except in an intranet
environment where the Win FM is still better.

 

[VK]

That's going to be really
<OFFTOPIC>

A better question for you would be, other than a good exercise, what
good is a web-based File Manager? Really, the only place its going to
work is on Windows based systems and then Windows has a built in FM that
has more features.

Wrong, because FileScriptingObject is used only for the "IE under
windows" block. Second part implements XPConnect equvalent which works
for all Gesko based browsers on all platform. So the total tested
coverage of jsFileManager will be:
Internet Explorer 5.0 or higher under Windows 98, NT, 2000, ME, XP
Gesko browsers under any platform.
- all by using single constructor call and uniformed interface.

I would say that this coverage is more than satisfactory and it can be
called "universal with few limitations" (a profound examination of the
term "universal" see in this thread

It still will not work but degrade seemlessly on an ancient browser or
say on "myFirstBrowser v0.1" under "KickA**OS v.01.002"
Guess how much should I and do I care?

After that, the library is of little use. Except in an intranet
environment where the Win FM is still better.

Wrong again, because you're missing the whole new big market of
JavaScript desktop applications - what Microsoft tried to push with
their HTA.
No access to file system and limited graphics abilities were the main
reasons it did not start earlier.

Now Firefox comes with SVG native support and VML in Microsoft plus
universal file access module - plus programming environment and
interpreter installed on 99.99% of existing PC's (did you see many PC's
w/o a browser on it?)
Sun with their stupid Java attempts never stayed even close to this.

Again - jsFileManager will work in the same way on both IE and Firefox
(universally - Gesko). Otherwise I would't mention it in this group.
</OFFTOPIC>

 

[Matt Kruse]

Thomas 'PointedEars' Lahn said the following on 11/13/2005 11:26 AM:
Welcome to Richard, Matt and clj

Believe me, I try not to make it so. Richard is absurdly verbose in most of
his posts here, and to keep anything short and to the point with him is near
impossible. I think he does have valuable insights into some things, and
is - at the very least - a good "devil's advocate" to my points in this
thread. He just types too damn much and argues about details instead of
seeing the bigger discussion sometimes.

I keep posting in threads like this because I think many of the questions
and issues raised are important and interesting to discuss. And they aren't
generally happening in other threads

Huh? And miss all this fun? You are kidding, right?

Do your news readers lack the ability to ignore an entire thread so you
don't even see it? I use it regularly, even in this newsgroup.

 

[Matt Kruse]

The other one takes JavaScript (or programming at whole) as a much
more humble *practical* matter. You may guess what side I am.

Hmmm.... I'm not sure if that helps my case

 

[Randy Webb]

Matt Kruse said the following on 11/13/2005 8:39 PM:

Believe me, I try not to make it so. Richard is absurdly verbose in most of
his posts here, and to keep anything short and to the point with him is near
impossible. I think he does have valuable insights into some things, and
is - at the very least - a good "devil's advocate" to my points in this
thread. He just types too damn much and argues about details instead of
seeing the bigger discussion sometimes.

I know, and agree with you 100%. Richard is very verbose at times, to
the point of being overly verbose.

I keep posting in threads like this because I think many of the questions
and issues raised are important and interesting to discuss. And they aren't
generally happening in other threads




Do your news readers lack the ability to ignore an entire thread so you
don't even see it? I use it regularly, even in this newsgroup.

It probably does, never looked for it. This thread actually doesn't
bother me, its informative to say the least.


--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Answer:It destroys the order of the conversation
Question: Why?
Answer: Top-Posting.
Question: Whats the most annoying thing on Usenet?

Please quote what you are replying to.

If you want to post a followup via groups.google.com, don't use the
"Reply" link at the bottom of the article. Click on "show options" at
the top of the article, then click on the "Reply" at the bottom of the
article headers.

 

[Randy Webb]

Matt Kruse said the following on 11/13/2005 8:40 PM:

Hmmm.... I'm not sure if that helps my case

With VK's past here, it doesn't help it any

 

[Thomas 'PointedEars' Lahn]

Do your news readers lack the ability to ignore an entire thread so you
don't even see it? I use it regularly, even in this newsgroup.

That is a very old argument which has been refuted very often already.

Firstly, what you post has to be distributed throughout the world, from one
NetNews peer server to another, according to the decentralized structure of
Usenet; it is consuming resources many provide for free to keep the medium
running.

Secondly, how dare you imposing your perception of a viable newsreader
on others just to satisfy your personal quarrel?

You are wasting precious bandwidth if you post something that is only to
value for two people. (And before one of the trolls around here starts
blathering: I try to continuously remind me of that important fact,
however I am not perfect either.)

Please don't get me wrong: I think your dispute, even in all its length,
is valuable in terms of semantics, maybe software development. However,
I fail to see any value in it regarding JS/ECMAScript programming
_specifically_ which is why I consider it to be off-topic in _this_
newsgroup.


PointedEars

 

[Matt Kruse]

Firstly, what you post has to be distributed throughout the world,
from one NetNews peer server to another, according to the
decentralized structure of Usenet; it is consuming resources many
provide for free to keep the medium running.

That's an absurd argument, given the quantity of news that gets distributed
daily.

Secondly, how dare you imposing your perception of a viable newsreader
on others just to satisfy your personal quarrel?

I was just pointing out a convenience feature which you or others may not be
aware of.

You are wasting precious bandwidth if you post something that is only
to value for two people.

I disagree. I think the bigger issues being discussed are valuable to many
others. When Richard makes it personal, I try to [snip] those parts out and
not even respond.

Please don't get me wrong: I think your dispute, even in all its
length, is valuable in terms of semantics, maybe software
development.

Semantics certainly is not something I care to debate, and the bigger issue
of software development is something I'd like to steer away from also.

However,
I fail to see any value in it regarding JS/ECMAScript programming
_specifically_ which is why I consider it to be off-topic in _this_
newsgroup.

Well, I disagree. Much of the discussion is specific to javascript - dealing
with generalizing methods for different contexts and browsers, delivering
extra code to the browser, dealing with different skill levels of javascript
developers, and the merits of a library approach to solving problems.

I agree that this thread has become a bit tiresome, but I think that could
be avoided with shorter more concise posts and less nit-picking about minute
points while ignoring the general issues.

It is the nature of newsgroups to have many posts and topics which do not
interest you personally. That's why I recommended using a newsreader with a
feature to ignore entire threads. I would imagine that anyone who grew tired
of this thread would have zapped it long ago and wouldn't even be bothered
by this off-topic discussion we're having now.

To continue this really _would_ be off-topic, so I'll try to keep responses
only to js-related posts from now on...

 

[Randy Webb]

Thomas 'PointedEars' Lahn said the following on 11/14/2005 5:16 PM:

Matt Kruse wrote:




That is a very old argument which has been refuted very often already.

What argument? That you, as the reader, control what you do or do not
read? That is precisely why NewsReaders have killfile's in the first place.

Firstly, what you post has to be distributed throughout the world, from one
NetNews peer server to another, according to the decentralized structure of
Usenet; it is consuming resources many provide for free to keep the medium
running.

Every post in every thread in this group (and all other Usenet groups)
have to be propogated also. This thread is not even making a slight
dimple in the resources used to keep Usenet running.

Secondly, how dare you imposing your perception of a viable newsreader
on others just to satisfy your personal quarrel?

And in the same token, how dare you attempt to impose your perception of
a timeframe for the end of a thread? You control what you do or do not
read, use that control.

You are wasting precious bandwidth if you post something that is only to
value for two people. (And before one of the trolls around here starts
blathering: I try to continuously remind me of that important fact,
however I am not perfect either.)

You are assuming that it is of value to only two people. Just because
only two people are posting to the thread does not mean other people are
not reading/gaining from the thread.

Please don't get me wrong: I think your dispute, even in all its length,
is valuable in terms of semantics, maybe software development.

It has value, to me anyway, in terms of WWW scripting.

However, I fail to see any value in it regarding JS/ECMAScript programming
_specifically_ which is why I consider it to be off-topic in _this_
newsgroup.

If you search these archives for CSS only, HTML only, and non-JS
solutions, the number of posts you find will be far far greater than the
posts in this thread. The point is, there are a ton of off-topic threads
in this group that take up a lot more resources than this one ever will.

If you don't want to read it, killfile the thread. Then, you are saving
your bandwidth, you are not adding to the bandwidth usage, and everybody
moves on.