Did Anyone Backup the "Code Worth Recommending Project"?

[Jeremy J Starcher]

Did anyone snag a copy of the Code Worth Recommending Project before it
vanished?

Old URL < http://cljs.michaux.ca >

I checked with The Wayback Machine < http://archive.org > and they didn't
have it.

 

[Thomas 'PointedEars' Lahn]

Did anyone snag a copy of the Code Worth Recommending Project before it
vanished?

Old URL < http://cljs.michaux.ca >

I checked with The Wayback Machine < http://archive.org > and they didn't
have it.

,-<http://web.archive.org/web/*/http://cljs.michaux.ca/>
|
| * Material typically becomes available here 6 months after collection

However, the Google cache doesn't have it, too:

<http://209.85.129.132/search?q=cache:http://cljs.michaux.ca/>

You must have had used a robots.txt of sorts to forbid caching.

Another Web cache is Coral CDN:

<http://michaux.ca.nyud.net:8090/>

(I took those from the CacheIt! Firefox extension.) I don't know what the
actual URI of the CWRP was, so you could try that if you still know it.

And sorry, no, I didn't mirror it.


PointedEars

 

[Jeremy J Starcher]

If I'm not mistaken, many ideas (if not everything) from CWR were
implemented in Peter's Fork library <http://forkjavascript.org/> and
David's "My Library" <http://www.cinsoft.net/mylib.html>

You can browse trunk of Fork via trac
<http://code.michaux.ca/trac/browser/trunk/Fork/public/javascripts/fork>

Ah, I know that David's "My Library" used a number of ideas from CWR but
it looks like he added a lot to it as well. I didn't realize that Fork
used the ideas to, but I should have.

Thanks.

 

[David Mark]

Ah, I know that David's "My Library" used a number of ideas from CWR but
it looks like he added a lot to it as well.  I didn't realize that Fork
used the ideas to, but I should have.

Fork predates CWR. Most of CWR ended up in My Library, but most of My
Library is not CWR (it became defunct soon after I started my
project.)

 

[David Mark]

Fork predates CWR.  Most of CWR ended up in My Library, but most of My
Library is not CWR (it became defunct soon after I started my project.)

It was your "My Library" [my grammar checker is going to love that] that
got me looking for CWR.  I was, uh, looking for code to recommend to
someone that was free of legal encumbrance.  

The only recommendation I would make regarding that project is to
learn from it. The first lesson is that a general-purpose script is a
bad idea. There are silly mistakes to be found (some documented in
its forum) and it has never been thoroughly tested (I haven't tried it
in any browser released after the beginning of 2008.)

The first thing to ask your associate is what they want to do (and in
what context.) My Library, Fork Javascript and the rest are likely
not ideal solutions. However, by reading those scripts (as opposed to
a fantasy like jQuery), your associate may learn enough to move
forward on their own.

 

[David Mark]

On Tue, 28 Apr 2009 10:12:23 -0700, David Mark wrote:
Ah, I know that David's "My Library" used a number of ideas from CWR
but it looks like he added a lot to it as well. I didn't realize that
Fork used the ideas to, but I should have.
Fork predates CWR. Most of CWR ended up in My Library, but most of My
Library is not CWR (it became defunct soon after I started my project.)
It was your "My Library" [my grammar checker is going to love that] that
got me looking for CWR. I was, uh, looking for code to recommend to
someone that was free of legal encumbrance.

The only recommendation I would make regarding that project is to
learn from it. The first lesson is that a general-purpose script is a
bad idea. There are silly mistakes to be found (some documented in

That probably depends on how one defines a general-purpose script.
Undoubtedly, a general purpose solution will always be less efficient
than a specific one. Nevertheless, I don't see how a collection of
low-level helpers (if such collection falls under the definition of
"general-purpose script") is a bad idea. Various getElement(s)?By*, XHR
and event handling wrappers, class manipulation, DOM traversal, etc. -
all come in useful when creating higher-level widgets.

Sure. I meant general-purpose and monolithic (like Prototype, jQuery,
etc.)

Of course, even these low-level helpers are generic to a certain degree.
Should `hasClass` separate tokens based on /\s/ or
/[\\u0020\\u0009\\u000A\\u000C\\u000D]/? Should `getElementsByTagName`
wrapper take care of older IE not working with wildcard ("*")? Should
`getTextContent` take care of Safari 2.x ignoring text of hidden
elements? Should position-related helpers work in quirks mode?

Yes, context is everything in browser scripting, which is why general-
purpose scripts are generally a bad idea.

Besides determining if a script must work in HTML/XHTML and
standards/quirks modes, it all seems to boil down to - a) which known

Standards mode and HTML are a good starting point.

browsers it should support (i.e. explicitly taking care of known bugs in
their implementations), and b) which edge cases it should take care of.

Yes, history must be taken into account (as well as the future.)

Which mistakes are you talking about? I remember there were some
concerns in CWR threads about which properties should be tested and
which browsers should be supported.

There's at least one silly bug in the Flash module (related to
attributes of all things.) I just read some reports about IE8's
handling of clip styles, which tells me that a couple of the effects
will need updates. Certainly there are others.

And remember, CWR was CWR in name only. It wasn't around long enough
to recommend anything (and most of My Library was never in CWR.) Also
realize that CWR and My Library date back to 2007 and strategies have
evolved since. The browsers haven't changed, but best practices for
cross-browser scripting certainly have.

Of course, the clip issue could have been anticipated. Looking at the
code today, it was obviously written with IE6/7 in mind. That was a
stupid thing to do then and I must fix a line or two to deal with it
now. I know where I went wrong and I know the logic that will put it
right (for this and future versions of IE.) The browser developers
are very easy to predict, especially the ones that work for MS.

In contrast, libraries like jQuery are all about taking wrong turns
and relying on unit tests to offer advice like dashboard GPS units.
That is why they must be upgraded every time a new browser version is
released (and why they cut the tethers to the old versions after a
year or two.)

 

[David Mark]

True, true...

However:  AFAIK, there isn't any nice list/book/example of what is
current best strategies and practices.

There is at least one book coming, but I think there are good examples
out there for virtually anything you can think of now. The first
mistake is looking for everything in one nice package.

Be sure to deregister any event handling before leaving the page to help

Absolutely not. Do not create circular references involving host
objects. Do not use libraries that insist on doing so when attaching
events. Be sure to avoid the unload event like the plague. Always
ask yourself, what wouldn't the libraries do?

avoid IE's memory-leaks.  Oh, unless you are on Firefox, in which case an
onpageunload causes Fx to invalidate its memory cache and slow down
backwards navigation.

Fast history navigation is hardly exclusive to Firefox. If memory
serves me correctly, MS came had it in IE2. Name a major browser that
doesn't do it, provided you do *not* create unload listeners.

Load scripts in the head.  Or, load them right before you close the
'body' tag.  Or, load them dynamically to avoid them hanging the browser.

Those are all context-sensitive decisions.

Code your pages to degrade nicely on -any- browser and take all known
browser bugs into account .. even IE4 and NS4.  Except IE5 for the Mac. 
Nobody is using that one anyways -- and requires buying a Mac to test.

You decide the cutoff for your site or app. You just have to know
when to cut it off. Are you really worried about IE4 and NS4? NS4
has no document.body. That is likely line one of the first tests for
a modern script. IE4 has no document.documentElement, which is also a
no-brainer to test in a modern script. So those two are typically
weeded out immediately. Think of IE5 Mac as ancient quasi-standard
browser with unknown bugs. There's lots of those out there. You
can't know all of their quirks and you can't code for all of their
quirks. All you can do is follow standards, use sound practices, keep
things simple as possible and test on as many agents as is feasible.

And what are you saying? You should buy a Mac anyway!

 

[David Mark]

David Mark wrote: [...]
The only recommendation I would make regarding that project is to
learn from it.  The first lesson is that a general-purpose script is a
bad idea.  There are silly mistakes to be found (some documented in
That probably depends on how one defines a general-purpose script.
Undoubtedly, a general purpose solution will always be less efficient
than a specific one. Nevertheless, I don't see how a collection of
low-level helpers (if such collection falls under the definition of
"general-purpose script") is a bad idea. Various getElement(s)?By*, XHR
and event handling wrappers, class manipulation, DOM traversal, etc. -
all come in useful when creating higher-level widgets.

Sure.  I meant general-purpose and monolithic (like Prototype, jQuery,
etc.)

It's good to see some of the JS libraries, like YUI, realize that
modular approach is the sanest way to go. Now if only they didn't sniff
in their DOM module
<http://github.com/yui/yui3/blob/0b9552b9cf1deb8b848b8b513d2a11fe43cb7...>

And their event module. YUI is junk too. Just bigger (and more
modular) junk.

[...]

Standards mode and HTML are a good starting point.
Absolutely.

[...]

Which mistakes are you talking about? I remember there were some
concerns in CWR threads about which properties should be tested and
which browsers should be supported.

There's at least one silly bug in the Flash module (related to
attributes of all things.)  I just read some reports about IE8's
handling of clip styles, which tells me that a couple of the effects
will need updates.  Certainly there are others.

I saw you posted a message in "My Library" group about "IE8 and clip"
but haven't had time to read it carefully yet.

That one isn't a big deal. A couple of special effects may be down in
IE8. Fix should be a couple of lines.

Glancing at the code quickly, I can see some mistakes in "Fork", but not
in "My Library" (except dependencies testing that I mentioned earlier
which appeared to be a non-issue).

That's another issue with large scripts. It is hard to spot little
mistakes. Trust me, there are some. I know I didn't patch the Flash
module, so it is still fouling up the "class" attribute of the
replacement OBJECT. That one is pretty silly, but I just don't have
time to mess with My Library right now.

It looks like back in '07 best practices already included solid
foundation of `isHost*` methods; nature of memory leaks in IE was
already researched well enough (to know that circular references should
be avoided); Which evolution are you talking about?

Lots of little things. Using My Library as an example, it is too
generalized, does too much to support ancient browsers, unnecessarily
attaches an unload listener to fix memory leaks that are never
created. Creates closures where none are needed, doesn't leverage QSA
(there's a five minute project), doesn't leverage built-in transitions
(except for IE), references getBoxObjectFor (thankfully not for
anything important), some modules create expandos (e.g. query), etc.

Unit tests is still an essential aspect of any serious
library/application. They are not meant as a guiding light for
trial-and-error development, of course; rather a way to maintain the
code safely and ensure system integrity.

Yes, they are very important. I leave that stuff to others, getting
involved only when things go wrong (thankfully that is rare.) That's
one of the reasons I find jQuery evangelists so amusing. They do seem
to spend a large percentage of their lives watching unit tests. They
must see progress meters in their sleep.

Software tends to be changed
with time, sometimes changes need to be done fast and there's no time to
analyze how and what they affect. Unit tests simply allow for a more
efficient development (Of course, making a system decoupled and modular
helps to reduce risk greatly )

When I make a little change, it is nice to know that it is a little
change. Modularity is key, but what is missing from scripts like My
Library is interchangeability. As one of my clients mentioned
recently, it would be nice to have another set of checkboxes to
indicate the desired level of browser support. CWR started out as
interchangeable functions and I just picked the level of support that
I felt was best in 2007.

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]

Trouble is, this collected wisdom of c.l.js has never been distilled
down. The FAQ is a start, but we really need a "Things you don't even
know enough to ask" kind of thing.

You will find some of those on my site, put there mainly as a result of
demonstrated ignorance here. Of course, you will know them all already;
but you will know them so well that you might not think to mention them.

There could be a FAQ Note on the subject.

The FAQ Notes would be more actually, as opposed to potentially, useful
if the FAQ contained an index to the FAQ notes - the major entries from
the TOC in the Notes.

 

[David Mark]

There is at least one book coming, but I think there are good examples
out there for virtually anything you can think of now.  The first
mistake is looking for everything in one nice package.

I look forward to the book.

[ Snipped comments on de-registering event handlers ]

You see, I know that and you know that .. but Jane Q. Public trying to
learn Javascript doesn't know that and there isn't a lot of c.l.js-
approved sites out there for them to learn from.  People are going to
learn from example and I was hoping that archived CWR would be part of
that example.

Those are all context-sensitive decisions.
ACK.

You decide the cutoff for your site or app.  You just have to know
when to cut it off.  Are you really worried about IE4 and NS4?

Me, no.  I don't worry about IE4 or NS4.  For most things I baseline test
to IE6  and make sure the fall back stuff works under IE 5.5.  I don't
even test under IE 5 all that often.

However, there are corporate environments where testing is still for IE 4
because it got written into the specs and never removed.

NS4
has no document.body.  That is likely line one of the first tests for
a modern script.  IE4 has no document.documentElement, which is also a
no-brainer to test in a modern script.  So those two are typically
weeded out immediately.

Full ACK.

Think of IE5 Mac as ancient quasi-standard
browser with unknown bugs.  There's lots of those out there.  You
can't know all of their quirks and you can't code for all of their
quirks.  All you can do is follow standards, use sound practices, keep
things simple as possible and test on as many agents as is feasible.

I've never looked at or tested against IE5Mac, but from everything I've
heard, I have to agree with you there too.

It's quite a piece of work. Doubtful that anyone uses it today as
most "Ajax sites" would be unusable. You will hear users of libraries
talking about "not worrying if their sites work with Mac IE" due to
the magical compatibility properties of their chosen monolith, but
they are definitely dreaming.

Trouble is, this collected wisdom of c.l.js has never been distilled
down.  The FAQ is a start, but we really need a "Things you don't even
know enough to ask" kind of thing.

Thats where my friend is, and what got me looking for the CWR archives.  
I am not looking at getting a full library for her, but I'd love to be
able to put together a good solid skeleton ... everything from the proper
4.01 doctype to a solid addEvent solution.  A good feature test example
that she can add to as she needs.

Add CSS files and you have a framework. The more coupling between the
three the better (just be sure to document tne relationships.)

And what makes you think that your friend needs an "addEvent
solution?" If they are just starting out, do they really need more
than one event per type per element? Tell them to start with the on*
properties show them how to get the event target for delegation.

And what are you saying?  You should buy a Mac anyway!

Oh, a Mac is on my list of things to buy but I have a half-dozen things
ahead of it on the priority scale.  Unless I'm willing to settle for an
oversized Mac laptop, I can't get one the proper Scottish way[1].

I don't follow exactly.

[1] Mugging the English.

Do the English carry over-sized Macbooks exclusively?

 

[Garrett Smith]

David Mark wrote: [...]
The only recommendation I would make regarding that project is to
learn from it. The first lesson is that a general-purpose script is a
bad idea. There are silly mistakes to be found (some documented in
That probably depends on how one defines a general-purpose script.
Undoubtedly, a general purpose solution will always be less efficient
than a specific one. Nevertheless, I don't see how a collection of
low-level helpers (if such collection falls under the definition of
"general-purpose script") is a bad idea. Various getElement(s)?By*, XHR
and event handling wrappers, class manipulation, DOM traversal, etc. -
all come in useful when creating higher-level widgets.

Sure. I meant general-purpose and monolithic (like Prototype, jQuery,
etc.)

It's good to see some of the JS libraries, like YUI, realize that
modular approach is the sanest way to go. Now if only they didn't sniff
in their DOM module
<http://github.com/yui/yui3/blob/0b9552b9cf1deb8b848b8b513d2a11fe43cb7485/src/dom/js/dom.js>

I can find plenty of small nits in the code and some comments that I
cannot believe to be true. The |create| method (where the odiferous
sniffing takes place) seems to have some mistakes in part of it.

I can't get the tests to run from that download. "YAHOO is not defined."

Running:-

/<yui3>/src/dom/tests/dom.html

- is see the error:-

YAHOO is not defined
(?)()(Object config=Object Env=Object version=test)dom.html (line 95)
onComplete()()yui.js (line 408)
use()()yui.js (line 472)
dom.html()()dom.html (line 94)
[Break on this error] tool = YAHOO.tool,
dom.html (line 95

I want to run the tests for the |create| method.


[...]

Unit tests is still an essential aspect of any serious
library/application. They are not meant as a guiding light for
trial-and-error development, of course; rather a way to maintain the
code safely and ensure system integrity. Software tends to be changed
with time, sometimes changes need to be done fast and there's no time to
analyze how and what they affect. Unit tests simply allow for a more
efficient development (Of course, making a system decoupled and modular
helps to reduce risk greatly )

[...]

Having a solid test suite takes a lot of risk out of refactoring, and in
any software project, refactoring is very important (requirement changes
dictate code changes, mistakes are found in existing code, etc).

The code design evolves as the requirements evolve. Methods might need
to get moved or broken into smaller routines up as they become more
complex. ADTs ("classes", in the general sense) get created, removed,
replaced, etc.

If the design is not changed as requirements change, it can get so bad
that it seems more attractive to start over with a new codebase.

The time saved is not just in easing a requirements change; it's the QA,
bugs, regression bugs, and bug scrub meetings. That takes everyone's
time and can tend to get more people spending their time blaming the
developer.

Having proof that something works can be helpful when no bugs are found
in that piece of suspect code; because it can lead to looking elsewhere
for cause of the problem.

(I've also found plenty of my own bugs in testing).
</soapbox>

I found the biggest downside to testing was setting it up and learning
how to do it.

Garrett

 

[Garrett Smith]

In comp.lang.javascript message <[email protected]


You will find some of those on my site, put there mainly as a result of
demonstrated ignorance here. Of course, you will know them all already;
but you will know them so well that you might not think to mention them.

There could be a FAQ Note on the subject.

The FAQ Notes would be more actually, as opposed to potentially, useful
if the FAQ contained an index to the FAQ notes - the major entries from
the TOC in the Notes.

I am not quite sure what you mean: "it would be useful if the FAQ
contained an index to the FAQ notes." Are you suggesting placing the
entire index page for the notes? But then "the major entries from the
TOC in the Notes" seems to suggest the reverse -- adding an index to the
FAQ within the notes document.

The FAQ contains links to the notes where relevant to the question at
hand. The FAQ also links to the notes very near the top of the document,
in "What questions are on-topic for comp.lang.javascript?" and "Why was
my post not answered?" questions

One thing that has come up a few times is the URI for the notes is long
and unmemorable. The path is something like:-

/faq/faq_notes/faq_notes.html

- but should instead be:-

/faq/notes/

(using default index page).

To do this, the links would need to be updated, in those documents. An
http redirect could be set up for the old faq_notes/ paths.

Richard Cornford has permissions for the "notes" documents.

Garrett

 

[Dr J R Stockton]

Dr J R Stockton wrote:

I am not quite sure what you mean: "it would be useful if the FAQ
contained an index to the FAQ notes." Are you suggesting placing the
entire index page for the notes?

No, that would be "the index" rather than "an index".

But then "the major entries from the TOC in the Notes" seems to
suggest the reverse -- adding an index to the FAQ within the notes
document.

No, that's grammatically a further detail.

Take the source of the UL in "Index of /faq/faq_notes" at <http://www.ji
bbering.com/faq/faq_notes/>, replace the visual aspect (shown next) of
each link with the H1 of the page that it links to (e.g. "Javascript
Closures"), and perform any necessary adjustments (omit "Parent
Directory" and "faq_notes.css", re-order, etc.). Perhaps add to the
visible text the number of the FAQ section.

* Parent Directory
* alt_dynwrite.html
* clj_posts.html
* cljs_charter.html
* closures.html
* contributors.html
* cookies.html
* faqNotes.zip
* faq_notes.css
* faq_notes.html
* form_access.html
* misc.html
* not_browser_detect.html
* pots1.html
* script_tags.html
* square_brackets.html
* type_convert.html


Alternatively, which is how I was earlier thinking of doing it, take the
ToC in faq_notes.html#toc but retain only "Introduction", the numbered
top-level list entries, and all after "Miscellaneous". The results
should be much the same.

Make it FAQ section 1.5. It would then be easier to find the Notes than
as ...

The FAQ contains links to the notes where relevant to the question at
hand. The FAQ also links to the notes very near the top of the
document, in "What questions are on-topic for comp.lang.javascript?"
and "Why was my post not answered?" questions


One thing that has come up a few times is the URI for the notes is long
and unmemorable. The path is something like:-

/faq/faq_notes/faq_notes.html

- but should instead be:-

/faq/notes/

(using default index page).

To do this, the links would need to be updated, in those documents. An
http redirect could be set up for the old faq_notes/ paths.

In earlier discussions in this group, it was agreed that routine
references to the FAQ, for example in FAQ 1.4, should use the full form,
independent of short cuts, defaults, etc. "http://www.jibbering.com/faq
/index.html" *looks* complete. The same should apply to the Notes, and
to the Regular Postings.

It seems likely that putting all the Notes material in
http://www.jibbering.com/faq/faq_notes/ makes access control easier.

/faq/faq_notes/faq_notes.html looks a bit silly because faq_notes is
repeated - rename the file to index.html.


Suggestions for making my $seq.htm faster would be of
interest; I really want to be able to put 5.8e6 in the
first window and have a run-time of less than 12 hours
(FF3, "busy" warning OFF (about:config to re-enable))
or Chrome.