By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,092 Members | 1,597 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,092 IT Pros & Developers. It's quick & easy.

AJAX.NET and prototype.js

P: n/a
I just noticed that prototype.js is one of the files in the Ajax.NET
distribution - I'm pretty concerned about this. Does anyone know if this
is the same "prototype.js" that is not well-liked around here?

If so, do you know if Ajax.NET can be used without prototype.js?
--
"The most convoluted explanation that fits all of the made-up facts is
the most likely to be believed by conspiracy theorists. Fitting the
actual facts is optional."
Jun 28 '06 #1
Share this Question
Share on Google+
31 Replies


P: n/a
Tony said the following on 6/28/2006 2:00 PM:
I just noticed that prototype.js is one of the files in the Ajax.NET
distribution - I'm pretty concerned about this. Does anyone know if this
is the same "prototype.js" that is not well-liked around here?
All it would take is to compare the file size and the first 10 lines or
so to see if they are the same.
If so, do you know if Ajax.NET can be used without prototype.js?


That would required testing it without prototype to see if it still
"works" or not.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Temporarily at: http://members.aol.com/_ht_a/hikksnotathome/cljfaq/
Javascript Best Practices -
Jun 28 '06 #2

P: n/a
Randy Webb wrote:
Tony said the following on 6/28/2006 2:00 PM:
I just noticed that prototype.js is one of the files in the Ajax.NET
distribution - I'm pretty concerned about this. Does anyone know if
this is the same "prototype.js" that is not well-liked around here?


All it would take is to compare the file size and the first 10 lines or
so to see if they are the same.
If so, do you know if Ajax.NET can be used without prototype.js?


That would required testing it without prototype to see if it still
"works" or not.


Obviously, I was hoping to hear from someone who had already been
through this experience :)
--
"The most convoluted explanation that fits all of the made-up facts is
the most likely to be believed by conspiracy theorists. Fitting the
actual facts is optional."
Jun 28 '06 #3

P: n/a
Tony wrote:
the same "prototype.js" that is not well-liked around here?


It's not well-liked? I think it can be really useful, as long as you
know what you're getting into when you use it and code accordingly.
IMHO, saying it's inherently bad is like saying the C++ STL is bad.
Sure, it's not part of the language per se, but if you want to make use
of the functionality it provides then what's the harm?

Just don't expect that any Prototype-independent libraries will still
work (although there are only a few problems that it causes - most
notably with for-in loops, which don't seem to be that widely used, and
in any case should never be used with any pre-assumptions about what
members they will discover).

Am I missing some big "gotcha" that's turned the community against this
library?

Jeremy
Jun 28 '06 #4

P: n/a
Jeremy wrote:
Tony wrote:
the same "prototype.js" that is not well-liked around here?
It's not well-liked?


Based on a number of posts I've read over the past month or so, yes.
I think it can be really useful, as long as you
know what you're getting into when you use it and code accordingly.
Perhaps, but that is a different discussion.
IMHO, saying it's inherently bad is like saying the C++ STL is bad.
I didn't say it was inherently bad. My question (that you didn't quote,
BTW) was if the Ajax.net one was the same one.
Sure, it's not part of the language per se, but if you want to make use
of the functionality it provides then what's the harm?
And if I DON'T want to make use of it?
Am I missing some big "gotcha" that's turned the community against this
library?


Take a look through this group's recent discussions on the matter, or
see http://www.javascripttoolbox.com/bes...ces/#prototype for a
quick summary.

So, are they the same?

--
"The most convoluted explanation that fits all of the made-up facts is
the most likely to be believed by conspiracy theorists. Fitting the
actual facts is optional."
Jun 28 '06 #5

P: n/a
Jeremy wrote:
Just don't expect that any Prototype-independent libraries will still
work (although there are only a few problems that it causes - most
notably with for-in loops, which don't seem to be that widely used,
and in any case should never be used with any pre-assumptions about
what members they will discover).
That is quite an assumption.

If I do:
var name = {'first':'bob'};

and then cycle through its properties, I expect to see 'first' and only
'first'. Otherwise, using an Object as a "Hash Table" isn't possible.
Am I missing some big "gotcha" that's turned the community against
this library?


http://www.javascripttoolbox.com/bes...ces/#prototype

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Jun 28 '06 #6

P: n/a
Matt Kruse wrote:

If I do:
var name = {'first':'bob'};

and then cycle through its properties, I expect to see 'first' and only
'first'. Otherwise, using an Object as a "Hash Table" isn't possible.

So why not use an Array as a "Hash Table"? Is that not what it's for?
Note: I'm not trying to be a jerk or come off as dense; I'm genuinely
interested. Does the ECMAScript specification require that an object
not have inherent properties, or that these properties not show up in a
for..in loop? The specification is pretty lax on that, and I would
argue that you shouldn't be relying on those assumptions in order for
your program to work.

Incidentally, it seems like this particular problem ought to be fixable
by setting the DontEnum attribute of the methods and properties that
prototype.js adds to Object. But I really have no idea if this is
implemented in user-agents; I'm sure someone would have implemented into
the library if it were feasible.

http://www.javascripttoolbox.com/bes...ces/#prototype


An interesting quote from your link:
"If you are writing code which only uses Prototype and nothing else,
then it can make your life simpler in often ingenious ways."

I'm not necessarily trying to argue that it's wise to use prototype.js -
I'm just arguing that the problems it causes are ALSO a symptom of
assumptions made by the people who diss it.

Jeremy
Jun 28 '06 #7

P: n/a
> Take a look through this group's recent discussions on the matter, or
see http://www.javascripttoolbox.com/bes...ces/#prototype for a
quick summary.


The fact that carelessly throwing in an otherwise useful script
framework might cause problems does not at all mean "the community is
against" it. Most people who use prototype improperly are probably
novices, and thus not active in "the community".

In my use, prototype has been very useful, and I also enjoy using the
effects libraries (e.g. rico) that are built on top of it.

Jun 28 '06 #8

P: n/a
Hi,

Jeremy wrote:
So why not use an Array as a "Hash Table"?


JavaScript allows to add properties dynamically to any object type. You
could even use an Image if you want. However, Array and other types have
already defined properties (Array.length, for example), which will
appear when you do a for...in. Additionally, in the case of a
"hashtable", these properties are unused, and disturb more than they
help. This is why it's better to use Object for a "hashtable" (but then
again, if someone external added properties to the Object prototype,
then you got the same problem, QED)

HTH,
Laurent
--
Laurent Bugnion, GalaSoft
Software engineering: http://www.galasoft-LB.ch
Private/Malaysia: http://mypage.bluewin.ch/lbugnion
Support children in Calcutta: http://www.calcutta-espoir.ch
Jun 28 '06 #9

P: n/a
Jeremy wrote:
Matt Kruse wrote:
If I do:
var name = {'first':'bob'};

and then cycle through its properties, I expect to
see 'first' and only 'first'. Otherwise, using an
Object as a "Hash Table" isn't possible.
So why not use an Array as a "Hash Table"? Is that not
what it's for?


Absolutely not. the only thing that allows an Array to be used as a
"Hash Table" is the fact that arrays are instances of the native
ECMAScritp object, so it is their objectness that would be being
employed not their arrayness. Arrays are for referencing elements by
integer index, and automatically tracking the largest index assigned
with the length.
Note: I'm not trying to be a jerk or come off as dense;
I'm genuinely interested. Does the ECMAScript specification
require that an object not have inherent properties, or that
these properties not show up in a for..in loop?
All of the specification defined properties of Arrays and Objects are
marked with the - DontEnum - attribute and for-in is specified as not
enumerating properties marked - DontEnum -.
The specification is pretty lax on that, and I would
argue that you shouldn't be relying on those assumptions
in order for your program to work.
I don't think the specification is lax in this area (See the last
sentence of paragraph 11 in ECMA 262, 3rd Ed. Section 15). Implementers
are allowed to add properties as extensions, but it would be careless of
them not to mark such extension properties - DontEnum - themselves, and
I don't know of any implementation extensions to Array or Object that do
show up in for-in loops.
Incidentally, it seems like this particular problem ought
to be fixable by setting the DontEnum attribute of the
methods and properties that prototype.js adds to Object.
You don't design good javascript code by wishing javascript was some
other language. It is quite clear that that the attributes of properties
are not intended for runtime modification (otherwise the - Internal -
attribute would be listed separately as it would not make sense for that
one to be modifiable).

It was a poor design decision in Prototype.js to extend the prototypes
of Object and Array, and its authors cannot excuse themselves with a
desire not be creating the extra objects necessary to extend Array and
Object further down the prototype chain (or by augmentation) as the
library itself continually creates and discards an excessive number of
superfluous objects as it runs.
But I really have no idea if this is implemented in
user-agents; I'm sure someone would have implemented
into the library if it were feasible.
It is not.

<snip> ... prototype.js - I'm just arguing that the problems it
causes are ALSO a symptom of assumptions made by the people
who diss it.


Like assuming that the language specification is not explicit about the
enumerability of the properties it defines?

Richard.
Jun 28 '06 #10

P: n/a
Laurent Bugnion wrote:
JavaScript allows to add properties dynamically to any object type. You
could even use an Image if you want. However, Array and other types have
already defined properties (Array.length, for example), which will
appear when you do a for...in. Additionally, in the case of a
"hashtable", these properties are unused, and disturb more than they
help. This is why it's better to use Object for a "hashtable" (but then
again, if someone external added properties to the Object prototype,
then you got the same problem, QED)


You're right. I thought about it some more, and using an Array solves
nothing. For some reason I had the idea that using an Array would allow
you to avoid using a for..in loop entirely. Not sure why I thought that
at the time, but it's clearly not the case.

Foot, meet mouth.

I also did a test of using the DontEnum property, but it didn't work. I
guess next time I'll take Tom Cruise's advice and Do My Research.

Jeremy
Jun 28 '06 #11

P: n/a
Richard Cornford wrote:

Absolutely not. the only thing that allows an Array to be used as a
"Hash Table" is the fact that arrays are instances of the native
ECMAScritp object, so it is their objectness that would be being
employed not their arrayness. Arrays are for referencing elements by
integer index, and automatically tracking the largest index assigned
with the length.

<snip>


You're right; I'm wrong :-) See my reply to the post above yours.

I stand by my position that prototype.js is useful, as long as you're
aware of the ramifications of using it. But I was wrong about pretty
much everything else.

However, I still think that the for..in loop is not very robust. I just
don't trust it, even without prototype.js mucking things up.

Jeremy
Jun 28 '06 #12

P: n/a
Jeremy wrote:
Richard Cornford wrote:

Absolutely not. the only thing that allows an Array to
be used as a "Hash Table" is the fact that arrays are
instances of the native ECMAScritp object, so it is their
objectness that would be being employed not their arrayness.
Arrays are for referencing elements by integer index, and
automatically tracking the largest index assigned with the
length.

<snip>
You're right; I'm wrong :-) See my reply to the post
above yours.


This is Usenet so there is no meaning to 'above'. As it happens the
particular display configuration (if its 256 odd) that my newsreader is
currently on has the post you are referring to below this one (until I
click a column header and re-order it).
I stand by my position that prototype.js is useful, as long
as you're aware of the ramifications of using it.
But the ramification are nowhere near documented, and so understanding
would imply an understanding of the code itself (with all its
convolutions). We are not seeing much evidence of the necessary
understanding of the prototype.js code either in the questions asked or
in the (non-dismissive subset of) answers provided to those questions.
It is clear that the people asking questions about it here have little
grasp of the internal mechanisms it uses, and the people providing
answers seem to be universally proposing solutions which involve
wrapping another layer of complexity around when a little understanding
of the code would not only avoid that additional complexity but often
allow an across the board simplification.

Still, almost nobody asking questions about prototype.js to date has
managed to provide enough of a starting point that anyone could work on
their issues for them so they are likely to be left with the poor, the
glib and the dismissive.

However, I have always thought that time spent learning to use this type
of library (rather than the (more or less) task-specific type with a
simple interface) is time spent not learning javascript and browser
script design, and learning javascript and browser script design will do
the javascript author more good in the long run.
But I was wrong about pretty
much everything else.

However, I still think that the for..in loop is not very
robust.
I have never liked it much, but if you have potentially large but very
sparse arrays it is the optimum method of iterating their properties
(performance wise). And as the application framework that I work on
needs to iterate the properties of such arrays, and do it as quickly as
possible, the first page of the documentation for cli9ent-side code
development lays down the rule that nobody is allowed to extend
Object.prototype or Array.prototype, and in 60,000 lines of javascript
code to date that has not been a problem (or even an inconvenience).
I just don't trust it, even without prototype.js mucking
things up.


Well, at least with Prototype.js you know it is 'mucked up' from the
outset. But then, if you are writing for known environments you may be
in a position to be certain that it is not 'mucked up' otherwise (my
application is only required to work with IE and Gecko (it needs to work
with any OS but its nature is such that the user will install a
specified browser if necessary) so I can use for-in in confidence with
it).

Richard.
Jun 28 '06 #13

P: n/a
Jeremy said the following on 6/28/2006 5:50 PM:

I stand by my position that prototype.js is useful, as long as you're
aware of the ramifications of using it.


The major problem with that statement is that if you are knowledgeable
enough to know the ramifications of using prototype.js then you aren't
using it to start with.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Temporarily at: http://members.aol.com/_ht_a/hikksnotathome/cljfaq/
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Jun 29 '06 #14

P: n/a
Hi,

Jeremy wrote:

I also did a test of using the DontEnum property, but it didn't work. I
guess next time I'll take Tom Cruise's advice and Do My Research.

Jeremy


I think that by asking in a newsgroup, you're Doing Your Research. I
have no problems with that ;-)

HTH,
Laurent
--
Laurent Bugnion, GalaSoft
Software engineering: http://www.galasoft-LB.ch
Private/Malaysia: http://mypage.bluewin.ch/lbugnion
Support children in Calcutta: http://www.calcutta-espoir.ch
Jun 29 '06 #15

P: n/a

Jeremy wrote:
I stand by my position that prototype.js is useful, as long as you're
aware of the ramifications of using it.


It seems from reading these posts that most of the regulars in this
usenet group disagree with you. However, most of these regulars also
believe that hand coding javascript is a worth while pursuit. AJAX.net
and Ruby On Rails both use prototype.js and both frameworks seek to
more or less do away with hand coding javascript. I imagine that
prototype.js works just fine within their well tested boundaries and if
it breaks, they will replace it something that works better without the
user knowing the difference.

In my mind the jury is out on javascript. I've come to respect it from
professional use and from mostly lurking on this group but I would
certainly be open to going to something more productive for building
serious web apps if it comes along. AJAX just begs for a framework,
IMHO.

Bob Gulian

Jun 29 '06 #16

P: n/a
bg*****@gmail.com said the following on 6/29/2006 11:49 AM:
Jeremy wrote:
I stand by my position that prototype.js is useful, as long as you're
aware of the ramifications of using it.
It seems from reading these posts that most of the regulars in this
usenet group disagree with you.


Actually, most would agree when you stop, read, and realize what is
said. The important part is "as long as you're aware of the
ramifications" and I would wager that 99% or more of the people using
prototype.js don't even know the ramifications exist much less what they
are.

And that is not with regards to prototype.js specifically, it is true of
any library.
However, most of these regulars also believe that hand coding
javascript is a worth while pursuit.
No, we all think it is better to load 100K of JS code so you can use 3
lines of it. <eyeroll>
AJAX.net and Ruby On Rails both use prototype.js and both frameworks seek to
more or less do away with hand coding javascript.
That is an admirable goal but it has failed to date.
I imagine that prototype.js works just fine within their well tested
boundaries and if it breaks, they will replace it something that works
better without the user knowing the difference.
Square pegs always fit in square holes. Its when you start trying to
force it into a round hole that you have problems.
In my mind the jury is out on javascript.
Why? JS is the future of the web at the moment.
I've come to respect it from professional use and from mostly lurking
on this group but I would certainly be open to going to something more
productive for building serious web apps if it comes along.
"More productive"? You use the right tool for the job, depending on what
the job requires.
AJAX just begs for a framework, IMHO.


Why?

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Temporarily at: http://members.aol.com/_ht_a/hikksnotathome/cljfaq/
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Jun 29 '06 #17

P: n/a
bg*****@gmail.com wrote:
Jeremy wrote:
I stand by my position that prototype.js is useful, as long
as you're aware of the ramifications of using it.
It seems from reading these posts that most of the regulars
in this usenet group disagree with you.


The position that seems to be taken most often is that the understanding
that allows an awareness of the ramifications coincides with a
recognition of superior strategies and so the awareness of the
ramifications will never coincide with the use of Prototype.js. It has
never been the case that the regulars on this group entirely agree with
each other (things would be rather boring if they/we did) so finding
that protoype.js has no champions at all does say something quite
important about it.
However, most of these regulars also believe that hand
coding javascript is a worth while pursuit.
That is really too vague to be properly responded to. What do you
consider 'hand coding'? It is not the case that the regulars here don't
believe in code re-use (we are not masochistic), but it is not an
'either or' situation. Not believing that large, interdependent,
monolithic general code libraries are not a good idea in browser
scripting does not imply a belief that everything should be hand written
from scratch for every project. There is a whole spectrum of
possibilities in between.
AJAX.net and Ruby On Rails both use prototype.js and both
frameworks seek to more or less do away with hand coding
javascript.
Neither seem to achieve that, and swapping writing javascript for
writing some other language is not much of a step forward, especially if
browser compatibility and reliability are sacrificed (and particularly
invisibly sacrificed) along the way.
I imagine that prototype.js works just fine within their well
tested boundaries and if it breaks, they will replace it
something that works better without the user knowing the difference.
From what I have seen of the way prototype.js is being used swapping it
for something else is not going to be that practical, the actual
interface exposed by the library is far too complex for that.
In my mind the jury is out on javascript. I've come to respect
it from professional use and from mostly lurking on this group
but I would certainly be open to going to something more
productive for building serious web apps if it comes along.
Javascript is an ideal language for client-side scripting of web
browsers because its dynamic nature allows it to adapt to the
environments it encounters. Trying to do what is easy in javascript with
a strongly typed and non-dynamic language such as Java would be a
nightmare (far too much reflection and error handling). So a replacement
client-side scripting language would best be something as flexible as
javascript, and if that then why replace at all?
AJAX just begs for a framework, IMHO.


That would be a very poor notion that would result in a system that
would try to be all things to all men, but end up being too much for
most and insufficient for some. AJAX is just too general a concept to be
subject to the creation of a single all encompassing framework.

At its worst you are looking at a hugely complex activity, say 'as they
type' validation, look-ups/suggestions, data retrieval, context
maintenance and switching, and all the rest of interactive activity that
might be expected of something like a data entry/reporting web
application, and all needing to be orchestrated with the asynchronous
activity of the user in a way that does not get in their way and still
makes sense.

While at its simplest you are just talking about the retrieval of data
from a server which the user may request and view, but with which they
will not directly interact.

A framework that automates the writing of the former will be
ridiculously over the top for the latter. While a framework that only
achieves the latter will obviously be seriously harmful if used in the
former context.

Richard.
Jun 30 '06 #18

P: n/a
Richard Cornford wrote:
bg*****@gmail.com wrote:
Jeremy wrote:
I stand by my position that prototype.js is useful, as long
as you're aware of the ramifications of using it. In my mind the jury is out on javascript. I've come to respect
it from professional use and from mostly lurking on this group
but I would certainly be open to going to something more
productive for building serious web apps if it comes along.


Javascript is an ideal language for client-side scripting of web
browsers because its dynamic nature allows it to adapt to the
environments it encounters. Trying to do what is easy in javascript with
a strongly typed and non-dynamic language such as Java would be a
nightmare (far too much reflection and error handling). So a replacement
client-side scripting language would best be something as flexible as
javascript, and if that then why replace at all?

My argument is questioning "hand coded" (as opposed to
program-generated) javascript as a reasonable, easily maintainable way
to build web applications. I have come to admire javascript as a
language and would never advocate for a replacement client-side
scripting language.
But...

AJAX just begs for a framework, IMHO.


That would be a very poor notion that would result in a system that
would try to be all things to all men, but end up being too much for
most and insufficient for some. ..<snip>

At its worst you are looking at a hugely complex activity, say 'as they
type' validation, look-ups/suggestions, data retrieval, ...<snip>
..and all needing to be orchestrated with the asynchronous
activity of the user in a way that does not get in their way and still
makes sense.


Yes, that is what a framework would have to do and as far as I've seen,
that is indeed what Ruby On Rails does and it does it well.

What I hear from you, correct me if I'm wrong, is that users shouldn't
use monolithic, invisible javascript code libraries, they should write
their own libraries (reusable code). This is the direction we are
moving towards in my company. Up to this point I have thought it was a
good direction, at least a lot better than relying on ASP or Java, But
I am starting to see a big problem with developing large amounts of
"the most misunderstood language" code. Stronger typed or more natural
languages (Ruby reads like english most of the time) don't need to be
wholly understood by the developer. Some of my coworkers (experts at
SQL and ASP) consider javascript to be magic. In this area of the
world (New York CIty), people who advertise themselves as Javascript
gurus really mean DHTML gurus. Most of them have never peeked at this
news group. This means, to me, that there will continue to be much
more bad javascript written than good javascript and I would furthur
maintain that this is much truer than of other languages due to
javascript's exclusivity in browsers.

What I said is that in my mind, the jury is still out on javascript. I
like the Yahoo UI widget libary almost as much as ROR and it is all
client side javascript. It is also a framework for handling AJAX and
events and while it won't completely handle "validation (while you
type)", it certainly makes it easier to implement things like that.

What I would like to see are more solid cross-browser libraries like
Yahoo UI and individually coded javascript tasks using those libraries
and complimenting a server based framework like Rails or server based
technology like PHP-Mysql. Yes, and I guess .NET (though it is not my
idea of fun).

Bob

Jun 30 '06 #19

P: n/a
bg*****@gmail.com wrote:
What I would like to see are more solid cross-browser libraries like
Yahoo UI and individually coded javascript tasks using those libraries
Problem #1: Writing and documenting good solid cross-browser reusable
libraries is difficult and very time-consuming.
Problem #2: Many of the best javascript coders here and elsewhere believe
that reusable libraries, as a concept, are flawed. So they won't write them.

My collection of libraries are available at:
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

I believe some of what I've done is superior to that of the yahoo libs and
prototype, for example. But it's all a matter of personal taste and what you
need.
and complimenting a server based framework like Rails or server based
technology like PHP-Mysql. Yes, and I guess .NET (though it is not my
idea of fun).


I think that automatically generating javascript from server-side code is a
dangerous task in many cases. For example, the js generated by .NET is
absolutely horrible.

I think in a complex situation there should be multiple layers of js code:

- Core reusable libraries which are lightweight and perform specific tasks
- Project-specific hand-written reusable code which uses the libs to create
commonly-required functionality for the project
- Screen-specific code which integrates the libs, the reusable
functionality, and screen-specific content
- (optional) Server-generated code which integrates the screen-specific
code with the server-side piece

IMO, solutions like .NET which try to hide every layer from the developer
and do it all magically will continue to be a flawed solution for the
foreseeable future.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Jun 30 '06 #20

P: n/a
bg*****@gmail.com wrote:
Richard Cornford wrote:
bg*****@gmail.com wrote:
Jeremy wrote:
I stand by my position that prototype.js is useful, as long
as you're aware of the ramifications of using it.
In my mind the jury is out on javascript. I've come to respect
it from professional use and from mostly lurking on this group
but I would certainly be open to going to something more
productive for building serious web apps if it comes along.
Javascript is an ideal language for client-side scripting of web
browsers because its dynamic nature allows it to adapt to the
environments it encounters. Trying to do what is easy in javascript with
a strongly typed and non-dynamic language such as Java would be a
nightmare (far too much reflection and error handling). So a replacement
client-side scripting language would best be something as flexible as
javascript, and if that then why replace at all?


My argument is questioning "hand coded" (as opposed to
program-generated) javascript as a reasonable, easily maintainable way
to build web applications.


Speaking as someone who works directly in the field, and deals with
"program-generated" javascript as well as "hand-coded" javascript, I
have to say that the hand-coded javascript is far easier to improve,
extend, and maintain. At some point, most of the program-generated
javascript that we use has ended up being replaced or overridden,
because of problems it caused in other parts of the application.
What I hear from you, correct me if I'm wrong, is that users shouldn't
use monolithic, invisible javascript code libraries, they should write
their own libraries (reusable code). This is the direction we are
moving towards in my company. Up to this point I have thought it was a
good direction, at least a lot better than relying on ASP or Java, But
I am starting to see a big problem with developing large amounts of
"the most misunderstood language" code. Stronger typed or more natural
languages (Ruby reads like english most of the time) don't need to be
wholly understood by the developer. Some of my coworkers (experts at
SQL and ASP) consider javascript to be magic. In this area of the
world (New York CIty), people who advertise themselves as Javascript
gurus really mean DHTML gurus. Most of them have never peeked at this
news group. This means, to me, that there will continue to be much
more bad javascript written than good javascript and I would furthur
maintain that this is much truer than of other languages due to
javascript's exclusivity in browsers.


I am by no means a "javascript guru" anywhere near the level of many on
this group, but any decently competent javascript coder should be able
to do what you need done.

Of course, finding one is a problem - because, as it is with any other
field, most js coder resumes are works of fiction.

Test your candidates. That's what my company does. It's amazing the
things that you discover about people when you do that - such as, their
ability (or inability) to do the job.


--
"The most convoluted explanation that fits all of the made-up facts is
the most likely to be believed by conspiracy theorists. Fitting the
actual facts is optional."
Jun 30 '06 #21

P: n/a
Matt Kruse wrote:

I think that automatically generating javascript from server-side code is a
dangerous task in many cases. For example, the js generated by .NET is
absolutely horrible.


You are being far too kind.

--
"The most convoluted explanation that fits all of the made-up facts is
the most likely to be believed by conspiracy theorists. Fitting the
actual facts is optional."
Jun 30 '06 #22

P: n/a
bg*****@gmail.com wrote:
Richard Cornford wrote:
>bg*****@gmail.com wrote:
>>Jeremy wrote:
I stand by my position that prototype.js is useful, as
long as you're aware of the ramifications of using it.
>>In my mind the jury is out on javascript. I've come to
respect it from professional use and from mostly lurking
on this group but I would certainly be open to going to
something more productive for building serious web apps
if it comes along.

Javascript is an ideal language for client-side scripting
of web browsers because its dynamic nature allows it to
adapt to the environments it encounters. Trying to do what
is easy in javascript with a strongly typed and non-dynamic
language such as Java would be a nightmare (far too much
reflection and error handling). So a replacement client-side
scripting language would best be something as flexible as
javascript, and if that then why replace at all?

My argument is questioning "hand coded" (as opposed to
program-generated) javascript as a reasonable, easily
maintainable way to build web applications.
There is a 'chicken and the egg' problem with that proposition. To be in
a position to design/write good machine generated javascript the
individual responsible will have to have learnt javascript, and its
(particularly browser scripting) applications pretty well, because they
are going to have to be automatically handing all of the issues of the
general case. They will not get into that position unless they have an
extensive experience of browser scripting (and server scripting for that
matter) and that will inevitably mean a great deal of hand coding (not
to mention that actual writing of the scripts that the machine
generates).

Historically, much server-script and automatically generated javascript
has been very poor, and it doesn't take much observing to see that
people who rely upon systems that generate client-side code are utterly
lost as soon as they encounter a problem with/limitation in the system
they are using. So lost that not only do they have no idea how to
address their problems but they cannot even express their problems in
terms applicable to client-side scripting ("I have an ASP.NET control";
says nothing in the context of client-side technologies).
I have come to admire javascript as a language and
would never advocate for a replacement client-side
scripting language.
But...
AJAX just begs for a framework, IMHO.

That would be a very poor notion that would result in a
system that would try to be all things to all men, but
end up being too much for most and insufficient for
some. ..<snip>
>At its worst you are looking at a hugely complex activity,
say 'as they type' validation, look-ups/suggestions, data
retrieval, ...<snip..and all needing to be orchestrated
with the asynchronous activity of the user in a way that
does not get in their way and still makes sense.

Yes, that is what a framework would have to do and as far
as I've seen,
But that is not an AJAX framework, it is one form of web application
framework, It would be far too much for most actual uses of AJAX.
that is indeed what Ruby On Rails does and it does it well.
Not from what I have seen of Ruby on Rails.
What I hear from you, correct me if I'm wrong, is that
users
Users? To my mind the user is the person on the receiving end of web
development, the one sitting in front of a browser interacting with the
end result. The person who's behaviour I may seek to alter in this
respect is the web developer, who, if he/she is using any form of
programming code, is a programmer (no matter how much they may not want
to admit it to themselves, or fall short of the skill set necessary to
do that job well).
shouldn't use monolithic, invisible javascript code libraries,
No they should not, that style of code authoring, while completely
appropriate in other programming contexts, is out of place in browser
scripting. It is appropriate in other contexts because it doesn't matter
how general and comprehensive a code library may be because the process
of compiling any code that uses it will allow for the automatic, and
selective, inclusion of _only_ the parts that are needed by the finished
executable. While with javascript no 'compiling' could happen until the
source code has been transmitted to the client, in its entirety. And
once sent to the client all the code received will be acted upon; All of
the code will be tokenised, all will be transformed into an executable
form, all global function declarations , for example, will result in the
unconditional creation of function objects, even if in reality some
percentage of them may never be used.

A code authoring strategy that is so near to being universally
advantageous in computer programming that people will defend it as the
only conceivable approach to sensible code re-use becomes a limiting
factor when applied to browser scripting. You just cannot set about
browser scripting by including one library then another and then
another, and actually using about 10% of each. The overheads in download
time, interpretation/compilation time and actual execution performance
adds up to the point where the end result eventually becomes non-viable.
Taking that path leads to a known destination, and it is somewhere that
should be avoided. Browser scripting has to use another strategy; a
strategy where the units of re-use are smaller, independent and
task/context specific.
they should write their own libraries (reusable code).
There is nothing wrong with using code written by others, if it is the
right type of code for the task/context. But to see that code is the
right type, is suitable written and of sufficient qualify, a javascript
programmer is going to have to gain some practical experience of browser
scripting (preferably in the most demanding applicant; public Internet
programming). And in setting about gaining that experience they will
likely write a great deal of code that will serve as the basis of their
own collection of re-useable components. Plus they will get an insight
into the issues of browser script design and a familiarity with
strategies that can be applied to address them.

I don't really need to say, as a blanket injunction, that people should
not use monolithic general purpose javascript libraries, all I have to
do is convince them to set about learning to script web browsers well
and they will see that for themselves eventually. And that is why the
champions of the general javascript library concept are not to be found
among the regular contributors to this group; the people who have put in
the effort to learn the practice well have seen the pitfalls and learnt
how to set about applying the practical alternatives.
This is the direction we are moving towards in my
company. Up to this point I have thought it was a
good direction, at least a lot better than relying on
ASP or Java, But I am starting to see a big problem
with developing large amounts of "the most misunderstood
language" code. Stronger typed or more natural languages
(Ruby reads like english most of the time) don't need to be
wholly understood by the developer. Some of my coworkers
(experts at SQL and ASP) consider javascript to be magic.
Isn't the implication of that that the people who make (or swing) the
decisions about the use of client-side technologies should be the people
who don't understand them?

I am reminded of all the times I have been told, by people who had no
idea of how to go about doing so themselves, that designing truly
cross-browser systems would be so restrictively expensive that is could
not be worth even trying. It is a bit like asking a plumber for a quote
on the cost of hart bypass surgery.

The perverse aspect to this situation (particularly with respect to
Prototype.js) is that not only is it the people who don't have the
pertinent skills who want to be directing implementation approaches but
that what is proposed largely goes against the advice of the people who
do.
In this area of the world (New York CIty), people who
advertise themselves as Javascript gurus really mean
DHTML gurus.
I don't think anyone could justify describing themselves as the latter
without also being the former (but I would seriously distrust anyone who
labelled themselves a 'guru' anyway).

But I appreciate that problem very well. When I applied for the job I
currently have, which advertised for javascript experts, I was given a
'technical' text. A test so superficial, easy and obvious that I would
consider anyone who did not get 100% on it not even to be qualified to
write javascript, it certainly didn't approach being a test of
'expertise' in the area. It transpired that one of the reasons that I
was offered the job was that _none_ of the other candidates had done
better than 50% on that test. I have no idea how these people offering
themselves for the role of javascript expert imagined that they would do
the job, I am forced to conclude that they thought that 'expert' had
been tacked onto the job description with the same misguided motivation
that has employers asking for technically skilled web developers with
"Dreamweaver" (which is almost an oxymoron).

I am also seeing this in the London job market, where a city bank (who
will have to be unnamed due to a confidentiality agreement) have spent
at least the last 6 months attempting to employ a good javascript
developer. They advertise for a couple of days, so quiet for a month,
and then advertise the job again. Presumably each time they find
someone, and then take the next month discovering that they are not up
to the job and have to start again. It must be very expensive to
repeatedly go through that cycle, and I cannot see that they will be
making much headway on whatever project this individual is supposed to
be working on.

So I can completely appreciate that you may be finding it difficult to
lay your hands on someone who can significantly contribute to your
project. However, I don't think you will solve that problem by assuming
that the authors of some library or framework would have been that
person if you had managed to employ them directly.

Still, my advice would be that if you want to create a system that makes
more than a trivial use of client-side scripting you will really need to
find someone who has the (combined server-side and client-side) skills
and experience for the task. Granted you will have to think of some
strategy for distinguishing the people who actually have those skills
from the people who just think they have, and you will have to offer
remuneration suitable for a seller's market. Otherwise my final
suggestion at the end of this post may be the best approach to take.
Most of them have never peeked at this news group.
Which would be a pity as with browser scripting the main practical
subject of this group the bulk of what gets discussed is DHTML in
practice (even if many don't like that particular label for it).
This means, to me, that there will continue to be much
more bad javascript written than good javascript
While I don't doubt that is true I don't see that it follows from your
previous comments. Bad javascript is written because it can be written,
and written more easily than virtually any other form of computer code.
There is no requirement for any specialised software, IDE, etc, and
people can create something that superficially 'works' with no more than
any javascript book or a little searching on the Internet. A situation
that allows people to easily becomes ridiculously over-confident
javascript abilities, which then motivates them to start contributing to
the mass of publicly available copy-n-paste scripts on the Internet (and
in extreme cases creating entire libraries for the even less experienced
to shoot themselves in the foot with).
and I would furthur maintain that this is much truer
than of other languages due to javascript's exclusivity
in browsers.
On the whole it is a good thing that client-side scripting is (to all
practical purposes) limited to a single language.
What I said is that in my mind, the jury is still out on
javascript.
But you did not elucidate the charges you think it is facing, so there
is not a great deal that can be said in response to those implied
charges.
I like the Yahoo UI widget libary almost as much as ROR and
it is all client side javascript. It is also a framework
for handling AJAX and events and while it won't completely
handle "validation (while you type)", it certainly makes it
easier to implement things like that.

What I would like to see are more solid cross-browser
libraries like Yahoo UI
As it happens earlier in the week I had reason to take a look at the
Yahoo libraries, specifically the Event library (indeed one specific
method call in that library), and was slightly shocked to see how
many serious faults I observed in the tiny fraction of the code that
I was interested in.

For a start it includes a couple of instances of userAgent string based
browser detection. User Agent string based browser detection is such a
universally recognised bad practice that in the extensive discussion we
had here on how to advise people on the recognition of bad javascript
code it was one of only two practices that were agreed to be universally
indicative of code so poor that it should be rejected out of hand (i.e.
you do a text search of the source for 'userAgen' and if found you
reject the script in question and move on to the next). (The other
universally agreed indicator of bad code being the direct - eval -ing of
string literals.)

User Agent string based browser detection is a bad practice because:

1. RFC 2616 (HTTP 1.1) makes it clear that the UserAgent header is not a
source of information about the user agent (because it does not require
the header to contain any specific information, or even be consistent
over time) and as the navigator.userAgent property reflects the HTTP
header it must also not be a source of information.

2. Many browser use, by default, User Agent headers that are practically
indistinguishable from the headers used by (normally more common)
browsers, and discriminating is not practical when the input data is
identical. (It was Microsoft's introduction of UserAgent header spoofing
that forced the HTTP 1.1 specification to give the UserAgent header its
current status as something that is not a source of information, though
Microsoft appears to have not noticed the consequences of their actions
and themselves make the mistake of integrating UA header browser
'discrimination' into .NET)

1. User Agent headers are amenable to user modification in almost all
cases, including on browsers such as IE, and as the HTTP specification
does not require the header to be a source of information no criticism
can reasonably be levelled at users who modify the header (regardless of
how inconvenient that may seem to people who have already made the error
of mistaking the header for a source of information).
The practical upshot of this error in the Yahoo code is that the
libraries will not be cross-browser, the best they could aver achieve
would be to be multi-browser, and then only multi-browser where the
browsers in question were (in some respects) operated in their default
configurations. And here is something that speaks to maintenance, as
this error could be fixed but if it is everyone who has tied their
project to the library has to make an effort to take advantage (assuming
that they find out about it).

The reason that I had to look at the browser detection was because it
was used to branch into this function (theoretically for IE only, though
in reality only for IE's with near default UA strings and any browser
with an IE like UA string and no pageX/Y property on its event
objects):-

| _getScroll: function() {
| var dd = document.documentElement; db = document.body;
| if (dd && dd.scrollTop) {
| return [dd.scrollTop, dd.scrollLeft];
| } else if (db) {
| return [db.scrollTop, db.scrollLeft];
| } else {
| return [0, 0];
| }
| }

However, this code demonstrates either a lack of understanding of the
behaviour of IE browsers, or a shortfall in the application of logic on
the part of its author. IE 6+ can operate in one of two 'modes' (which
it knows a 'CSS1Compat' and 'BackCompat', all earlier IEs do the same is
IE 6+ in 'BackCompat' mode (as that is 'Back' referred to). The
arrangement with scrollTop/Left is that when in 'BackCompat' mode you
read the values form the document.body, and in 'CSS1Compat' you read
them form the document.documentElement (which does not exist prior to IE
5.0). Fortunately for this code, on IE whichever of these elements is
not reporting the actual scroll offsets of a page will report zero
values for scrollLeft/Top (rather than NaN or undefined values). This
allows the code to disregard the reported 'mode' of the browser (as
retrieved from - document.compatMode - on IE 6+) and instead deduce
that zero values imply a need to look elsewhere.

However, if a document is in 'CSS1Compat' mode and has been scrolled
horizontally but not vertically the - if (dd && dd.scrollTop) { - test
will return false (because dd.scrollTop is still zero), and so the
scrollTop/Left values will be read from the document.body element, where
both values will be zero because the page is in 'CSS1Compt' mode.

This fault is inherent in the logic of code, and I assume that the
author would not have written code that outputs erroneous values under
realistically possible conditions deliberately. So when I look at barely
16 line of code from this library and find a universally recognised bad
practice and implemented logic that will produce erroneous results under
realistic circumstances I am inclined to be seriously unimpressed, and
wonder to what extent these shortcomings manifest themselves elsewhere
in the code. I also wonder to what extent those using this code, and
recommending its use to others, appreciate its faults and limitations.
The author(s) obviously are not aware of what they have done here, else
they would have applied joined up logic to the situation.

Unfortunately for many the decision to use this code will be based upon
a trust in the source of the code (Yahoo's reputability) and the
recommendations of others, who may not be an any better position to
properly asses the library's actual code.
and individually coded javascript tasks using those libraries
and complimenting a server based framework like Rails or server
based technology like PHP-Mysql. Yes, and I guess .NET (though
it is not my idea of fun).
But is that solving problems or hiding from them; abdicating
responsibility for the quality of your products to third parties, and
third parties you are unlikely to be able to assess the skills of but
you have to trust to be doing their job properly, and properly testing
their creations. Your cited Yahoo library illustrates the shortcomings
of this approach, where the author did not perceive the hole in the
logic implemented and the QA testing applied did not expose it.

There is always the option of taking another course, and just leaving
client-side scripting alone. It certainly is not compulsory to use it
and may be better not used than used badly.

Richard.
Jul 2 '06 #23

P: n/a
Richard,

Wow! Your post below* was really great. I enjoyed reading it.

The sentiment you espouse almost makes it seem like browser scripting
with JavaScript is futile or hopeless for those that are not complete
experts. However, people need to actually finish websites in a finite
time to satisfy their customers and eat dinner. So people look to
JavaScript libraries to help save time. And they may give up on
cross-browser in favor of multi-browser support. These decisions are
pragmatic. What do you suggest to them? Tell their clients that what
they desire is too lofty and loose the contract? Give up? Be satisfied
with multi-browser support and bugs here and there?

There is little doubt in my mind that both an event and an AJAX library
like the Yahoo! UI libraries are a good idea. These are reasonable
sized chunks of functionality. For example, a developer using the
Yahoo! AJAX library is likely to use 80% of it in a website of
reasonable size. It must be possible to write good, cross-browser,
reusable JavaScript libraries like these that would pass your tests for
acceptable, high-quality JavaScript practices. Do you think this is
true?

Peter

* I top-posted for the benefit of those without the message archived.
Richard Cornford wrote:
bg*****@gmail.com wrote:
Richard Cornford wrote:
bg*****@gmail.com wrote:
Jeremy wrote:
I stand by my position that prototype.js is useful, as
long as you're aware of the ramifications of using it.
>In my mind the jury is out on javascript. I've come to
respect it from professional use and from mostly lurking
on this group but I would certainly be open to going to
something more productive for building serious web apps
if it comes along.

Javascript is an ideal language for client-side scripting
of web browsers because its dynamic nature allows it to
adapt to the environments it encounters. Trying to do what
is easy in javascript with a strongly typed and non-dynamic
language such as Java would be a nightmare (far too much
reflection and error handling). So a replacement client-side
scripting language would best be something as flexible as
javascript, and if that then why replace at all?
My argument is questioning "hand coded" (as opposed to
program-generated) javascript as a reasonable, easily
maintainable way to build web applications.

There is a 'chicken and the egg' problem with that proposition. To be in
a position to design/write good machine generated javascript the
individual responsible will have to have learnt javascript, and its
(particularly browser scripting) applications pretty well, because they
are going to have to be automatically handing all of the issues of the
general case. They will not get into that position unless they have an
extensive experience of browser scripting (and server scripting for that
matter) and that will inevitably mean a great deal of hand coding (not
to mention that actual writing of the scripts that the machine
generates).

Historically, much server-script and automatically generated javascript
has been very poor, and it doesn't take much observing to see that
people who rely upon systems that generate client-side code are utterly
lost as soon as they encounter a problem with/limitation in the system
they are using. So lost that not only do they have no idea how to
address their problems but they cannot even express their problems in
terms applicable to client-side scripting ("I have an ASP.NET control";
says nothing in the context of client-side technologies).
I have come to admire javascript as a language and
would never advocate for a replacement client-side
scripting language.
But...
AJAX just begs for a framework, IMHO.

That would be a very poor notion that would result in a
system that would try to be all things to all men, but
end up being too much for most and insufficient for
some. ..<snip>
At its worst you are looking at a hugely complex activity,
say 'as they type' validation, look-ups/suggestions, data
retrieval, ...<snip..and all needing to be orchestrated
with the asynchronous activity of the user in a way that
does not get in their way and still makes sense.
Yes, that is what a framework would have to do and as far
as I've seen,

But that is not an AJAX framework, it is one form of web application
framework, It would be far too much for most actual uses of AJAX.
that is indeed what Ruby On Rails does and it does it well.

Not from what I have seen of Ruby on Rails.
What I hear from you, correct me if I'm wrong, is that
users

Users? To my mind the user is the person on the receiving end of web
development, the one sitting in front of a browser interacting with the
end result. The person who's behaviour I may seek to alter in this
respect is the web developer, who, if he/she is using any form of
programming code, is a programmer (no matter how much they may not want
to admit it to themselves, or fall short of the skill set necessary to
do that job well).
shouldn't use monolithic, invisible javascript code libraries,

No they should not, that style of code authoring, while completely
appropriate in other programming contexts, is out of place in browser
scripting. It is appropriate in other contexts because it doesn't matter
how general and comprehensive a code library may be because the process
of compiling any code that uses it will allow for the automatic, and
selective, inclusion of _only_ the parts that are needed by the finished
executable. While with javascript no 'compiling' could happen until the
source code has been transmitted to the client, in its entirety. And
once sent to the client all the code received will be acted upon; All of
the code will be tokenised, all will be transformed into an executable
form, all global function declarations , for example, will result in the
unconditional creation of function objects, even if in reality some
percentage of them may never be used.

A code authoring strategy that is so near to being universally
advantageous in computer programming that people will defend it as the
only conceivable approach to sensible code re-use becomes a limiting
factor when applied to browser scripting. You just cannot set about
browser scripting by including one library then another and then
another, and actually using about 10% of each. The overheads in download
time, interpretation/compilation time and actual execution performance
adds up to the point where the end result eventually becomes non-viable.
Taking that path leads to a known destination, and it is somewhere that
should be avoided. Browser scripting has to use another strategy; a
strategy where the units of re-use are smaller, independent and
task/context specific.
they should write their own libraries (reusable code).

There is nothing wrong with using code written by others, if it is the
right type of code for the task/context. But to see that code is the
right type, is suitable written and of sufficient qualify, a javascript
programmer is going to have to gain some practical experience of browser
scripting (preferably in the most demanding applicant; public Internet
programming). And in setting about gaining that experience they will
likely write a great deal of code that will serve as the basis of their
own collection of re-useable components. Plus they will get an insight
into the issues of browser script design and a familiarity with
strategies that can be applied to address them.

I don't really need to say, as a blanket injunction, that people should
not use monolithic general purpose javascript libraries, all I have to
do is convince them to set about learning to script web browsers well
and they will see that for themselves eventually. And that is why the
champions of the general javascript library concept are not to be found
among the regular contributors to this group; the people who have put in
the effort to learn the practice well have seen the pitfalls and learnt
how to set about applying the practical alternatives.
This is the direction we are moving towards in my
company. Up to this point I have thought it was a
good direction, at least a lot better than relying on
ASP or Java, But I am starting to see a big problem
with developing large amounts of "the most misunderstood
language" code. Stronger typed or more natural languages
(Ruby reads like english most of the time) don't need to be
wholly understood by the developer. Some of my coworkers
(experts at SQL and ASP) consider javascript to be magic.

Isn't the implication of that that the people who make (or swing) the
decisions about the use of client-side technologies should be the people
who don't understand them?

I am reminded of all the times I have been told, by people who had no
idea of how to go about doing so themselves, that designing truly
cross-browser systems would be so restrictively expensive that is could
not be worth even trying. It is a bit like asking a plumber for a quote
on the cost of hart bypass surgery.

The perverse aspect to this situation (particularly with respect to
Prototype.js) is that not only is it the people who don't have the
pertinent skills who want to be directing implementation approaches but
that what is proposed largely goes against the advice of the people who
do.
In this area of the world (New York CIty), people who
advertise themselves as Javascript gurus really mean
DHTML gurus.

I don't think anyone could justify describing themselves as the latter
without also being the former (but I would seriously distrust anyone who
labelled themselves a 'guru' anyway).

But I appreciate that problem very well. When I applied for the job I
currently have, which advertised for javascript experts, I was given a
'technical' text. A test so superficial, easy and obvious that I would
consider anyone who did not get 100% on it not even to be qualified to
write javascript, it certainly didn't approach being a test of
'expertise' in the area. It transpired that one of the reasons that I
was offered the job was that _none_ of the other candidates had done
better than 50% on that test. I have no idea how these people offering
themselves for the role of javascript expert imagined that they would do
the job, I am forced to conclude that they thought that 'expert' had
been tacked onto the job description with the same misguided motivation
that has employers asking for technically skilled web developers with
"Dreamweaver" (which is almost an oxymoron).

I am also seeing this in the London job market, where a city bank (who
will have to be unnamed due to a confidentiality agreement) have spent
at least the last 6 months attempting to employ a good javascript
developer. They advertise for a couple of days, so quiet for a month,
and then advertise the job again. Presumably each time they find
someone, and then take the next month discovering that they are not up
to the job and have to start again. It must be very expensive to
repeatedly go through that cycle, and I cannot see that they will be
making much headway on whatever project this individual is supposed to
be working on.

So I can completely appreciate that you may be finding it difficult to
lay your hands on someone who can significantly contribute to your
project. However, I don't think you will solve that problem by assuming
that the authors of some library or framework would have been that
person if you had managed to employ them directly.

Still, my advice would be that if you want to create a system that makes
more than a trivial use of client-side scripting you will really need to
find someone who has the (combined server-side and client-side) skills
and experience for the task. Granted you will have to think of some
strategy for distinguishing the people who actually have those skills
from the people who just think they have, and you will have to offer
remuneration suitable for a seller's market. Otherwise my final
suggestion at the end of this post may be the best approach to take.
Most of them have never peeked at this news group.

Which would be a pity as with browser scripting the main practical
subject of this group the bulk of what gets discussed is DHTML in
practice (even if many don't like that particular label for it).
This means, to me, that there will continue to be much
more bad javascript written than good javascript

While I don't doubt that is true I don't see that it follows from your
previous comments. Bad javascript is written because it can be written,
and written more easily than virtually any other form of computer code.
There is no requirement for any specialised software, IDE, etc, and
people can create something that superficially 'works' with no more than
any javascript book or a little searching on the Internet. A situation
that allows people to easily becomes ridiculously over-confident
javascript abilities, which then motivates them to start contributing to
the mass of publicly available copy-n-paste scripts on the Internet (and
in extreme cases creating entire libraries for the even less experienced
to shoot themselves in the foot with).
and I would furthur maintain that this is much truer
than of other languages due to javascript's exclusivity
in browsers.

On the whole it is a good thing that client-side scripting is (to all
practical purposes) limited to a single language.
What I said is that in my mind, the jury is still out on
javascript.

But you did not elucidate the charges you think it is facing, so there
is not a great deal that can be said in response to those implied
charges.
I like the Yahoo UI widget libary almost as much as ROR and
it is all client side javascript. It is also a framework
for handling AJAX and events and while it won't completely
handle "validation (while you type)", it certainly makes it
easier to implement things like that.

What I would like to see are more solid cross-browser
libraries like Yahoo UI

As it happens earlier in the week I had reason to take a look at the
Yahoo libraries, specifically the Event library (indeed one specific
method call in that library), and was slightly shocked to see how
many serious faults I observed in the tiny fraction of the code that
I was interested in.

For a start it includes a couple of instances of userAgent string based
browser detection. User Agent string based browser detection is such a
universally recognised bad practice that in the extensive discussion we
had here on how to advise people on the recognition of bad javascript
code it was one of only two practices that were agreed to be universally
indicative of code so poor that it should be rejected out of hand (i.e.
you do a text search of the source for 'userAgen' and if found you
reject the script in question and move on to the next). (The other
universally agreed indicator of bad code being the direct - eval -ing of
string literals.)

User Agent string based browser detection is a bad practice because:

1. RFC 2616 (HTTP 1.1) makes it clear that the UserAgent header is not a
source of information about the user agent (because it does not require
the header to contain any specific information, or even be consistent
over time) and as the navigator.userAgent property reflects the HTTP
header it must also not be a source of information.

2. Many browser use, by default, User Agent headers that are practically
indistinguishable from the headers used by (normally more common)
browsers, and discriminating is not practical when the input data is
identical. (It was Microsoft's introduction of UserAgent header spoofing
that forced the HTTP 1.1 specification to give the UserAgent header its
current status as something that is not a source of information, though
Microsoft appears to have not noticed the consequences of their actions
and themselves make the mistake of integrating UA header browser
'discrimination' into .NET)

1. User Agent headers are amenable to user modification in almost all
cases, including on browsers such as IE, and as the HTTP specification
does not require the header to be a source of information no criticism
can reasonably be levelled at users who modify the header (regardless of
how inconvenient that may seem to people who have already made the error
of mistaking the header for a source of information).
The practical upshot of this error in the Yahoo code is that the
libraries will not be cross-browser, the best they could aver achieve
would be to be multi-browser, and then only multi-browser where the
browsers in question were (in some respects) operated in their default
configurations. And here is something that speaks to maintenance, as
this error could be fixed but if it is everyone who has tied their
project to the library has to make an effort to take advantage (assuming
that they find out about it).

The reason that I had to look at the browser detection was because it
was used to branch into this function (theoretically for IE only, though
in reality only for IE's with near default UA strings and any browser
with an IE like UA string and no pageX/Y property on its event
objects):-

| _getScroll: function() {
| var dd = document.documentElement; db = document.body;
| if (dd && dd.scrollTop) {
| return [dd.scrollTop, dd.scrollLeft];
| } else if (db) {
| return [db.scrollTop, db.scrollLeft];
| } else {
| return [0, 0];
| }
| }

However, this code demonstrates either a lack of understanding of the
behaviour of IE browsers, or a shortfall in the application of logic on
the part of its author. IE 6+ can operate in one of two 'modes' (which
it knows a 'CSS1Compat' and 'BackCompat', all earlier IEs do the same is
IE 6+ in 'BackCompat' mode (as that is 'Back' referred to). The
arrangement with scrollTop/Left is that when in 'BackCompat' mode you
read the values form the document.body, and in 'CSS1Compat' you read
them form the document.documentElement (which does not exist prior to IE
5.0). Fortunately for this code, on IE whichever of these elements is
not reporting the actual scroll offsets of a page will report zero
values for scrollLeft/Top (rather than NaN or undefined values). This
allows the code to disregard the reported 'mode' of the browser (as
retrieved from - document.compatMode - on IE 6+) and instead deduce
that zero values imply a need to look elsewhere.

However, if a document is in 'CSS1Compat' mode and has been scrolled
horizontally but not vertically the - if (dd && dd.scrollTop) { - test
will return false (because dd.scrollTop is still zero), and so the
scrollTop/Left values will be read from the document.body element, where
both values will be zero because the page is in 'CSS1Compt' mode.

This fault is inherent in the logic of code, and I assume that the
author would not have written code that outputs erroneous values under
realistically possible conditions deliberately. So when I look at barely
16 line of code from this library and find a universally recognised bad
practice and implemented logic that will produce erroneous results under
realistic circumstances I am inclined to be seriously unimpressed, and
wonder to what extent these shortcomings manifest themselves elsewhere
in the code. I also wonder to what extent those using this code, and
recommending its use to others, appreciate its faults and limitations.
The author(s) obviously are not aware of what they have done here, else
they would have applied joined up logic to the situation.

Unfortunately for many the decision to use this code will be based upon
a trust in the source of the code (Yahoo's reputability) and the
recommendations of others, who may not be an any better position to
properly asses the library's actual code.
and individually coded javascript tasks using those libraries
and complimenting a server based framework like Rails or server
based technology like PHP-Mysql. Yes, and I guess .NET (though
it is not my idea of fun).

But is that solving problems or hiding from them; abdicating
responsibility for the quality of your products to third parties, and
third parties you are unlikely to be able to assess the skills of but
you have to trust to be doing their job properly, and properly testing
their creations. Your cited Yahoo library illustrates the shortcomings
of this approach, where the author did not perceive the hole in the
logic implemented and the QA testing applied did not expose it.

There is always the option of taking another course, and just leaving
client-side scripting alone. It certainly is not compulsory to use it
and may be better not used than used badly.

Richard.
Jul 19 '06 #24

P: n/a
pe**********@gmail.com wrote:
Richard,

Wow! Your post below* was really great. I enjoyed reading it.

The sentiment you espouse almost makes it seem like browser
scripting with JavaScript is futile or hopeless for those
that are not complete experts.
What precisely that I have said gave you that impression?
However, people need to actually finish websites in a
finite time to satisfy their customers and eat dinner.
A satisfied customer is likely to be one who has received the best
possible processional service. Customers are, of course, unlikely to be
in a position to asses the real quality of scripting work undertaken for
them, and certainly may never be aware that some 'professional' has cost
them an uncertain percentage of their potential turnover, profits, or
needlessly imposed an ongoing maintenance burden through poor script
design. The pity is that this 'professional' may not be aware that they
have done so, though worse if they did know and screwed the client
anyway.
So people look to JavaScript libraries to help
save time.
Maybe, but saving time is not necessarily the actual consequence of
using javascript libraries, nor is it the case that time cannot be saved
without using a javascript library. The main influence of a library on
script development time is that they avoid the need to write the code in
the library yourself. But they imply the need to learn how to use the
library, and understand what the code in the library actually does. They
also cannot do much about the time needed for system design, except act
to restrict the possibilities.

Other code re-use strategies also act to avoid re-writing the entire
code for a project, and a more granular approach can even facilitate a
larger proportion of code re-use, offer greater flexibility to
accommodate the most appropriate design for context of application, and
minimise (even negate) the inclusion of redundant code.

It can also avoid the issues that follow from a general library's need
to be general, and common failure to actually be general for practical
reasons. The point being that if you are going to take something from
someone else's shelf for use in your project you need it to be
sufficiently general to accommodate the context in which you want to use
it. One example may be a drag and drop library. A simple application may
be a desire to allow the user to drag a DIV about a page, while the
opposite extreme may be to transfer data/concepts/actions
from/between/to various types of object in draggable IFRAM 'windows' in
a full-on web application (something approaching the truly general
drag/drop facilities of an operating system). Any actual 'library' is
going to pitch itself somewhere in this spectrum and in doing so it will
be needlessly complex and expensive (in terms of performance) for the
lower end of the spectrum and fail to be sufficiently general for the
other end.

Another aspect of the issue of generality appears in the problem of
reporting the positions and dimensions or the representations of
elements on a page. The very simplest strategy, of summing up the
offsetTop/Left values of offsetsParents works in many context and is
sufficient for the task. Introduce borders, padding, margins, scrolling
elements, borders and padding defined on the root elements in browsers
where the root element changes depending on the rendering mode, and
attempt to be sufficiently general as to be able to report values for
TABLE elements and their contents and OL/UL and their contests, for
example, and you have a problem so huge that nobody has ever published
code that can do the job. But for a general library to genuinely offer
positioning information it is that latter problem that needs to be
solved. So libraries do not offer the full position reporting facially,
and just settle for being broadly general and accepting that they will
fail in some contexts.

My approach to the position reporting problem was to observe that there
are actually no general contexts of application and to design an
interface, implemented as an indefinite number of re-useable components
that provide the same interface but back it up with code that is context
specific, that is, it does enough to provide the required information in
any given context, and the different objects back the interface up with
different code that accommodates different contexts.

Outwardly the component is a function that is passed a reference to the
DOM element for which the position/dimension information is wanted. That
function call returns the interface, which takes the form of a function
object with properties. The code that wants to know the position of the
element is expected to hang on to this interface and re-use it. It calls
the function to have the properties of the interface updated and then it
reads the properties of the interface, including absolute top/left,
absolute inner top/left (inside the borders), width/height and the four
border dimensions.

I designed this interface after three or four examples of wanting to
know the position/dimensions of an element (the experience necessary to
know what sort of properties the interface would need to support), and
implemented the first component to facilitate it in precisely the
context in which I first needed it.

That specific context allowed for considerable optimisation, such as
knowing that the DOM structure was not going to be dynamically modified
after the component was first activated (which allows elements to know
their offsetParent from the outset instead of re-resolving it for each
calculation), the types of elements who's positions were needed did not
include the problematic set, and no elements had scrolling overflow. It
has been repeatedly re-used in subsequent projects, but obviously it is
not suited to all contexts so when a new context presents itself a new
implementation is created.

I have built up a collection of about 12 implementations of this
component. Some accommodate nested scrolling elements, some accommodate
runtime DOM manipulation, some needed to take account of BODY and HTML
padding/margins in a cross-browser way, while others where created for
browser specific Intranets and are as pared down to just what is needed
for the specific browsers. And there are permutations of contexts for
which I have not yet had to create an implementation, but for which I
could (the important pint here is that while the general problem is
almost too convoluted to be implement, any real context will eliminate
so many of the other possibilities that a solution can be implemented,
and often a very efficient one). Almost all have been re-used, some very
frequently.

Obviously this interface is employed by higher level components, and in
order to transfer those components to contexts for which they were not
specifically designed all I have to do is swap the position/dimension
reporting component for the one suited to that context (and of course
all the other similar low-level components upon which it is dependent).

By using low-level components that provide a consistent interface I am
creating code tailored to an application context (thus efficient in
terms of execution and download size) largely (70-90%) made up of
pre-created, well tested and reliable, units. A situation where I am
actually writing nothing but the application specific logic and the rest
is entirely re-used code.

My approach has all the proposed benefits of the general purpose library
concept, but side-steps almost all of the issues inherent in monolithic
libraries. However, the meat of the strategy is in the code design, the
interface design, and the 'just-in-time' creation of the re-useable
units. It is not an approach that can be delivered to a third party as a
whole. My current collection of position/dimension reporting components
could not be put forward as a general solution, it is just a
manifestation of a strategy.
And they may give up on cross-browser in favor of
multi-browser support. These decisions are pragmatic.
What do you suggest to them? Tell their clients that what
they desire is too lofty and loose the contract? Give up?
Be satisfied with multi-browser support and bugs here and
there?
I suggest the people who want to sell their services as browser script
authors should learn to be browser script authors.
There is little doubt in my mind that both an event and
an AJAX library like the Yahoo! UI libraries are a good
idea.
Didn't I mention that superficial success in scripting browsers tends to
produce an unjustified over confidence that results in people doing
considerable harm, while understanding more may make them more reticent?
Haven't we discussed the way the needlessly AJAX dependent e-commerce
site would be costing the owners a proportion of their potential income?
An instance of someone who didn't appreciate how easy it would have been
to accommodate all potential customers doing what they thought was a
good idea and doing harm as a consequence of their ignorance.

I accept your assertion of a lack of doubt but would you still be
thinking that way after you had some practice of designing truly
cross-browser systems (even if just for the exercise)? You still have
not properly thought out the question of why you cannot find people who
understand browser scripting well and support the general library
concept.

However, you have elected not to directly respond to the question of how
general a general AJAX library should be. You favoured something toward
the all 'singing and dancing' end of the spectrum, so something well
beyond the needs of the majority of real life applications or AJAX.

Of course I use a layered structure of re-useable components, ranging up
form a simple XML HTTP request object that does little more than pass
responses to call-back functions and automates aspects like aborting
pending requests when the application shuts down, with more specific
objects layered upon that. Going up to quite high level objects such as
a SOAP interface that loads WSDL files to automatically determine what
facilities will be available to the application, and layers that manages
the choreography of asynchronous responses with asynchronous user
interactions (in a number of different ways). And of course I only
include sufficient of those structures to accommodate the context of the
application.

A new, complex, context of application may need new upper layers but
will almost certainly be capable of being built upon the existing
(well-tested and reliable) lower layers, while an AJAX library that
cannot accommodate a new context can only be replaced wholesale with an
alternative, implying another learning cycle to familiarise yourself
with the code, and that is assuming that a suitable library is
available.
These are reasonable sized chunks of functionality. For
example, a developer using the Yahoo! AJAX library is
likely to use 80% of it in a website of reasonable size.
I would imagine that Yahoo use 100% of it.
It must be possible to write good, cross-browser,
reusable JavaScript libraries like these that would
pass your tests for acceptable, high-quality JavaScript
practices. Do you think this is true?
No I don't. It is possible to accumulate a considerable collection of
re-useable code (and call it a library if you like) but the notion of
including large, interdependent, generalised libraries is itself the
antithesis of good browser script design.
* I top-posted for the benefit of those without the
message archived.
You those who don't have it in their personal archives and are incapable
of looking it up on, say, google groups? For everyone else, including
those do have already read it and those who don't care it is just a
waste of bandwidth (and time/effort as they scroll down to see if any
points received specific comment.
Richard Cornford wrote:
<snip>

Please do not top post to comp.lang.javascript.

Richard.
Jul 20 '06 #25

P: n/a
Richard Cornford wrote:
My approach has all the proposed benefits of the general purpose
library concept...
One benefit it lacks is the ability to share code with others that may help
them in their situation.

If a sufficiently experienced and knowledgeable js author writes
"generalized" code to solve a problem in most contexts, this can be a great
learning tool for others who are maybe just trying to solve for a specific
context. If a person wants to take the code and trim it down to only handle
the specific case they have, they can do so.

But the vast majority (imo) of js authors lack the time, experience, and
browser test suite to truly understand and solve the complexities involved
in some cross-browser scripting. They may find a "solution" that works in a
single context and think that it will work in others, only to find that it
breaks and they don't know how to fix it.

The primary benefit of a general purpose lib, IMO, is to encapsulate all the
learning, trial-and-error, testing, and multi-browser debugging that is
required to perform many tasks. Clearly, if you know how to solve for 12
different contexts, you could combine those into a single solution that
someone else could learn from.

I'm certainly not someone who advocates writing a wrapper around everything
involved in browser scripting or learning an interface to a specific library
instead of learning the underlying concepts. While I don't use the YUI libs
and I don't recommend their use to others, I have downloaded the code and
looked at how they approached a few quirks and problems in cross-browser
scripting, and in a couple cases it was helpful. That's one benefit of the
general purpose library concept.
>[snip] you cannot find people
who understand browser scripting well and support the general library
concept.
Of course, Richard dissents from the majority opinion in this matter.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Jul 20 '06 #26

P: n/a
Matt Kruse wrote:
Richard Cornford wrote:
>My approach has all the proposed benefits of the general
purpose library concept...

One benefit it lacks is the ability to share code with
others that may help them in their situation.
No it does not. It just lacks the ability to share code without
discrimination, because if 'their' situation is not covered by an
existing component there in no code to share.
If a sufficiently experienced and knowledgeable js author
writes "generalized" code to solve a problem in most
contexts, this can be a great learning tool for others who
are maybe just trying to solve for a specific context. If
a person wants to take the code and trim it down to only
handle the specific case they have, they can do so.
And if the general case cannot be solved but the specific cases can?
While the ability to trim down the general algorithm to only what is
needed for the specific case implies the ability to recognise what is
relevant to the specific case, and so effectively knowing how to author
the specific case to start with.
But the vast majority (imo) of js authors lack the time,
experience, and browser test suite to truly understand and
solve the complexities involved in some cross-browser
scripting.
Or; are not sufficiently qualified for the job they are trying to do.
They may find a "solution" that works in a single context
and think that it will work in others, only to find that
it breaks and they don't know how to fix it.
Inevitably.
The primary benefit of a general purpose lib, IMO, is to
encapsulate all the learning, trial-and-error, testing,
and multi-browser debugging that is required to perform
many tasks.
Then why do they actually act to discourage people form learning
javascript? But while they should encapsulate QA testing that is clearly
not something that can be taken on trust, particularly when libraries as
'popular' as Yahoo and Prototype.js fail even in common browser contexts
without any indication being provided that they will do so, or evidence
that their authors are aware of the issues.
Clearly, if you know how to solve for 12 different contexts,
you could combine those into a single solution that someone
else could learn from.
We have discussed this before and you know that I think I can solve the
general case, but an not willing to write the code because the general
case would require so much code (2000-odd liens) and run so slowly, that
it would be of no practical use to anyone. The point of writing 12
different components is to address precisely the contexts for which they
were created, avoiding the need to address possibilities that where not
involved in those particular contexts. The added complexity of adding
testing and branching to accolade all of the permutations in all of the
contexts, combined with the loss of the ability to do any of the
internal optimisation that some of the components are capable of, would
make the result ridiculously big and slow. The result would be
significantly inferior if used in any of the context for which specific
components exist while not accommodating any context beyond those
already covered.
I'm certainly not someone who advocates writing a wrapper
around everything involved in browser scripting or learning
an interface to a specific library instead of learning the
underlying concepts.
<snip>
>>[snip] you cannot find people
who understand browser scripting well and support the general
library concept.

Of course, Richard dissents from the majority opinion in this
matter.
And of course Matt practices disingenuous editing of what he quotes.

Richard.
Jul 20 '06 #27

P: n/a
JRS: In article <11**********************@m73g2000cwd.googlegroups .com>
, dated Wed, 19 Jul 2006 14:09:45 remote, seen in
news:comp.lang.javascript, pe**********@gmail.com posted :
>Lines: 409
>* I top-posted for the benefit of those without the message archived.
*PLONK*

--
John Stockton, Surrey, UK. yyww merlyn demon co uk Turnpike v4.00 MIME
Web <URL:http://www.uwasa.fi/~ts/http/tsfaq.html-Timo Salmi: Usenet Q&A.
Web <URL:http://www.merlyn.demon.co.uk/news-use.htm: about usage of News.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
Jul 20 '06 #28

P: n/a
JRS: In article <e9*******************@news.demon.co.uk>, dated Thu, 20
Jul 2006 01:31:03 remote, seen in news:comp.lang.javascript, Richard
Cornford <Ri*****@litotes.demon.co.ukposted :
>
Please do not top post to comp.lang.javascript.
ISTM unwise to write only that, since if heeded it may lead to posting
such material in the other order. It needs to be accompanied by a
reference to trimming unnecessary material, and to interleaving
responses.

--
John Stockton, Surrey, UK. yyww merlyn demon co uk Turnpike v4.00 MIME
Web <URL:http://www.uwasa.fi/~ts/http/tsfaq.html-Timo Salmi: Usenet Q&A.
Web <URL:http://www.merlyn.demon.co.uk/news-use.htm: about usage of News.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
Jul 20 '06 #29

P: n/a
Hi Richard,

Richard Cornford wrote:
>
Of course I use a layered structure of re-useable components, ranging up
form a simple XML HTTP request object that does little more than pass
responses to call-back functions and automates aspects like aborting
pending requests when the application shuts down, with more specific
objects layered upon that. Going up to quite high level objects such as
a SOAP interface that loads WSDL files to automatically determine what
facilities will be available to the application, and layers that manages
the choreography of asynchronous responses with asynchronous user
interactions (in a number of different ways). And of course I only
include sufficient of those structures to accommodate the context of the
application.

A new, complex, context of application may need new upper layers but
will almost certainly be capable of being built upon the existing
(well-tested and reliable) lower layers, while an AJAX library that
cannot accommodate a new context can only be replaced wholesale with an
alternative, implying another learning cycle to familiarise yourself
with the code, and that is assuming that a suitable library is
available.
I find myself wanting to do something very similar to what you
mentioned for a few reusable drag drop components that are not intended
to solve all problems for everyone. I am thinking about having a couple
layers that can be used. Each layer adds s little more fancyness.

Do you find that with this layered design you overwrite some of the
functions in the lower layers with the new upper layers? Or do you only
add code? Or leave stub hook functions in the lower layers that can be
fleshed out in the upper layers?

It must be possible to write good, cross-browser,
reusable JavaScript libraries like these that would
pass your tests for acceptable, high-quality JavaScript
practices. Do you think this is true?

No I don't. It is possible to accumulate a considerable collection of
re-useable code (and call it a library if you like) but the notion of
including large, interdependent, generalised libraries is itself the
antithesis of good browser script design.
How would you share smaller-granularity, layered components with other
JavaScript programmers? Or do you think that type of sharing is
generally a bad idea?

Thanks,
Peter

Aug 6 '06 #30

P: n/a
pe**********@gmail.com wrote:
Richard Cornford wrote:
>>
Of course I use a layered structure of re-useable
components, ranging up form a simple XML HTTP request
object that does little more than pass responses to
call-back functions and automates aspects like aborting
pending requests when the application shuts down, with
more specific objects layered upon that. Going up to
quite high level objects such as a SOAP interface that
loads WSDL files to automatically determine what facilities
will be available to the application, and layers that
manages the choreography of asynchronous responses with
asynchronous user interactions (in a number of different
ways). And of course I only include sufficient of those
structures to accommodate the context of the application.

A new, complex, context of application may need new upper
layers but will almost certainly be capable of being built
upon the existing (well-tested and reliable) lower layers, ...

I find myself wanting to do something very similar to what
you mentioned for a few reusable drag drop components that
are not intended to solve all problems for everyone. I am
thinking about having a couple layers that can be used. Each
layer adds s little more fancyness.

Do you find that with this layered design you overwrite some
of the functions in the lower layers with the new upper layers?
Not as such. The very lowest layers tend to be very simple facility
providing objects. They are not employed in inheritance structures so
overloading their methods does not really make sense. Intermediate
layers often follow a more 'class'-like structure and do have their
methods overloaded at higher levels.
Or do you only add code?
Or leave stub hook functions in the lower layers that
can be fleshed out in the upper layers?
Looking at examples I don't find any methods that could be called
'stubs'. The methods that get overloaded seem to be methods that do
something useful at the level in which they are fist created but would
need to be doing more at a higher level.

I don't think those answers are going to be very useful to you.
Generally, (and given that the entire strategy is predicated on an
interest in the context of application) useful advice with regard to
code design issues can only be given if the subject can be rendered
concrete.
>>It must be possible to write good, cross-browser,
reusable JavaScript libraries like these that would
pass your tests for acceptable, high-quality JavaScript
practices. Do you think this is true?

No I don't. It is possible to accumulate a considerable
collection of re-useable code (and call it a library if
you like) but the notion of including large, interdependent,
generalised libraries is itself the antithesis of good
browser script design.

How would you share smaller-granularity, layered components
with other JavaScript programmers?
Who are these javascript programmers? My colleges can use the components
that I write if they have a good set of documentation for the interfaces
of the components, and given an interface specification they should (at
least some of them) be able to write a variation of the same component
for a modified context.
Or do you think that type of sharing is
generally a bad idea?
Where handing someone code results in them avoiding learning how to
write code for themselves doing so is maybe not such a good idea
(copy-and-paste javascript collection sites almost certainly do
considerably more harm than good). Where it inspires them (preferable to
do better), provides examples of approaches and techniques, and
illustrates design issues, it is probably a good idea.

Richard.
Aug 7 '06 #31

P: n/a
Richard Cornford wrote:
pe**********@gmail.com wrote:
Do you find that with this layered design you overwrite some
of the functions in the lower layers with the new upper layers?

Not as such. The very lowest layers tend to be very simple facility
providing objects. They are not employed in inheritance structures so
overloading their methods does not really make sense. Intermediate
layers often follow a more 'class'-like structure and do have their
methods overloaded at higher levels.
Or do you only add code?
Or leave stub hook functions in the lower layers that
can be fleshed out in the upper layers?

Looking at examples I don't find any methods that could be called
'stubs'. The methods that get overloaded seem to be methods that do
something useful at the level in which they are fist created but would
need to be doing more at a higher level.

I don't think those answers are going to be very useful to you.
Actually those answers are very useful.

Thank you.

Peter

Aug 8 '06 #32

This discussion thread is closed

Replies have been disabled for this discussion.