n00b questions for javascript!

[Kenny]

I been at this a while, I know quality when I see it. Little things like
the build process, the runtime errors (amazing detail),

[Exception... "'Error: Error in property asynchronous of class
qx.io.remote.Request in method setAsynchronous with incoming value
'undefined': Undefined value is not allowed!' when calling method:
[nsIDOMEventListener::handleEvent]" nsresult: "0x8057001c
(NS_ERROR_XPC_JS_THREW_JS_OBJECT)" location: "<unknown>" data: no]

Doh! Missed off a new parameter from the call site. Instant debugging
thx to thorough work by the qooxers.

kt

 

[David Mark]

Working out pretty well, too, for what classes do best: divide up huge
wodges of code and even maybe make reuse a little easier.

Working out pretty well? I already showed you a sample that will
clearly cause problems. It was a pretty low-level function too, so
God only knows how many things call it. So what are you judging by?
Pretty graphics on the demo pages?

qooxdoo Just Works. If I work for two hours I produce two hours of
application. It has been a while since I experienced that playing with
dojo and yui.

But your "application" will only "work" in a handful of browsers in
their default configurations and it will be huge. How is that useful?

I gotta confess, a build of my qooxdoo app is now bigger than that!

No kidding.

I am talking about click vs shift-click vs control-click -- the simplest
thing in the world and qooxdoo is the first I have seen that got it right..

LOL. That accounts for about two lines of code. I wonder if they
used browser sniffing there too? How do you justify the other 300K of
rubbish to your client? Oh sorry, did I say I knew browser
scripting? I lied. After ten minutes of arduous research, I
concluded that 300K+ of rubbish called "qooxdoo" (sp?) would
compensate for my inabilities. It didn't "Just Work" as I first
thought. Sorry for any inconvenience.

I been at this a while, I know quality when I see it. Little things like

No you don't.

the build process, the runtime errors (amazing detail), the slick layout

Oh yes, the "runtime errors." I saw that they throw exceptions on
invalid arguments in lots of functions. That is an ignorant thing to
do and accounts for much of the bloat.

(nothing else comes close -- well, I did not try them all).

You could have saved time by not typing that.

And I like to shoot from the hip.

I will come back and confess if it does not work out for us.

That's already been predicted.

 

[Kenny]

[snip]

Meanwhile I see these hardcores here want me doing html and css -- I bet

That makes no sense. Poorly written "framework" scripts are hardly a
substitute for HTML and CSS.

qooxdoo means to hide html and css completely. they are still there,
just as there are native instuctions behind my Lisp code, but I am not
supposed to have to think about them.

Have they succeeded? I dunno, so far, no HTML, no CSS, and she looks
nice and works. except on IE.

You still don't get it. People who actually write browser scripts
accumulate repositories of re-usable code. That's what they use to
build Web applications.

Great! I would love a pointer to the most highly recommended open source
repositories. (Google shows one last updated in 1996 -- is that it?) In
fact, it may not be too late -- I'd love not to use a library, esp. one
like qooxdoo that makes me write JS (nice language, but it's no Lisp) --
but I just found out I have till after Thanksgiving to produce or I go
the way of all turkeys, so make it fast!

Those who do not, download other people's

repositories and pray that the authors knew what they were doing (and
will always be there to help them.) The impetus to stick with them is
so strong (anything to remain blissfully ignorant to the rigors of
browser scripting)

You know, all you are describing is every use of technology to get ahead
without reinventing the wheel. Of course people use libraries.

Do many libraries suck, js or not? Yep. Are many great. yep. Are any JS
libraries great? qooxdoo is my last gasp. Will JS always suck? Nope.

that some communities "flourish" even after their

leaders have been exposed as clueless windbags (e.g. John Resig.)
Good luck with that. See you back here in a few months with lots of
impossibly complex problems.

I'll lose the contrat in two weeks if you are right, I'll come back so
you can all gloat.

The important point is that no one here has offered any alternatives
other than a ten year apprenticeship. And that is not an alternative.

kt

 

[David Mark]

[snip]

Meanwhile I see these hardcores here want me doing html and css -- I bet

That makes no sense.  Poorly written "framework" scripts are hardly a
substitute for HTML and CSS.

qooxdoo means to hide html and css completely. they are still there,

That makes zero sense when describing a browser scripting framework.

just as there are native instuctions behind my Lisp code, but I am not
supposed to have to think about them.

What does that mean in this context?

Have they succeeded? I dunno, so far, no HTML, no CSS, and she looks

No HTML or CSS? What are you serving?

nice and works. except on IE.

"Works" on everything but the most used browser. Great.

Great! I would love a pointer to the most highly recommended open source
repositories. (Google shows one last updated in 1996 -- is that it?) In

Who said anything about an open source repository? And the
repositories of the late 90's have been replaced by libraries that are
stocked with similarly incompetent code.

fact, it may not be too late -- I'd love not to use a library, esp. one
like qooxdoo that makes me write JS (nice language, but it's no Lisp) --

What does that mean?

but I just found out I have till after Thanksgiving to produce or I go
the way of all turkeys, so make it fast!

So, you are willing to throw anything at the client to avoid
termination.

I just read an interesting quote from an equally clueless blogger
(which was resoundingly approved by lots of oddly named people at the
bottom of the page.) I think it applies here.

"A JavaScript framework may not make you a better programmer, but it
will make you more efficient."

More efficient at doing what? Writing inefficient code? So the
programmer "saves time" (quotes indicate that it is all borrowed
against the inevitable future rewrites) by saddling the users with
needless delays.

It goes on to say:

"That alone should be reason enough to choose a JavaScript framework,
or library if you prefer."

Really?! So you can churn out trash faster and then throw your hands
up when things inevitably go to hell (call the jQuery guy!)

  Those who do not, download other people's


You know, all you are describing is every use of technology to get ahead
without reinventing the wheel. Of course people use libraries.

What you fail to understand is that none of the general-purpose
libraries out there were good ideas in the first place. Why re-invent
them? Yes, lots of people have tried. I even wrote a similar library
(in my defense, it is at least modular.) Do I use it? No, I
inevitably make a build of the features I need for a project and then
chip away everything that is unneeded in that context. Typically I
save the stripped down versions of each function for future use.

It is just plain stupid for a Web application to serve unneeded code
(even stupider if that code is incompetently written.) Stupidest of
all is to serve lots of obviously incompetent and unneeded code, and
that perfectly describes the average browser scripting library.

For a concrete example, I have been working in my spare time on a
sequel to "My Library", which is tentatively titled "My Page." It is
an HTML template (probably won't bother with XHTML this time around),
assorted alternate style sheets (themes in library-speak) and a script
that is essentially a stripped-down version of my library. It is
intended as a starting point for those who wish to publish accessible,
semantic documents on the Web, without sacrificing "cool" features
like removable (or re-arrangable) navigation, special effects, themes,
persistence, etc. The effects, drag and drop, etc. are easily more
impressive (and infinitely more compatible) than anything built with
one of those 300K monstrosities. Last I checked, after I had added a
few bells and whistles that will likely be made optional in the
builder, the script was 11K (minified but uncompressed.) This is
because I only had to design for certain DOM structures and styles
(and doesn't that describe any Website development?)

In short, the first three rules of browser scripting are context,
context, context.

Do many libraries suck, js or not? Yep. Are many great. yep. Are any JS

What makes you qualified to judge the "greatness" of code written in a
language you don't understand. Perhaps you should instead listen to
those who do understand it?

libraries great? qooxdoo is my last gasp. Will JS always suck? Nope.

Then you are about to suffocate. You can't say you weren't warned.

that some communities "flourish" even after their


I'll lose the contrat in two weeks if you are right, I'll come back so
you can all gloat.

Whether you lose the "contrat" is a matter for management. You may be
in luck there as most managers know nothing about browser scripting
(you are supposed to be the expert.)

The important point is that no one here has offered any alternatives
other than a ten year apprenticeship. And that is not an alternative.

I offered no such apprenticeship. And if you are a LISP programmer,
then you should be able to pick up browser scripting in something less
than ten years.

Another alternative would be to do something else with your life.

 

[Kenny]

Never mind. I see that the question is "name another monstrous blob
of ill-advised browser scripting rubbish."

/**
* Whether the first element contains the second one
*
* Uses native non-standard contains() in Internet Explorer,
* Opera and Webkit (supported since Safari 3.0 beta)
*
* @signature function(element, target)
* @param element {Element} Parent element
* @param target {Node} Child node
* @return {Boolean}
*/
contains : qx.core.Variant.select("qx.client",
{
"webkit|mshtml|opera" : function(element, target)

So if some baseless series of characters contains these strings
(assumes some variant of Safari, IE or Opera), take this fork.

{
if (qx.dom.Node.isDocument(element))

Passing a document to this would seem a waste for most applications.
And who knows what sort of mysticism is used in this "isDocument"
method? Designs that require differentiating between host object
types are doomed to fail (see jQuery.)

{
var doc = qx.dom.Node.getDocument(target);

return element && doc == element;

} else if (qx.dom.Node.isDocument(target))
{
return false;

Waste of code.

}
else
{
return element.contains(target);

Assumes a non-standard method exists. Blows up in anything that looks
remotely like IE, Safari or Opera, but does not implement a "contains"
method on elements.

}
},

// http://developer.mozilla.org/en/docs/DOM:Node.compareDocumentPosition
"gecko" : function(element, target) {

Sure, anything that calls itself "Gecko" must...

return !!(element.compareDocumentPosition(target) & 16);

support compareDocumentPosition!

},

Hmmm, not sure but I think a lurker just filed a bug report over on
qooxdoo related to this. If not it is coincidentally *very* close, and
certainly in the same spirit of faulty browser detection.

Speaking of spirit, the above nicely makes the whole point of libraries:
they constitute a way of collecting in one place tech wisdom (in re
things like isolating browser variability) and effort (when fancy
datagrids can be had off the shelf).

Not sure why this is such a threat to you all that you have to speak so
disparagingly of those who take the trouble to build them and noobs like
us who try to use them.

Worrying about bloat is ok, but doesn't that yield eventually to
optimizers that can prune the unneeded? (Answer:yes, but watch out for
dynamic code). Similarly, people whine about it being impossible to
build an 8k exe in Lisp, as if 8k exes are a widespread target. ie, You
are impressing no one but your self.

A web application is not launched to check the weather or respond to a
google ad, it is launched for at least five minutes of work and launches
faster than any of my desktop apps. That sound you just heard was the
"game over" sound from Pac Man.

Why don't you all lose the grumpy old men in the balcony of The Muppets
act and start an Anti-Framework project? I'd use it, I like lean and
mean, truth be told.

Oh, and start watching late night comedy, you seriously need to grow a
sense of humor.

hth, kt

 

[Matt Kruse]

It is just plain stupid for a Web application to serve unneeded code

That's not a convincing argument. If my browser gets 10k of code that
isn't needed on page X, but caches it and has in on hand for when page
Y needs it, then that isn't so bad. It might be bad to serve 500k of
unneeded code. Not so bad to serve 1k of unneeded code. Where to draw
the line is up for debate.

an HTML template (probably won't bother with XHTML this time around),

Obvious choice, since XHTML is a bad choice to begin with.

 This is
because I only had to design for certain DOM structures and styles
(and doesn't that describe any Website development?)

Not at all. What about, for example, an open source tool that is used
by many sites and allows the users to create their own themes and
layout? If the tool is to have any scripting features, it needs to
create them in as generalized a way as possible, to consider as many
different DOM structures as it possibly can. The tool authors don't
get the chance to go back and selectively choose the code module that
will work in a given layout. It has to be generalized. What approach
to you recommend they take?

What about writing a "widget" for a webapp that can be inserted on any
page by the app admin? The widget should be self-contained, yet it
can't know anything about it's container until it runs.

What about when a site owner decides to change structure and layout of
their site by modifying their page template, but doesn't want to go
back and re-write javascript code? Wouldn't a more generalized
solution that still works in any design he chooses be the better
choice?

In short, the first three rules of browser scripting are context,
context, context.

And when the context is unknown to you until the time your code runs,
then what? What's plan B?

I offered no such apprenticeship.  

A common argument is that the best alternative to a library is to grow
your own expert in js coding, who creates his own reusable functions
over time and uses them when required.

This works great in some situations, but is not possible for everyone.
People like you rarely offer an alternative other than "well, you
shouldn't be writing javascript, then" which is not helpful or
realistic. At least library authors offer something helpful, even if
you think it's not ideal.

Matt Kruse

 

[David Mark]

That's not a convincing argument. If my browser gets 10k of code that
isn't needed on page X, but caches it and has in on hand for when page
Y needs it, then that isn't so bad. It might be bad to serve 500k of
unneeded code. Not so bad to serve 1k of unneeded code. Where to draw
the line is up for debate.

Far South of these ridiculous general-purpose libraries for virtually
any Web site or application.

Obvious choice, since XHTML is a bad choice to begin with.

As opposed to *both* half-wit.

Not at all. What about, for example, an open source tool that is used
by many sites and allows the users to create their own themes and
layout? If the tool is to have any scripting features, it needs to
create them in as generalized a way as possible, to consider as many
different DOM structures as it possibly can. The tool authors don't
get the chance to go back and selectively choose the code module that
will work in a given layout. It has to be generalized. What approach
to you recommend they take?

I want the last 20 seconds of my life back. Why would you bother to
write such a thing?

What about writing a "widget" for a webapp that can be inserted on any

And this.

page by the app admin? The widget should be self-contained, yet it
can't know anything about it's container until it runs.

You clearly didn't understand what I said. Perhaps one day you will.

What about when a site owner decides to change structure and layout of
their site by modifying their page template, but doesn't want to go
back and re-write javascript code? Wouldn't a more generalized
solution that still works in any design he chooses be the better
choice?

Again, you don't get it.

And when the context is unknown to you until the time your code runs,
then what? What's plan B?

That's the whole point. Optimally, you design script for a specific
context (e.g. a certain set of documents.) If the context of your
site is unknown to you, then you have much bigger problems.

A common argument is that the best alternative to a library is to grow
your own expert in js coding, who creates his own reusable functions
over time and uses them when required.
Right.


This works great in some situations, but is not possible for everyone.

Are you kidding? That is why *everyone* should not be posing as
programmers, especially not in browser scripting. (!) That's another
point you refuse to see after all these months of "debate" on this
subject.

People like you rarely offer an alternative other than "well, you

You have either lost your memory or your mind. And stop trying to be
the Voice of the Delusional Poser.

 

[Kenny]

That's not a convincing argument. If my browser gets 10k of code that
isn't needed on page X, but caches it and has in on hand for when page
Y needs it, then that isn't so bad. It might be bad to serve 500k of
unneeded code. Not so bad to serve 1k of unneeded code. Where to draw
the line is up for debate.




Obvious choice, since XHTML is a bad choice to begin with.




Not at all. What about, for example, an open source tool that is used
by many sites and allows the users to create their own themes and
layout? If the tool is to have any scripting features, it needs to
create them in as generalized a way as possible, to consider as many
different DOM structures as it possibly can. The tool authors don't
get the chance to go back and selectively choose the code module that
will work in a given layout. It has to be generalized. What approach
to you recommend they take?

What about writing a "widget" for a webapp that can be inserted on any
page by the app admin? The widget should be self-contained, yet it
can't know anything about it's container until it runs.

What about when a site owner decides to change structure and layout of
their site by modifying their page template, but doesn't want to go
back and re-write javascript code? Wouldn't a more generalized
solution that still works in any design he chooses be the better
choice?




And when the context is unknown to you until the time your code runs,
then what? What's plan B?




A common argument is that the best alternative to a library is to grow
your own expert in js coding, who creates his own reusable functions
over time and uses them when required.

Perhaps a middle ground would be an Anti-Framework Project
(Unframework?) that just took care of the hard stuff and simply offered
examples of things folks need to do, leaving adaptation to specific
requirements to developers who at least get a headstart from a good
working example. Truth be told, off-the-shelf stuff can be a bear to
understand and live with, so no loss there.

But it occurs to me that qooxdoo offers a core primitives library that
provides the low-level wiring and lets us do the rest:

http://qooxdoo.org/documentation/0.8/setup_a_low-level_application

Nice design, eh?



kt

 

[David Mark]

Hmmm, not sure but I think a lurker just filed a bug report over on

Good for them. Too bad it is a dead project.

qooxdoo related to this. If not it is coincidentally  *very* close, and
certainly in the same spirit of faulty browser detection.

What does that mean?

Speaking of spirit, the above nicely makes the whole point of libraries:
they constitute a way of collecting in one place tech wisdom (in re
things like isolating browser variability) and effort (when fancy
datagrids can be had off the shelf).

And the place to collect such "wisdom" (more like idiocy in most
cases) is on users' hard drives?

Not sure why this is such a threat to you all that you have to speak so

Oh Christ. LOL. There is not a single library jockey (or code monkey
if you prefer) that is even a remote threat to *me*. However they are
a major *irritation* to anyone who has to use the Web on a regular
basis (especially users of off-brand browsers, mobile devices, screen
readers, etc.) Get it?

disparagingly of those who take the trouble to build them and noobs like
us who try to use them.

What did I tell you? Don't use them. Why *you* would argue is a
mystery as you are admittedly clueless on the subject. And I will
speak disparagingly about anyone who pollutes the Web with trash
(especially Javascript trash.)

Worrying about bloat is ok, but doesn't that yield eventually to

Thanks for that.

optimizers that can prune the unneeded? (Answer:yes, but watch out for

No. More wild speculation from somebody who admittedly knows nothing.

dynamic code). Similarly, people whine about it being impossible to
build an 8k exe in Lisp, as if 8k exes are a widespread target. ie, You
are impressing no one but your self.

Will you stop talking about LISP?

A web application is not launched to check the weather or respond to a
No?

google ad, it is launched for at least five minutes of work and launches

Where do you come up with this stuff? And who is talking exclusively
of Web applications. Most code monkeys do not build Web applications
as they are incapable of implementing even the simplest enhancements
without forcing the user to download 300K of incompetently written
code.

faster than any of my desktop apps. That sound you just heard was the
"game over" sound from Pac Man.

Yep. Looks like you will lose the "contrat." Why did you waste all
of this time babbling in here?

Why don't you all lose the grumpy old men in the balcony of The Muppets
act and start an Anti-Framework project? I'd use it, I like lean and
mean, truth be told.

Is that supposed to be a joke?

[snip]

 

[dmark]

Perhaps a middle ground would be an Anti-Framework Project
(Unframework?) that just took care of the hard stuff and simply offered
examples of things folks need to do, leaving adaptation to specific
requirements to developers who at least get a headstart from a good
working example. Truth be told, off-the-shelf stuff can be a bear to
understand and live with, so no loss there.

But it occurs to me that qooxdoo offers a core primitives library that
provides the low-level wiring and lets us do the rest:

[snip]

Do you really think I am going to review more of their code? It
didn't take more than a minute to find the first major blunder. I
threw it away after that. You should do the same.

 

[Thomas 'PointedEars' Lahn]

That's the whole point. Optimally, you design script for a specific
context (e.g. a certain set of documents.) If the context of your
site is unknown to you, then you have much bigger problems.

Yes, *optimally*. However, when you write a *library*, it stands to reason
that you can't always know the context of its application when you write it.

This is no excuse for unnecessarily bloated code, of course, but it is a
good reason for writing more general code in a library because that is what
a library is and should be about, like it or not.

ISTM that you don't see that there can be (at least) two approaches to
writing a library: One, to start with generalizing for one context and
refine the library every time you encounter a new context; two, to try to
write it as general as possible (and reasonable) in the first place so that
it can be used later without much adaption by its user.

Both approaches are taken in their own right. Some people like to develop
libraries, e.g. to provide efficient algorithms for daily tasks to other
developers, and nothing else. That a large number of libraries out there
is badly written, or simply junk, e.g. because the approach taken has been
too general (I'm thinking of jQuery wanting to handle a method check on DOM
nodes) or the author is a half-wit programmer is a /different/ story.


PointedEars

 

[David Mark]

Yes, *optimally*.  However, when you write a *library*, it stands to reason
that you can't always know the context of its application when you write it.

Presumably you mean a library for use by others.

This is no excuse for unnecessarily bloated code, of course, but it is a
good reason for writing more general code in a library because that is what
a library is and should be about, like it or not.

Exactly. That's why writing a *general-purpose* browser scripting
library is silly.

ISTM that you don't see that there can be (at least) two approaches to
writing a library: One, to start with generalizing for one context and
refine the library every time you encounter a new context; two, to try to
write it as general as possible (and reasonable) in the first place so that
it can be used later without much adaption by its user.

We are talking about a specific type (e.g. third-party, generalized,
do-everything-for-everybody libraries.) They are a terrible idea for
the reasons listed. That doesn't mean you shouldn't organize your own
code for the types of projects that you work on.

Both approaches are taken in their own right.  Some people like to develop
libraries, e.g. to provide efficient algorithms for daily tasks to other
developers, and nothing else.  That a large number of libraries out there

If they are specific enough tasks and the code is well written and
documented then great. But that's not what we are talking about. The
whole thread has degenerated into an attempt to justify poorly written
(and generalized) junk like jQuery and qx00D00 (sp?)

is badly written, or simply junk, e.g. because the approach taken has been
too general (I'm thinking of jQuery wanting to handle a method check on DOM

There you go.

nodes) or the author is a half-wit programmer is a /different/ story.

But it is a related story (at least in this thread.) If all of the gp
libraries are junk (which they certainly are), then that is another
reason to ignore them.

 

[Thomas 'PointedEars' Lahn]

Presumably you mean a library for use by others.

Not only, no.

Exactly. That's why writing a *general-purpose* browser scripting
library is silly.

I don't think you got my meaning right. No, it is _not_ silly to write more
general code. But maybe I misunderstand how you define "general-purpose".

[that] the author is a half-wit programmer is a /different/ story.

But it is a related story (at least in this thread.) If all of the gp
libraries are junk (which they certainly are), then that is another
reason to ignore them.

Yes, *iff*.


PointedEars

 

[David Mark]

Not only, no.

Well, third-party libraries and blind faith are the subjects at hand.

I don't think you got my meaning right.  No, it is _not_ silly to writemore
general code.  But maybe I misunderstand how you define "general-purpose".

It is silly to write general-purpose browser scripting libraries as
there are too many variables involved to be reasonably efficient (and
often these variables are filled in by browser sniffing, but that is
another story.) It is and has always been folly to attempt such a
thing.

[that] the author is a half-wit programmer is a /different/ story.

But it is a related story (at least in this thread.)  If all of the gp
libraries are junk (which they certainly are), then that is another
reason to ignore them.

Yes, *iff*.

No. Even if a general-purpose library is perfectly designed and
written, it will still fall short of most context-specific solutions
in terms of efficiency (and performance of course.) As Richard has
stated repeatedly, a repository of lightweight and interchangeable
functions is the best option. Having written solutions both ways, I
can tell you that he is correct.

 

[David Mark]

Not only, no.

Also, lets take a concrete example of a module you might write for
yourself. Lets say you are charged with writing a script to determine
the offset position of an element. With no context, I can tell you
from experience that the function(s) involved will be relatively large
and complex. But if you knew that the documents in the project have a
relatively positioned body, you can crop out a large chunk of the
code. If you know something about the types of elements involved
(e.g. perhaps none of their containers have borders), you can lose
more of the bloat and complexity. Smaller and simpler is good thing
in browser scripting.

Clearly if you write scripts for every page, they are optimal for
none. There are trade-offs of course. It would be wonderful if you
never had to change scripts due to markup and/or changes but that is
not always possible (at least not practical.) However, if you have
thought through your design carefully, taking into account future
needs, it isn't likely to be a problem. I use more or less the same
basic HTML template for everything, which can be presented and
scripted in so many ways that it works just as well for basic
documents as Web applications. YMMV.

 

[Matt Kruse]

Far South of these ridiculous general-purpose libraries for virtually
any Web site or application.

That's not helpful to anyone. Care to explain how you would arrive at
a good limit to the amount of code that should be delivered to the
client?
You're right up there with the "I can't define obscenity, but I know
it when I see it" argument.

I want the last 20 seconds of my life back.  Why would you bother to
write such a thing?

Because it's a real-world problem that many people face, and you have
no solution for it. You just choose to ignore situations that don't
fit well within your pre-defined box of solutions.

The trouble is, many people are not working within your model, yet you
still think you have something useful to say to them. You do not.

And this.

Have you never done such a thing? You should try it, you may benefit
from a different perspective.

You clearly didn't understand what I said.  Perhaps one day you will.

Only if you begin to write clearly and make actual statements.

Again, you don't get it.
Ditto.

That's the whole point.  Optimally, you design script for a specific
context (e.g. a certain set of documents.)  If the context of your
site is unknown to you, then you have much bigger problems.

Not really bigger problems. Just different problems. And ones you
don't know how to address (or choose to ignore).
Of course you would criticize such a situation when you don't have a
solution that is helpful.
You have a hammer, therefore only nails should exist. You wouldn't
know what to do if you saw a screw.
It's easy to think your solution is best when you ignore situations
where your solution doesn't work.

Are you kidding?  

Not at all. But you can ignore the real-world situation again if you
wish.

That is why *everyone* should not be posing as
programmers, especially not in browser scripting. (!)  That's another
point you refuse to see after all these months of "debate" on this
subject.

Nicely dodged again. Just because you don't think a situation is ideal
and should therefore not exist, doesn't make it so.

I'm reminded of a story:

Climber #1: "Help! I'm hanging off the side of this cliff! I'm going
to die! Help me!"

Climber #2: "You shouldn't fall off cliffs to begin with."

Climber #1: "Yes, but I already did, and I'm here. What should I do?"

Climber #2: "Well, you're an idiot for falling off the cliff. The only
sensible solution is to not fall off cliffs."

Climber #1: "That doesn't help me!

Climber #2: "You got yourself into this. Obviously I'm right. You
shouldn't fall off cliffs."

Climber #3: "Here, use this rope!"

Climber #2: "#3, you are an idiot. That rope won't work if there are
sharp rocks, or if the wind is too high, or if climber #1 is not
strong. Just because it may work in some situations doesn't mean it
will work in all. It's foolish to suggest such a solution. He would be
better served if he just didn't fall off cliffs to begin with."

Climber #1: "Ah, thanks #3, that did the trick this time. Maybe I
should reconsider my climbing strategy, but I'll use this rope for
now. #2, you're an idiot."

Wow, great story!

Matt Kruse

 

[Matt Kruse]

It is silly to write general-purpose browser scripting libraries as
there are too many variables involved to be reasonably efficient (and
often these variables are filled in by browser sniffing, but that is
another story.)  It is and has always been folly to attempt such a
thing.

Why? Because you say so? What are your arguments against it?
Just because existing libraries don't live up to your standards is
_not_ an argument against the concept. Just because some libraries use
browser sniffing is _not_ a reason to dismiss them all.
In fact, it seems almost like you are arguing in _favor_ of
generalized libraries, just in a different form than what exists
today. Great! Then we agree!

No.  Even if a general-purpose library is perfectly designed and
written, it will still fall short of most context-specific solutions
in terms of efficiency (and performance of course.)

There are different ways to measure efficiency.
To you, performance and code bloat may be the best measures of
efficiency.
To someone else, the least development effort required to provide an
acceptable solution may be the best measure of efficiency.

Computers are fast. Just because there is extra unneeded code or
because a routine is not as optimized as it could be for a given
context doesn't mean that it isn't acceptable. There is always a trade-
off.

I may choose to save 10 hours of development time (a lot of $$$) by
using a library, yet sacrifice 500ms of performance in some operations
and deliver an extra 40k of unneeded code. Who are you to say that is
absolutely the wrong decision? Are you really so narrow-minded? If I
can't afford the 10 hours of development, and the performance hit is
not bothersome to me, isn't it really the best solution to use an
"inefficient" general-purpose library?

And just because my general-purpose library of choice won't get the
right element position if I start using a positioned body, is that
really an argument against it if I _don't have_ such a case? Who cares
if the library can't do X right if I have no intention of doing X? If
it does Y right, and I only want to do Y, then why is it bad?

I would love to hear about a time when you had to write a widget or
component that would be plugged into a bigger system that you had no
control over. Or a time when you had to write script for a site that
may change layouts frequently or even with every request, depending on
user's preferences. Or a time when you designed functionality before
the layout and structure of a site was decided for certain, and you
didn't have the ability to go back and change it later.

If you haven't found yourself in such situations, then you lack a
perspective that is required to intelligently talk about generalized
solutions and libraries, IMO.

Matt Kruse

 

[David Mark]

That's not helpful to anyone. Care to explain how you would arrive at
a good limit to the amount of code that should be delivered to the
client?

Depends on the context doesn't it?

You're right up there with the "I can't define obscenity, but I know
it when I see it" argument.

Irrelevant babbling.

Because it's a real-world problem that many people face, and you have
no solution for it. You just choose to ignore situations that don't
fit well within your pre-defined box of solutions.

No. Why would you write such a paragraph? Do you not understand the
term "context?" Hint: all you have done is name a context where
scripts would be relatively more generalized. Doesn't really add
anything does it?

The trouble is, many people are not working within your model, yet you
still think you have something useful to say to them. You do not.

Oh brother. This from you?

Have you never done such a thing? You should try it, you may

Groan. You know I have.

benefit from a different perspective.

You know much better than that.

[snip]

I'm reminded of a story:

I'm reminded of what an idiot you are.

 

[Brian Adkins]

No. Even if a general-purpose library is perfectly designed and
written, it will still fall short of most context-specific solutions
in terms of efficiency (and performance of course.) As Richard has
stated repeatedly, a repository of lightweight and interchangeable
functions is the best option. Having written solutions both ways, I
can tell you that he is correct.

It's possible that when some folks are requesting information on
"JavaScript libraries", you hear "general purpose framework", when in
fact they simply mean JavaScript code that may be reused such as
"lightweight and interchangeable functions". If so, communication may
be difficult.

 

[David Mark]

It's possible that when some folks are requesting information on
"JavaScript libraries", you hear "general purpose framework", when in

Not likely as a context is rarely specified (as in the case of this
thread.)