(Yet another) simple JS OO framework (by a python programmer)

[aum]

Hi,

I'm a Python programmer, just starting to get into javascript. On reading
some of the js guides, and not liking any of the OO usage patterns I saw,
I've cooked up something which python folks might find to taste.

Here's the code - first the 'engine', then some code demonstrating the
usage patterns.

For me (and maybe for some of you), it promotes readability and some
pattern similarity for classical OO languages.

Cheers
aum


*** start code ***

// this is the 'engine' of it all - usage patterns follow

Object.prototype.subclass = function(props) {

// extract 'init' function from property list, or
// use a null default function
if (props.hasOwnProperty('init')) {
constructor = props['init']
}
else {
constructor = function() {}
}

// set up inheritance
constructor.prototype = new this();

// populate prototype object with all properties except init
for (key in props) {
if (key != 'init' && key != 'subclass') {
//alert("Inheriting property '" + key + "'");
constructor.prototype[key] = props[key];
}
}

// done
return constructor;
}

// USAGE PATTERNS

// Create 'employee' class
employee = Object.subclass({

init: function(name) {
this.name = name;
},

getname: function() {
return this.name;
},

toString: function() {
return "[employee: "+this.name+"]";
}
})

// Create engineer class
engineer = employee.subclass({

init: function(name, project) {

// invoke parent initialiser
employee.apply(this, [name]);

// do local initialisations
this.project = project;
},

getproject: function() {
return this.project;
},

toString: function() {
return "[engineer: "+this.name+"(" + this.project + ")]";
}

})

// Create 'engineer's assistant' class
assistant = engineer.subclass({

init: function(name, boss) {

// invoke parent initialiser
engineer.apply(this, [name, boss.project]);

this.boss = boss
},

getboss: function() {
return this.boss;
},

toString: function() {
return "[assistant: "+this.name + " (reporting to "+this.boss+")]";
},
})

alert("Constructing employee 'fred'...");
fred = new employee("Fred Dagg")
alert("Constructing engineer 'mary'...");
mary = new engineer("Mary Smith", "Networks")

alert("Constructing assistant 'jim'...");
jim = new assistant("Jim Jones", mary)

alert("fred.name='" + fred.name + "'");
alert("fred.getname() = '" + fred.getname() + "'");

alert("mary.project='" + mary.project + "'");
alert("mary.getproject() = '" + mary.getproject() + "'");

alert("mary.name='" + mary.name + "'");
alert("mary.getname() = '" + mary.getname() + "'");

alert("jim.name='" + jim.name + "'");
alert("jim.boss='" + jim.boss.name + "'");

 

[Richard Cornford]

I'm a Python programmer, just starting to get into javascript.

Which makes you the best person to be judging how javascript should be
used?

On reading some of the js guides, and not liking any of
the OO usage patterns I saw, I've cooked up something
which python folks might find to taste.

<snip>

One of the consequences of trying to make javascript resemble other
programming languages as those rewarded by the effort tend to start
applying the expectations and pre-conceptions of that other language to
javascript, only to be ultimately disappointed. There is a great deal to
be said for people adopting a javascript mindset when they wrote
javascript.

*** start code ***

// this is the 'engine' of it all - usage patterns follow

Object.prototype.subclass = function(props) {

// set up inheritance
constructor.prototype = new this();

It seems a little perverse to be crating a property of -
Object.prototype - that can only be called in a way where the - this -
reference is a reference to a function. This would feel better if the -
subclass - method was an extension of - Function.prototype -. It would
work as well in that case, but that change would also have the advantage
of not modifying the - Object.prototype - by adding an enumerable
property. Such an adition to Object.prototype - has implications for all
uses of - for-in - loops on javascript objects, while enumerating the
properties of functions is uncommon so much less of a problem.

// populate prototype object with all properties except init
for (key in props) {

<snip>

Here - key - has not been declared as a local variable, so all
assignments to it act as assignments to a property of the global object
(effectively a global variable). This is a very bad practice. The
general programming axiom that no variable should be given more scope
than it absolutely needs is as true in javascript as it is in any other
language. And chaotic results will follow from any attempt to subclass
one object while subclassing another, as they will be sharing the -
key - variable. (That may be an improbable contingency but risk can be
eliminated entirely by decrying the variable locally)

Richard.

 

[aum]

On Sun, 17 Sep 2006 15:23:40 +0100, Richard Cornford wrote:

Firstly - thanks for your reply.

Which makes you the best person to be judging how javascript should be
used?

No way - it makes me someone who has gotten very comfortable with python,
who is feeling way out of his comfort zones with javascript, and is
wrestling with the issue of how to write code in javascript that is
similarly readable and understandable.

What I'm trying to do is render the common javascript idiom:

function Manager (name, dept) {
this.base = Employee;
this.base(name, dept);
this.reports = [];
}
Manager.prototype = new Employee;
Manager.prototype.addReport = function(employee) {
this.reports.push(employee);
}

as something I'm (presently) finding more intuitive and readable, eg:

Manager = subclass(Employee, {

init: function(name, dept) {
Employee.apply(this, [name, dept])
},
addReport: function(employee) {
this.reports.push(employee);
}
})

One of the consequences of trying to make javascript resemble other
programming languages as those rewarded by the effort tend to start
applying the expectations and pre-conceptions of that other language to
javascript, only to be ultimately disappointed.

I can understand and respect that.

I do accept that the web browser development organisations are not about
to work together to support client-side python scripting in any great
hurry, so I'm going to have to relax my cling on the python paradigm, and
figure out how to get my brain thinking javascript.

There is a great deal to
be said for people adopting a javascript mindset when they wrote
javascript.

Maybe you can recommend some websites and portals, beyond the core
language and dom guides etc, that help people from other language
backgrounds to appreciate 'javascript-flavoured reality'.

It seems a little perverse to be crating a property of -
Object.prototype - that can only be called in a way where the - this -
reference is a reference to a function.

I could just as easily implement 'subclass' as a global function accepting
as arguments the base class and a property mapping for the new class (see
below).

Here - key - has not been declared as a local variable, so all
assignments to it act as assignments to a property of the global object
(effectively a global variable).

Thanks for the correction - I was still thinking python, where variables
are local-by-default, not global-by-default. My bad.

Anyway, here's my amended implementation:

function subclass(base, props) {
var constructor, key;

// extract 'init' function from property list, or
// use a null default function
if (props.hasOwnProperty('init')) {
constructor = props['init']
}
else {
constructor = function() {}
}

// set up inheritance
constructor.prototype = new base();

// populate prototype object with all properties except init
for (key in props) {
if (key != 'init') {
constructor.prototype[key] = props[key];
}
}

return constructor;
}

As a javascript neophyte, I do throw myself open to this group for
constructive suggestions and feedback.

Cheers
aum

 

[aum]

I've written up my subclassing scheme at:

http://www.freenet.org.nz/misc/jsoo.html

Cheers
aum

 

[Richard Cornford]

Richard Cornford wrote:

Which makes you the best person to be judging how
javascript should be used?

No way - it makes me someone who has gotten very comfortable
with python, who is feeling way out of his comfort zones with
javascript, and is wrestling with the issue of how to write
code in javascript that is similarly readable and
understandable.

What I'm trying to do is render the common javascript idiom:

function Manager (name, dept) {
this.base = Employee;
this.base(name, dept);
this.reports = [];
}
Manager.prototype = new Employee;
Manager.prototype.addReport = function(employee) {
this.reports.push(employee);
}

as something I'm (presently) finding more intuitive and
readable, eg:

Manager = subclass(Employee, {

init: function(name, dept) {
Employee.apply(this, [name, dept])
},
addReport: function(employee) {
this.reports.push(employee);
}
})

And after years of javascript programming I find the former second
nature and the latter unfamiliar and obscure.

One question that has arisen when people have tried to dress javascript
up as some other language in the past is where do people who adopt these
systems go when they need help. Often they will come to
comp.lang.javascript, where they find themselves presenting code that is
unfamiliar and obscure to the people who they want answers from. But if
the question is related to the internal details of javascript there is
little point going to the authors of these systems for help, as their
intention was to avoid becoming familiar with javascript from the
outset.

Javascript is flexible enough to be bent into all sorts of shapes. As
javascript it can be enjoyed for its flexibility. Once bent into a
python-like, or pear-like, or Java-like shape there may not be the same
flexibility left.

Maybe you can recommend some websites and portals, beyond
the core language and dom guides etc, that help people
from other language backgrounds to appreciate
'javascript-flavoured reality'.

What would be wrong with reading comp.lang.javascript? You probably
cannot assume that everyone will know python but if you can explain the
concepts from python that interest you any parallels and possibilities
in javascript probably can be made clear.

I could just as easily implement 'subclass' as a global
function accepting as arguments the base class and a
property mapping for the new class (see below).

You could do that, but an extension of the - Function.prototype - object
would be the more javascript-like way of achieving what you had done. It
would also keep another function object out of the global namespace.

Thanks for the correction - I was still thinking python, where
variables are local-by-default, not global-by-default. My bad.

Doesn't that rather make my point about having to adopt a javascript
mindset to write javascript?

Where I work there are people writing Java and people writing
javascript, and a few doing both. As Java and javascript are quite
similar in syntax/structure, when we wrote the javascript coding
standards document it was agreed to adopt a block layout/indentation
structure that was deliberately distinct from the one in the existing
Java coding standards document. That was a deliberate effort to make the
two languages as visually distinct as possible, and so encourage
programmers to think Java when writing Java and think javascript when
writing javascript. That and the fact that both Java and javascript may
appear together in JSP code and then telling one form the other at a
glance is useful (in a JSP they would be subject to the same
syntax-highlighting scheme).

As a javascript neophyte, I do throw myself open to
this group for constructive suggestions and feedback.

Where 'constructive' advice may include abandoning an idea entirely
and/or starting again from scratch it may be perceived and
non-constructive. If you post here you will get what you will get.

Richard.

 

[Jake Barnes]

Hi,

I'm a Python programmer, just starting to get into javascript. On reading
some of the js guides, and not liking any of the OO usage patterns I saw,
I've cooked up something which python folks might find to taste.

Here's the code - first the 'engine', then some code demonstrating the
usage patterns.

For me (and maybe for some of you), it promotes readability and some
pattern similarity for classical OO languages.

Cheers
aum


*** start code ***

// this is the 'engine' of it all - usage patterns follow

Object.prototype.subclass = function(props) {

When Sam Stephenson initially developed the Prototype library he added
to the prototype of Object and he caught utter hell for it, for a lot
of good reasons. He later relented. He now adds to the prototype of
Array and String and most of the other types, but not Object.

More here:

http://sam.conio.net/

 

[Jake Barnes]

One question that has arisen when people have tried to dress javascript
up as some other language in the past is where do people who adopt these
systems go when they need help. Often they will come to
comp.lang.javascript, where they find themselves presenting code that is
unfamiliar and obscure to the people who they want answers from. But if
the question is related to the internal details of javascript there is
little point going to the authors of these systems for help, as their
intention was to avoid becoming familiar with javascript from the
outset.

In the end, it comes down to community, and how much support that
community can offer. If there sprang up a large, cohesive, helpful
community of people dedicated to making Javascript look like Python,
then those who wanted to do so could certainly get away with it. That
has already happened for the group that wants to make Javascript look
like Ruby. They've several large, very active forums where people can
go if they prefer to write Javascript that looks just like Ruby:

http://groups.google.com/group/rubyonrails-spinoffs?lnk=li

These folk use Prototype to give Javascript an each() method just like
Ruby, and to give Javascript associative arrays. For this crew, the
most exciting about Javascript is how much it can be made to look like
Ruby, as this article explains:

http://encytemedia.com/blog/article...eets-ruby-a-look-at-enumerable-array-and-hash

There are at this point large subgroups using Javascript that have
their own forums for dealing with their particular issues.
comp.lang.javascript seems to be overly focused on the web. During 2005
my biggest freelance gig involved automating catalog production for a
large jewelry company, using Javascript to script Adobe Photoshop and
Adobe InDesign. I relied on the Adobe forums when I had questions about
using Javascript in that space. Those questions would have seemed out
of place on comp.lang.javascript. I was dealing with the same language
but a very different API. It's a different community.

Likewise, the community that wants Javascript to look like Ruby is
setting up its own forums, because they understand that their issues
are special and may not belong on a mainstream Javascript site.

Right now, the main failing with making Javascript look like Python, is
that there is no large community supporting it. Each programmer who
goes down this road needs to find their own way. This could, of course,
change.

 

[Richard Cornford]

In the end, it comes down to community, and how much support
that community can offer.

Probably it does, but how much support can a community offer when it is
defined by a desire to avoid using javascript as such?

If there sprang up a large, cohesive, helpful community of
people dedicated to making Javascript look like Python,
then those who wanted to do so could certainly get away with it.

Being able to "get away" with something does not make it a good idea.
Indeed in web development a great deal has been gotten away with that
would not have stood up to informed scrutiny.

That has already happened for the group that wants to make Javascript
look like Ruby. They've several large, very active forums where people
can go if they prefer to write Javascript that looks just like Ruby:

http://groups.google.com/group/rubyonrails-spinoffs?lnk=li

These folk use Prototype

When people who have a good understanding of javascript and browser
scripting (which is the application of the Prototype library) reject
the use of the Prototype library (for many reasons, including it
fundamental design flaws, inherent complexity and consequential
inefficiency) the implication is that the people who support the
prototype library are relatively ignorant of javascript. The result of
an isolated group operating in relative ignorance of javascript may
just be the propagation of a story (if maybe a logically consistent
story) about javascript in place of any actual knowledge of the
subject. It is like the HTML comment-like structures in script elements
thing; such ideas propagate well beyond their usefulness, along with
mystical justifications, when there is nobody around the challenge
them.

to give Javascript an each() method just like
Ruby, and to give Javascript associative arrays. For this crew, the
most exciting about Javascript is how much it can be made to look
like Ruby, as this article explains:

And if they wanted to they could implement a full Ruby
interpreter/compiler in javascript and be in a position to write 100%
ruby to script web pages. The goal of scripting a cline with Ruby would
be completely achieved.

http://encytemedia.com/blog/article...eets-ruby-a-look-at-enumerable-array-and-hash

While a javascript centric approach to hashtables is to see when an
enumerable hashtable implementation is necessary and then include one.
The end result functionality is the same, but the efficiently is
considerably better and there are minimal knock-on effects on the rest
of the environment.

There are at this point large subgroups using Javascript that have
their own forums for dealing with their particular issues.
comp.lang.javascript seems to be overly focused on the web.

Only because the majority of the applications of javascript are
client-side in web pages. There is no reason for not discussing
javascript's use in other environments, its just a matter of people
asking answerable questions.

During 2005 my biggest freelance gig involved automating catalog
production for a large jewelry company, using Javascript to script
Adobe Photoshop and Adobe InDesign. I relied on the Adobe
forums when I had questions about using Javascript in that space.
Those questions would have seemed out of place on
comp.lang.javascript.

They may have seemed out of place, but they are not. The usefulness of
asking them depends on the question. There is certainly little value in
asking questions about the Adobe object models without referring
readers who are likely to be unfamiliar with those object models to the
pertinent documentation, but an ECMAScript implementation will still be
an ECMAScript implementation whatever object model it is scripting.

I was dealing with the same language
but a very different API. It's a different community.

Not necessarily. Javascript is designed to script differing object
models in differing environments.

Likewise, the community that wants Javascript to look like Ruby is
setting up its own forums, because they understand that their issues
are special and may not belong on a mainstream Javascript site.

They may understand their own issues (though it doesn't look like they
fully understand them to me) but they first created their own issues.

Right now, the main failing with making Javascript look like Python, is
that there is no large community supporting it.

Not that it is an inherently bad idea?

Each programmer who goes down this road needs to find their own way.

Especially when the advice they are given is not to start on that road
to begin with.

This could, of course, change.

There will never be a time when everyone wants to program javascript as
if it was python, or any other non-javascript language.

Richard.

 

[Jake Barnes]

Probably it does, but how much support can a community offer when it is
defined by a desire to avoid using javascript as such?


Being able to "get away" with something does not make it a good idea.
Indeed in web development a great deal has been gotten away with that
would not have stood up to informed scrutiny.


When people who have a good understanding of javascript and browser
scripting (which is the application of the Prototype library) reject
the use of the Prototype library (for many reasons, including it
fundamental design flaws, inherent complexity and consequential
inefficiency) the implication is that the people who support the
prototype library are relatively ignorant of javascript. The result of
an isolated group operating in relative ignorance of javascript may
just be the propagation of a story (if maybe a logically consistent
story) about javascript in place of any actual knowledge of the
subject. It is like the HTML comment-like structures in script elements
thing; such ideas propagate well beyond their usefulness, along with
mystical justifications, when there is nobody around the challenge
them.

I agree with much of what you said, but I think the people behind
Prototype are aware of the potential negative effects of using
Prototype. "Inheritance madness" is an often used phrase, by people who
like Prototype and would like to see it improved.

http://encytemedia.com/blog/articles/2006/05/23/prototype-inheritance-madness

To my mind, the most important criticism of Prototype is that it
doesn't play well with others. It breaks a lot of existing code out
there.

 

[Richard Cornford]

I agree with much of what you said, but I think the people behind
Prototype are aware of the potential negative effects of using
Prototype.

I don't believe that. The consequences of being aware would not be the
continued development of Prototype.

"Inheritance madness" is an often used phrase, by people who
like Prototype and would like to see it improved.

http://encytemedia.com/blog/articles/2006/05/23/prototype-inheritance-madness

To my mind, the most important criticism of Prototype is that it
doesn't play well with others. It breaks a lot of existing code out
there.

Playing well with other scripts is a problem inherent in libraries, and
so ultimately avoidable. I would worry more about the ludicrous
complexity, the indirection, the inflexibility and the performance
overheads. Though the thing with that is that I know what the users of
Prototype are missing, while they only know what they want from what
they have.

Richard.

 

[Jake Barnes]

Playing well with other scripts is a problem inherent in libraries, and
so ultimately avoidable. I would worry more about the ludicrous
complexity, the indirection, the inflexibility and the performance
overheads. Though the thing with that is that I know what the users of
Prototype are missing, while they only know what they want from what
they have.

Can you explain why you use the word "ludicrous"? Prototype is fairly
small, only 48k. Most of the other libraries that came out this last
year (Yahoo, dojo) are bigger. You're still referring to the
inheritance scheme, yes? I can't think of anything in Prototype that
has "complexity, the indirection, the inflexibility" unless you're
talking about the results of extending Array and other primitives using
their prototype chains.

Anyway, do you see a way forward for Javascript that doesn't involve
any libraries? I think its safe to say that the position of Javascript
in most web design firms has undergone a revolution. But I can't see
much forward progress if everyone writes everything from scratch on
each project. Even if a web design firm doesn't use Prototype or Yahoo
or Dojo or jQuery of any of the other libraries, all that will happen
instead is that they will end up using their own in-house code, that
is, their own library. And what are the chances that their own code
will get the review and testing of these big open source projects?

 

[Richard Cornford]

Can you explain why you use the word "ludicrous"?

To express negative associations. It is not realistic to expect people
who understand javascript to be in favour of authors writing code that
abandons compatibility with browsers that are still in use for no good
reason, and particularly not writing code that is not even compatible
with ECMAScript.

Prototype is fairly small, only 48k.

48K is not anywhere near small. Especially for a script that facilitates
almost nothing on its own.

Most of the other libraries that came out this last
year (Yahoo, dojo) are bigger.

Not being as bad as it could be is not the same as being good.

You're still referring to the
inheritance scheme, yes?

No, I was referring to the whole.

I can't think of anything in Prototype that
has "complexity, the indirection, the inflexibility"
unless you're talking about the results of extending Array
and other primitives using their prototype chains.

You don't think it is (needlessly) complex, indirect, inflexible and
inefficient to be passing an object into a method call as a vehicle for
its arguments (in a language that does not require an explicit set of
arguments) then to create another object to represent parameters, and
then to explicitly transfer the values of the first object onto this
second?

Anyway, do you see a way forward for Javascript that doesn't
involve any libraries?

Is "a way forward" anything more substantial than pure marketing-speak?
What do you envision changing in a way that might represent "forward"?
What is to be achieved that could be achieved but has not already been
done?

It is very easy to throw hollow phrases about but you are not saying
anything at all if they cannot be rendered concrete. There is no need for
any 'movement' (including forward) unless some very specific fault can be
identified with the status quo, and anything identified will probably
suggest the "way forward" itself.

I think its safe to say that the position of Javascript
in most web design firms has undergone a revolution.

It is certainly a statement that is vague enough to accommodate
interpretations that would be mutually exclusive.

But I can't see much forward progress if everyone writes
everything from scratch on each project.

Is code re-use your criteria for "a way forward" then? We have that now;
the choices are not libraries or writing everything from scratch.

Even if a web design firm doesn't use Prototype or Yahoo
or Dojo or jQuery of any of the other libraries, all that
will happen instead is that they will end up using their
own in-house code, that is, their own library.

That would depend a great deal on how you want to define a 'library'. The
libraries you list are (more or less) downloaded to the client in big
interrelated/interdependent chucks. An experienced javascript author will
not choose to be downloading code that is not necessary for a particular
context, and so will prefer to target code re-use at smaller,
stand-alone, units that fulfil specific requirements. The collection of
such re-useable units that results form any extended period of browser
scripting may be regarded as a 'library', but differs from the listed
examples in that it would never be a good idea to download the whole
thing to the client.

In practice web design firms rarely employ experienced javascript
authors, as software houses pay them better for their skills.

And what are the chances that their own code
will get the review and testing of these big open
source projects?

Being reviewed is not, of itself, beneficial. Prototype has been reviewed
here, with the conclusion that it is a poor implementation of a very bad
idea. Has it been changed to take accounts of that? The errors in, and
shortcomings of, the Yahoo library have been discussed here and even
passed on the those responsible, but no changes follow and none will
follow.

If people what their code reviewed they can post it here, but if they
don't intend addressing the issues raised then there is little point in
doing so.

Richard.

 

[RobG]

Can you explain why you use the word "ludicrous"? Prototype is fairly
small, only 48k.

With compiled code, generally only the used parts of a library are
included in the executable. However, with javascript code, the entire
'library' is included even if none of it is used.

In addition to the arguments provided by Richard, another reason to
avoid prototype.js is that it encourages bad programming habits - $()
is a classic example.

Some programmers use prototype.js solely for $(id). If they expect
measurable programmer performance gains by creating an alias for
document.getElementById, they should seriously consider how extensively
they are using it. I can't see that $() can provide *any* execution
performance gain, in fact it should slow things down (though likely not
measurably in most cases).

$() is not much more than a simple wrapper for
document.getElementById() and doesn't provide support for older
browsers which might have been expected.

It encourages frequent, multiple use of $() when it is likely better to
store a reference to an element once and subsequently re-use the
reference (recent tests show it is generally 2 to 3 times faster to use
the stored reference method).

It encourages developers to use $() even when they have a reference to
an element - I've never really understood why it does that, or why
programmers would use it.

Here's an example of prototype.js's bad influence: the $A() function
returns an array based on the argument passed to it. A touted benefit
is that it is a simple way of turning a node list into an array, e.g.

<script>

function showOptions(){
var someNodeList =
$('lstEmployees').getElementsByTagName('option');
var nodes = $A(someNodeList);

nodes.each(function(node){
alert(node.nodeName + ': ' + node.innerHTML);
});
}
</script>

<URL: http://www.sergiopereira.com/articles/prototype.js.html#Whatsthat
Now let's convert that to "normal" script:

function showOptions(){
var someNodeList = document.getElementById('lstEmployees').options;
for (var i=0, len=someNodeList.length; i<len; i++){
alert( 'Option ' + i + ': ' + someNodeList.text );
}
}


The first is 225 characters, the second 218. What has been gained by
using Prototype.js? Obfuscated code that is dependent on prototype.js
and requires an extra 48kB download. You'll note the programmer didn't
even take advantage of $F() to get the value of the element, instead
using innerHTML.

I guess the point is that many of the things that prototype.js does are
trivial to do directly in the code and usually require no more
keystrokes to do so. Things that take more code would likely be put
into small library functions or objects anyway (such as converting
nodeLists to arrays if that's what you really want to do on a frequent
basis).

Most of the other libraries that came out this last
year (Yahoo, dojo) are bigger. You're still referring to the
inheritance scheme, yes? I can't think of anything in Prototype that
has "complexity, the indirection, the inflexibility" unless you're
talking about the results of extending Array and other primitives using
their prototype chains.

Anyway, do you see a way forward for Javascript that doesn't involve
any libraries?

First you need to define what you mean by "a way forward for
Javascript". In terms of the language itself, there are proposals for
ECMAScript Ed 4 and JavaScript 2.0. JScript is on a path of its own,
JScript .NET already implements many features found in class-based OO
languages.

What changes would you suggest in addition, or as an alternative, to
the above?

I think its safe to say that the position of Javascript
in most web design firms has undergone a revolution. But I can't see
much forward progress if everyone writes everything from scratch on
each project.

I don't think anyone does that, but similarly there is no need to
presume that every web project requires vast slabs of javascript.

Even if a web design firm doesn't use Prototype or Yahoo
or Dojo or jQuery of any of the other libraries, all that will happen
instead is that they will end up using their own in-house code, that
is, their own library. And what are the chances that their own code
will get the review and testing of these big open source projects?

There is no reason to expect that a project based on prototype.js or
any other open library will be any better from a quality perspective
than one based purely on in-house code. Indeed, there are arguments to
the contrary, such as those presented above.

 

[Dr John Stockton]

JRS: In article <[email protected]>,
dated Thu, 28 Sep 2006 00:35:50 remote, seen in

With compiled code, generally only the used parts of a library are
included in the executable. However, with javascript code, the entire
'library' is included even if none of it is used.

AFAIK, "library" is not a defined term in Javascript, HTML, or browsers.

One must distinguish carefully between those two types of Javascript
library, since both are available.



One is the file, or maybe set of files, incorporated in a Web page by
code such as
<script type="text/javascript" src="include1.js"></script>
- the whole of include1.js is downloaded to each user, though it may be
shared between pages and/or cached.

Such a library should only be used if a reasonable proportion of the
contents can be expected to benefit the average usage of the page.



The other is a collection of subroutines and other code fragments that a
page author can copy items from for putting in his own pages or include
files. The need for such a library is that a typical page author
consulting it benefits from the consultation - so if it is well-
organised and indexed and spread over an appropriate [Web/book] page
structure, it's total size should be only of interest to its own author
and his hosting service.

The latter is analogous to libraries for compiled languages, where only
the required parts contribute to the distributed executable.



Any large code collection should take the second form.



Of course, it's hard to define "large", "reasonable", etc.; but the
principle should be borne in mind.



Patch :
Lines[J] = (Line ? SS + Line : "") } // Indent the Line