comp.lang.javascript Cookbook Proposal

[Peter Michaux]

There has been plenty of "friendly chat" about JavaScript libraries
here lately. The readily available libraries are not satisfactory in
many peoples opinion though. It is also clear code reuse is desirable
with some form of a library or code repository. It is clear to me
that, overall, the regulars at comp.lang.javascript have more
experience and technical knowledge about fundamental browser scripting
issues than other online groups. Can we harness that knowledge?

I don't think the comp.lang.javascript contributors will agree on any
large scale structure for a JavaScript library. Perhaps we can compile
a cookbook of examples that is along the lines of some of the FAQ and
FAQ notes but inclusive for less frequent topics. Perhaps this would
be a way to revitalize the FAQ and FAQ notes. This would allow
multiple implementations of a particular solution to be included in
the cookbook with recommendations for when/how each particular
solution should be used. There are some low level tasks that could
easily fall into this cookbook. Examples would include element
position reporting and form serialization, etc. This may also be more
fun and productive to compile than to have the "friendly chats" about
other libraries.

I think the added documentation notes about when a solution is
applicable may allow the interesting social dynamics of the group to
have success since there will be no single right answer. Also by
stating in which browsers a particular solution works will make the
examples somewhat durable over time as a resource. This would also be
more that the group could point to and say "this is a good JavaScript
resource." Rather than always having so little to recommend.

I think there would need to be a standardized format for the cookbook.
Which browsers the solution supports. What happens in other browsers.
How to detect when the solution is supported in a particular browser.
On which other solutions in the cookbook does the solution depend. It
would be nice if the format is parsable so that if someone wanted to
build a library with a particular API it could be done automatically
with a build system. That build system would be up to individuals to
build and out of scope of the cookbook.

I'll venture that at least some other people find this idea intriguing
and would participate. I think a group project would be good for
c.l.js and perhaps this would be a good one that would not take
extraordinary brainpower or time commitment. I think a good cookbook
of low level functions could be assembled quite quickly by the group.

Here is a stab at what information might be included for our favorite
example of trimming whitespace from the FAQ. XML might be nicer/more
compact for this task but HTML allows easy posting to the web. Please
note I didn't really check which browsers support which solution
below. This is just an example to get the ball rolling on how to
format a solution.


<div class="problem" id="problem_1">

<p class="statement">
remove whitespace from the beginning and end of a string
</p>

<div class="solution" id="solution_1_1">

<ul class="browsers">
<li>IE5+</li>
<li>FF1+</li>
<li>NN6+</li>
<li>S1+</li>
<li>O7+</li>
<li>K2+</li>
<li>IW1+</li>
</ul>

<div class="notes">
<p>
In browsers that do not support regular expression literal
syntax,
this code will cause a syntax error. The entire script element
containing this
trim function will not be evaluated and so the trim function
will not
be available. If your set of target browsers is outside the set
of browsers
supported this recipe you should test for the existence of the
trim
function before calling it. For example,
</p>

<code class="use">
if (trim) {
str = trim(str);
}
</code>
</div>

<code>
function trim(str) {
return str.replace(/^\s+|\s+$/g, '');
}
</code>
</div>

<div class="solution" id="solution_1_2">

<!-- supported browsers inherited from dependencies -->

<div class="notes">
<p>See notes of dependencies.</p>
</div>

<ul class="dependencies">
<li><a href="#solution_2_2">solution_2_2</a></li> <!-- lTrim -->
<li><a href="#solution_3_2">solution_3_2</a></li> <!-- rTrim -->
</ul>

<code>
function trim(str) {
return lTrim(rTrim(str));
}
</code>
</div>

</div>


This is starting to have the feel of a database. Perhaps a different
storage format would be more appropriate. An HTML form could be
created to make generating one of these solution blocks easier.

What do you think?

Peter

 

[RobG]

There has been plenty of "friendly chat" about JavaScript libraries
here lately. The readily available libraries are not satisfactory in
many peoples opinion though. It is also clear code reuse is desirable
with some form of a library or code repository. It is clear to me
that, overall, the regulars at comp.lang.javascript have more
experience and technical knowledge about fundamental browser scripting
issues than other online groups. Can we harness that knowledge?

I agree whole heartedly and suggest that it is a wikki so that those
who are interested can contribute without needing a single person to
maintain it. Perhaps password access should be required for those who
wish to maintain it - something similar to the Mozilla DOM pages
should do the trick:

<URL: http://developer.mozilla.org/en/docs/Gecko_DOM_Reference >

A search utility would be good, especially if each article also has
some metadata for keywords and associated subjects.

Care to suggest somewhere to host such a thing? Sites with a minimal
cost may be OK if someone is feeling magnanimous.

 

[Peter Michaux]

I agree whole heartedly and suggest that it is a wikki so that those
who are interested can contribute without needing a single person to
maintain it. Perhaps password access should be required for those who
wish to maintain it - something similar to the Mozilla DOM pages
should do the trick:

<URL:http://developer.mozilla.org/en/docs/Gecko_DOM_Reference>

A search utility would be good, especially if each article also has
some metadata for keywords and associated subjects.

Care to suggest somewhere to host such a thing? Sites with a minimal
cost may be OK if someone is feeling magnanimous.

I think a wiki would be great. I think a login is a good idea as spam
is a concern and a few maintainers perhaps democratically chosen if
more than a few people want access. If there is no concern about
reducing the central focus of the jibbering site and it's importance,
I can host a wiki on my site. Somehow I would like to ensure this is
considered a comp.lang.javascript project.

Peter

 

[Jeremy]

I agree whole heartedly and suggest that it is a wikki so that those
who are interested can contribute without needing a single person to
maintain it. Perhaps password access should be required for those who
wish to maintain it - something similar to the Mozilla DOM pages
should do the trick:

<URL: http://developer.mozilla.org/en/docs/Gecko_DOM_Reference >

A search utility would be good, especially if each article also has
some metadata for keywords and associated subjects.

Care to suggest somewhere to host such a thing? Sites with a minimal
cost may be OK if someone is feeling magnanimous.

Here you go:

http://www.cljwiki.org/


Go nuts.

Jeremy

 

[Peter Michaux]

Here you go:

http://www.cljwiki.org/

Go nuts.

Great enthusiasm, Jeremy. I think we should bash the idea around a bit
first. For example, a wiki would not allow easy build system from code
into a library format. I'd like to read what some other people write
first.

Would moving the jibbering site to wiki format be beneficial for
maintenance, Randy? Perhaps now it isn't taking much maintenance but
somehow I'd like to see the groups organized knowledge like the FAQ
notes expand.

Peter

 

[Peter Michaux]

I agree whole heartedly and suggest that it is a wikki so that those
who are interested can contribute without needing a single person to
maintain it. Perhaps password access should be required for those who
wish to maintain it - something similar to the Mozilla DOM pages
should do the trick:

<URL:http://developer.mozilla.org/en/docs/Gecko_DOM_Reference>

A search utility would be good, especially if each article also has
some metadata for keywords and associated subjects.

Care to suggest somewhere to host such a thing? Sites with a minimal
cost may be OK if someone is feeling magnanimous.

As a slight alternate to the wiki format, we could have a version
control system (eg. subversion) that has text files and write access
to a few people. The text files could be built into a website on a
regular basis or built into a JavaScript library depending on the
build tool. This might be a more flexible format for reusing the code.

Peter

 

[Peter Michaux]

Peter Michaux said the following on 11/1/2007 10:39 PM:



The issue, whether a Wiki or not, is in who has access to modify it and
how do you control that access? Meaning, what criteria is set to say who
can or can not edit a Wiki or any other files on the server?

I don't think that we need a wiki (or other) where anyone can edit.
There is already wikipedia for that so another one is not needed.

The idea is to have a few gatekeepers that are reasonable people and
can recognize their own personal bias versus the general feeling of
the group. You have shown yourself to be that kind of person so at the
very least we know that it is possible to find the right type of
person (whether you would like to be involved or not.)

Right now, Jim and you are the only ones with keys. You can hand them
out to a few more people that you think are reasonable and interested.
In practice, I really don't think it is so complex. All small open
source projects seem to work this way. (By "handing out keys" that
doesn't necessarily mean server ssh/root access. Just write access to
some repository or login to the wiki.)

If only a few people have write access, it seems to me that a
repository like subversion with text files would be far easier to
manage for those with write access than a wiki would be (or the
current system is for you.) Other people could submit patches that
could be applied quickly. This would save the "can you change this to
that for me". Using patches would force contributors to submit their
contribution in a non-suggestive, hand-waving way but in a concrete it-
should-say-exactly-this way.

Think about the prospect of VK trying to explain AJAX and then answer
the above question

I really doubt anyone would ever hand over keys to VK...keys for
anything.

Peter

 

[Peter Michaux]

Peter Michaux said the following on 11/1/2007 10:04 PM:

It would make single person maintenance non existent as it would allow
instant update anytime someone saw a need to update it. The drawback is
that it would allow instant destruction anytime someone saw fit to do
so.

Thankfully it's possible to roll back both a wiki and a version
control repository. I would hope it wouldn't come to that as the
people with write access would be reasonable.

Jim has said in the past that he was willing, able and agreeable to
installing the wiki software on the jibbering server. The thread is from
October of 2006 and was started by you

Jeez...and I'm still here a year later?!

<URL:http://groups.google.com/group/comp.lang.javascript/browse_thread/thr...>
<URL:http://groups.google.com/group/comp.lang.javascript/browse_thread/thr...>

Is a starting point and then the threads have links to other threads
where a Wiki is discussed.

As for making the Notes section a Wiki, it wouldn't have but about a 10
minute impact on the FAQ itself as the only thing to do to the FAQ would
be to change the Notes links. The Notes and FAQ itself could be taken
and used as the "starter" for a Wiki. Each section could be an entry of
its own. It would make the FAQ itself useless though as all it would be
is a table of contents (of sorts) to the Wiki itself.


Can you see Matt and Richard editing a Wiki entry on libraries?

I think this would actually be good if the format allowed it. Each
could present a body of text stating how they feel about library
design with their name attached. No back and forth. These would be
like the editorial section of the newspaper.

This is a bit of a problem however and it is why I thought low-level
functions where multiple solutions can be posted for a particular task
with notes explaining when the solution is appropriate. I think this
is something the group could agree on and with a few good editors with
write access it could work. If it works for low level tasks then
perhaps it could be bumped up to larger level tasks like library
design where Matt and Richard could present their positions as
solutions appropriate to particular situations.

Peter

 

[Brian Adkins]

It is also clear code reuse is desirable
with some form of a library or code repository.
Yes.

It is clear to me
that, overall, the regulars at comp.lang.javascript have more
experience and technical knowledge about fundamental browser scripting
issues than other online groups. Can we harness that knowledge?

Yes, I think "consolidating and capturing" that knowledge would be
beneficial

I don't think the comp.lang.javascript contributors will agree on any
large scale structure for a JavaScript library.

If you're referring to specific APIs, you might be right, but I think
there may be some agreement on good ways to modularize code to
minimize conflicts, increase flexibility, etc. In other words,
providing some guidance on good ways to combine the specific cookbook
solutions into a larger collection would be nice.

Perhaps we can compile
a cookbook of examples that is along the lines of some of the FAQ and
FAQ notes but inclusive for less frequent topics.

I think a "cookbook" approach makes a lot of sense. Providing smaller
building blocks of portable code that individuals can combine into
larger libraries of code if they desire would be great.

This may also be more
fun and productive to compile than to have the "friendly chats" about
other libraries.

Absolutely I expect a much higher signal to noise ratio with this
approach. There will always be potential for disagreement, but I think
the closer a discussion is to solving a specific problem (with code
examples), the easier it will be for proponents to display the
benefits of a specific approach.

I think the added documentation notes about when a solution is
applicable may allow the interesting social dynamics of the group to
have success since there will be no single right answer.

Although for many specific problems, I would hope we can iron out
differences in newsgroup threads to the point of only contributing one
primary solution. To use the string trimming as a simplistic example,
I wouldn't expect many good variations.

If a good faith attempt to arrive at a "best" solution via newsgroup
discussions fails, then providing alternate solutions would be fine,
but if each cookbook entry has many solutions provided, it may be
confusing.

This would also be
more that the group could point to and say "this is a good JavaScript
resource." Rather than always having so little to recommend.

That would be great.

I think there would need to be a standardized format for the cookbook.

Yes. There are many language cookbooks in existence. Maybe looking at
several formats will provide format/style ideas.

Which browsers the solution supports. What happens in other browsers.
How to detect when the solution is supported in a particular browser.
Yes!

I'll venture that at least some other people find this idea intriguing
and would participate.
Yes

What do you think?

I think it's a great idea. Thanks for getting the ball rolling.

 

[RobG]

Thankfully it's possible to roll back both a wiki and a version
control repository. I would hope it wouldn't come to that as the
people with write access would be reasonable.

If the Gecko DOM wikki is anything to go by, I don't think it's an
issue. Pretty much anyone with an interest should be able to
contribute, all that is required is registration with a valid e-mail
address and a password.

If someone posts crap, it is rolled back. If they continue, disable
their account - they'll soon tire of the game.

[...]

I think this would actually be good if the format allowed it.

Yes, it would. Even if someone posts poor quality code, others can
edit it to make it sound rather than just posting fixes here. And
where there are differing, well presented and defended opinions...

Each
could present a body of text stating how they feel about library
design with their name attached. No back and forth. These would be
like the editorial section of the newspaper.
Yep.


This is a bit of a problem however and it is why I thought low-level
functions where multiple solutions can be posted for a particular task
with notes explaining when the solution is appropriate.

And all code should be posted with the intention that it is read by a
novice programmer - e.g. the stuff that JRS posts might be technically
sound but it is concise to the point of obfuscation.

I think this
is something the group could agree on and with a few good editors with
write access it could work. If it works for low level tasks then
perhaps it could be bumped up to larger level tasks like library
design where Matt and Richard could present their positions as
solutions appropriate to particular situations.

I think access should be as wide as possible[1] - if that turns out to
be a bad choice, access can always be restricted later. The benefit
of wide access is that it will encourage contributions and support.
Restricting access in order to protect against malicious or inept
entries will discourage participation and likely be more hindrance
than help.


1. Registration should be via an automated system - submit an e-mail
address, verify it by responding to an e-mail and you're in.
Moderators and site administrators of course must be hand picked from
volunteers.

 

[Brian Adkins]

If only a few people have write access, it seems to me that a
repository like subversion with text files would be far easier to
manage for those with write access than a wiki would be (or the
current system is for you.) Other people could submit patches that
could be applied quickly. This would save the "can you change this to
that for me". Using patches would force contributors to submit their
contribution in a non-suggestive, hand-waving way but in a concrete it-
should-say-exactly-this way.

If you're not careful, you might end up with the JavaScript Standard
Library

Seriously though, I like the idea of a subversion repository as long
as a web site can be generated from it periodically to allow
convenient browsing. Commit/edit privileges could be expanded to
individuals who are providing significant contributions to the body of
work.

 

[Brian Adkins]

I think access should be as wide as possible[1] - if that turns out to
be a bad choice, access can always be restricted later. The benefit
of wide access is that it will encourage contributions and support.
Restricting access in order to protect against malicious or inept
entries will discourage participation and likely be more hindrance
than help.

I'm a little skeptical of making access as wide as possible. Not so
much because of fearing malicious entries, or even inept ones, but
because it seems like it could become very disorganized quickly.

Would it be better to use the newsgroup as a filter prior to
submitting to the repository? So someone could propose a new entry
into the cookbook by starting a thread and presenting the idea. Others
could comment until, hopefully, some sort of consensus is arrived at,
then it's added to the repository.

It might be easier to start with more restricted access and open it
over time than vice versa.

 

[RobG]

RobG said the following on 11/2/2007 2:36 AM:



My point with choosing Richard, Matt and the subject was that you will
never get Richard to agree with Matt (and probably vice versa) to the
point that you would end up with two entries. Or, you would end up with
100 pages of debate over every sentence that was written.

Taking that example further, while it would be good for them to
publish their own arguments, I don't think either Richard or Matt
necessarily need to publish anything personally. Someone else could
post a brief precise of what they said with a link to the thread and
if they want they can review it - or not.

But anyhow, enough gas bagging. The FAQ can stand for the moment.
Peter's idea of a repository is good but I think would discourage
contributions, much like a restricted wikki. So why not just setup a
wikki and see how it goes? We can always kill it off and go back to
the FAQ.

 

[Peter Michaux]

Yes, I think "consolidating and capturing" that knowledge would be
beneficial


If you're referring to specific APIs, you might be right, but I think
there may be some agreement on good ways to modularize code to
minimize conflicts, increase flexibility, etc. In other words,
providing some guidance on good ways to combine the specific cookbook
solutions into a larger collection would be nice.

I agree and this could be in a README file created sometime down the
line _after_ people have tried various techniques to combine the code
into libraries. The fundamental goal would be the collection of
building blocks itself. If the building block code and related
documentation/comments are sufficiently data-like then many
manipulations could be made.

I think a "cookbook" approach makes a lot of sense. Providing smaller
building blocks of portable code that individuals can combine into
larger libraries of code if they desire would be great.


Absolutely I expect a much higher signal to noise ratio with this
approach. There will always be potential for disagreement, but I think
the closer a discussion is to solving a specific problem (with code
examples), the easier it will be for proponents to display the
benefits of a specific approach.


Although for many specific problems, I would hope we can iron out
differences in newsgroup threads to the point of only contributing one
primary solution. To use the string trimming as a simplistic example,
I wouldn't expect many good variations.

With string trimming probably not. With element position reporting,
definitely yes.

A large reason for maintaining multiple solutions is there would not
be a "primary solution". Each solution would apply to different
situations and so would all be equally important. The criteria for
labeling a solution "primary" would not be good criteria for any
situation except the one satisfied by that criteria.

I think Richard Cornford's post explaining why maintaining more
implementations is better is very persuasive. I have not been lead
astray taking any of Richard's advice before.

<URL: http://groups.google.com/group/comp.lang.javascript/msg/9812a8de13c71866>

A major gripe with the big name hyped libraries is that they try to
create single solutions that apply to all situations (or some big
subset they tell you is good enough). If the group is to have any
success I think we need to do the opposite. For example, if the
library requires try-catch then Randy Webb would likely loose interest
quickly as his cell phone doesn't support try-catch.

All that said, if solution "A" is consumed by solution "B" and
solution "B" applies to a wider range of situations with no additional
disadvantages (including code size or any other reasonable
consideration) then there would be no need for solution "A". That is
if folks agree solution "A" can be removed. If both stay people can
judge for themselves.

If a good faith attempt to arrive at a "best" solution via newsgroup
discussions fails, then providing alternate solutions would be fine,
but if each cookbook entry has many solutions provided, it may be
confusing.

If a cookbook reader needs to evaluate several solutions and decide
which is best for them, I think that is a positive aspect. If someone
wants to package a library for some fixed set of requirements then the
readers who don't want to think can just use that packaged library.

That would be great.


Yes. There are many language cookbooks in existence. Maybe looking at
several formats will provide format/style ideas.


I think it's a great idea. Thanks for getting the ball rolling.

Randy Webb has done a great job rolling the ball by maintaining the
group's jibbering site. I think a slightly more modern format would
encourage the group's knowledge to aggregate more and in a more usable
way.

Peter

 

[Peter Michaux]

Peter Michaux said the following on 11/2/2007 12:39 AM:



Sounds like what you are describing is a "comp.lang.javascript Dynamic
Drive" type repository.

If you mean http://www.dynamicdrive.com/ then perhaps but definitely
minus the "Cursor Trailer Text" and "Flying Bats Script" ;-) Even with
the existence of that site, I think the group would need to feel
ownership of the content to make it a success. Also I think we would
have no problem focusing on more fundamental and common browser
scripting tasks.

The Javascript entry in Wikipedia is a joke though. Do I dare point out
the "associative arrays" error or the errors in the sole code block in
the entry? Or, the differences in how Javascript is spelled through out
that page?


What I personally think would be more valuable than a repository is a
c.l.j tutorial. Rather than trying to post snippets of code that perform
specific functions, write pages that teach people how to write that
code. Show the different ways to write the same code, the differences in
the approaches along with the benefits and drawbacks of the different
approaches. Example? Take the FAQ entry on trimming white space(4.16).
There are two different approaches to coding in that single entry. One
approach is to augment the built in String Object, the other is a simple
function(You should recognize that thought). The advantage of the
prototype approach is that you avoid potential naming conflicts within
the document. The advantage to a simple function approach is that you
avoid augmenting built in Objects. Both have advantages, both have
disadvantages.

You get the long drawn out threads in this group when you get two people
trying to argue over why one is "better" than the other when neither is.

This is why I propose accepting multiple solutions that satisfy
different criteria.

The basic idea is the "Give a man a fish, feed him for a day. Teach a
man to catch a fish, feed him for life" (there are variations to that
but the principle is the same).

What people are lacking isn't a repository of code as much as a good,
solid, reliable place to learn how to code.

I think that tutorials are great and the faq notes are valuable for
that and don't think they should disappear. However at some point the
English in the tutorials has to be written concretely as JavaScript to
remove all doubt remaining in the English. I've always felt learning
from concrete examples is the best way.

There is no way the repository would ever cover everything and that
probably shouldn't be the goal. After reading and using the repository
a developer would get a feel for the style.

I also don't think we should necessarily try to make a resource that
holds a beginners hand at every step of the way. If we create
something that has value to the regular contributors of the group I
think we have a larger chance at success. I think that perhaps the
lack of value to the regulars themselves is why contributions to the
jibbering site are now more or less extinct.

Peter

 

[Peter Michaux]

RobG said the following on 11/2/2007 2:36 AM:


Taking that example further, while it would be good for them to
publish their own arguments, I don't think either Richard or Matt
necessarily need to publish anything personally. Someone else could
post a brief precise of what they said with a link to the thread and
if they want they can review it - or not.

I think this is a good idea. I also think that if reasonable people
are given write access they will be responsible. Whatever format
emerges it cannot be one that allows back and forth discussion. That
is the purpose of the group.

But anyhow, enough gas bagging.

Only a few people have had the opportunity to gas bag. ;-)

The FAQ can stand for the moment.
Peter's idea of a repository is good but I think would discourage
contributions, much like a restricted wikki.

I think a wide access wikki would degrade the quality and require
gardening. There is already wikipedia for that and many other
JavaScript sites on the web that allow what amounts to anonymous
contribution and are relatively useless. These sites certainly are not
authoritative. I would rather see the content aggregate slower and be
much higher quality.

So why not just setup a
wikki and see how it goes? We can always kill it off and go back to
the FAQ.

I would really like to see the content as data that can be manipulated
into a library. I think using a wiki would make that difficult.

Peter

 

[Peter Michaux]

Brian Adkins said the following on 11/2/2007 2:45 AM:

I think access should be as wide as possible[1] - if that turns out to
be a bad choice, access can always be restricted later. The benefit
of wide access is that it will encourage contributions and support.
Restricting access in order to protect against malicious or inept
entries will discourage participation and likely be more hindrance
than help.

I'm a little skeptical of making access as wide as possible. Not so
much because of fearing malicious entries, or even inept ones, but
because it seems like it could become very disorganized quickly.

That is a possibility.

Would it be better to use the newsgroup as a filter prior to
submitting to the repository? So someone could propose a new entry
into the cookbook by starting a thread and presenting the idea. Others
could comment until, hopefully, some sort of consensus is arrived at,
then it's added to the repository.

That isn't a good idea. That is the way the FAQ gets updated now and it
is a colossal disaster sometimes.

I think Brian's idea is a good one with a change. There will be less
pressure for consensus if multiple solutions for different criteria
are allowed.

Many programming languages have a "weekly quiz". It could be that new
topics for the repository are added in that way. At some time interval
a new topic is introduced (eg. form serialization, position reporting,
opacity setting, etc) and people post suggested solutions to the
group. We bash them around ad nauseam and learn more about the
problem. Then a ticket is created, patches are submitted and the
editors decide what to commit based on the group's discussion. If the
solution was not unanimously approved the editors could add a note
saying so with a link to the thread.

By the time you open access, you could alienate 90% of the people
interested in contributing to it.

Right now write access to the jibbering site is only used by you yet
the daily FAQ posts receive many responses.

Peter

 

[Matt Kruse]

Perhaps we can compile
a cookbook of examples that is along the lines of some of the FAQ and
FAQ notes but inclusive for less frequent topics.

I like the concept, and I've tried to start something similar in the
past with no success or participation. Some comments:

1) Just Do It. Too much planning and debating about how it should run
and what format the content should be in, etc will lead to analysis
paralysis. It's better to just get something going and refine it
later. Only solicit input from a few key people, then decide and go.

2) Good luck getting perhaps the most informed people like Richard to
contribute. Using him as an example, he objects to most "generalized"
solutions to common problems, instead preferring to write code that
addresses a very specific problem on a specific page using very low-
level reusable code. This doesn't mesh well with the idea of a
"Cookbook" whose goal it is to provide some general solutions to real
problems. Otherwise you could have recipes for 100 different contexts,
which would end up being of no practical use to anyone.

3) I don't really think there are _that_ many problems that are
extremely difficult to solve. Your cookbook may end up having things
like trim functions, which any novice javascript programmer could
create on their own. The more difficult things like positioning,
dimensions, dealing with attribute quirks, handling events, ajax, etc
are more difficult to put into a "cookbook". And if you do end up with
generalized solutions for these things, what you've ended up doing is
building a general-purpose library. Which is exactly what many people
in this group object to.

In fact, isn't a library mostly a collection of "cookbook" recipes
sewn together with a consistent API? You could start with something
like Dean Edwards' Base2 which already does a great job of normalizing
standard DOM behavior between browsers. Half your work is done
already.

I'm not trying to be negative. I say go for it. I just think that this
is exactly the way all these despised general-purpose libraries
actually start out!

Matt Kruse

 

[Peter Michaux]

I like the concept, and I've tried to start something similar in the
past with no success or participation. Some comments:

1) Just Do It. Too much planning and debating about how it should run
and what format the content should be in, etc will lead to analysis
paralysis. It's better to just get something going and refine it
later. Only solicit input from a few key people, then decide and go.

2) Good luck getting perhaps the most informed people like Richard to
contribute. Using him as an example, he objects to most "generalized"
solutions to common problems, instead preferring to write code that
addresses a very specific problem on a specific page using very low-
level reusable code. This doesn't mesh well with the idea of a
"Cookbook" whose goal it is to provide some general solutions to real
problems. Otherwise you could have recipes for 100 different contexts,
which would end up being of no practical use to anyone.

What I am proposing is to find a way to execute Richard's strategy as
a group. I agree with him and others with a similar opinion that the
single generalized solutions are fatally flawed (ie. more generalized
is more bloat to the point of absurdity) and the multiple
implementations approach is better. In fact, most libraries state that
they are for the most common situations and if you have extraordinary
situations you need to program specifically for those. I actually
think the views of library designers and library detractors are more
similar than different. It is just that each group weights priorities
differently.

If a group repository had several implementations, it may be that only
one of the implementations is used 80% of the time for a particular
problem but that doesn't mean solutions to other situations are less
important.

3) I don't really think there are _that_ many problems that are
extremely difficult to solve. Your cookbook may end up having things
like trim functions, which any novice javascript programmer could
create on their own. The more difficult things like positioning,
dimensions, dealing with attribute quirks, handling events, ajax, etc
are more difficult to put into a "cookbook". And if you do end up with
generalized solutions for these things, what you've ended up doing is
building a general-purpose library. Which is exactly what many people
in this group object to.

We can't take the general-purpose approach. It just won't work with
the group. I think the multiple solutions approach could work both as
an code resource and a learning resource.

In fact, isn't a library mostly a collection of "cookbook" recipes
sewn together with a consistent API?

Yes but a library is designed for only one set of conditions.

You could start with something
like Dean Edwards' Base2 which already does a great job of normalizing
standard DOM behavior between browsers. Half your work is done
already.

I'm not trying to be negative. I say go for it. I just think that this
is exactly the way all these despised general-purpose libraries
actually start out!

Thanks for the thoughts. If the few key people are not interested then
there is no point. I'm testing the waters to see if some changes to
past ideas for a group code repository would make the project
acceptable.

Peter

 

[Matt Kruse]

If a group repository had several implementations, it may be that only
one of the implementations is used 80% of the time for a particular
problem but that doesn't mean solutions to other situations are less
important.

So for something like an object position-finding function, what kind
of different implementations can you imagine existing? There are so
many factors to consider: doctype, fixed/relative positioning,
borders, scrolling elements, etc. The most efficient solution will
always be one that is written specifically for the exact page it runs
on.

But you can't have a function for "finding the position of a div on a
page that consists of a 3-column layout using floats, a 50px height
header, and a scrolling body with a 10px padding and 2px border." That
would be of no use to anyone. How are you going to decide which
contexts to group together? And is the result actually going to be
useful to anyone? And when you have 5 different solutions hammered out
that handle most common possible contexts, why not group them together
so that a single function can be called to run in any of the contexts?
Why, then you have a general-purpose function!

Nevertheless, I'll definitely look at whatever is created. I'm sure,
if it exists, it will be a valuable resource.

Matt Kruse