Why should I eschew prototype.js?
nolo contendere
scriptaculous, and found both very helpful in developing web pages
with lots of pop. Modal boxes, SlideUp/Down, calendars, etc.
I've also recently ramped up my lurking and participation in this
newsgroup. There are some who advocate using prototype, and others who
are adamantly opposed to it. Are there any concrete reasons why I
should NOT use it? Is it inefficient? It seems that today's computers
have sufficient processing power to overcome most slowly implemented
solutions in javascript. And the benefits of being able to inject such
a wide variety of effects into a page (to me) far outweigh any harm.
Gregor Kofler
> Are there any concrete reasons why I
> should NOT use it?
Since it won't foster any understanding of proper JavaScript programming
(or even use).
You'll run into problems sooner or later (because you'll combine
prototype with mooTools and jQuery and throw in another "framework" for
good measure, and all those "frameworks" have their individual
shortcomings).
You will end up asking another one of those "my this-or-that form
element doesn't work the way I expect it, why?" questions.
And all the advice you'll get, is to look for help elsewhere.
Gregor
--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum
nolo contendere
> nolo contendere meinte:
>
> > Are there any concrete reasons why I
> > should NOT use it?
>
> Since it won't foster any understanding of proper JavaScript programming
> (or even use).
>
> You'll run into problems sooner or later (because you'll combine
> prototype with mooTools and jQuery and throw in another "framework" for
> good measure, and all those "frameworks" have their individual
> shortcomings).
> You will end up asking another one of those "my this-or-that form
> element doesn't work the way I expect it, why?" questions.
>
> And all the advice you'll get, is to look for help elsewhere.
This argument can be applied to any library of functions. The harm
here is that by not using a library, one must constantly reinvent the
wheel. If I get a job as a front-end developer, I'll likely inherit
some code. Whether the code was homebrewed by the previous developer,
or adopted by him/her, it's possible that coding I do for projects
going forward will conflict with this library, and I'll have to debug.
At least with a library that is more widely adopted, and for which
there is some documentation, I'll have better tools and more resources
for doing that debugging.
As far as not fostering understanding of Javascript, that's not what
libraries are for. It's my responsibility as a developer to learn the
language.
I can definitely see your point that it could be a crutch though, and
could enable bad programming practices as well as laziness in
understanding the language. If that's the primary disadvantage, I
won't worry about it. I've just seen in some poster's tags that
prototype was written by people who don't understand javascript, but
there was no evidence to support that claim.
Thanks for your response.
Gregor Kofler
> As far as not fostering understanding of Javascript, that's not what
> libraries are for. It's my responsibility as a developer to learn the
> language.
Discussing the *use* of JS libraries is not the focus of clj.
> I can definitely see your point that it could be a crutch though, and
> could enable bad programming practices as well as laziness in
> understanding the language. If that's the primary disadvantage, I
> won't worry about it. I've just seen in some poster's tags that
> prototype was written by people who don't understand javascript, but
> there was no evidence to support that claim.
Google might help - the problems (or - for some - the lack of these)
with these frameworks have been discussed in this NG several times.
Thomas 'PointedEars' Lahn
> [...] There are some who advocate using prototype, and others who
> are adamantly opposed to it.
You will observe the individuals who recommend against Prototype.js usually
to be more knowledgeable about the language(s) than the individuals who
recommend in favor of it. That should account for something.
> Are there any concrete reasons why I should NOT use it? Is it inefficient?
Yes.
> It seems that today's computers have sufficient processing power
> to overcome most slowly implemented solutions in javascript.
You are mistaken. First-world high-end computers and Internet connections
are not the standard to develop for on the Web, at least they should not be.
Besides, efficience is not restricted to runtime efficience, and efficience
is one of the lesser problems with Prototype.js.
> And the benefits of being able to inject such a wide variety of effects
> into a page (to me) far outweigh any harm.
The harm comes from another direction.
Ceterum censeo Prototype.js esse delendam.[1]
PointedEars
___________
[1] Belated thanks to Evertjan. who by his correction put me on track
to find out that the English verb "(to) delete" is derived from
the Latin verb "deleo" ([to] destroy).
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
nolo contendere
> nolo contendere meinte:
>
> > As far as not fostering understanding of Javascript, that's not what
> > libraries are for. It's my responsibility as a developer to learn the
> > language.
>
> Discussing the *use* of JS libraries is not the focus of clj.
I suppose not--as i stated previously, I'm new here. However, just
because it's not the focus doesn't mean that there can't be ancillary
discussions about it.
>
> > I can definitely see your point that it could be a crutch though, and
> > could enable bad programming practices as well as laziness in
> > understanding the language. If that's the primary disadvantage, I
> > won't worry about it. I've just seen in some poster's tags that
> > prototype was written by people who don't understand javascript, but
> > there was no evidence to support that claim.
>
> Google might help - the problems (or - for some - the lack of these)
> with these frameworks have been discussed in this NG several times.
Did so.
I had not realized prototype.js was such a hot topic, or that just by
bringing it up I might invite myself to being viewed with immediate
hostility, or, at best, a standoffish neutrality rather than with a
friendly smile and an offer of a helping hand. Still, better than what
some newbies get at c.l.perl.misc...;-)
After reviewing some threads about this subject, I discovered an
enlightening one:
http://tinyurl.com/yps5l9
Thanks.
Gregor Kofler
> I had not realized prototype.js was such a hot topic,
I'd say it is anything but "hot" on clj.
> or that just by
> bringing it up I might invite myself to being viewed with immediate
> hostility, or, at best, a standoffish neutrality rather than with a
> friendly smile and an offer of a helping hand.
People using prototype are rarely interested in writing their own
scripts, particularly writing them properly. However, that's what a lot
of people reading clj want to do. I once got in touch with prototype
about two years ago - the size of library and the then complete lack of
documentation drove me to writing my own lean libraries.
> Still, better than what
> some newbies get at c.l.perl.misc...;-)
That's usenet. If you want to be caressed you have to resort to web
forums, I suppose.
nolo contendere
> nolo contendere meinte:
>
> > I had not realized prototype.js was such a hot topic,
>
> I'd say it is anything but "hot" on clj.
>
s/hot/hot button/
s0lnic
> Are there any concrete reasons why I
> should NOT use it?
No, there aren't, unless you're able to write something better then
jQuery/Prototype/YUI/Mojo/whatever or you just want to have your own
library and you have enough time to do this. If you're creating webapps
with a rich UI then you definitely need a JavaScript library.
> Is it inefficient?
No, it's not.
--
# Regards || piotr[.]solnica[at]gmail[.]com || jid : s0l...@jabster.pl #
# s0lnic || http://blog.solnic.in5.pl || icq : 385935391 #
Thomas 'PointedEars' Lahn
> nolo contendere wrote:
>> Are there any concrete reasons why I
>> should NOT use it?
>
> No, there aren't, unless you're able to write something better then
> jQuery/Prototype/YUI/Mojo/whatever
Almost anyone is able to write something better than those, with *maybe*
the exception of YUI.
> or you just want to have your own library and you have enough time
> to do this.
That is an entirely different matter, of course.
> If you're creating webapps with a rich UI then you definitely need
> a JavaScript library.
But not necessarily a library written by people who don't have a clue
about what they are doing.
PointedEars, with a fitting random signature
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>
nolo contendere
> nolo contendere wrote:
> > Are there any concrete reasons why I
> > should NOT use it?
>
> No, there aren't, unless you're able to write something better then
> jQuery/Prototype/YUI/Mojo/whatever or you just want to have your own
> library and you have enough time to do this. If you're creating webapps
> with a rich UI then you definitely need a JavaScript library.
>
> > Is it inefficient?
>
> No, it's not.
Thanks Piotr. That's the second time you've helped me :-).
Thomas 'PointedEars' Lahn
Blind leading the blind.
PointedEars
--
"Use any version of Microsoft Frontpage to create your site. (This won't
prevent people from viewing your source, but no one will want to steal it.)"
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>
Matt Kruse
> There are some who advocate using prototype, and others who
> are adamantly opposed to it.
There are a few long threads (one recently) about the concept of
libraries and philosophies about how javascript should be developed.
People usually fall somewhere in the spectrum between "use a library
like prototype and do it all that way" and "never use a general-
purpose library - write your own code to meet the requirement at
hand".
Where you land depends a lot on your javascript knowledge and
experience, your goals, priorities, and context. If you are
comfortable with the idea of using a general-purpose library, then
that whole discussion can be tabled and instead you can focus on which
library you should use and how you should best use it.
> Are there any concrete reasons why I
> should NOT use it?
Stylistic preferences would be one. I don't like its emphasis on
classes, inheritance, etc. For me, the API is too large and complex -
it tries to do more than I want it to. And I found it hard to use to
just add some quick effects or helper functions to an existing page.
I've never looked into the internals to judge it technically.
> Is it inefficient?
Certainly more inefficient than using core DOM functions and built-in
javascript functionality. But probably not enough to make a difference
in most cases. If you get into heavy UI stuff, general-purpose
libraries tend to slow down, in my experience.
> It seems that today's computers
> have sufficient processing power to overcome most slowly implemented
> solutions in javascript.
Depends on your target audience.
> And the benefits of being able to inject such
> a wide variety of effects into a page (to me) far outweigh any harm.
Again, it comes back to your requirements and priorities. If you want
to support as many users and browsers as possible, trying to create a
slick client-side UI with lots of effects and stuff will kill some
people.
I think it's best to read the arguments on both sides to become more
informed. Then consider all the factors in front of you and come to
your own conclusion about whether a javascript library will be helpful
to you.
Matt Kruse
nolo contendere
> On Nov 12, 9:44 am, nolo contendere <simon.c...@fmr.com> wrote:
>
---8<---snip--->8--
> > And the benefits of being able to inject such
> > a wide variety of effects into a page (to me) far outweigh any harm.
>
> Again, it comes back to your requirements and priorities. If you want
> to support as many users and browsers as possible, trying to create a
> slick client-side UI with lots of effects and stuff will kill some
> people.
True, but you can't please all the people all the time. I'm testing
out my code in IE 6, FF 2.0, and Safari 3. That covers enough area for
me. Also, this is an internal site, so I can be reasonably sure of the
consistency and specs of the machines that will be used to view the
site.
>
> I think it's best to read the arguments on both sides to become more
> informed. Then consider all the factors in front of you and come to
> your own conclusion about whether a javascript library will be helpful
> to you.
Sage advice for any topic.
>
> Matt Kruse
During the course of my research into the original question, your name
popped up a few times. I checked out your site, and also noticed that
the clj FAQ guy, Randy, had your Best Practices link in his sig. I
don't know too much about your credentials, but you at least seem to
try to help people rather than latch on to some trivial technicality
or misspelling or minutia and harp on it, for which you get my
respect.
I also noticed that you wrote several Google Gadgets--they look pretty
neat, although the target audience seems to be pretty advanced users
(read: hard-core geeks). By this I mean that the gadgets are very
customizable, which is a good thing, but the number of configuration
options may dissuade it's adoption by the general masses.
Anyway, thanks for your input. It was constructive.
Matt Kruse
> I also noticed that you wrote several Google Gadgets--they look pretty
> neat, although the target audience seems to be pretty advanced users
> (read: hard-core geeks). By this I mean that the gadgets are very
> customizable, which is a good thing, but the number of configuration
> options may dissuade it's adoption by the general masses.
True, but I wrote them all for my own use. My iGoogle page is heavily
customized and filled with tons of feeds and info. I make the gadgets
available to the world because I never know who might find them
useful :)
Matt Kruse
nolo contendere
aahh...I thought you might be trying for the Google Gadget Venture:
http://www.google.com/gadgetventures/
Gregor Kofler
> True, but you can't please all the people all the time. I'm testing
> out my code in IE 6, FF 2.0, and Safari 3. That covers enough area for
> me.
It's not a compatibility issue (at least with a decent library) -
webpages should always provide a fallback for people without JS. JS for
the eye-candy and the enhanced usability, but not for the core
functionality, but then...
> Also, this is an internal site, so I can be reasonably sure of the
> consistency and specs of the machines that will be used to view the
> site.
...YMMV.
s0lnic
>> Thanks Piotr. That's the second time you've helped me :-).
>
> Blind leading the blind.
Why? There are no perfect tools, I'm sure you know that. Prototype helps me
a lot in my everyday work, there are many things which bugs me, but it's
getting better and better. I don't have any serious problems with it, its
current http://www.prototypejs.org/api is very useful, its performance is
just fine, it resolves many common crossbrowser issues which every web
developer has to deal with (sooner or later). I started using Prototype
about 1.5 year ago, before that I was writing all my JavaScript without a
use of any other library and it was sometimes really painful (back then
IE5.5 had to be supported ;P). Maybe you, JavaScript masters with zillions
years of experience, have better alternatives, maybe you have written your
very own libraries, which are better then anything else - good for you
then! I wish I had enough time to do the same, but I don't and I'm using
what's available, and Prototype IS a good option, maybe other libs are
better (jQuery looks very promising), I don't know, haven't used them in
any real project yet. The fact is that I DID use Prototype and there are
MANY working applications which are based on Prototype, and you know what?
People use these apps, and they really like them, so what's the problem?
No, stop, don't answer - Prototype creators don't know what they are doing,
they know sh*t about JavaScript, this library should be destroyed.
Whatever, man.
Cheers and EOT
Randy Webb
> I've recently begun playing with prototype.js as well as
> scriptaculous, and found both very helpful in developing web pages
> with lots of pop. Modal boxes, SlideUp/Down, calendars, etc.
What you call "lots of pop" can be very annoying to some people though.
And that has nothing to do with Prototype.js in particular. What you are
going to find in this group is that you can't get two people here to
agree on anything.
> I've also recently ramped up my lurking and participation in this
> newsgroup. There are some who advocate using prototype, and others who
> are adamantly opposed to it. Are there any concrete reasons why I
> should NOT use it?
The major problem, lately, with prototype.js is people asking here "Why
doesn't it work?" and Peter Michaux has been posting the best answer to
those questions. It is no different than trying to ask in a C++ group
why a program written in C++ doesn't "work". The only difference is one
is open source and one isn't.
In contrast, if someone posts a question along the lines of "This is how
prototype.js does it, is there a better way?" (or similar) then it would
appropriate here.
Why you should, or shouldn't, use it is a decision that you have to
make. Whether it satisfies your needs or not. And, what your end goals
are. If your goal is simply to get something on the web without ever
wanting to learn more, and it satisfies your needs, then use it.
> Is it inefficient?
I can't, and so I won't, comment on that. I have not looked at the
prototype code in a very long time.
> It seems that today's computers have sufficient processing power to
> overcome most slowly implemented solutions in javascript.
That is a backwards issue that has been in computing for over 30 years.
"I don't have to write efficient code because computers are fast enough
to compensate for it."
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
nolo contendere
> nolo contendere said the following on 11/12/2007 10:44 AM:
>
>
> > It seems that today's computers have sufficient processing power to
> > overcome most slowly implemented solutions in javascript.
>
> That is a backwards issue that has been in computing for over 30 years.
> "I don't have to write efficient code because computers are fast enough
> to compensate for it."
>
Sure, taken to either extreme, the efficiency of code can either be
the most or least important thing. Practically speaking, it doesn't
make sense to spend years profiling and tuning code to get the
absolute best performance out of it. And yet it also doesn't make
sense to use algorithms that are O(n^3) or worse. I didn't mean to
blithely assert that I can be lazy and not have to consider the
performance of my code, I was looking at it more from an order of
magnitude scope. My earlier question could have been better phrased
"Would using prototype.js rather than the native DOM/javascript
functions impose a cost that would be orders of magnitudes greater?".
If not, then I wouldn't want to spend time micro-optimizing.
I have some expertise in Perl, and like to write efficient code, but I
realize that if performance was THE most important factor, I wouldn't
write code in Perl.
Richard Cornford
> I've recently begun playing with prototype.js as well as
> scriptaculous, and found both very helpful in developing
> web pages with lots of pop. Modal boxes, SlideUp/Down,
> calendars, etc.
>
> I've also recently ramped up my lurking and participation
> in this newsgroup. There are some who advocate using prototype,
Here?
> and others who are adamantly opposed to it. Are there any
> concrete reasons why I should NOT use it?
Lots, but I don't have time to go through all of them right now.
However, one good illustration is the least you deserve.
Take this code form the latest (1.6.0) version of Prototype.js:-
| var Hash = Class.create(Enumerable, (function() {
| if (function() {
| var i = 0, Test = function(value) { this.key = value };
| Test.prototype.key = 'foo';
| for (var property in new Test('bar')) i++;
| return i > 1;
| }()) {
| function each(iterator) {
| var cache = [];
| for (var key in this._object) {
| var value = this._object[key];
| if (cache.include(key)) continue;
| cache.push(key);
| var pair = [key, value];
| pair.key = key;
| pair.value = value;
| iterator(pair);
| }
| }
| } else {
| function each(iterator) {
| for (var key in this._object) {
| var value = this._object[key], pair = [key, value];
| pair.key = key;
| pair.value = value;
| iterator(pair);
| }
| }
| }
| ...
- What this appears to represent is the conditional creation of a
function based upon (rather complex) test. But in ECMAScript terms this
is actually one big syntax error, because inside each of the
BlockStatement branches of the - if-else - there are what appear to be
function declarations, and BlockStatemen may only contain Statements
(not FunctionDeclarations (FunctionDeclarations and Statements being the
two distinct syntactic units from which ECMAScript Programs and function
bodies are constructed)).
Obviously if the 3 or 4 browsers with which Prototype.js 'works'
actually generated a syntax error that fact would have been noticed, so
what is happening? The first part of the answer is that JavaScript(tm)
has a non-standard syntax extension that is a FunctionStatement, which
(being a Statement) may appear inside a BlockStatement and can be
conditionally evaluated. ECMAScript allows for such extensions, though
they usually must be avoided when creating cross-browser code. The
second part of the answer is that JScript (and many other ECMAScript
implementations, including Opera's) are tolerant enough to
unconditionally treat these out of context 'FunctionDeclarations' as
FunctionDeclarations. But because FunctionDeclarations are processed
during variable instantiation, before any actual code execution, in
these environments the effect of the above is the equivalent of:-
var Hash = Class.create(Enumerable, (function() {
function each(iterator) {
for (var key in this._object) {
var value = this._object[key], pair = [key, value];
pair.key = key;
pair.value = value;
iterator(pair);
}
}
function each(iterator) {
var cache = [];
for (var key in this._object) {
var value = this._object[key];
if (cache.include(key)) continue;
cache.push(key);
var pair = [key, value];
pair.key = key;
pair.value = value;
iterator(pair);
}
}
if (function() {
var i = 0, Test = function(value) { this.key = value };
Test.prototype.key = 'foo';
for (var property in new Test('bar')) i++;
return i > 1;
}()) {
} else {
}
...
- Where the first - each - FunctionDeclaration results in the creation
of a function object and the assignment of a reference to that function
to the 'each' property of the variable object, and then the second -
each - FunctionDeclaration - results in the creation of a second
function object which is then assigned to the 'each' property of the
variable object, replacing the first. So in these environments it is the
second FunctionDeclaration that defines 'each', unconditionally, and
the - if-else - statement is effectively empty, making its execution
worthless.
Now if this code 'works' at all it 'works' mostly by coincidence as it
is relying on a non-standard extension wherever the - if-else - is
effective, and where the FunctionDeclaration are unconditionally acted
upon the result must only 'work' due to the order in which the two
declarations appear.
Of course the conditional creation of function objects is trivial in
javascript in a way that fully conforms with the ECMAScript
specification, and so in a way that can be expected to be fully
cross-browser and consistently executed in ECMA 262 3rd Ed. implementing
environments. Such code would be something like:-
var Hash = Class.create(Enumerable, (function() {
var each;
if (function() {
var i = 0, Test = function(value) { this.key = value };
Test.prototype.key = 'foo';
for (var property in new Test('bar')) i++;
return i > 1;
}()) {
each = function (iterator) {
var cache = [];
for (var key in this._object) {
var value = this._object[key];
if (cache.include(key)) continue;
cache.push(key);
var pair = [key, value];
pair.key = key;
pair.value = value;
iterator(pair);
}
}
} else {
each = function (iterator) {
for (var key in this._object) {
var value = this._object[key], pair = [key, value];
pair.key = key;
pair.value = value;
iterator(pair);
}
}
}
...
- replacing the 'syntax error' FunctionDeclaration with Expression
Statements where a Function Expression is assigned to an Identifier. The
result is fully ECMAScript standard and so will 'work' consistently in
all past, present and future ECMA 262 3rd Ed. conforming
implementations.
It is simply the case that anyone knowing javascript would have written
the original code in this final form. So would not be writing code that
functioned purely by coincidence but instead they would be programming.
The problem with the way this sort of ignorance of javascript results in
code that only works by coincidence is highlighted by browsers like
Opera. Opera currently acts like JScript, and unconditionally acts on
the FunctionDeclarations out of their (otherwise syntax error) context
but while Opera has an ECMA 262 conforming javascript implementation,
they also aim to emulate JavaScript(tm), and so may introduce
JavaScript(tm)'s FunctionStatement extension at any moment. And so code
that works by coincidence because of the order of the
'FunctionDeclarations' may find itself suddenly conditionally evaluating
FunctionStatements with any next version of Opera, and what these
branches do in that versions of Opera may be totally inappropriate.
The Prototype.js approach results in code that cannot be expected to
work in any more browsers than those in which it has been demonstrated
to 'work', and so cannot even be expected to 'work' with the future
versions of that those browsers. This cannot be a viable approach to
creating cross-browser code, and it does not.
That is quite a bit of writing in order to demonstrate that the authors
of Prototype.js don't know javascript. Similar demonstrations are
possible for bad design, ridiculous inefficiencies, avoidable bad
practices and much else besides, but I don't have time right now so you
will have to look them up in the archive.
> Is it inefficient?
The code itself is about a quarter as efficient as it could be, but
certain aspects of the design promote its extremely inefficient use, so
examples you will see are often orders of magnitude worse than that.
Fast computers mitigate that problem, but you would find systems created
with Prototype.js become unacceptably sluggish at much lower levels of
complexity.
> It seems that today's computers have sufficient processing
> power to overcome most slowly implemented solutions in
> javascript.
Maybe, but that doesn't stop my boss continually wanting the client-side
code our web applications to run faster. He maintains that they are
easier to sell when they are fast, and then that they are easier to sell
if they have ever more bells and whistles. Obviously those are
contradictory demands.
> And the benefits of being able to inject such
> a wide variety of effects into a page (to me) far
> outweigh any harm.
At least for as long as you avoid understanding how those effects work,
and so how trivial they are to create for yourself.
Richard.
nolo contendere
wrote:
> nolo contendere wrote:
> > I've recently begun playing with prototype.js as well as
> > scriptaculous, and found both very helpful in developing
> > web pages with lots of pop. Modal boxes, SlideUp/Down,
> > calendars, etc.
>
> > I've also recently ramped up my lurking and participation
> > in this newsgroup. There are some who advocate using prototype,
>
> Here?
>
In this very thread in fact.
> > and others who are adamantly opposed to it. Are there any
> > concrete reasons why I should NOT use it?
>
> Lots, but I don't have time to go through all of them right now.
> However, one good illustration is the least you deserve.
>
I appreciate it.
Why has a library not been written this way? Obviously it's not your
responsibility to do it, or to even know the reason why it hasn't been
done thus far, but if so many people are in error, and it causes you
any distress, it would behoove you to write one, or at least begin
one. Perhaps set up a project? Clearly you care a lot about this
subject, and have invested much time in it. This is just another
avenue by which you can participate in -- and even shape -- the future
of how javascript is used.
> It is simply the case that anyone knowing javascript would have written
> the original code in this final form. So would not be writing code that
> functioned purely by coincidence but instead they would be programming.
>
> The problem with the way this sort of ignorance of javascript results in
> code that only works by coincidence is highlighted by browsers like
> Opera. Opera currently acts like JScript, and unconditionally acts on
> the FunctionDeclarations out of their (otherwise syntax error) context
> but while Opera has an ECMA 262 conforming javascript implementation,
> they also aim to emulate JavaScript(tm), and so may introduce
> JavaScript(tm)'s FunctionStatement extension at any moment. And so code
> that works by coincidence because of the order of the
> 'FunctionDeclarations' may find itself suddenly conditionally evaluating
> FunctionStatements with any next version of Opera, and what these
> branches do in that versions of Opera may be totally inappropriate.
>
So this is the browser's problem. They are too permissive. But if you
think about it, if 90% of people do something one way, and that way
doesn't conform to "the standard" (in this case, ECMA), doesn't the
way most people do it BECOME the standard? It may be horrific in its
implementation, syntax, whatever, but so is HTTP. So you either adapt
and use it, or try to make change.
> The Prototype.js approach results in code that cannot be expected to
> work in any more browsers than those in which it has been demonstrated
> to 'work', and so cannot even be expected to 'work' with the future
> versions of that those browsers. This cannot be a viable approach to
> creating cross-browser code, and it does not.
>
Again, this may be the browser's fault then. Bear in mind that browser
developers do have to cater to existing web pages, and have all sorts
of testing to try to ensure that nothing breaks in future versions. I
highly doubt that just because a page doesn't conform to ECMA
standards, the browser developers will say "screw that web page, if
they don't follow ECMA they don't get a proper rendering in our
browser." This may work if the percentage of "bad" web pages were
vanishingly small, but hey, this is the real world where people are
stupid and market share is of vital importance to a browser's
continued existence. I'm not saying I'm encouraging bad coding, or
stupidity, but I'm being a realist. Once all market share is captured,
THEN you can begin to gradually enforce whichever standards are the
best. But until then, it's a free-for-all.
> That is quite a bit of writing in order to demonstrate that the authors
> of Prototype.js don't know javascript. Similar demonstrations are
> possible for bad design, ridiculous inefficiencies, avoidable bad
> practices and much else besides, but I don't have time right now so you
> will have to look them up in the archive.
>
I truly do appreciate your perspective. I did a little research on
you, and you appear to be a very intelligent individual, although (and
I don't mean to be destructively critical) a bit of an idealist/
purist--which the world does need, but isn't the way the world works.
> > Is it inefficient?
>
> The code itself is about a quarter as efficient as it could be, but
> certain aspects of the design promote its extremely inefficient use, so
> examples you will see are often orders of magnitude worse than that.
> Fast computers mitigate that problem, but you would find systems created
> with Prototype.js become unacceptably sluggish at much lower levels of
> complexity.
>
> > It seems that today's computers have sufficient processing
> > power to overcome most slowly implemented solutions in
> > javascript.
>
> Maybe, but that doesn't stop my boss continually wanting the client-side
> code our web applications to run faster. He maintains that they are
> easier to sell when they are fast, and then that they are easier to sell
> if they have ever more bells and whistles. Obviously those are
> contradictory demands.
>
> > And the benefits of being able to inject such
> > a wide variety of effects into a page (to me) far
> > outweigh any harm.
>
> At least for as long as you avoid understanding how those effects work,
> and so how trivial they are to create for yourself.
Again, if they are so trivial, why wouldn't a "good" library have been
written? Wouldn't evolution cause the "good" librarues to bubble up
and become the de facto standard? Wouldn't "bad libraries" break in
future revs, independent browsers, etc, and the "good libraries" gain
mind- and market-share with each manifestation of the "bad
libararies'" failure?
Gregor Kofler
> Again, this may be the browser's fault then. Bear in mind that browser
> developers do have to cater to existing web pages, and have all sorts
> of testing to try to ensure that nothing breaks in future versions.
You know what? There are websites (not conforming to standards, sure),
wich looked perfectly ok on IE6, but break more or less seriously on IE7.
> I highly doubt that just because a page doesn't conform to ECMA
> standards, the browser developers will say "screw that web page, if
> they don't follow ECMA they don't get a proper rendering in our
> browser." This may work if the percentage of "bad" web pages were
> vanishingly small, but hey, this is the real world where people are
> stupid and market share is of vital importance to a browser's
> continued existence. I'm not saying I'm encouraging bad coding, or
> stupidity, but I'm being a realist. Once all market share is captured,
> THEN you can begin to gradually enforce whichever standards are the
> best. But until then, it's a free-for-all.
Websites all break in different ways. It's impossible to care about all
of them.
> I truly do appreciate your perspective. I did a little research on
> you, and you appear to be a very intelligent individual, although (and
> I don't mean to be destructively critical) a bit of an idealist/
> purist--which the world does need, but isn't the way the world works.
What's your point? You're looking for points against prototype, but
whenever points follow you dismiss them with empty statements.
> Again, if they are so trivial, why wouldn't a "good" library have been
> written?
Perhaps mine *could* be better. But I don't want to put in all the
effort needed for proper testing and documentation. And I deem those
things important, when publicising a library (contrary to the prototype
authors). Other authors might have similar or other reasons.
> Wouldn't evolution cause the "good" librarues to bubble up
> and become the de facto standard? Wouldn't "bad libraries" break in
> future revs, independent browsers, etc, and the "good libraries" gain
> mind- and market-share with each manifestation of the "bad
> libararies'" failure?
I suppose that's the reason, why the least standards compliant browser
has the marginal market share of, say, 80 percent?
nolo contendere
> nolo contendere meinte:
>
> > Again, this may be the browser's fault then. Bear in mind that browser
> > developers do have to cater to existing web pages, and have all sorts
> > of testing to try to ensure that nothing breaks in future versions.
>
> You know what? There are websites (not conforming to standards, sure),
> wich looked perfectly ok on IE6, but break more or less seriously on IE7.
Of course, I'm saying that the future versions of browsers would make
the attempt to break as few sites out there as possible. If the
majority of sites DON'T conform to ECMA standards, the deveoplers will
cater towards THAT first, and not the standards.
>
> > I highly doubt that just because a page doesn't conform to ECMA
> > standards, the browser developers will say "screw that web page, if
> > they don't follow ECMA they don't get a proper rendering in our
> > browser." This may work if the percentage of "bad" web pages were
> > vanishingly small, but hey, this is the real world where people are
> > stupid and market share is of vital importance to a browser's
> > continued existence. I'm not saying I'm encouraging bad coding, or
> > stupidity, but I'm being a realist. Once all market share is captured,
> > THEN you can begin to gradually enforce whichever standards are the
> > best. But until then, it's a free-for-all.
>
> Websites all break in different ways. It's impossible to care about all
> of them.
>
> > I truly do appreciate your perspective. I did a little research on
> > you, and you appear to be a very intelligent individual, although (and
> > I don't mean to be destructively critical) a bit of an idealist/
> > purist--which the world does need, but isn't the way the world works.
>
> What's your point? You're looking for points against prototype, but
> whenever points follow you dismiss them with empty statements.
No, I don't dismiss them. I appreciate the points. My argument is that
however wonderful the vision is of a completely standards compliant
web, reality differs. It's pointless to rail against something one
deems "bad", and not do anything about it. Either adapt, or strive to
improve it. Here, Robert does strive to improve it a little by
engaging in this discussion, but his efforts would be more fruitful
simply to come up with a better library.
>
> > Again, if they are so trivial, why wouldn't a "good" library have been
> > written?
>
> Perhaps mine *could* be better. But I don't want to put in all the
> effort needed for proper testing and documentation. And I deem those
> things important, when publicising a library (contrary to the prototype
> authors). Other authors might have similar or other reasons.
So by saying that you need all that effort, you are contradicting the
statement that it is trivially easy. You can't have it both ways.
>
> > Wouldn't evolution cause the "good" librarues to bubble up
> > and become the de facto standard? Wouldn't "bad libraries" break in
> > future revs, independent browsers, etc, and the "good libraries" gain
> > mind- and market-share with each manifestation of the "bad
> > libararies'" failure?
>
> I suppose that's the reason, why the least standards compliant browser
> has the marginal market share of, say, 80 percent?
You're missing the point. I'm saying if you have enough market share,
rightly or wrongly, you MAKE the standards.
Thomas 'PointedEars' Lahn
> On Nov 13, 12:56 pm, Gregor Kofler <use...@gregorkofler.at> wrote:
>> nolo contendere meinte:
>>> Again, this may be the browser's fault then. Bear in mind that browser
>>> developers do have to cater to existing web pages, and have all sorts
>>> of testing to try to ensure that nothing breaks in future versions.
>> You know what? There are websites (not conforming to standards, sure),
>> wich looked perfectly ok on IE6, but break more or less seriously on IE7.
>
> Of course, I'm saying that the future versions of browsers would make
> the attempt to break as few sites out there as possible. If the
> majority of sites DON'T conform to ECMA standards, the deveoplers will
> cater towards THAT first, and not the standards.
And therefore writing non-standard code that breaks *now* is a good thing?
That's just ridiculous.
>>> Wouldn't evolution cause the "good" librarues to bubble up
>>> and become the de facto standard? Wouldn't "bad libraries" break in
>>> future revs, independent browsers, etc, and the "good libraries" gain
>>> mind- and market-share with each manifestation of the "bad
>>> libararies'" failure?
>> I suppose that's the reason, why the least standards compliant browser
>> has the marginal market share of, say, 80 percent?
>
> You're missing the point. I'm saying if you have enough market share,
> rightly or wrongly, you MAKE the standards.
That is what companies like Microsoft want naive people like you to believe.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
nolo contendere
wrote:
> nolo contendere wrote:
> > On Nov 13, 12:56 pm, Gregor Kofler <use...@gregorkofler.at> wrote:
> >> nolo contendere meinte:
> >>> Again, this may be the browser's fault then. Bear in mind that browser
> >>> developers do have to cater to existing web pages, and have all sorts
> >>> of testing to try to ensure that nothing breaks in future versions.
> >> You know what? There are websites (not conforming to standards, sure),
> >> wich looked perfectly ok on IE6, but break more or less seriously on IE7.
>
> > Of course, I'm saying that the future versions of browsers would make
> > the attempt to break as few sites out there as possible. If the
> > majority of sites DON'T conform to ECMA standards, the deveoplers will
> > cater towards THAT first, and not the standards.
>
> And therefore writing non-standard code that breaks *now* is a good thing?
> That's just ridiculous.
>
Why do you infer that the non-standard code breaks now? Richard's
stance was that it DOES work, albeit coincidentally.
> >>> Wouldn't evolution cause the "good" librarues to bubble up
> >>> and become the de facto standard? Wouldn't "bad libraries" break in
> >>> future revs, independent browsers, etc, and the "good libraries" gain
> >>> mind- and market-share with each manifestation of the "bad
> >>> libararies'" failure?
> >> I suppose that's the reason, why the least standards compliant browser
> >> has the marginal market share of, say, 80 percent?
>
> > You're missing the point. I'm saying if you have enough market share,
> > rightly or wrongly, you MAKE the standards.
>
> That is what companies like Microsoft want naive people like you to believe.
I don't think I'm being naive. I think hoping/expecting/suggesting
that no one use "imperfect" libraries is naive. If you disagree with
the status quo, and you know better and have the ability, make change.
Gregor Kofler
> Why do you infer that the non-standard code breaks now? Richard's
> stance was that it DOES work, albeit coincidentally.
This very example. Richard picked an example to illustrate the bad code
quality, nothing else.
> I don't think I'm being naive. I think hoping/expecting/suggesting
> that no one use "imperfect" libraries is naive.
I'd say no one on clj hopes/expects/suggests that *no one* uses
imperfect libraries. However, if one is willing and able, there might be
better ways.
Anyway, since you are perfectly satisfied with prototype and can live
with it's shortcomings: use it, and end this futile discussion.
EOD, Gregor
Randy Webb
> On Nov 13, 12:56 pm, Gregor Kofler <use...@gregorkofler.at> wrote:
>> nolo contendere meinte:
>>
>>> Again, this may be the browser's fault then. Bear in mind that browser
>>> developers do have to cater to existing web pages, and have all sorts
>>> of testing to try to ensure that nothing breaks in future versions.
>> You know what? There are websites (not conforming to standards, sure),
>> wich looked perfectly ok on IE6, but break more or less seriously on IE7.
>
> Of course, I'm saying that the future versions of browsers would make
> the attempt to break as few sites out there as possible. If the
> majority of sites DON'T conform to ECMA standards, the deveoplers will
> cater towards THAT first, and not the standards.
I have been saying that in this group for years. Give up, it doesn't do
any good.
90% of the people that write Javascript don't know what ECMAScript is.
Of the remaining 10%, 90% of those don't care what ECMAScript is.
The other 1% post here proclaiming it as the savior of Javascript.
ECMAScript, in its current incarnation, was nothing more than an effort
to "standardize" what was already in place. And probably for no other
reason than to be able to say "There is a standard". And, it was a
stroke of marketing/research genius on the part of Microsoft.
It was Richard, not Robert, but, I don't think Richard was trying to
improve on Prototype.js as much as show the flaws in it. There is
another one that is, perhaps without a doubt, the mostly hotly debated
in this group and that is the use of $ as a function name. The main
issue is "ECMAScript says it is intended for machine generated code" and
people grasp onto that and want to condemn the practice simply because
"ECMAScript says so".
The $ function itself is another area where it could be improved simply
by removing some of it. It is over-written for what it is used for.
>>> Wouldn't evolution cause the "good" librarues to bubble up
>>> and become the de facto standard? Wouldn't "bad libraries" break in
>>> future revs, independent browsers, etc, and the "good libraries" gain
>>> mind- and market-share with each manifestation of the "bad
>>> libararies'" failure?
>> I suppose that's the reason, why the least standards compliant browser
>> has the marginal market share of, say, 80 percent?
>
> You're missing the point. I'm saying if you have enough market share,
> rightly or wrongly, you MAKE the standards.
I don't think they "make" the standard as much as they "become" the
standard. Microsoft drives this market, whether people admit it or not.
It isn't a pro-MS or anti-MS sentiment, it is just a fact. If MS came
out next week and proclaimed "The only markup language we will support
in the future is MSML(Microsoft Markup Language), the only script
language we will support is MSScript (Microsoft Script), and nothing
else". Then the rest of the browser world would flip on it's head in an
effort to support them and the W3C would become a thing of the past.
Randy Webb
> nolo contendere wrote:
>> On Nov 13, 12:56 pm, Gregor Kofler <use...@gregorkofler.at> wrote:
>>> nolo contendere meinte:
>>>> Again, this may be the browser's fault then. Bear in mind that browser
>>>> developers do have to cater to existing web pages, and have all sorts
>>>> of testing to try to ensure that nothing breaks in future versions.
>>> You know what? There are websites (not conforming to standards, sure),
>>> wich looked perfectly ok on IE6, but break more or less seriously on IE7.
>> Of course, I'm saying that the future versions of browsers would make
>> the attempt to break as few sites out there as possible. If the
>> majority of sites DON'T conform to ECMA standards, the deveoplers will
>> cater towards THAT first, and not the standards.
>
> And therefore writing non-standard code that breaks *now* is a good thing?
> That's just ridiculous.
What is more ridiculous is to believe that everybody is going to write
"perfect" code. Now or ever.
>>>> Wouldn't evolution cause the "good" librarues to bubble up
>>>> and become the de facto standard? Wouldn't "bad libraries" break in
>>>> future revs, independent browsers, etc, and the "good libraries" gain
>>>> mind- and market-share with each manifestation of the "bad
>>>> libararies'" failure?
>>> I suppose that's the reason, why the least standards compliant browser
>>> has the marginal market share of, say, 80 percent?
>> You're missing the point. I'm saying if you have enough market share,
>> rightly or wrongly, you MAKE the standards.
>
> That is what companies like Microsoft want naive people like you to believe.
Oh monkeys ass.
nolo contendere
LMMAO!
Doug Miller
>Thomas 'PointedEars' Lahn said the following on 11/13/2007 12:31 PM:
>>
>> That's just ridiculous.
>
>What is more ridiculous is to believe that everybody is going to write
>"perfect" code. Now or ever.
You misspelled "anybody". <g>
--
Regards,
Doug Miller (alphageek at milmac dot com)
It's time to throw all their damned tea in the harbor again.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn said the following on 11/13/2007 12:31 PM:
>> nolo contendere wrote:
>>> On Nov 13, 12:56 pm, Gregor Kofler <use...@gregorkofler.at> wrote:
>>>> nolo contendere meinte:
>>>>> Again, this may be the browser's fault then. Bear in mind that browser
>>>>> developers do have to cater to existing web pages, and have all sorts
>>>>> of testing to try to ensure that nothing breaks in future versions.
>>>> You know what? There are websites (not conforming to standards, sure),
>>>> wich looked perfectly ok on IE6, but break more or less seriously on IE7.
>>> Of course, I'm saying that the future versions of browsers would make
>>> the attempt to break as few sites out there as possible. If the
>>> majority of sites DON'T conform to ECMA standards, the deveoplers will
>>> cater towards THAT first, and not the standards.
>> And therefore writing non-standard code that breaks *now* is a good thing?
>> That's just ridiculous.
>
> What is more ridiculous is to believe that everybody is going to write
> "perfect" code. Now or ever.
I did not state anything about "perfect code", you just made that up. That
aside, technical newsgroups like this exist to increase understanding. If
no poster would believe that it is possible to convince a reasonable number
of readers that it is better to write good code, this newsgroup would have
lost its purpose and all people who post now could stop posting.
That it still exists, and that people knowing more still provide people
knowing less with corrections, suggestions and better code proves that you
are utterly wrong.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
Matt Kruse
wrote:
> That
> aside, technical newsgroups like this exist to increase understanding.
And also to inflate the egos of people have a good technical
understanding and want to flaunt it for all to see by criticizing
everyone they can. It's amusing to watch sometimes.
This group exists for more than to simply reduce all problems to the
most efficient and standards-compliant code that could possibly be
written. There are Javascript-related questions that are only
partially technical. For example, recent discussions on libraries
point out that people have different priorities. If someone comes here
looking for advice on the pros and cons of library X, the technical
issues with the library is only part of the equation. Even if a
library has technical problems, using it still may be the best
business decision, and that overall discussion is still Javascript-
related.
Technical perfection is not _THE_ goal, but _A_ goal.
Critiques of code and offering advice on why it is good or bad and how
it could be improved is a great thing that should always be welcome.
But not at the expense of discussing what the OP is really trying to
figure out. That's where so many regulars on this group get it wrong.
IMO.
I would still like to see answers from some of the hardcore critics
here about real-world situations and what they would recommend when
real-world problems and priorities need to be taken into
consideration. When technical merit is probably not the #1 concern,
but maybe down the list a bit. Then falling back to the same old
"libraries suck" arguments and pointing to all coding practices that
conflict with the "standards" do you no good, and many here don't seem
to be able to carry on an intelligent conversation once their mantra
is irrelevant.
Matt Kruse
Randy Webb
> Randy Webb wrote:
>> Thomas 'PointedEars' Lahn said the following on 11/13/2007 12:31 PM:
>>> nolo contendere wrote:
>>>> On Nov 13, 12:56 pm, Gregor Kofler <use...@gregorkofler.at> wrote:
>>>>> nolo contendere meinte:
>>>>>> Again, this may be the browser's fault then. Bear in mind that browser
>>>>>> developers do have to cater to existing web pages, and have all sorts
>>>>>> of testing to try to ensure that nothing breaks in future versions.
>>>>> You know what? There are websites (not conforming to standards, sure),
>>>>> wich looked perfectly ok on IE6, but break more or less seriously on IE7.
>>>> Of course, I'm saying that the future versions of browsers would make
>>>> the attempt to break as few sites out there as possible. If the
>>>> majority of sites DON'T conform to ECMA standards, the deveoplers will
>>>> cater towards THAT first, and not the standards.
>>> And therefore writing non-standard code that breaks *now* is a good thing?
>>> That's just ridiculous.
>> What is more ridiculous is to believe that everybody is going to write
>> "perfect" code. Now or ever.
>
> I did not state anything about "perfect code", you just made that up.
Let me check and re-read what I wrote. Nope, I never said you stated
anything about perfect code. Nope, sure didn't. Do you see where I did?
Didn't think so. Now, who is "making things up"?
> That aside, technical newsgroups like this exist to increase understanding.
No, that is not why they exist. If understanding is increased then it is
a by-product, not the product of the group.
> If no poster would believe that it is possible to convince a reasonable number
> of readers that it is better to write good code, this newsgroup would have
> lost its purpose and all people who post now could stop posting.
Your problem is you think that any code that doesn't follow some
"standard" to the letter isn't "good code". You couldn't be further from
the truth when it comes to writing cross-browser scripts for the web.
> That it still exists, and that people knowing more still provide people
> knowing less with corrections, suggestions and better code proves that you
> are utterly wrong.
You should endeavor to understand what it is that you are whining about
before you whine about it.
dhtmlk...@gmail.com
A method should do what it says. What does $ say it does? If it were a
shortcut to document.getElementById, I'd call unnecessary delegation,
but that's not the case.
The $ has been so overloaded to do xpath, et c in jQuery. In a way,
it's like those html pages where every tag is div.
> The $ function itself is another area where it could be improved simply
> by removing some of it. It is over-written for what it is used for.
>
I'm in complete agreement. All the getBySelector functionality. YAGNI.
The only one time I needed something like that was when I wrote the
CssEditor, and then I really needed to parse the styleSheet and
capture clicks on elements matching the most specific selector.
Another place it was used is Selenium, although I do not use those
selectors in Selenium becauise selenium already has xpath which is
very good at what it does.
> >>> Wouldn't evolution cause the "good" librarues to bubble up
> >>> and become the de facto standard? Wouldn't "bad libraries" break in
> >>> future revs, independent browsers, etc, and the "good libraries" gain
> >>> mind- and market-share with each manifestation of the "bad
> >>> libararies'" failure?
> >> I suppose that's the reason, why the least standards compliant browser
> >> has the marginal market share of, say, 80 percent?
>
> > You're missing the point. I'm saying if you have enough market share,
> > rightly or wrongly, you MAKE the standards.
>
> I don't think they "make" the standard as much as they "become" the
> standard. Microsoft drives this market, whether people admit it or not.
> It isn't a pro-MS or anti-MS sentiment, it is just a fact. If MS came
> out next week and proclaimed "The only markup language we will support
> in the future is MSML(Microsoft Markup Language), the only script
> language we will support is MSScript (Microsoft Script), and nothing
> else". Then the rest of the browser world would flip on it's head in an
> effort to support them and the W3C would become a thing of the past.
>
I doubt that. So many HTML pages now, and people need to log in to
their pages, et c. If IE doesn't support that feature (HTML) then it
would fall out of favor. MS would have to get users on to a new
platform first, and get enogh pgs developed on that platrofm to make
it really attractiuve,.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn said the following on 11/13/2007 2:20 PM:
>> Randy Webb wrote:
>>> Thomas 'PointedEars' Lahn said the following on 11/13/2007 12:31 PM:
>>>> nolo contendere wrote:
>>>>> On Nov 13, 12:56 pm, Gregor Kofler <use...@gregorkofler.at> wrote:
>>>>>> nolo contendere meinte:
>>>>>>> Again, this may be the browser's fault then. Bear in mind that browser
>>>>>>> developers do have to cater to existing web pages, and have all sorts
>>>>>>> of testing to try to ensure that nothing breaks in future versions.
>>>>>> You know what? There are websites (not conforming to standards, sure),
>>>>>> wich looked perfectly ok on IE6, but break more or less seriously on IE7.
>>>>> Of course, I'm saying that the future versions of browsers would make
>>>>> the attempt to break as few sites out there as possible. If the
>>>>> majority of sites DON'T conform to ECMA standards, the deveoplers will
>>>>> cater towards THAT first, and not the standards.
>>>> And therefore writing non-standard code that breaks *now* is a good thing?
>>>> That's just ridiculous.
>>> What is more ridiculous is to believe that everybody is going to write
>>> "perfect" code. Now or ever.
>> I did not state anything about "perfect code", you just made that up.
>
> Let me check and re-read what I wrote. Nope, I never said you stated
> anything about perfect code. Nope, sure didn't. Do you see where I did?
As you appear to have impaired vision, I have marked it for you above.
> Didn't think so. Now, who is "making things up"?
You are.
>> That aside, technical newsgroups like this exist to increase understanding.
>
> No, that is not why they exist. If understanding is increased then it is
> a by-product, not the product of the group.
A matter of opinion.
>> If no poster would believe that it is possible to convince a reasonable number
>> of readers that it is better to write good code, this newsgroup would have
>> lost its purpose and all people who post now could stop posting.
>
> Your problem is you think that any code that doesn't follow some
> "standard" to the letter isn't "good code". You couldn't be further from
> the truth when it comes to writing cross-browser scripts for the web.
You are an idiot. Any code has to be written according to some convention
or it could not qualify as good code; that is, code that does not only run
in a single test environment. Adhering to the convention of a standard,
especially *the* international standard for the programming language, is
vital for it to become interoperable. Without that property, it definitely
qualifies as bad code.
Gregor Kofler
> I don't think they "make" the standard as much as they "become" the
> standard. Microsoft drives this market, whether people admit it or not.
> It isn't a pro-MS or anti-MS sentiment, it is just a fact. If MS came
> out next week and proclaimed "The only markup language we will support
> in the future is MSML(Microsoft Markup Language), the only script
> language we will support is MSScript (Microsoft Script), and nothing
> else". Then the rest of the browser world would flip on it's head in an
> effort to support them and the W3C would become a thing of the past.
Come on... MS isn't even able to make their IE7 the "standard" browser.
People stick rather to the wretched interface of IE6, than "learn" to
use the added comfort of alternative products.
Randy Webb
Let me try, desperately, to explain plain English to you Thomas. I know
it is difficult for you to comprehend as it is not your native language.
As difficult as this is going to be, I am still going to try. Ready?
Thomas said: "writing non-standard code...."
Randy added: "What is more ridiculous....."
To which you replied and accused me of saying you said anything about
perfect code. I never said you did. Now, if you can "mark" for me where
I said you said anything about perfect code, then please do so.
Otherwise, you are still whining about something that didn't happen.
Your move.
>> Didn't think so. Now, who is "making things up"?
>
> You are.
See above. And then try again.
>>> That aside, technical newsgroups like this exist to increase understanding.
>> No, that is not why they exist. If understanding is increased then it is
>> a by-product, not the product of the group.
>
> A matter of opinion.
And what the outdated charter of this group has to say.
>>> If no poster would believe that it is possible to convince a reasonable number
>>> of readers that it is better to write good code, this newsgroup would have
>>> lost its purpose and all people who post now could stop posting.
>> Your problem is you think that any code that doesn't follow some
>> "standard" to the letter isn't "good code". You couldn't be further from
>> the truth when it comes to writing cross-browser scripts for the web.
>
> You are an idiot.
<URL: http://en.wikipedia.org/wiki/Idiot>
<quote>
Its modern meaning and form dates back to Middle English around the year
1300, from the Old French idiote ("uneducated or ignorant person").
</quote>
Specifically, the part about "uneducated". Since every person on this
planet is uneducated about something in some form or fashion, your
attempt to insult me was nowhere near as successful as you would like
for it to have been.
Try again Thomas, you failed.
> Any code has to be written according to some convention or it could
> not qualify as good code; that is, code that does not only run
> in a single test environment.
I wrote nothing about conventions, I wrote about it conforming to a
"standard", in this case the ECMAScript standard.
> Adhering to the convention of a standard, especially *the* international
> standard for the programming language, is vital for it to become
> interoperable. Without that property, it definitely qualifies as bad code.
So, you are saying that if code doesn't "adhere to the international
standard" for javascript, then it is "bad code"? Be careful because
there are a lot of things that you have to do in IE that doesn't adhere
to the "standards" but it won't work if you make your code adhere
strictly to that standard. Must mean you have to write "bad code" in
order for it to be "cross-browser". And that leads right back to what I
said. Code that is cross-browser can be good, solid code and not even
come close to adhering to a "standard".
Now, since you can't adhere strictly to that standard, and you are
producing "bad code" because of it, then you can't possibly write "good
cross-browser scripts". Of course, you can prove me wrong here. Simple
actually. I only have to give you one example of where you can't write
strictly standard code and have it cross-browser to prove you wrong. So,
to prove me wrong, all you have to do is write a cross-browser
compatible script that adheres *strictly* to the "standards" with these
requirements:
Given a string of JS Code, create a script element and have the browser
execute that code in proper context. Pretty simple huh? I will give you
a hint though, you can't do it as IE won't handle createTextNode
properly and you have to fall back on a proprietary method to pull it off.
You really should take more care in trying to understand what you read.
Randy Webb
> On Nov 13, 10:52 am, Randy Webb <HikksNotAtH...@aol.com> wrote:
<snip>
>> It was Richard, not Robert, but, I don't think Richard was trying to
>> improve on Prototype.js as much as show the flaws in it. There is
>> another one that is, perhaps without a doubt, the mostly hotly debated
>> in this group and that is the use of $ as a function name. The main
>> issue is "ECMAScript says it is intended for machine generated code" and
>> people grasp onto that and want to condemn the practice simply because
>> "ECMAScript says so".
>>
> that's one issue. The other is that it's not semantic.
>
> A method should do what it says. What does $ say it does? If it were a
> shortcut to document.getElementById, I'd call unnecessary delegation,
> but that's not the case.
No, that is not all that $ does in Prototype. Far from it. In fact, it
is so convoluted you would have a hard time coming up with a "semantic"
name for it that was under about 20 characters or so.
As for "unnecessary delegation", I can see a benefit to having a wrapper
function as long as the function handled feature detection. Then you
wouldn't have to write this every time:
if (document.getElementById){
//
}
You could simply write:
getRef('someElement')
And then have the function getRef handle the feature detection.
But, most of the discussions about the use of $ don't center on the
semantics of it (although it has been mentioned in the past), the
discussion centers on the "ECMAScript says don't do it" aspect of it.
> The $ has been so overloaded to do xpath, et c in jQuery. In a way,
> it's like those html pages where every tag is div.
Honestly, I have never looked at jQuery other than seeing snippets of it
here so I can't comment on it. The only reason I have looked at
Prototype.js lately is because of this thread.
<snip>
>> I don't think they "make" the standard as much as they "become" the
>> standard. Microsoft drives this market, whether people admit it or not.
>> It isn't a pro-MS or anti-MS sentiment, it is just a fact. If MS came
>> out next week and proclaimed "The only markup language we will support
>> in the future is MSML(Microsoft Markup Language), the only script
>> language we will support is MSScript (Microsoft Script), and nothing
>> else". Then the rest of the browser world would flip on it's head in an
>> effort to support them and the W3C would become a thing of the past.
>>
> I doubt that. So many HTML pages now, and people need to log in to
> their pages, et c. If IE doesn't support that feature (HTML) then it
> would fall out of favor. MS would have to get users on to a new
> platform first, and get enogh pgs developed on that platrofm to make
> it really attractiuve,.
Let me clarify it a little differently as it is a little ambiguous as I
wrote it. If MS came out and said:
<conjecture>
The only way IE will process a script block is if it is formatted in
this manner:
<script type="MSScript">
//script code here
</script>
Furthermore, if any other attributes are present, IE will ignore the
script block.
</conjecture>
Then you would see a TON of webpages get changed in a hurry. Would they
ever do it? No. Could they do it and make it work? Absolutely. It is a
bad side effect of having a dominating monopoly over the browser area.
Want a real world example though? XHTML. MS snubbed there noses at it
and now it's a dead language. Not because it was bad, not because of
anything other than the fact that MS doesn't support it. Not saying
there aren't uses for it (there are). But for the web itself, it is a
pretty dead language.
Microsoft didn't gain that advantage by offering a better product, they
gained it by brute force of forcing IE onto the desktop and then
integrating it into the OS.
Now that we are way off topic, I don't want to continue having a
discussion about MS and the problems with it. Let's just get back to
Prototype.js :)
--
Randy
Chance Favors The Prepared Mind
Randy Webb
> Randy Webb meinte:
>
>> I don't think they "make" the standard as much as they "become" the
>> standard. Microsoft drives this market, whether people admit it or
>> not. It isn't a pro-MS or anti-MS sentiment, it is just a fact. If MS
>> came out next week and proclaimed "The only markup language we will
>> support in the future is MSML(Microsoft Markup Language), the only
>> script language we will support is MSScript (Microsoft Script), and
>> nothing else". Then the rest of the browser world would flip on it's
>> head in an effort to support them and the W3C would become a thing of
>> the past.
>
> Come on... MS isn't even able to make their IE7 the "standard" browser.
> People stick rather to the wretched interface of IE6, than "learn" to
> use the added comfort of alternative products.
If, and only if, they are made aware of the alternative product and MS
does a damn spiffy job of attempting to hide that fact. You can't get a
new Windows based PC manufacturer to pre-install a different browser
because MS won't allow it.
Thomas 'PointedEars' Lahn
> [...] You can't get a new Windows based PC manufacturer to pre-install a
> different browser because MS won't allow it.
Yes, you can. M$ has lost that case already, and it is unlikely they will
try again.
Randy Webb
> Randy Webb wrote:
>> [...] You can't get a new Windows based PC manufacturer to pre-install a
>> different browser because MS won't allow it.
>
> Yes, you can. M$ has lost that case already, and it is unlikely they will
> try again.
Whatever you say, kiddie. It doesn't help your credibility any when you
fall prey to the "cool" stuff like referring to Microsoft as M$, it
detracts from it.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn said the following on 11/15/2007 5:17 AM:
>> Randy Webb wrote:
>>> [...] You can't get a new Windows based PC manufacturer to pre-install a
>>> different browser because MS won't allow it.
>> Yes, you can. M$ has lost that case already, and it is unlikely they will
>> try again.
>
> Whatever you say, kiddie. It doesn't help your credibility any when you
> fall prey to the "cool" stuff like referring to Microsoft as M$, it
> detracts from it.
| Learn to read what you are replying to.
| Learn to understand what other people have written.
| Learn the basic vocabulary of a culture you are participating in.
-- Harald Blahovec (translated)
That said, we are pretty much off-topic already with *your* introducing
Microsoft into the equation. Speaking of which, they do have paid a lot
of $s as results of the lawsuits and appeals of competitors against the
aforementioned practice :)
VK
> I had not realized prototype.js was such a hot topic
For two years at least or even more. More exactly: the usage of
"solution size" libraries in JavaScript as such, prototype.js is just
a banner of this fight IMHO :-)
I personally do not stand with the kind of argument "as the result
people will not learn JavaScript". One may think that the the whole
army of C++ programmers spending their days in for(x=y;x<z;++x) and
similar programming. Just give me a break! 95% of programming in an
average company consists of linking and registering different
libraries, calling their methods over pre-filled drop-downs and
searching through the help what a hey method does what I need in
A=>B=>C=>D=>E=>F=>G=>H object - the last often is the main time
consumer :-) I now some libraries that came into life exactly because
it was quicker to write something of your own rather than memorize
some too weird named or placed properties and methods of a 3rd party
library.
IMHO there are two differences and problems for JavaScript libraries.
1) All DLL are written with Windows and Visual Studio in mind.
Respectively if one registered a new DLL and some weird stuff started,
normally one files complain/bug report to DLL producer. JavaScript
libraries are some creations "out of time and space". So it is often
some one linked Dojo, jQuery, Prototype and a couple more, the browser
gets crazy of it, and where to look for help? Who has to get your bug
report (or misuse explanation)? Often clj is chosen for that for the
lack of any other evident place - and I definitely understand that
people here are refusing to accept the role of a world-wide free 3rd
party libraries maintenance and correction.
2) The formation of JavaScript libraries was and remains up till now a
totally anarchical process. There is not any RFC or any other commonly
accepted technical documents about JavaScript structuring,
interfacing, naming or documenting. As a result the progress in the
area reminds me a bunch of ants dragging something big to the ant
house: it seems like everyone is working together but really each one
is pushing to his own side, so the slow movement happens only because
the resulting vector is a bit above zero and going to the right
direction. :-)
Randy Webb
> Randy Webb wrote:
>> Thomas 'PointedEars' Lahn said the following on 11/15/2007 5:17 AM:
>>> Randy Webb wrote:
>>>> [...] You can't get a new Windows based PC manufacturer to pre-install a
>>>> different browser because MS won't allow it.
>>> Yes, you can. M$ has lost that case already, and it is unlikely they will
>>> try again.
>> Whatever you say, kiddie. It doesn't help your credibility any when you
>> fall prey to the "cool" stuff like referring to Microsoft as M$, it
>> detracts from it.
>
> | Learn to read what you are replying to.
> | Learn to understand what other people have written.
> | Learn the basic vocabulary of a culture you are participating in.
> -- Harald Blahovec (translated)
>
> That said, we are pretty much off-topic already with *your* introducing
> Microsoft into the equation. Speaking of which, they do have paid a lot
> of $s as results of the lawsuits and appeals of competitors against the
> aforementioned practice :)
I would tell you that your intelligence level is beginning to remind me
of VK, but, I don't want to insult VK like that so I won't.
P.S. Fix your signature.
dhtmlk...@gmail.com
>
> read more >>
I think the idea here is looking at the code is a good idea.
There will always be bugs. (browsers are a good example) Some bugs you
can live with, others are too unacceptable.
Mistakes and misconceptions are different.
Looking at code can show how the author thinks. Mistakes are one
thing, but when a script is written with misconceptions, well, it kind
of makes you look sideways at the script.
VK
> I would tell you that your intelligence level is beginning to remind me
> of VK, but, I don't want to insult VK like that so I won't.
You mean that VK needs a special profoundly thought insult, not a
simplified spontaneous one? :-)
Randy Webb
Geez, just when I thought you might be using your brain, you prove me wrong.
If telling PointedHead that he is acting like you is an insult to you,
that means he is acting worse than you. But now, I am not so sure anymore.
VK
> If telling PointedHead that he is acting like you is an insult to you,
> that means he is acting worse than you.
So is it a compliment to me? OK, but also can be read as an insult to
PointedEars (or anyone else in the future): "You are worser than VK" -
so "really ground bottom". A too complex statement for simple minds
like mine :-)
Randy Webb
> On Nov 17, 3:19 am, Randy Webb <HikksNotAtH...@aol.com> wrote:
>> If telling PointedHead that he is acting like you is an insult to you,
>> that means he is acting worse than you.
>
> So is it a compliment to me?
Don't get your hopes up :)
> OK, but also can be read as an insult to PointedEars (or anyone else in the future):
You are beginning to grasp it.
> "You are worser than VK" - so "really ground bottom".
I am proud of you. It only took you three posts to figure that out.
> A too complex statement for simple minds like mine :-)
No comment :)
VK
> >> If telling PointedHead that he is acting like you is an insult to you,
> >> that means he is acting worse than you.
>
> > So is it a compliment to me?
>
> Don't get your hopes up :)
>
> > OK, but also can be read as an insult to PointedEars (or anyone else in the future):
>
> You are beginning to grasp it.
>
> > "You are worser than VK" - so "really ground bottom".
>
> I am proud of you. It only took you three posts to figure that out.
Oh... But from the other side "there are people worser then you, VK,
so be proud of"; but from the other side "you're getting worser than
VK, PointedEars, so try to shape up"; but also can be read as ...
Did you you ever tried for a White House PR representative? You would
pass the sort out tests for sure.
:-)
</OT>
Dr J R Stockton
2g2000prg.googlegroups.com>, Fri, 16 Nov 2007 12:19:49,
"dhtmlk...@gmail.com" <dhtmlk...@gmail.com> posted:
Lines: 253
>> ... ... ...
>
>I think the idea here is looking at the code is a good idea.
>
>There will always be bugs. (browsers are a good example) Some bugs you
>can live with, others are too unacceptable.
>
>Mistakes and misconceptions are different.
>
>Looking at code can show how the author thinks. Mistakes are one
>thing, but when a script is written with misconceptions, well, it kind
>of makes you look sideways at the script.
Please trim your quotes. See FAQ 2.3.
--
(c) John Stockton, Surrey, UK. replyYYWW merlyn demon co uk Turnpike 6.05.
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 precede replies. Snip well. Write clearly. Mail no News.
Richard Cornford
> On Nov 12, 8:45 pm, Richard Cornford wrote:
>> nolo contendere wrote:
>>> I've recently begun playing with prototype.js as well
>>> as scriptaculous, and found both very helpful in
>>> developing web pages with lots of pop. Modal boxes,
>>> SlideUp/Down, calendars, etc.
>>
>>> I've also recently ramped up my lurking and participation
>>> in this newsgroup. There are some who advocate using
>>> prototype,
>>
>> Here?
>
> In this very thread in fact.
If you are talking about "s0lnic" then you should note that he has
hardly made a dozen posts in the last 3 month and the only code he has
posted featured the usual cross-browser error and needed to be corrected
before it was fit for its proposed purpose.
>>> and others who are adamantly opposed to it. Are there
>>> any concrete reasons why I should NOT use it?
>>
>> Lots, but I don't have time to go through all of them
>> right now. However, one good illustration is the least
>> you deserve.
>
> I appreciate it.
>
>> Take this code form the latest (1.6.0) version of Prototype.js:-
<snip>
>> - What this appears to represent ...
<snip>
>> Now if this code 'works' at all it 'works' mostly by
>> coincidence ...
<snip>
>> Of course the conditional creation of function objects is
>> trivial in javascript in a way that fully conforms with
>> the ECMAScript specification, ...
<snip>
>>... and so will 'work' consistently in all past, present
>> and future ECMA 262 3rd Ed. conforming implementations.
>
> Why has a library not been written this way?
In what way? Such that the code used conforms to language's
specification and does not rely on inconsistent implementation details?
Lots of libraries have been written in that way. For example I have not
yet noticed anything in dojo that relies upon language extensions or
non-standard implementation features. Granted the evidence that dojo's
authors don't understand the code they are writing suggests that that
is itself probably best attributed to coincidence, but still it is the
case.
> Obviously it's not your responsibility to do it, or to even
> know the reason why it hasn't been done thus far,
Except it has been done, and is probably the norm, even in otherwise
very dubious library code.
> but if so many people are in error, and it causes you
> any distress,
What makes you think it causes me any distress? I am massively cynical,
so a world where idleness, ignorance, ineptitude and incompetence are
endemic is reassuring (almost comforting).
> it would behoove you to write one, or at
> least begin one.
One what? A general-purpose library? Doesn't that imply a
presupposition that a general-purpose library would be
something that would be useful to have? If that a-priori
assumption is not itself valid then creating such an object
could be a bad idea and I could be entirely justified in
not spending my time pursuing folly.
> Perhaps set up a project? Clearly you care a lot about
> this subject, and have invested much time in it. This
> is just another avenue by which you can participate in
> -- and even shape -- the future of how javascript is used.
Why do I need another avenue to shape the future of how javascript is
used?
>> It is simply the case that anyone knowing javascript would
>> have written the original code in this final form. So would
>> not be writing code that functioned purely by coincidence
>> but instead they would be programming.
>>
>> The problem with the way this sort of ignorance of javascript
>> results in code that only works by coincidence is highlighted
>> by browsers like Opera. Opera currently acts like JScript,
>> and unconditionally acts on the FunctionDeclarations out of
>> their (otherwise syntax error) context but while Opera has an
>> ECMA 262 conforming javascript implementation, they also aim
>> to emulate JavaScript(tm), and so may introduce
>> JavaScript(tm)'s FunctionStatement extension at any moment.
>> And so code that works by coincidence because of the order
>> of the 'FunctionDeclarations' may find itself suddenly
>> conditionally evaluating FunctionStatements with any next
>> version of Opera, and what these branches do in that versions
>> of Opera may be totally inappropriate.
>>
>
> So this is the browser's problem.
No, it is the programmer's responsibility. The responsibility of the
browsers is no more than to correctly implement the standards that they
claim to implement. Whatever they do beyond that is up to them.
> They are too permissive.
It does appear that web browsers being permissive leads to problems when
people try to learn programming entirely by trial and error in a
restricted set of browsers and then try to move on to cross-browser
scripting.
> But if you think about it, if 90%
> of people do something one way, and that way doesn't conform
> to "the standard" (in this case, ECMA), doesn't the
> way most people do it BECOME the standard?
But what then 'becomes the standard'? The code I highlighted is amenable
to three different interpretations in web browser environments, and
actually behaves radically differently in the two most popular browsers.
Is that either JavaScript's or JScript's interpretation that 'becomes
the standard', or do you mean that it becomes the standard to be writing
code that behaves differently in each and every browser it encounters?
We tried that and it did not work, which is why the standardisation of
the language (and the DOM) was started.
One of the main reasons that it is currently possible for the uses of
javascript to be taking the directions they are taking is that
ECMAScript has been stable since the turn of the century and so its
implementations have become very complete and stable.
> It may be horrific in its
> implementation, syntax, whatever, but so is HTTP.
What is wrong with HTTP? It does precisely what it was designed to do,
and does it very well. Of course you start to see issues as soon as you
attempt to use HTTP for something other than what it was designed for,
but that is hardly surprising or unusual.
> So you either adapt
> and use it, or try to make change.
>
>> The Prototype.js approach results in code that cannot be
>> expected to work in any more browsers than those in which
>> it has been demonstrated to 'work', and so cannot even be
>> expected to 'work' with the future versions of that those
>> browsers. This cannot be a viable approach to creating
>> cross-browser code, and it does not.
>
> Again, this may be the browser's fault then.
No, it is the programmer's fault.
> Bear in mind that browser developers do have to cater to
> existing web pages, and have all sorts of testing to try
> to ensure that nothing breaks in future versions. I
> highly doubt that just because a page doesn't conform to
> ECMA standards, the browser developers will say "screw
> that web page, if they don't follow ECMA they don't get
> a proper rendering in our browser."
ECMAScript conformance has nothing what so ever to do with rendering.
Whether the Prototype.js code conforms to the ECMA standard or not was
not the issue. The issue is that the code does not actually do what its
author clearly thinks it does, and what it does do is not even the same
in the two most common browsers. Re-writing it as ECMA 262 conforming
code only acts to avoid that issue, as the code will then do the one
thing it is programmed to do, and do that same thing on (at absolute
minimum) all the browsers that Prototype.js is interested in.
It would also be possible to re-write the code so that it acted in a way
that made sense in terms of how it would be interpreted under
JavaScript(tm) and JScript, where you would short-circuit the
heavyweight - if - test on finding that the - each - function was
defined prior to the test (i.e. wherever the test was futile). The
result would not be any more cross-browser but at least it would show an
author actually programming the library instead of being at the mercy of
misconceptions and coincidence.
> This may work if the percentage of "bad" web pages were
> vanishingly small, but hey, this is the real world where people are
> stupid and market share is of vital importance to a browser's
> continued existence.
Market share has nothing to do with the existence or viability of web
browsers. Recently the growth area in web browsers has been browsers for
embedded devices (usually mobile phones), and that is simply because
that is virtually the only market where money is exchanged for web
browsers (even if indirectly). Unlike the desktop browser market where
if the user doesn't get the browser for free they go and get one form
someone else. The embedded browsers don't have much market share (yet),
but they do have the potential to fund their own development, return a
profit, and continue to exist for that reason.
> I'm not saying I'm encouraging bad coding, or
> stupidity, but I'm being a realist.
You are not being a realist. You are assuming that you have enough
information to make informed judgments about a subject while admitting
near total ignorance of the technologies involved. A realistic position
would be to recognise that you are probably not yet qualified to judge.
> Once all market share is captured, THEN you can begin to
> gradually enforce whichever standards are the best. But
> until then, it's a free-for-all.
<snip>
No web project is ever created without it's having some purpose. That
is, there is always someone who wants something from it. That
'something' may be profit/turnover, publicity, goodwill, specific
functionality, etc. (or some combination of those sorts of things). The
'professional' web developer's responsibility should be to maximise the
project's ability to achieve that 'something'. That is not a
"free-for-all", it is a knowledge driven process with a context specific
pre-defined direction.
> I truly do appreciate your perspective. I did a little
> research on you, and you appear to be a very intelligent
> individual, although (and I don't mean to be destructively
> critical) a bit of an idealist/ purist--which the world
> does need, but isn't the way the world works.
The way the world works at the moment has the demand for my (client-side
scripting) skills exceeding their supply. Which leaves me
(idealist/purist or not) selling in a seller's market and quite happy
with the outcome. And the direction javascript use has taken makes me
think that that situation is not going to change in the near future.
When my boss comes to me and says, "Can we do this thing ... ?" (as he
usually does at lest a couple of times a week) I can answer "yes", "yes,
but ..." or "no" and be pretty sure that when I say "yes" I can deliver,
when I say "yes, but ..." I am accurately enumerating the pertinent
caveats, and that when I say "no" he is not going to be able to find
anyone else who can deliver what I cannot. This while the vast bulk of
the 'competition' are operating at a level of knowledge and
understanding that is below those of the authors of the libraries that
they have learnt to be dependent upon. While the authors of those
libraries don't actually know enough to be programming with javascript.
<snip>
>>> And the benefits of being able to inject such
>>> a wide variety of effects into a page (to me) far
>>> outweigh any harm.
Can you judge the 'harm'? A while ago I was directed to a web page where
a web developer was proudly explaining how he had used a particular
rapid development process/system to create an e-commerce site, and how
easy/profitable it had been for him. He was very satisfied with the
outcome, and though his clients were also very happy with the outcome.
However, when I viewed the site using IE 6 I found that the shopping
cart did not work at all, which is pretty fatal for an e-commerce site.
Looking at the source for the site it immediately became obvious that my
problem was because of the specific configuration of my IE 6, but
simultaneously I observed that the code would only 'work' with 3 or 4
'major' desktop browsers in their default configurations.
There is a lot of nonsense talked about 'target audiences' when trying
to justify only supporting limited sets of (default configurations of)
browsers. It is a notion that starts with odd assertion that there is a
strong relationship between groupings of individuals and the web
browsers they use such that a 'target audience' implies some specific
set of web browser will be used by that audience (as opposed to
admitting the reality where anyone could be using just about any
(non-archaic) browser at all and that it is only a trivial coincidence
that the majority of them will be using the 'most common' browsers). The
'target audience' excuse also suffers from web 'statistics' problem,
where HTTP is inherently resistant to accurate browser usage statistics
gathering and most statistics gathering techniques are incapable if
distinguishing 'minor' browsers from 'major' browsers.
On the other hand the notion of 'target audiences' did have something to
contribute to this particular project because the e-commerce site in
question was selling web icon imagery. That means that its 'target
audience' is web developers, web designers and people in related fields.
While generalisations about web browser usage are inherently problematic
it certainly is the case that this particular target audience is the
target audience that is _most_ likely to be using non-standard web
browsers and web browsers in non-default configurations (because they
are the single group of users most likely to know about a wide range of
browser, have attitudes towards the browsers they use, and be confident
about configuring those browsers in precisely the way that suites them).
This means that from the point of view of the e-commerce site's client
the web developer's 'decision' to create something that only worked with
default configurations of 3 or 4 browsers was potentially harmful. It
effectively throttled potential turnover at the design stage. Of course
they don't appreciate that as if they had been in a position to make
that sort of judgement they would not have needed to employ someone else
to create the site for them. So instead they employed a 'professional'
and trusted that they would not be screwed as a result.
(Remember that this e-commerce site could have been created such that it
could take money off anyone who's browser is capable of making HTTP(S)
connections, displaying HTML pages, showing images and submitting a from
in a POST request (which is pretty much every non-pure text web browser
that has ever existed).)
The ironic aspect of this is that a month or so after this site was
pointed out to me I was in the office on a Saturday afternoon knocking
up some web material for a sails presentation and my boss decided that
he wanted different/better icon graphics. He could not get (hold of) any
of our designers to come in and create the graphics and didn't think he
could afford to leave the task until Monday. So he went to Google,
credit card in hand, to find and purchase some off the shelf graphics.
The very fist site he hit was our e-commerce icon seller above. He liked
one of the sets of icons and so hit the shopping cart to purchase them,
and it did not work for him. It did not work for him because his IE is
not in its default configuration either, but his is not in its default
configuration because our technical department found out that he had let
some spyware get onto his laptop and so leaked a company e-mail address
book (meaning we all got spammed continuously for a couple of months).
So they have clamped down his browser security in the Internet zone and
arranged that he (and I) cannot re-set those settings. The practical
upshot was that my boss's money went to a different seller of web icons.
So given that the original web developer was proud of his creation, and
how easy and profitable it had been (for him), so much so that he
published a web page to boast about his triumph, do you think he
appreciated the harm his design decisions had done? I don't think so,
and if challenged I bet he would make a lot of noise about working in
the 'real world' and play down the impact of his design decisions on his
client's turnover as 'not statistically significant' (without daring to
ask their opinion on the subject).
>> At least for as long as you avoid understanding how those
>> effects work, and so how trivial they are to create for
>> yourself.
>
> Again, if they are so trivial, why wouldn't a "good" library
> have been written?
For a start; a total disconnection of responsibilities. You just don't
need a 'library' to do trivial things.
But where is your statement of a valid justification for the creation of
a 'library' to start with? Without that we haven't even arrived at this
question.
> Wouldn't evolution cause the "good" librarues to bubble up
> and become the de facto standard? Wouldn't "bad libraries"
> break in future revs, independent browsers, etc, and the "good
> libraries" gain mind- and market-share with each manifestation
> of the "bad libararies'" failure?
In a world where people don't see demonstrations of a library's author
not knowing the language well enough to actually be programming with it
as sufficient grounds to dismiss the use of that library out of hand it
is quite likely that manifestations of failure would go unnoticed (or be
disregarded).
Richard.
Matt Kruse
wrote:
> But where is your statement of a valid justification for the creation of
> a 'library' to start with? Without that we haven't even arrived at this
> question.
Some arguments in favor of a 'library' are:
1. Normalizing browser behavior, to the greatest extent possible, and
encapsulating the code required to do so into a 'standard' API
relieves the developer of the effort of considering browser quirks
every time code is to be written.
2. The code required to perform some common and repeated javascript
tasks correctly can be long and error-prone. Putting a layer over
commonly-used functionality so access to that functionality is shorter
and more concise leads to clearer code and simplifies development.
3. Not all organizations or development efforts are able to employ
javascript programmers with the level of knowledge required to write
robust, cross-browser code. Having a library of pre-written code by
someone who is much more experienced allows more inexperienced
javascript developers to perform complex tasks and develop
functionality that otherwise could not have realistically been
written.
4. A single library js file can be used on many pages throughout a web
site or webapp, and the reasonable assumption is that browsers will
cache the source. Rather than writing page-specific code (or putting
reusable functions in each page where they are required) that is
downloaded with each request, the caching of the library code can
result in faster pages.
There are caveats, of course. I don't think that using a general-
purpose library is always a good solution. Do you never believe that
it _is_ a good solution?
Under what situations do you think that using a general-purpose
library is a good choice? What kind of functionality would this
library have or not have?
Matt Kruse
Richard Cornford
> On Nov 17, 8:47 pm, Richard Cornford wrote:
>
>> But where is your statement of a valid justification for the creation
>> of a 'library' to start with? Without that we haven't even arrived
>> at this question.
>
> Some arguments in favor of a 'library' are:
Arguments in favour of a 'library' are things that can only be achieved
with a library and are in some sense favourable.
> 1. Normalizing browser behavior, to the greatest extent possible,
That does not require a library. And normalizing browser behaviour to
the greatest extent possible is not a particularly good idea because any
code acting to normalise any browser behaviour that is irrelevant in
context is wistful.
> and encapsulating the code required to do so into a 'standard'
> API relieves the developer of the effort of considering browser
> quirks every time code is to be written.
You can only get a 'standard' API if that API is designed for a worst
case scenario (say, must make provision for operating with multiple
frames/framesets regardless of whether any particular application has
frames or not) and be all encompassing. Otherwise you end up with
multiple APIs, and none of them in a position to be regarded as
'standard'.
A system where multiple smaller scale APIs are aggregated for any given
application would be considerably more efficient, but could not easily
be regarded as 'a library'.
> 2. The code required to perform some common and repeated
> javascript tasks correctly can be long and error-prone.
> Putting a layer over commonly-used functionality so access
> to that functionality is shorter and more concise leads to
> clearer code and simplifies development.
But putting a layer over commonly used complex functionality does not
require a library.
> 3. Not all organizations or development efforts are able to
> employ javascript programmers with the level of knowledge
> required to write robust, cross-browser code.
Then maybe they should not be in the business of attempting to write
cross-browser code.
It remains the case that probably the most important aspect of browser
scripting is designing a system that is appropriate for the context of
its use. If an organisation has nobody who capable of cross-browser
scripting how can they be making informed design decisions?
It is also not the case that a library is necessary to allow individuals
to do things that they would not otherwise be capable of. As is
demonstrated by all the copy and paste code collections that exist.
> Having a library of pre-written code
A library is not the only means of having access to pre-written code.
> by someone who is much more experienced
Yet we find the libraries in use are often written by individuals who
don't know enough be actually be programming in javascript. Which does
not mean that they are not more experienced than these 'inexperienced'
developers, but it does say something about the sorts of outcomes that
can be expected.
> allows more inexperienced javascript
> developers to perform complex tasks and develop functionality
> that otherwise could not have realistically been written.
You mean 'realistically written by them', because if a library could
facilitate its creation in some sense then it must have been writable to
start with. Libraries don't perform magic so anything that could be done
with one could also be done without one.
> 4. A single library js file can be used on many pages throughout
> a web site or webapp, and the reasonable assumption is that
> browsers will cache the source.
As may be true for any single javascript file, so not an argument in
favour of libraries, but instead an argument in favour of the considered
deployment of javascript code.
> Rather than writing page-specific code (or putting
> reusable functions in each page where they are required) that is
> downloaded with each request,
The situation is not a choice of using a library or writing page
specific code.
> the caching of the library code can result in faster pages.
The caching of any code can result in faster pages. There is nothing
special about files containing 'libraries' that encourages their
caching.
And there are no shortage of examples where people are including entire
libraries in web pages to do ridiculously trivial tasks. Just last week
someone posted a suggestion here that an OP include Prototype.js in a
web page just in order to reference two elements by ID and set their -
style.display - properties. It does not matter how much caching goes on
in that process, the outcome will absolutely not be faster pages.
> There are caveats, of course. I don't think that using a
> general- purpose library is always a good solution. Do you
> never believe that it _is_ a good solution?
A good solution to what? The current set of general purpose libraries
have a perverse attitude towards browser support. Too much for most
Intranet/web applications uses, and too little for public web
applications.
> Under what situations do you think that using a
> general-purpose library is a good choice?
Whenever such a library exactly matched the application it was to be
put to, with nothing superfluous or wasteful in context.
> What kind of functionality would this
> library have or not have?
Exactly the functionality necessary for the task.
So your list does not include anything that both requires a library and
is favourable. Thus there is no argument in favour of libraries here.
Richard.
Randy Webb
> On Nov 19, 2:29 pm, Matt Kruse wrote:
>> On Nov 17, 8:47 pm, Richard Cornford wrote:
>>
>>> But where is your statement of a valid justification for the creation
>>> of a 'library' to start with? Without that we haven't even arrived
>>> at this question.
>>
>> Some arguments in favor of a 'library' are:
>
> Arguments in favour of a 'library' are things that can only be achieved
> with a library and are in some sense favourable.
And what one person finds favorable another finds objectionable and the
debate never ends.
Matt Kruse
wrote:
> On Nov 19, 2:29 pm, Matt Kruse wrote:
> > Some arguments in favor of a 'library' are:
> Arguments in favour of a 'library' are things that can only be achieved
> with a library and are in some sense favourable.
That is quite a bias to begin with. I see no reason why arguments in
favor of a library must be things that can only be achieved with a
library. Rather, a library is one way to gain the benefits that I
listed. Given a very specific context, a library may or not be the
best choice in a given situation. So I think you're starting out with
a ridiculous set of criteria with which to judge the suitability of a
'library' approach.
I think you should rather consider the possible benefits of a using a
library, then consider the cons, and decide if overall it is a good
choice. If you consider all the factors, I find it hard to believe
that you think using a library is _never_ the best choice.
> > 1. Normalizing browser behavior, to the greatest extent possible,
> That does not require a library.
Of course not, but using a library is one way to accomplish the goal.
> And normalizing browser behaviour to
> the greatest extent possible is not a particularly good idea because any
> code acting to normalise any browser behaviour that is irrelevant in
> context is wistful.
Why so? If I have an internal webapp used by 10 people on a LAN, do
you really think that an extra 50k of js code on a page is of any
concern to to me? In some contexts, this may be a con. Not in all.
> You can only get a 'standard' API if that API is designed for a worst
> case scenario
Not at all. "Standard" doesn't have to mean that it covers all cases.
Just that it is the API used regularly in most cases. A "standard" API
can put restrictions on its applicability, as well. There are plenty
of "standard" API's out there that don't handle every possible use
case.
> But putting a layer over commonly used complex functionality does not
> require a library.
Of course not. But it is one benefit of a library.
> > 3. Not all organizations or development efforts are able to
> > employ javascript programmers with the level of knowledge
> > required to write robust, cross-browser code.
> Then maybe they should not be in the business of attempting to write
> cross-browser code.
The lack of expertise in an area has never been much of a concern for
businesses in the past. It just means you have to be more creative in
solving the problem. If every company needed to be an expert in every
area of work they did, surely there would be few successful companies.
The fact is, sometimes you need to do the best you can with the
resources you have. To expect anything else is truly naive.
> > Having a library of pre-written code
> A library is not the only means of having access to pre-written code.
Of course not, but it is one approach.
> > by someone who is much more experienced
> Yet we find the libraries in use are often written by individuals who
> don't know enough be actually be programming in javascript.
And yet they do so, and their work is used by thousands of people on
thousands of successful web sites around the world. If they don't know
enough to write javascript, how do you account for their success?
Surely if their work was horrible it would have been exposed by now
and the free market of information would have found a better
replacement, no?
> > 4. A single library js file can be used on many pages throughout
> > a web site or webapp, and the reasonable assumption is that
> > browsers will cache the source.
> [snip]
> And there are no shortage of examples where people are including entire
> libraries in web pages to do ridiculously trivial tasks.
Which is part of my argument - if you include jquery.js on every page,
for example, some pages may use it heavily while others use it only
for a line or two. But once it's cached, it doesn't even matter. You
can use it for just 2 lines if you want to on a page without worrying
because it doesn't require a big additional download.
> > There are caveats, of course. I don't think that using a
> > general- purpose library is always a good solution. Do you
> > never believe that it _is_ a good solution?
> A good solution to what?
Anything. Is there any case you can dream up where you think, for
example, that using YUI or jQuery or Prototype is a good decision? Or
do you think it's always, universally a bad choice?
> > Under what situations do you think that using a
> > general-purpose library is a good choice?
> Whenever such a library exactly matched the application it was to be
> put to, with nothing superfluous or wasteful in context.
Why is it important to not have waste?
Matt Kruse
Richard Cornford
> On Nov 24, 10:50 am, Richard Cornford wrote:
>> On Nov 19, 2:29 pm, Matt Kruse wrote:
>>> Some arguments in favor of a 'library' are:
>> Arguments in favour of a 'library' are things that can only be
>> achieved with a library and are in some sense favourable.
>
> That is quite a bias to begin with. I see no reason why arguments
> in favor of a library must be things that can only be achieved
> with a library.
Yes, in retrospect that position is too extreme. An argument in favour
of libraries might also be something that is favourable but could be
achieved in a number of ways but where the library was objectively the
best way of achieving it.
Remember the question that drove this branch of the thread. We have a
situation where there is a fair sized group of individuals who have
browser scripting expertise but do not spend their time creating general
purpose javascript libraries, and evidence that the individuals who are
working on general purpose javascript libraries don't know enough to
avoid demonstrating an ignorance of the language they are using. If the
a-priori assumption that creating general purpose libraries is an
optimum strategy is a valid assumption then the status quo warrants some
explanation, as it would be an otherwise unexpected situation. On the
other hand, if the assumption is invalid, so and creating general
purpose libraries is actually a manifestation of a novice mistake, then
the status quo is an understandable (even inevitable) outcome. We were
asked why the current situation pertains, and so a rigorous examination
of the assumption seems like a reasonable step toward answering that
question.
> Rather, a library is one way to gain the benefits that I
> listed.
If you want to drive a nail into a piece of wood using a rock is one way
of doing so. But being able to do it that way is hardly an argument in
favour of using rocks for the task.
> Given a very specific context, a library may or not be
> the best choice in a given situation.
And if you only had a rock to drive your nails then using a rock becomes
the best choice for driving nails.
> So I think you're starting out with a ridiculous set of
> criteria with which to judge the suitability of a
> 'library' approach.
You still did not present any arguments for libraries being the best way
achieving the things you listed.
> I think you should rather consider the possible benefits of a
> using a library, then consider the cons, and decide if overall
> it is a good choice.
I can consider those things. Achieving optimum outcomes for web projects
though informed design decision making is the panicle of the browser
scripting skill-set. But one of your arguments in favour of libraries is
that they allow individuals who don't have the necessary skills to do
jobs that they re not qualified to for. So how do they then apply the
knowledge they don't have to the decisions they must make?
> If you consider all the factors, I find it hard to believe
> that you think using a library is _never_ the best choice.
Did I ever say that could never be the case?
>>> 1. Normalizing browser behavior, to the greatest extent
>>> possible,
>
> That does not require a library.
>
> Of course not, but using a library is one way to accomplish
> the goal.
But being one way to do something is not actually an argument in favour
of doing it in that particular way.
>> And normalizing browser behaviour to the greatest extent
>> possible is not a particularly good idea because any code
>> acting to normalise any browser behaviour that is irrelevant
>> in context is wistful.
^^^^^^^
Should have been "wasteful".
>
> Why so? If I have an internal webapp used by 10 people on a LAN, do
> you really think that an extra 50k of js code on a page is of any
> concern to to me?
Over the years I have repeatedly been impressed by our capacity for not
being concerned.
So we have an internal web app being used by 10 individuals? How many
browsers does that involve? It must be ten or fewer, and realistically
it is likely to be just one or two, and those will likely be IE 6 or 7
and Firefox or Safari. At which point the need for "normalizing browser
behaviour" has almost despaired. The standard DOM API is going to be
good enough for 95% of what is likely to be needed in context.
> In some contexts, this may be a con. Not in all.
>
>> You can only get a 'standard' API if that API is designed
>> for a worst case scenario
>
> Not at all. "Standard" doesn't have to mean that it covers all cases.
To be regarded as "a 'standard' API" there has to be only one, and if
there is only one it has to accommodate all that is asked of it, which
is "Normalizing browser behaviour, to the greatest extent possible" in
this context.
> Just that it is the API used regularly in most cases. A
> "standard" API can put restrictions on its applicability,
> as well. There are plenty of "standard" API's out there
> that don't handle every possible use case.
Where an API is not all encompassing it still covers every possible use
case, because their own restrictions define "possible" for them.
You appear to be backing away form "greatest extent possible", where
"greatest extent possible" is the requirement that separates the
alternatives for "normalizing browser behavior" from the general purpose
library approach.
>> But putting a layer over commonly used complex functionality
>> does not require a library.
>
> Of course not. But it is one benefit of a library.
You have made no case for that here. The possible advantages of putting
a layer over commonly used complexity are independent of that layer
possibly featuring in a library, and so cannot be "one benefit of a
library".
And we also see plenty of examples where libraries have put layers of
ridiculous complexity over commonly used internal simplicity. Dojo, for
example, has an IFRAME creation method that tests and branches all aver
the place (with a different browser being the - else - case in each
branch) despite there being a 'one code fits all' method of creating and
inserting IFRAMEs that works fine with the 3 or 4 browsers dojo is
interested in. Or that javascript code insertion function from JQuery,
where three possible branches may be taken and the author has not seen
that if the final branch works at all it would work with all the
browsers that have taken either of the other two branches.
Wrapping a layer around internal complexity is one thing, having that
layer needlessly multiply the internal complexity is something else
entirely.
>>> 3. Not all organizations or development efforts are able to
>>> employ javascript programmers with the level of knowledge
>>> required to write robust, cross-browser code.
>
>> Then maybe they should not be in the business of attempting
>> to write cross-browser code.
>
> The lack of expertise in an area has never been much of a
> concern for businesses in the past.
Bullshit (particularly the "never").
> It just means you have to be more creative in
> solving the problem.
No amount of creativity is going to turn someone who does not know how
to do it into an architect capable of designing and overseeing the
building of a skyscraper. In reality there are only a very limited
number of fields where you can get away with not knowing what you are
doing, and that still does not make attempting to do so a good idea.
> If every company needed to be an expert in every
> area of work they did, surely there would be few
> successful companies.
Doesn't that pre-suppose that companies that are successful do not have
expertise in the fields where they operate? If your assumption that
"lack of expertise in an area has never been much of a concern for
businesses" is not valid then the existence of successful companies does
not speak for endemic ignorance and incompetence in business.
> The fact is, sometimes you need to do the best you
> can with the resources you have. To expect anything
> else is truly naive.
There is never a choice but do the best you can with the resources
available, except maybe doing less than you could with the resources
available. But in practice systems are usually not so closed that the
resources available are fixed. It is certainly not unreasonable to take
the position that if something cannot be sensibly achieved without
particular resources then it is only rational to acquire those
resources.
>>> Having a library of pre-written code
>> A library is not the only means of having access
>> to pre-written code.
>
> Of course not, but it is one approach.
But not the best approach (particularly where the authors of that
re-used code don't know the language they are using to write the code).
>>> by someone who is much more experienced
>> Yet we find the libraries in use are often written by individuals
>> who don't know enough be actually be programming in javascript.
>
> And yet they do so,
Yes, the less experienced will make worse mistakes than the more
experienced, even when the 'more experienced' are not really that
experienced.
> and their work is used by thousands of people on
> thousands of successful web sites around the world.
> If they don't know enough to write javascript, how
> do you account for their success?
The generally low standard of the completion (or the absence of direct
completion) would be sufficient explanation.
> Surely if their work was horrible it would have been
> exposed by now and
Do you really regard, for example, Google groups as not having been
exposed by now? We know Google groups is programmed by a mass of
incompetent jellies who are totally out of their depth.
> the free market of information would have found a better
> replacement, no?
Not necessarily. If there was a better alternative then Google groups
would suffer from it, but who has the long term Usenet archives that
would be necessary to compete?
>>> 4. A single library js file can be used on many pages
>>> throughout a web site or webapp, and the reasonable
>>> assumption is that browsers will cache the source.
>> [snip]
>> And there are no shortage of examples where people are
>> including entire libraries in web pages to do ridiculously
>> trivial tasks.
>
> Which is part of my argument - if you include jquery.js on
> every page, for example, some pages may use it heavily while
> others use it only for a line or two.
And there you start with an "if". The example I cited did not include
any indication that there were any other pages involved at all, let
alone that they would be likely to be subject to more complex scripted
manipulation.
> But once it's cached, it doesn't even matter.
> You can use it for just 2 lines if you want to on a
> page without worrying because it doesn't require a big
> additional download.
Downloading is not the only issue. Once loaded the script code still
needs to be complied into an executable form before it can be used.
>>> There are caveats, of course. I don't think that using a
>>> general- purpose library is always a good solution. Do you
>>> never believe that it _is_ a good solution?
>> A good solution to what?
>
> Anything. Is there any case you can dream up where you think,
> for example, that using YUI or jQuery or Prototype is a good
> decision? Or do you think it's always, universally a bad choice?
You are forgetting what YUI is. It is an application framework for a
fairly larger search engine. In the event of working for a fairly large
search engine and needing an application framework it is extremely
likely to be pretty much 100% fit for the task, and so make not using it
an extremely questionable thing to be doing.
Prototype.js, on the other hand, is just a streaming pile of excrement,
and so fundamentally poorly designed that it could never be 'fixed'
(beyond its just being deleted) so there are no circumstances where I
could envision using that.
>>> Under what situations do you think that using a
>>> general-purpose library is a good choice?
>> Whenever such a library exactly matched the application it
>> was to be put to, with nothing superfluous or wasteful in
>> context.
>
> Why is it important to not have waste?
Download speed, loading and complying speed, runtime execution speed,
reliability relating to complexity, management/maintenance and QA costs
relating to complexity, management/maintenance costs relating to code
bulk. KISS is too good a principle to be abandoned just because it is
one option.
Richard.