Rails spinoffs - Jul 2006 - RE: Re: Documenting Prototype...

> What is the story with Sam? I don''t remember seeing a post from
him in
> the last year.  Sometimes I wonder if his general absence partly due
> to the JavaScript community''s fervent dislike of his Prototype.js
> library.
I like his library, I just wish he''d test in IE when he makes major
changes that totally break functionality (like cleanWhitespace in the
latest release in IE - there have been other examples).

I''ve submitted a couple patches over the last year, and some eventually
got implemented.  He never said a word to me, though.  Would''ve liked a
''hey thanks'' or even just some acknowledgement that he cared
about the
community.

I really wish he would either be more involved, or release it to the
community to be maintained.  As it is, I''m stuck with scriptaculous 1.5
because I can''t upgrade prototype until it''s fixed.  Will it
ever be
fixed?  Who knows?  This is the problem when one person maintains total
control over a project; if he buggers off, everyone else is S.O.L.  

I guess I shouldn''t complain about free software.

Greg

Hill, Greg wrote:
>> What is the story with Sam? I don''t remember seeing a post
from him in
>> the last year.  Sometimes I wonder if his general absence partly due
>> to the JavaScript community''s fervent dislike of his
Prototype.js
>> library.
> 
> I like his library, I just wish he''d test in IE when he makes
major
> changes that totally break functionality (like cleanWhitespace in the
> latest release in IE - there have been other examples).
> 
> I''ve submitted a couple patches over the last year, and some
eventually
> got implemented.  He never said a word to me, though.  Would''ve
liked a
> ''hey thanks'' or even just some acknowledgement that he
cared about the
> community.
Here''s a "me too."  The first time I looked at prototype.js,
I was
*impressed* and I''m not one to impress easily.  The code was beautiful
and inspiring.  I''ve wanted to contribute ever since.  I spent a couple
months helping out on dev.rubyonrails.org responding to bugs, submitting
patches, helping users.  I''ve been on this mailing list for five months
now.  I''ve had patches applied, but Sam''s never acknowledged
me.

I''m a bit of critic of Sam-as-maintainer, but I still believe in
Prototype-the-project.  I *want* to help.
> I really wish he would either be more involved, or release it to the
> community to be maintained.  As it is, I''m stuck with
scriptaculous 1.5
> because I can''t upgrade prototype until it''s fixed.  Will
it ever be
> fixed?  Who knows?  This is the problem when one person maintains total
> control over a project; if he buggers off, everyone else is S.O.L.  
There''s been discussions on the list in the past about forking and how
a
fork wouldn''t be likely to be successful because it wouldn''t
be
associated with RoR.  To that end, I''m going to pursue getting commit
rights to rails/spinoffs.  Thomas, can you provide any assistance here?
 Do you have commit rights to spinoffs/prototype, or are you isolated to
spinoffs/scriptaculous?  If yes, would you be willing to apply
community-discussed/approved patches?  Is there a specific person
associated with the SVN repositories that I should be talking to about
getting a developer account?  Talking to Sam has been a complete dead
end for me so far.

Todd Ross

On 7/19/06, Todd Ross
<rails-spinoffs-25kFIyuv2iRiLUuM0BA3LQ@public.gmane.org> wrote:
> but I still believe in Prototype-the-project.
I''m curious why.

I''ve been reading different criticisms of Prototype.js on the web for
months and wonder why it is the default JavaScript library for Rails.
Perhaps there weren''t many options avaliable when Prototype.js was
chosen for Rails but that is changing.

I would like to see Prototype.js out of Rails in favor of something
more like the Yahoo! UI approach. More modular. More standard style
JavaScript.

Prototype.js tries to make JavaScript like Ruby. That is unnecessary
as JavaScript is a fully capable language of it''s own. Then Rails
wraps Prototype.js code in Ruby. That is a lot of potentially buggy
wrapping and not at all DRY! JavaScript is repeated by Prototype.js
which is repeated by Ruby. Maintenance nightmare!

All this along with the fact that the prototype.js project is not
responsive is going to hold back the future success of Rails.
Client-side code will be a bigger and bigger part of web apps as we
head towards Web 3.0 (whatever that is) and beyond.

For example, I virtually rewrote the scriptaculous drag and drop
library to clean it up and fix about 15 tickets total. The whole thing
deadended because I couldn''t take the punishment that Prototype.js was
giving to me daily.

Peter

Sounds like a vote to remove the prototype dependency from  
scriptaculous.  I''m in favor for all sorts of reasons.

A clean separation obviates any the-owner-doesn''t-participate-anymore- 
style discussions. I want to be able to trim the file size by  
removing unused functions. I want my developers to be able to  
understand it without learning the new syntax. I don''t want to have  
to suffer the slowdown introduced by some of the syntactic sugar.


TAG

On Jul 19, 2006, at 4:03 PM, Peter Michaux wrote:
> Prototype.js tries to make JavaScript like Ruby. That is unnecessary
> as JavaScript is a fully capable language of it''s own.
<snip>
>
> <snip>
>
> For example, I virtually rewrote the scriptaculous drag and drop
> library to clean it up and fix about 15 tickets total. The whole thing
> deadended because I couldn''t take the punishment that Prototype.js
was
> giving to me daily.
>
> Peter
> _______________________________________________
> Rails-spinoffs mailing list
> Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs

My vote is against removing it, if any votes are being counted here, which I
don''t think they are.

On 7/19/06, Tom Gregory <tomg-PGZyUNKar/Q@public.gmane.org>
wrote:
>
> Sounds like a vote to remove the prototype dependency from
> scriptaculous.  I''m in favor for all sorts of reasons.
>
> A clean separation obviates any
the-owner-doesn''t-participate-anymore-
> style discussions. I want to be able to trim the file size by
> removing unused functions. I want my developers to be able to
> understand it without learning the new syntax. I don''t want to
have
> to suffer the slowdown introduced by some of the syntactic sugar.
>
>
> TAG
>
> On Jul 19, 2006, at 4:03 PM, Peter Michaux wrote:
>
> > Prototype.js tries to make JavaScript like Ruby. That is unnecessary
> > as JavaScript is a fully capable language of it''s own.
<snip>
> >
> > <snip>
> >
> > For example, I virtually rewrote the scriptaculous drag and drop
> > library to clean it up and fix about 15 tickets total. The whole thing
> > deadended because I couldn''t take the punishment that
Prototype.js was
> > giving to me daily.
> >
> > Peter
> > _______________________________________________
> > Rails-spinoffs mailing list
> > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
>
> _______________________________________________
> Rails-spinoffs mailing list
> Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
>

_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs

Peter Michaux wrote:
> On 7/19/06, Todd Ross
<rails-spinoffs-25kFIyuv2iRiLUuM0BA3LQ@public.gmane.org> wrote:
> 
>> but I still believe in Prototype-the-project.
> 
> I''m curious why.
I''ve already eluded to the why.  Its the cleanest, most elegant
JavaScript code base that I''ve ever laid eyes on.  My first exposure to
Prototype was when I was tasked with evaluating JavaScript libraries for
work.  I evaluated Prototype, Dojo, and a handful of other, smaller,
ones.  YUI wasn''t available until a couple months after we had already
chosen Prototype, not that it would have affected my decision.  Dojo
threw JavaScript errors left and right just browsing their website.
That doesn''t inspire a lot of confidence.

At the time, Prototype also /seemed/ like it was under active
development (although that can be hard to gauge as an outsider looking
in).  It was just transitioning to a rails/spinoffs project which I
expected to *speed* development, not halt it.  If I were asked to
reflect on the decision to adopt Prototype today then I''d say that I
probably backed the wrong horse, but my reasons for being attracted to
Prototype in the first place are still valid.

At this point it''s also partly momentum.  I''ve invested a fair
amount of
time in getting to know its capabilities and I''ve written a substantial
amount of code that takes advantage of them.  I''ve never touched the
RoR
wrappers however.  I''m a Perl hacker by trade.
> I would like to see Prototype.js out of Rails in favor of something
> more like the Yahoo! UI approach. More modular. More standard style
> JavaScript.
And /significantly/ more verbose.  I''ve taken a look at the YUI source
since its been released and I''m still not as impressed as I was with
Prototype.
> Prototype.js tries to make JavaScript like Ruby. That is unnecessary
> as JavaScript is a fully capable language of it''s own. Then Rails
> wraps Prototype.js code in Ruby. That is a lot of potentially buggy
> wrapping and not at all DRY! JavaScript is repeated by Prototype.js
> which is repeated by Ruby. Maintenance nightmare!
Like I said; I''ve only adopted prototype.js, not RoR.  script.aculo.us
has a foot in the door where I work (another developer has adopted it)
although I haven''t done much with it.  But, that would have pulled in
Prototype anyway.
> All this along with the fact that the prototype.js project is not
> responsive is going to hold back the future success of Rails.
> Client-side code will be a bigger and bigger part of web apps as we
> head towards Web 3.0 (whatever that is) and beyond.
And, that''s the rub.  It''s why I''ve been such a vocal
critic of the way
that its being maintained.  Prototype *is* falling behind.  There is
*no* stated direction for the project.  It has one foot in the grave.
The people who want to contribute to its success are being put off.
> For example, I virtually rewrote the scriptaculous drag and drop
> library to clean it up and fix about 15 tickets total. The whole thing
> deadended because I couldn''t take the punishment that Prototype.js
was
> giving to me daily.
And did you submit patches for those tickets before giving up?  Thomas
has been pretty responsive in my experience.

Todd Ross

On 7/19/06, Todd Ross
<rails-spinoffs-25kFIyuv2iRiLUuM0BA3LQ@public.gmane.org>
wrote:
>
> [Prototype.js is] the cleanest, most elegant
> JavaScript code base that I''ve ever laid eyes on.
I respect your right to think that but I certainly feel the other way
on the issue. For me, Prototype.js suffers from being too clever for
it''s own good. With the Yahoo! UI library I can just jump straight in
and start reading the code and make sense of it. Prototype.js seems to
abstract things way to much to a terse style that is unreadable. (I
just read a blog about this happening in Ruby code
http://blog.hasmanythrough.com/articles/2006/07/19/speaking-at-rubyconf-2006)

---------------

Prototype.js was written without full regard for the ECMAScript
specifications. Prototype.js makes use of properties like $() and $A()
which the ECMAScript specifications

http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf

says

"The dollar sign is intended for use only in mechanically generated
code."

Prototype.js also over uses $() at the beginning of so many functions
where it is not necessary. The calling function is sending the results
of a $() anyway.

This is just one example but I would guess that Prototype.js breaks
other specs but I don''t know for sure.

---------------

Playing with the prototypes of built-in JavaScript objects like Object
was a big design mistake. (I imagine Sam got this idea from page 123
of Flanagan''s JavaScript 4th ed by O''Reilly.) Although this
tampering
is possible it is probably not wise for a big library that must play
nicely with other libraries.

Given this design decision was made at all, the disasters it has
caused, and that the same attitude was likely taken in making other
design decisions, I''m left wondering what other disasters will crop up
in the future.

---------------

Prototype.js is not "cross-browser". I believe it is buggy partly due
to the obscuring effect of all the "write-javascript-like-ruby" code.
It is partly buggy because Sam is elusive.

Prototype.js uses navigator.userAgent instead of feature detection
where it is possible. This means that as browsers evolve Prototype.js
does not automatically evolve with them. It is an endless maintenance
cycle (at least worse than it needs to be).

--------------

The Ruby-style enumerable stuff is a good way to cause trouble. It is
many lines of JavaScript. It doesn''t really save bytes that need to be
downloaded by a user. Even if it does save a bite or two it would take
a big library to make up for the bulk in Prototype.js to set up the
enumerable stuff.

Because the enumerable stuff is written in JavaScript it will never
run as quickly as native JavaScript loops. The enumerable stuff will
never be as easily read or maintained by a JavaScript expert not
familiar with Prototype.js. The enumerable stuff will probably need
tinkering along the way and new bugs will appear. JavaScript is not a
cool as Ruby but it is not assembly level language either. Using the
native loops is better in my opinion.

--------------
> If I were asked to reflect on the decision to adopt Prototype today then
I''d say that I
> probably backed the wrong horse,
Unfortunately so did Rails and Scriptaculous. Rails is the biggest
community using Prototype.js and I think it will ultimately hold back
Rails because it is so convoluted. I think a new JavaScript library
should be chosen or developed for use with Rails and have a plugin
Ruby wrapper. Then move Prototype out to a plugin for backwards
compatibility and absorb the new library into Rails as the default.

> > I would like to see Prototype.js out of Rails in favor of something
> > more like the Yahoo! UI approach. More modular. More standard style
> > JavaScript.
>
> And /significantly/ more verbose.
Something _like_ Yahoo! UI. I don''t think YUI is the perfect solution.
I certainly think YAHOO.util.Dom.getXY() could be shortened to
YUI.getXY().

Prototype.js is a huge library. Something like 1800 lines if I
remember correctly. And Prototype.js is going to get even bigger to
overcome _only one_ of it''s problems in a backwards compatible way.

http://sam.conio.net/

> And, that''s the rub.  It''s why I''ve been such a
vocal critic of the way
> that its being maintained.  Prototype *is* falling behind.  There is
> *no* stated direction for the project.
There is a stated direction it just isn''t very inspiring

http://sam.conio.net/


> It has one foot in the grave.
> The people who want to contribute to its success are being put off.
A bad sign for sure. But this could easily be fixed by a higher up
like DHH himself.

> > For example, I virtually rewrote the scriptaculous drag and drop
> > library to clean it up and fix about 15 tickets total. The whole thing
> > deadended because I couldn''t take the punishment that
Prototype.js was
> > giving to me daily.
>
> And did you submit patches for those tickets before giving up?  Thomas
> has been pretty responsive in my experience.
No I didn''t submit patches because they were all part of the rewrite.
I was so discouraged by the use of Prototype.js I just shelved the
project and moved on to other things. After really digging through the
dragdrop library for a week and refactoring/rewriting it in the same
style, I decided I just didn''t want any part of a library built on
Prototype.js. I emailed with Thomas a couple times and he was quite
responsive.

I think Prototype.js is a lost cause by design.

Peter

"I think Prototype.js is a lost cause by design."
So-- then what are you doing on the Prototype/script.aculo.us mailing  
list? :)

The sole point of Prototype is to give the programmer a powerful,  
opinionated
toolset, to make programming JavaScript less pain (with some extra  
special
sugar-on-the-top for Ruby devs).

IMHO, saying things like ''I would guess that Prototype.js breaks  
other specs''  and
''I''m left wondering what other disasters will crop up in the
future''
is just spreading
FUD.

Spreading FUD on JavaScript-related stuff won''t help any libraries  
out there.

Best,
Thomas

Am 20.07.2006 um 02:12 schrieb Peter Michaux:
> On 7/19/06, Todd Ross
<rails-spinoffs-25kFIyuv2iRiLUuM0BA3LQ@public.gmane.org> wrote:
>>
>> [Prototype.js is] the cleanest, most elegant
>> JavaScript code base that I''ve ever laid eyes on.
>
> I respect your right to think that but I certainly feel the other way
> on the issue. For me, Prototype.js suffers from being too clever for
> it''s own good. With the Yahoo! UI library I can just jump straight
in
> and start reading the code and make sense of it. Prototype.js seems to
> abstract things way to much to a terse style that is unreadable. (I
> just read a blog about this happening in Ruby code
> http://blog.hasmanythrough.com/articles/2006/07/19/speaking-at- 
> rubyconf-2006)
>
> ---------------
>
> Prototype.js was written without full regard for the ECMAScript
> specifications. Prototype.js makes use of properties like $() and $A()
> which the ECMAScript specifications
>
> http://www.ecma-international.org/publications/files/ECMA-ST/ 
> Ecma-262.pdf
>
> says
>
> "The dollar sign is intended for use only in mechanically generated  
> code."
>
> Prototype.js also over uses $() at the beginning of so many functions
> where it is not necessary. The calling function is sending the results
> of a $() anyway.
>
> This is just one example but I would guess that Prototype.js breaks
> other specs but I don''t know for sure.
>
> ---------------
>
> Playing with the prototypes of built-in JavaScript objects like Object
> was a big design mistake. (I imagine Sam got this idea from page 123
> of Flanagan''s JavaScript 4th ed by O''Reilly.) Although
this tampering
> is possible it is probably not wise for a big library that must play
> nicely with other libraries.
>
> Given this design decision was made at all, the disasters it has
> caused, and that the same attitude was likely taken in making other
> design decisions, I''m left wondering what other disasters will
crop up
> in the future.
>
> ---------------
>
> Prototype.js is not "cross-browser". I believe it is buggy partly
due
> to the obscuring effect of all the "write-javascript-like-ruby"
code.
> It is partly buggy because Sam is elusive.
>
> Prototype.js uses navigator.userAgent instead of feature detection
> where it is possible. This means that as browsers evolve Prototype.js
> does not automatically evolve with them. It is an endless maintenance
> cycle (at least worse than it needs to be).
>
> --------------
>
> The Ruby-style enumerable stuff is a good way to cause trouble. It is
> many lines of JavaScript. It doesn''t really save bytes that need
to be
> downloaded by a user. Even if it does save a bite or two it would take
> a big library to make up for the bulk in Prototype.js to set up the
> enumerable stuff.
>
> Because the enumerable stuff is written in JavaScript it will never
> run as quickly as native JavaScript loops. The enumerable stuff will
> never be as easily read or maintained by a JavaScript expert not
> familiar with Prototype.js. The enumerable stuff will probably need
> tinkering along the way and new bugs will appear. JavaScript is not a
> cool as Ruby but it is not assembly level language either. Using the
> native loops is better in my opinion.
>
> --------------
>
>> If I were asked to reflect on the decision to adopt Prototype  
>> today then I''d say that I
>> probably backed the wrong horse,
>
> Unfortunately so did Rails and Scriptaculous. Rails is the biggest
> community using Prototype.js and I think it will ultimately hold back
> Rails because it is so convoluted. I think a new JavaScript library
> should be chosen or developed for use with Rails and have a plugin
> Ruby wrapper. Then move Prototype out to a plugin for backwards
> compatibility and absorb the new library into Rails as the default.
>
>
>> > I would like to see Prototype.js out of Rails in favor of
something
>> > more like the Yahoo! UI approach. More modular. More standard
style
>> > JavaScript.
>>
>> And /significantly/ more verbose.
>
> Something _like_ Yahoo! UI. I don''t think YUI is the perfect
solution.
> I certainly think YAHOO.util.Dom.getXY() could be shortened to
> YUI.getXY().
>
> Prototype.js is a huge library. Something like 1800 lines if I
> remember correctly. And Prototype.js is going to get even bigger to
> overcome _only one_ of it''s problems in a backwards compatible
way.
>
> http://sam.conio.net/
>
>
>> And, that''s the rub.  It''s why I''ve been
such a vocal critic of
>> the way
>> that its being maintained.  Prototype *is* falling behind.  There is
>> *no* stated direction for the project.
>
> There is a stated direction it just isn''t very inspiring
>
> http://sam.conio.net/
>
>
>
>> It has one foot in the grave.
>> The people who want to contribute to its success are being put off.
>
> A bad sign for sure. But this could easily be fixed by a higher up
> like DHH himself.
>
>
>> > For example, I virtually rewrote the scriptaculous drag and drop
>> > library to clean it up and fix about 15 tickets total. The whole  
>> thing
>> > deadended because I couldn''t take the punishment that  
>> Prototype.js was
>> > giving to me daily.
>>
>> And did you submit patches for those tickets before giving up?   
>> Thomas
>> has been pretty responsive in my experience.
>
> No I didn''t submit patches because they were all part of the
rewrite.
> I was so discouraged by the use of Prototype.js I just shelved the
> project and moved on to other things. After really digging through the
> dragdrop library for a week and refactoring/rewriting it in the same
> style, I decided I just didn''t want any part of a library built on
> Prototype.js. I emailed with Thomas a couple times and he was quite
> responsive.
>
> I think Prototype.js is a lost cause by design.
>
> Peter
> _______________________________________________
> Rails-spinoffs mailing list
> Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
--
Thomas Fuchs
wollzelle

http://www.wollzelle.com

questentier on AIM
madrobby on irc.freenode.net

http://www.fluxiom.com :: online digital asset management
http://script.aculo.us :: Web 2.0 JavaScript
http://mir.aculo.us :: Where no web developer has gone before

1) script.aculo.us will always depend on Prototype
2) Yes, the votes don''t count :)

Best,
Thomas

Am 20.07.2006 um 00:16 schrieb Ryan Gahl:
> My vote is against removing it, if any votes are being counted  
> here, which I don''t think they are.
>
> On 7/19/06, Tom Gregory < tomg-PGZyUNKar/Q@public.gmane.org> wrote:
> Sounds like a vote to remove the prototype dependency from
> scriptaculous.  I''m in favor for all sorts of reasons.
>
> A clean separation obviates any
the-owner-doesn''t-participate-anymore-
> style discussions. I want to be able to trim the file size by
> removing unused functions. I want my developers to be able to
> understand it without learning the new syntax. I don''t want to
have
> to suffer the slowdown introduced by some of the syntactic sugar.
>
>
> TAG
>
> On Jul 19, 2006, at 4:03 PM, Peter Michaux wrote:
>
> > Prototype.js tries to make JavaScript like Ruby. That is unnecessary
> > as JavaScript is a fully capable language of it''s own.
<snip>
> >
> > <snip>
> >
> > For example, I virtually rewrote the scriptaculous drag and drop
> > library to clean it up and fix about 15 tickets total. The whole  
> thing
> > deadended because I couldn''t take the punishment that  
> Prototype.js was
> > giving to me daily.
> >
> > Peter
> > _______________________________________________
> > Rails-spinoffs mailing list
> > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
>
> _______________________________________________
> Rails-spinoffs mailing list
> Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
>
> _______________________________________________
> Rails-spinoffs mailing list
> Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
--
Thomas Fuchs
wollzelle

http://www.wollzelle.com

questentier on AIM
madrobby on irc.freenode.net

http://www.fluxiom.com :: online digital asset management
http://script.aculo.us :: Web 2.0 JavaScript
http://mir.aculo.us :: Where no web developer has gone before






_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs

Hello Thomas,

Although, I understand your anger a little - I do also understand the big
anger, pain, and frustration of this community due to the lack of
responsiveness to user input (ideas, patches, etc.) from Sam. We got to a
point where one has to decide either to stay with prototype and like it as
is, or add hacks, patches etc. yourself, or eventually move to something
else. There are already a lot of people moving on to something else.

I believe in the long run, prototype will only succeed if Sam is going to
listen to the community and respond to it.

I have been following the mailing list of jquery for a while and it''s a
pleasure to see how John Resig deals with the community and responds to
problems, user input and patches. Moreover, the features and documentation
gets better almost every day.

-----Original Message-----
From: rails-spinoffs-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
[mailto:rails-spinoffs-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org]
On Behalf Of Thomas
Fuchs
Sent: Thursday, July 20, 2006 10:39 AM
To: rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
Subject: Re: [Rails-spinoffs] Re: Documenting Prototype...

"I think Prototype.js is a lost cause by design."
So-- then what are you doing on the Prototype/script.aculo.us mailing  
list? :)

The sole point of Prototype is to give the programmer a powerful,  
opinionated
toolset, to make programming JavaScript less pain (with some extra  
special
sugar-on-the-top for Ruby devs).

IMHO, saying things like ''I would guess that Prototype.js breaks  
other specs''  and
''I''m left wondering what other disasters will crop up in the
future''
is just spreading
FUD.

Spreading FUD on JavaScript-related stuff won''t help any libraries  
out there.

Best,
Thomas

Am 20.07.2006 um 02:12 schrieb Peter Michaux:
> On 7/19/06, Todd Ross
<rails-spinoffs-25kFIyuv2iRiLUuM0BA3LQ@public.gmane.org> wrote:
>>
>> [Prototype.js is] the cleanest, most elegant
>> JavaScript code base that I''ve ever laid eyes on.
>
> I respect your right to think that but I certainly feel the other way
> on the issue. For me, Prototype.js suffers from being too clever for
> it''s own good. With the Yahoo! UI library I can just jump straight
in
> and start reading the code and make sense of it. Prototype.js seems to
> abstract things way to much to a terse style that is unreadable. (I
> just read a blog about this happening in Ruby code
> http://blog.hasmanythrough.com/articles/2006/07/19/speaking-at- 
> rubyconf-2006)
>
> ---------------
>
> Prototype.js was written without full regard for the ECMAScript
> specifications. Prototype.js makes use of properties like $() and $A()
> which the ECMAScript specifications
>
> http://www.ecma-international.org/publications/files/ECMA-ST/ 
> Ecma-262.pdf
>
> says
>
> "The dollar sign is intended for use only in mechanically generated  
> code."
>
> Prototype.js also over uses $() at the beginning of so many functions
> where it is not necessary. The calling function is sending the results
> of a $() anyway.
>
> This is just one example but I would guess that Prototype.js breaks
> other specs but I don''t know for sure.
>
> ---------------
>
> Playing with the prototypes of built-in JavaScript objects like Object
> was a big design mistake. (I imagine Sam got this idea from page 123
> of Flanagan''s JavaScript 4th ed by O''Reilly.) Although
this tampering
> is possible it is probably not wise for a big library that must play
> nicely with other libraries.
>
> Given this design decision was made at all, the disasters it has
> caused, and that the same attitude was likely taken in making other
> design decisions, I''m left wondering what other disasters will
crop up
> in the future.
>
> ---------------
>
> Prototype.js is not "cross-browser". I believe it is buggy partly
due
> to the obscuring effect of all the "write-javascript-like-ruby"
code.
> It is partly buggy because Sam is elusive.
>
> Prototype.js uses navigator.userAgent instead of feature detection
> where it is possible. This means that as browsers evolve Prototype.js
> does not automatically evolve with them. It is an endless maintenance
> cycle (at least worse than it needs to be).
>
> --------------
>
> The Ruby-style enumerable stuff is a good way to cause trouble. It is
> many lines of JavaScript. It doesn''t really save bytes that need
to be
> downloaded by a user. Even if it does save a bite or two it would take
> a big library to make up for the bulk in Prototype.js to set up the
> enumerable stuff.
>
> Because the enumerable stuff is written in JavaScript it will never
> run as quickly as native JavaScript loops. The enumerable stuff will
> never be as easily read or maintained by a JavaScript expert not
> familiar with Prototype.js. The enumerable stuff will probably need
> tinkering along the way and new bugs will appear. JavaScript is not a
> cool as Ruby but it is not assembly level language either. Using the
> native loops is better in my opinion.
>
> --------------
>
>> If I were asked to reflect on the decision to adopt Prototype  
>> today then I''d say that I
>> probably backed the wrong horse,
>
> Unfortunately so did Rails and Scriptaculous. Rails is the biggest
> community using Prototype.js and I think it will ultimately hold back
> Rails because it is so convoluted. I think a new JavaScript library
> should be chosen or developed for use with Rails and have a plugin
> Ruby wrapper. Then move Prototype out to a plugin for backwards
> compatibility and absorb the new library into Rails as the default.
>
>
>> > I would like to see Prototype.js out of Rails in favor of
something
>> > more like the Yahoo! UI approach. More modular. More standard
style
>> > JavaScript.
>>
>> And /significantly/ more verbose.
>
> Something _like_ Yahoo! UI. I don''t think YUI is the perfect
solution.
> I certainly think YAHOO.util.Dom.getXY() could be shortened to
> YUI.getXY().
>
> Prototype.js is a huge library. Something like 1800 lines if I
> remember correctly. And Prototype.js is going to get even bigger to
> overcome _only one_ of it''s problems in a backwards compatible
way.
>
> http://sam.conio.net/
>
>
>> And, that''s the rub.  It''s why I''ve been
such a vocal critic of
>> the way
>> that its being maintained.  Prototype *is* falling behind.  There is
>> *no* stated direction for the project.
>
> There is a stated direction it just isn''t very inspiring
>
> http://sam.conio.net/
>
>
>
>> It has one foot in the grave.
>> The people who want to contribute to its success are being put off.
>
> A bad sign for sure. But this could easily be fixed by a higher up
> like DHH himself.
>
>
>> > For example, I virtually rewrote the scriptaculous drag and drop
>> > library to clean it up and fix about 15 tickets total. The whole  
>> thing
>> > deadended because I couldn''t take the punishment that  
>> Prototype.js was
>> > giving to me daily.
>>
>> And did you submit patches for those tickets before giving up?   
>> Thomas
>> has been pretty responsive in my experience.
>
> No I didn''t submit patches because they were all part of the
rewrite.
> I was so discouraged by the use of Prototype.js I just shelved the
> project and moved on to other things. After really digging through the
> dragdrop library for a week and refactoring/rewriting it in the same
> style, I decided I just didn''t want any part of a library built on
> Prototype.js. I emailed with Thomas a couple times and he was quite
> responsive.
>
> I think Prototype.js is a lost cause by design.
>
> Peter
> _______________________________________________
> Rails-spinoffs mailing list
> Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
--
Thomas Fuchs
wollzelle

http://www.wollzelle.com

questentier on AIM
madrobby on irc.freenode.net

http://www.fluxiom.com :: online digital asset management
http://script.aculo.us :: Web 2.0 JavaScript
http://mir.aculo.us :: Where no web developer has gone before




_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs

Well there you have it folks! :D

Now if only maybe instead of "depending" on Prototype, it could
"absorb" it, keeping separate libraries still, of course.

Thomas Fuchs wrote:

  1) script.aculo.us will always depend on Prototype

  2) Yes, the votes don''t count :)

  Best,

  Thomas

  Am 20.07.2006 um 00:16 schrieb Ryan Gahl:

  My vote is against removing it, if any votes
are being counted here, which I don''t think they are.

    On 7/19/06, Tom Gregory < tomg-PGZyUNKar/Q@public.gmane.org>
wrote:
    Sounds
like a vote to remove the prototype dependency from 

scriptaculous.  I''m in favor for all sorts of reasons.

A clean separation obviates any the-owner-doesn''t-participate-anymore-

style discussions. I want to be able to trim the file size by

removing unused functions. I want my developers to be able to 

understand it without learning the new syntax. I don''t want to have

to suffer the slowdown introduced by some of the syntactic sugar.

TAG

On Jul 19, 2006, at 4:03 PM, Peter Michaux wrote:

> Prototype.js tries to make JavaScript like Ruby. That is
unnecessary

> as JavaScript is a fully capable language of it''s own. 

>

> 

>

> For example, I virtually rewrote the scriptaculous drag and drop 

> library to clean it up and fix about 15 tickets total. The whole
thing

> deadended because I couldn''t take the punishment that
Prototype.js
was

> giving to me daily.

>

> Peter

> _______________________________________________ 

> Rails-spinoffs mailing list

> Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org

> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs

_______________________________________________

Rails-spinoffs mailing list

      Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org

http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs

    _______________________________________________

    Rails-spinoffs mailing list

    Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org

    http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs

  --

  Thomas Fuchs

  wollzelle

  http://www.wollzelle.com

  questentier on AIM

  madrobby on irc.freenode.net

  http://www.fluxiom.com ::
online digital asset management

  http://script.aculo.us :: Web 2.0 JavaScript

  http://mir.aculo.us :: Where no web developer has gone
before

_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs


_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs

Hi Thomas,

On 7/20/06, Thomas Fuchs <t.fuchs-moWQItti3gBl57MIdRCFDg@public.gmane.org>
wrote:
> "I think Prototype.js is a lost cause by design."
> So-- then what are you doing on the Prototype/script.aculo.us mailing
> list? :)
This is the Rails spinoffs list. It is the choice of Prototype.js as
the default JavaScript library in Rails that I am contesting.

> The sole point of Prototype is to give the programmer a powerful,
> opinionated
> toolset, to make programming JavaScript less pain
That is a great idea but unfortuntely, prototype.js ends up making it
more pain because of the many concrete reasons I listed before.

> (with some extra special sugar-on-the-top for Ruby devs).
But they are JavaScript devs when they are programming JavaScript.


Peter

Just let it go man. I''m guessing that the vast majority of people on
this
list have heard all the arguments against prototype before. It is just one
of those libraries that you either love or you love to hate. Your not
helping anyone anyone at this point. I love the ''sugar-on-the-top for
Ruby
devs'' and I purposely decided I would accept any performance hits, as
minor
as they may be, to have a more efficient and frankly more fun way to write
my JavaScript. It isn''t for everyone and it doesn''t try to be.
You can find
that with other heavier libraries.

Several of your arguments are a little puzzling to me though. You mentioned
that this library uses userAgent for browser testing. You do know that this
isn''t the only library that does that and on occasion it just
isn''t
practical to feature test.

You also mentioned the size. In my experience this library is small and is a
great starting point for extending. Especially when compared with Dojo and
YUI. Those libraries felt a little to heavy for me and way too painful to
continuously have to be typing out namespaces. Before I get flamed for that
comment, I completely understand the need for namespaces on libraries that
try to be all to all and work with other libraries. For me, this is not
necessary. I just need a good foundation and I''ll add what I need and
what I
don''t need. I''m not going to mix other libraries whole sale.

Now I have my gripes about prototype just as much as anyone else but
I''ll
add my patches and if they are good enough they will be applied, eventually.

Bottom line ... prototype takes away a lot of the pain and has been a great
foundation, for me.

Enjoy your namespaces.

On 7/20/06, Peter Michaux
<petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> Hi Thomas,
>
> On 7/20/06, Thomas Fuchs
<t.fuchs-moWQItti3gBl57MIdRCFDg@public.gmane.org> wrote:
> > "I think Prototype.js is a lost cause by design."
> > So-- then what are you doing on the Prototype/script.aculo.us mailing
> > list? :)
>
> This is the Rails spinoffs list. It is the choice of Prototype.js as
> the default JavaScript library in Rails that I am contesting.
>
>
> > The sole point of Prototype is to give the programmer a powerful,
> > opinionated
> > toolset, to make programming JavaScript less pain
>
> That is a great idea but unfortuntely, prototype.js ends up making it
> more pain because of the many concrete reasons I listed before.
>
>
> > (with some extra special sugar-on-the-top for Ruby devs).
>
> But they are JavaScript devs when they are programming JavaScript.
>
>
> Peter
> _______________________________________________
> Rails-spinoffs mailing list
> Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
>

_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs

Before I voice my view (from the bottom), let me say I''ve developed an
application which uses prototype.js, script aculo, and the "windows"
extension.  I''ve also made use of  Event Selectors and the
"debug.js" which
is offered by the "windows" group.  I have an investment beyond
academic
interest.

Our choice to develop with prototype.js resulted in a clean deliverable and
a development time which exceeded (in a good way) my expectations.  That
said, I have concerns similar to others voiced in this thread.  Prototype.js
is still on a "pre" release 1.5 (unless I missed a release?), and I
have
never witnessed any participation from the developer.  Instead, there is
what appears to be a closed-door stance, resulting in zero-visibility
conditions of upcoming releases.  Worse, the lack of a "full" 1.5
release
suggests prototype.js has been abandoned in some way, in the best case for
2.0 development, which has no announced beta date.

This is a regretful set of circumstances given the satisfaction, and the
investment I have in prototype.js.  The author may surprise us with
prototype.js 2.0, next week, next year, or not at all.  (Does anyone know?)
In the meantime, the persistent uncertainty in prototype.js support has led
me to reluctantly look at the alternatives.  I do not look forward to
rewriting our application because the foundation library (prototype.js) has
a lack of support.

My confidence in prototype.js would improve if there were any developer
interaction..  At a bare minimum, planned release dates would be a real
confidence boost.  Better yet, some interaction in this forum.  No feedback,
in addition to a languishing "pre" release, is unacceptable.

Sam (C)

They way I read this <http://sam.conio.net/> I don''t expect to be
seeing
much new funcionality. Perhaps it doesn''t need it though ?

Excerpt :

"I don’t have a roadmap for Prototype, but version 2.0—the next major 
release after 1.5—will focus on polishing what we have now, not on 
adding new functionality. You can expect Base to make its way into 
Prototype 2.0 in a form that’s backwards-compatible with Class.create 
and Object.extend."

Matt

Sam wrote:

 >
 > Before I voice my view (from the bottom), let me say I''ve
developed an
 > application which uses prototype.js, script aculo, and the
"windows"
 > extension.  I''ve also made use of  Event Selectors and the
"debug.js"
 > which
 > is offered by the "windows" group.  I have an investment beyond
academic
 > interest.
 >
 > Our choice to develop with prototype.js resulted in a clean
 > deliverable and
 > a development time which exceeded (in a good way) my expectations.  That
 > said, I have concerns similar to others voiced in this thread.
 > Prototype.js
 > is still on a "pre" release 1.5 (unless I missed a release?),
and I have
 > never witnessed any participation from the developer.  Instead, there is
 > what appears to be a closed-door stance, resulting in zero-visibility
 > conditions of upcoming releases.  Worse, the lack of a "full"
1.5 release
 > suggests prototype.js has been abandoned in some way, in the best case
 > for
 > 2.0 development, which has no announced beta date.
 >
 > This is a regretful set of circumstances given the satisfaction, and the
 > investment I have in prototype.js.  The author may surprise us with
 > prototype.js 2.0, next week, next year, or not at all.  (Does anyone
 > know?)
 > In the meantime, the persistent uncertainty in prototype.js support
 > has led
 > me to reluctantly look at the alternatives.  I do not look forward to
 > rewriting our application because the foundation library
 > (prototype.js) has
 > a lack of support.
 >
 > My confidence in prototype.js would improve if there were any developer
 > interaction..  At a bare minimum, planned release dates would be a real
 > confidence boost.  Better yet, some interaction in this forum.  No
 > feedback,
 > in addition to a languishing "pre" release, is unacceptable.
 >
 > Sam (C)
 >
 >
 >
 >
 >
 > _______________________________________________
 > Rails-spinoffs mailing list
 > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
 > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
 >

Can I just say what, here? What? That''s just a general what to this
premise
that a new release every X days/months/years is a necessary thing to the
success of (what?).

Ok, so you used prototype version X.X (doesn''t matter, I''m
still using 1.4)...
and you''ve built a clean toolkit or componenet set or application
around it
and it works great. What is the rush to get a new version of prototype? My
applications are world class medical systems (cardiology data collection and
reporting) used in hospitals around the country, and I''m still using
proto
1.4 with no immediate plan or need to upgrade to 1.5pre or 2.0 or 12.6. As
far as general support, this is the place, man. We in this list are the
support for both proto and scriptaculous and we''re damn good at that.

As I''ve said, all avenues for moving proto forward have NOT been
exhausted...

Thomas, please can we get some official statement on this matter as far
where _you_ are on it? I''m assuming you''re behind us, so can
we formally put
together some sort of action plan? Clearly you have connections, so are you
privvy to some information that''s not being generally shared in the
community about the immediate future of prototype?


On 7/20/06, Sam <sam.google-Uc2IQQBAS6sAvxtiuMwx3w@public.gmane.org>
wrote:
>
>
> Before I voice my view (from the bottom), let me say I''ve
developed an
> application which uses prototype.js, script aculo, and the
"windows"
> extension.  I''ve also made use of  Event Selectors and the
"debug.js"
> which
> is offered by the "windows" group.  I have an investment beyond
academic
> interest.
>
> Our choice to develop with prototype.js resulted in a clean deliverable
> and
> a development time which exceeded (in a good way) my expectations.  That
> said, I have concerns similar to others voiced in this thread.
> Prototype.js
> is still on a "pre" release 1.5 (unless I missed a release?), and
I have
> never witnessed any participation from the developer.  Instead, there is
> what appears to be a closed-door stance, resulting in zero-visibility
> conditions of upcoming releases.  Worse, the lack of a "full" 1.5
release
> suggests prototype.js has been abandoned in some way, in the best case for
> 2.0 development, which has no announced beta date.
>
> This is a regretful set of circumstances given the satisfaction, and the
> investment I have in prototype.js.  The author may surprise us with
> prototype.js 2.0, next week, next year, or not at all.  (Does anyone
> know?)
> In the meantime, the persistent uncertainty in prototype.js support has
> led
> me to reluctantly look at the alternatives.  I do not look forward to
> rewriting our application because the foundation library (prototype.js)
> has
> a lack of support.
>
> My confidence in prototype.js would improve if there were any developer
> interaction..  At a bare minimum, planned release dates would be a real
> confidence boost.  Better yet, some interaction in this forum.  No
> feedback,
> in addition to a languishing "pre" release, is unacceptable.
>
> Sam (C)
>
>
>
>
>
> _______________________________________________
> Rails-spinoffs mailing list
> Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
>

_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs

On 7/20/06, Matt Spendlove <mspendlove506-YDxpq3io04c@public.gmane.org>
wrote:
> They way I read this <http://sam.conio.net/> I don''t expect
to be seeing
> much new funcionality. Perhaps it doesn''t need it though ?
>
> Excerpt :
>
> "I don''t have a roadmap for Prototype, but version 2.0—the
next major
> release after 1.5—will focus on polishing what we have now, not on
> adding new functionality. You can expect Base to make its way into
> Prototype 2.0 in a form that''s backwards-compatible with
Class.create
> and Object.extend."
With the inclusion of Base it just looks like things are getting
bigger and messier.

Peter

Base _is_ completely unnecessary since I''ve demonstrated that proto
already
provides the means to achieve that functionality in a very clean manner.

But more importantly, can you stop perpetuating this thread in a completely
non-productive manner? Seriously, you are bringing no value to anyone in
this list.

If you are interested in improving prototype, that''s one thing, but
then
offer constructive ways to do so rather than just repeating yourself over
and over. You read a couple of articles out there from people critiquing
proto and now you just want to jump in as though you''re some sort of
javascript expert and we are newbies. News flash, a good lot of us in this
list are javascript experts and we''ve managed to use proto with GREAT
success in spite of anyone''s judgements against it.

Moreover, this list is a place for people to present their
problems/solutions centered around proto/scriptaculous. You are doing
neither. Just stop.

On 7/20/06, Peter Michaux
<petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> On 7/20/06, Matt Spendlove
<mspendlove506-YDxpq3io04c@public.gmane.org> wrote:
> > They way I read this <http://sam.conio.net/> I don''t
expect to be seeing
> > much new funcionality. Perhaps it doesn''t need it though ?
> >
> > Excerpt :
> >
> > "I don''t have a roadmap for Prototype, but version
2.0—the next major
> > release after 1.5—will focus on polishing what we have now, not on
> > adding new functionality. You can expect Base to make its way into
> > Prototype 2.0 in a form that''s backwards-compatible with
Class.create
> > and Object.extend."
>
> With the inclusion of Base it just looks like things are getting
> bigger and messier.
>
> Peter
> _______________________________________________
> Rails-spinoffs mailing list
> Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
>

_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs

Well said. I am sick of the prototype bashing. This is a list for  
those who WANT to use prototype. Would those who dont want to use it  
please leave.

Having said that, I also would like to say I think it is vital for  
prototype tat the lead developers have SOME presence on this list and  
let us know what the plans are even if that is in the saying "We are  
not sure, but we are still working on things" Just a simple Hi, Im  
still alive would go a long way.

As far as the "whats the rush for the next version" I somewhat  
disagree. I NEED to know that versions 1.5 and 2 are in the pipe, if  
I am going to commit my applications to the use of prototype.js. What  
happens when things break in IE7, or IE8 or Firefox4 or whatever.   
The point is browsers dont stand still, and I need to be confident  
that libraries I am dependent on will not become obsolete. I am not a  
javascipt "Expert", so I am dependent on others to maintain this code.

The FUD that I see on this thread concerns be deeply.

FUD is Fear Uncertainty and Doubt, but in this case, there is some  
validity in it.

Fear - I fear that my dependancy on prototype might be a mistake.
Uncertainty - I am uncertan that the developers of prototype are  
committed to the project, as they do not participate in this list and  
provide no information.
Doubt - I doubt that this project will survive if the developers dont  
interact with the community.

This is a cancer that will eat at the community if left unchecked.

The solution is simple. Communication between the developers and the  
community.

Just my 2 bits.

Alex Duffield



On 20-Jul-06, at 9:38 AM, Ryan Gahl wrote:
>
>
> If you are interested in improving prototype, that''s one thing,
but
> then offer constructive ways to do so rather than just repeating  
> yourself over and over. You read a couple of articles out there  
> from people critiquing proto and now you just want to jump in as  
> though you''re some sort of javascript expert and we are newbies.  
> News flash, a good lot of us in this list are javascript experts  
> and we''ve managed to use proto with GREAT success in spite of  
> anyone''s judgements against it.
>
> Moreover, this list is a place for people to present their problems/ 
> solutions centered around proto/scriptaculous. You are doing  
> neither. Just stop.
>
>


_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs

On 7/20/06, Alex Duffield
<alex-GLL9njBnHiGqPKKiFzS5XxZCeNDtXRbv@public.gmane.org>
wrote:
>
> This is a list for those who WANT to use prototype.
With Rails in the name of this mailing list, Prototype.js being in
Rails svn and Prototype.js''s direct integration in Rails core, this is
also an appropriate place to discuss the future connection of
Prototype.js and Rails. I am concerned about the long term success of
Rails not Prototype.js.

Has anyone else actually tried out this IDE Aptana (http://www.aptana.com/)?
You know ... the reason this thread was started.

Looks pretty interesting; however, I''m a TextMate fanatic and ever
since
have immediately had doubts about other editors. I might try it out later on
today if I can find the time.

On 7/20/06, Peter Michaux
<petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> On 7/20/06, Alex Duffield
<alex-GLL9njBnHiGqPKKiFzS5XxZCeNDtXRbv@public.gmane.org> wrote:
> >
> > This is a list for those who WANT to use prototype.
>
> With Rails in the name of this mailing list, Prototype.js being in
> Rails svn and Prototype.js''s direct integration in Rails core,
this is
> also an appropriate place to discuss the future connection of
> Prototype.js and Rails. I am concerned about the long term success of
> Rails not Prototype.js.
> _______________________________________________
> Rails-spinoffs mailing list
> Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
>

_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs

Also it seems that I completely overlooked where it said, "We''ve
already
documented all of prototype and would love to get it in."

That sounds like a big deal to me. Seems like every time I turn around
someone is complaining about the lack of documentation. How can we help them
get it into SVN and published? Perhaps Thomas can help?

On 7/20/06, Brandon Aaron
<brandon.aaron-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> Has anyone else actually tried out this IDE Aptana
(http://www.aptana.com/)?
> You know ... the reason this thread was started.
>
> Looks pretty interesting; however, I''m a TextMate fanatic and ever
since
> have immediately had doubts about other editors. I might try it out later
on
> today if I can find the time.
>
> On 7/20/06, Peter Michaux
<petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> > On 7/20/06, Alex Duffield
<alex-GLL9njBnHiGqPKKiFzS5XxZCeNDtXRbv@public.gmane.org> wrote:
> > >
> > > This is a list for those who WANT to use prototype.
> >
> > With Rails in the name of this mailing list, Prototype.js being in
> > Rails svn and Prototype.js''s direct integration in Rails
core, this is
> > also an appropriate place to discuss the future connection of
> > Prototype.js and Rails. I am concerned about the long term success of
> > Rails not Prototype.js.
> > _______________________________________________
> > Rails-spinoffs mailing list
> > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
> >
>
>

_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs

Fair enough.
______________________________________________________________________
Alex Duffield . Principal . InControl Solutions . http:// 
www.incontrolsolutions.com



On 20-Jul-06, at 2:50 PM, Peter Michaux wrote:
> On 7/20/06, Alex Duffield
<alex-GLL9njBnHiGqPKKiFzS5XxZCeNDtXRbv@public.gmane.org> wrote:
>>
>> This is a list for those who WANT to use prototype.
>
> With Rails in the name of this mailing list, Prototype.js being in
> Rails svn and Prototype.js''s direct integration in Rails core,
this is
> also an appropriate place to discuss the future connection of
> Prototype.js and Rails. I am concerned about the long term success of
> Rails not Prototype.js.
> _______________________________________________
> Rails-spinoffs mailing list
> Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs


_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs

On 7/20/06, Thomas Fuchs <t.fuchs-moWQItti3gBl57MIdRCFDg@public.gmane.org>
wrote:
>
> The sole point of Prototype is to give the programmer a powerful,
opinionated  toolset, to make programming JavaScript less pain (with some extra
special sugar-on-the-top for Ruby devs).
How special is this sugar? Below are four randomly selected uses of
Prototype.js enumberable methods from Scriptaculous. Yes three of the
Prototype.js versions are somewhat shorter but they require the user
to download the enumerable part of Prototype.js which is big, tokenize
it and compile it.

In each of these examples below I gave the native JavaScript versions
using an Array or using a "Hash" (JavaScript object as an associative
array). Count the number of function calls in each of the Prototype.js
versions. One for the enumerable method and then one for each of the
conditions. In the compound example the number of function calls is
doubled + two. This makes the Prototype.js versions much slower.

As I wrote before, the Prototype.js versions require a new maintainer
to learn Prototype.js. Also the actual Prototype.js library code is an
extra layer of code that can contain bugs.

I don''t see that the sugar is so sweet.

I am not criticising anyone that uses Prototype.js. I am looking at
Prototype.js critically.

Peter



= each

== Prototype.js
s.droppables.each(function(d){Droppables.remove(d)});

== Native JavaScript with Array
var ds=s.droppables;for(var i=0;i<ds.length;i++){Droppables.remove(ds[i])}

== Native JavaScript with "Hash"
var ds=s.droppables;for(var p in ds){Droppables.remove(ds[p])}



= detect

== Prototype.js
return drop._containers.detect(function(c){return containmentNode==c});

== Native JavaScript with Array
for(var i=0;i<drop._containers.length;i++){var
c=drop._containers[i];if(containmentNode==c){return c;}}

== Native JavaScript with "Hash"
for(var p in drop._containers){var
c=drop._containers[p];if(containmentNode==c){return c;}}



= reject

== Prototype.js
this.observers=this.observers.reject(function(o){return o.element==element});

== Native JavaScript with Array
var os=this.observers;for(var
i=0;i<os.length;i++){if(os[i].element==element){delete os[i]}}

== Native JavaScript with "Hash"
var os=this.observers;for(var p in os){if(os[p].element==element){delete os[p]}}



= compound: findAll & each

== Prototype.js
this.effects.findAll(function(e){return
e.state==''idle''}).each(function(e){
    e.startOn  += effect.finishOn;
    e.finishOn += effect.finishOn;
  });

== Native JavaScript with Array
for(var i=0;i<this.effects.length;i++){var
e=this.effects[i];if(e.state==''idle''){
    e.startOn  += effect.finishOn;
    e.finishOn += effect.finishOn;
  }}

== Native JavaScript with "Hash"
for(var p in this.effects){var
e=this.effects[p];if(e.state==''idle''){
    e.startOn  += effect.finishOn;
    e.finishOn += effect.finishOn;
  }}

I feel a bit responsible for kicking off the rather lengthy  
discussion over the past couple of days.  I don''t mean for this post  
to make it go on for several more.

Two different sides and several in the middle have been represented.   
Despite the angst some are feeling, I for one feel more informed and  
have a better feel for the pulse of the list.

I don''t think it''s as black and white as you suggest, Alex.
You call
it FUD, but as it''s most often used, the term connotes a slanted view  
of the world with the intent of distracting listeners from something  
else.  That''s NOT what I see here.  The views expressed are valid,  
real-world concerns from development managers who want to see  
Scriptaculous succeed, and need to be addressed. As you said, in  
order to trust the future of the project we need to know a road-map  
exists.  Asking for one--however inelegantly worded--isn''t FUD.  
Addressing the uncertainties makes the project stronger. Yes, parts  
of some of the emails are a but "fuddy," but don''t throw the
baby out
with the bath water.

To summarize the concerns I''ve heard from others on the list, (and  
remember, because they are relevant to me):
Prototype
P1. Is it actively being developed? (Will the $$() improvements be in  
the next version? When is that?)
P2. I want to contribute, but can''t. It''s frustrating.
P3. The project is too big for a single person.
P4. The file is too big; can it be be better compartmentalized?
P5. It has too much syntactic sugar
P6. It''s too much like Ruby. [I don''t think this is worth
fully
debating, but it has been expressed.]

Scriptaculous
S1. What is the future of Scriptaculous if Prototype flounders?
S2. My developers need to be able to read Scriptaculous code; it  
would be easier if they didn''t have to learn Prototype syntax too.

I''m not suggesting the above be debated (again), but let''s not
shoo
away those who raise valid concerns. Note too, that most of the  
concerns voiced are with Prototype, not Scriptaculous.

I''m here because I''m impressed with Scriptaculous and want it
to
succeed. Thomas Fuchs has done a good thing for the Javascript  
community.  I want it to last.

Ya''ll have proven time and again that there are smarter heads than me  
on this list. I want to offer some suggestions for consideration:

-----------
== Spread the work better.
Thomas, find a small handful of active contributors willing to filter  
bugs and test patches on multiple platforms, and recommend patches  
for inclusion.  Also task them to present lists of bugs to close  
(duplicate/irrelevant/not a bug/won''t fix) or vote/highlight/ 
prioritize those reporting serious issues. Have a group of trusted  
programmers you can assign things to. Task another handful of people  
to update/fix the documentation. Design a process flow whereby  
patches/updates can be immediately reflected in documentation.

  In short, delegate; remain at the helm, but let others do the  
legwork. Perhaps all of this is already happening in a less public  
way, and I''m running my mouth off.

== Merge with or fork Prototype.
This is a touchy subject, and I don''t mean to approach it lightly.   
It would, however, recognize the concerns mentioned above regarding  
Prototype has having validity. This is but one possible way to  
address them. Take a moment, publicly or not, to examine the pros and  
cons of a merge or a fork, as compared with running separate  
projects. Talk it over with Sam.
-----------

That''s more  long winded than I meant to be, and I don''t mean
to
rehash old issues.  If you made it this far, thanks for putting up  
with me.


TAG
tomg-PGZyUNKar/Q@public.gmane.org


On Jul 20, 2006, at 3:24 PM, Alex Duffield wrote:
> Well said. I am sick of the prototype bashing. This is a list for  
> those who WANT to use prototype. Would those who dont want to use  
> it please leave.
>
> Having said that, I also would like to say I think it is vital for  
> prototype tat the lead developers have SOME presence on this list  
> and let us know what the plans are even if that is in the saying  
> "We are not sure, but we are still working on things" Just a
simple
> Hi, Im still alive would go a long way.
>
> As far as the "whats the rush for the next version" I somewhat  
> disagree. I NEED to know that versions 1.5 and 2 are in the pipe,  
> if I am going to commit my applications to the use of prototype.js.  
> What happens when things break in IE7, or IE8 or Firefox4 or  
> whatever.  The point is browsers dont stand still, and I need to be  
> confident that libraries I am dependent on will not become  
> obsolete. I am not a javascipt "Expert", so I am dependent on  
> others to maintain this code.
>
> The FUD that I see on this thread concerns be deeply.
>
> FUD is Fear Uncertainty and Doubt, but in this case, there is some  
> validity in it.
>
> Fear - I fear that my dependancy on prototype might be a mistake.
> Uncertainty - I am uncertan that the developers of prototype are  
> committed to the project, as they do not participate in this list  
> and provide no information.
> Doubt - I doubt that this project will survive if the developers  
> dont interact with the community.
>
> This is a cancer that will eat at the community if left unchecked.
>
> The solution is simple. Communication between the developers and  
> the community.
>
> Just my 2 bits.
>
> Alex Duffield
>
>
>
> On 20-Jul-06, at 9:38 AM, Ryan Gahl wrote:
>
>>
>>
>> If you are interested in improving prototype, that''s one
thing,
>> but then offer constructive ways to do so rather than just  
>> repeating yourself over and over. You read a couple of articles  
>> out there from people critiquing proto and now you just want to  
>> jump in as though you''re some sort of javascript expert and we
are
>> newbies. News flash, a good lot of us in this list are javascript  
>> experts and we''ve managed to use proto with GREAT success in
spite
>> of anyone''s judgements against it.
>>
>> Moreover, this list is a place for people to present their  
>> problems/solutions centered around proto/scriptaculous. You are  
>> doing neither. Just stop.
>>
>>
>
> _______________________________________________
> Rails-spinoffs mailing list
> Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs


_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs

On 7/20/06, Peter Michaux
<petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On 7/20/06, Thomas Fuchs
<t.fuchs-moWQItti3gBl57MIdRCFDg@public.gmane.org> wrote:
> >
> > The sole point of Prototype is to give the programmer a powerful,
opinionated  toolset, to make programming JavaScript less pain (with some extra
special sugar-on-the-top for Ruby devs).
>
> How special is this sugar? Below are four randomly selected uses of
> Prototype.js enumberable methods from Scriptaculous.
Here is one from Prototype.js itself. Look at how hard the JavaScript
has to work to use each(). It needs many function calls and even must
use bind. This is not the sugar''s fault. But the sugar encouraged this
type of thinking.  In native JavaScript it is just a plain loop that
everyone can understand.

== Prototype.js

fragments.each((function(fragment){
  this.element.appendChild(fragment);}).bind(this));

== Native JavaScript

for(var i=0;i<fragments.length;i++){
  this.element.appendChild(fragments[i]);
}

I used the IDE in anger
yesterday and it was a joy to use. It''s an Eclipse distro and I am an
Eclipse user (on this job anyway)  so it''s a familiar env for me. The
docs say it CAN be plugged in as an Eclipse perspective but best to run
as standalone app for now. Hopefully that''s safely working soon. For
now, I just point it at a common codebase.

IMHO it''s a good tool and far better than any other "front
end" Eclipse
plugin I''ve used. Hopefully it''ll grow into a truly great tool
in
time...Mind you, IntelliJ has all this stuff built into one app - but
it''ll cost you..

BTW - the current download doesn''t include the prototype1.4 docs (out
Tuesday apparently) but Paul (who started this thread many moons ago !)
kindly emailed me a zipped version.

Matt

Brandon Aaron wrote:

Also it seems that I completely
overlooked where it said, "We''ve already documented all of
prototype
and would love to get it in."

That sounds like a big deal to me. Seems like every time I turn around
someone is complaining about the lack of documentation. How can we help
them get it into SVN and published? Perhaps Thomas can help?

  On
7/20/06, Brandon Aaron
<brandon.aaron-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:

    Has anyone else
actually tried out this IDE Aptana (http://www.aptana.com/)?
You know ... the reason this thread was started.

Looks pretty interesting; however, I''m a TextMate fanatic and ever
since have immediately had doubts about other editors. I might try it
out later on today if I can find the time.

    On 7/20/06, Peter
Michaux <
petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

    On
7/20/06, Alex Duffield
<alex-GLL9njBnHiGqPKKiFzS5XxZCeNDtXRbv@public.gmane.org
> wrote:

>

> This is a list for those who WANT to use prototype.

With Rails in the name of this mailing list, Prototype.js being in

Rails svn and Prototype.js''s direct integration in Rails core, this is

also an appropriate place to discuss the future connection of

Prototype.js and Rails. I am concerned about the long term success of

Rails not Prototype.js.

_______________________________________________

Rails-spinoffs mailing list

      Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org

      http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs

  _______________________________________________

Rails-spinoffs mailing list

Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org

  http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs


_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs

On 7/20/06, Thomas Fuchs <t.fuchs-moWQItti3gBl57MIdRCFDg@public.gmane.org>
wrote:
> "I think Prototype.js is a lost cause by design."
> So-- then what are you doing on the Prototype/script.aculo.us mailing
> list? :)
>
> The sole point of Prototype is to give the programmer a powerful,
> opinionated
> toolset, to make programming JavaScript less pain (with some extra
> special
> sugar-on-the-top for Ruby devs).

I think it is very telling to hear Sam himself say that a good way to
optimize JavaScript is to minimize use of the enumerable methods. Just
before 15:00 in this podcast

http://odeo.com/audio/1414538/view

It is easy to write native JavaScript versions of code written using
the Prototype.js enumerable methods. I''ve given a few examples. It is
obvious that the native versions are much more efficient and have
other benefits. Why not just write native from the start?

On Friday 21 July 2006 21:27, Peter Michaux wrote:
> It is easy to write native JavaScript versions of code written using
> the Prototype.js enumerable methods. I''ve given a few examples. It
is
> obvious that the native versions are much more efficient and have
> other benefits. Why not just write native from the start?
If I''m not mistaken the enumerable methods exist partly to make the job
of the Rails JavaScriptGenerator easier (although the Prototype.js 
implementation of them predates the JavaScriptGenerator). The 
JavaScriptGenerator translates a subset of Ruby into JavaScript so that 
RJS templates can be written entirely in Ruby.

Michael

-- 
Michael Schuerig
mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org
http://www.schuerig.de/michael/

On 7/21/06, Michael Schuerig
<michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org>
wrote:
> On Friday 21 July 2006 21:27, Peter Michaux wrote:
> > It is easy to write native JavaScript versions of code written using
> > the Prototype.js enumerable methods. I''ve given a few
examples. It is
> > obvious that the native versions are much more efficient and have
> > other benefits. Why not just write native from the start?
>
> If I''m not mistaken the enumerable methods exist partly to make
the job
> of the Rails JavaScriptGenerator easier (although the Prototype.js
> implementation of them predates the JavaScriptGenerator). The
> JavaScriptGenerator translates a subset of Ruby into JavaScript so that
> RJS templates can be written entirely in Ruby.
I have looked through the JavaScriptGenerator in resonable detail over
the last couple days. I don''t know about the <<, [], or show
methods
yet but all the other rjs methods do not need the enumerable stuff. Do
you have an example?

Peter

On 7/21/06, Peter Michaux
<petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> > If I''m not mistaken the enumerable methods exist partly to
make the job
> > of the Rails JavaScriptGenerator easier (although the Prototype.js
> > implementation of them predates the JavaScriptGenerator). The
> > JavaScriptGenerator translates a subset of Ruby into JavaScript so
that
> > RJS templates can be written entirely in Ruby.
>
> I have looked through the JavaScriptGenerator in resonable detail over
> the last couple days. I don''t know about the <<, [], or show
methods
> yet but all the other rjs methods do not need the enumerable stuff. Do
> you have an example?
Oops. I meant  the <<, [] and select methods

On Saturday 22 July 2006 00:20, Peter Michaux wrote:
> On 7/21/06, Michael Schuerig
<michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org> wrote:
> > On Friday 21 July 2006 21:27, Peter Michaux wrote:
> > > It is easy to write native JavaScript versions of code written
> > > using the Prototype.js enumerable methods. I''ve given a
few
> > > examples. It is obvious that the native versions are much more
> > > efficient and have other benefits. Why not just write native from
> > > the start?
> >
> > If I''m not mistaken the enumerable methods exist partly to
make the
> > job of the Rails JavaScriptGenerator easier (although the
> > Prototype.js implementation of them predates the
> > JavaScriptGenerator). The JavaScriptGenerator translates a subset
> > of Ruby into JavaScript so that RJS templates can be written
> > entirely in Ruby.
>
> I have looked through the JavaScriptGenerator in resonable detail
> over the last couple days. I don''t know about the <<, [], or
show
> methods yet but all the other rjs methods do not need the enumerable
> stuff. Do you have an example?
Have a look (in edge rails) at  
JavaScriptCollectionProxy#method_missing. This method relies on there 
being JS equivalents for the Ruby enumerable methods.

Michael

-- 
Michael Schuerig
mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org
http://www.schuerig.de/michael/

On 20/07/06, Peter Michaux
<petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> On 7/20/06, Thomas Fuchs
<t.fuchs-moWQItti3gBl57MIdRCFDg@public.gmane.org> wrote:
> > The sole point of Prototype is to give the programmer a powerful,
> > opinionated
> > toolset, to make programming JavaScript less pain
>
> That is a great idea but unfortuntely, prototype.js ends up making it
> more pain because of the many concrete reasons I listed before.
>
Not for me. Prototype-style expressions match the way I think and make
me more productive. Prototype can only get better over time. I dig it
the mostest, baby.

This is open source after all, and with a very permissive license to
boot. You are free to take it and turn it into your own beautiful
creations.

On 7/22/06, Andrew Tetlaw
<atetlaw-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> Prototype-style expressions match the way I think and make
> me more productive.
But I would say they make your client-side pages less efficient,
robust and maintainable. All this for how much extra productivity? A
few extra key strokes saved in writing the quality, native JavaScript
loops that you need to know how to write anyway?

> Prototype can only get better over time.
That''s optimistic but not at all necessarily true. The inclusion of
base.js is going to make Prototype.js bigger but not better.

Peter

On 7/19/06, Todd Ross
<rails-spinoffs-25kFIyuv2iRiLUuM0BA3LQ@public.gmane.org>
wrote:
> Peter Michaux wrote:
> > On 7/19/06, Todd Ross
<rails-spinoffs-25kFIyuv2iRiLUuM0BA3LQ@public.gmane.org> wrote:
> >
> >> but I still believe in Prototype-the-project.
> >
> > I''m curious why.
>
> I''ve already eluded to the why.  Its the cleanest, most elegant
> JavaScript code base that I''ve ever laid eyes on.
It may be the cleanest and most elegant that you''ve seen but it is not
clean or elegant. For example, look at the insertion code

Here is the code that for Insert.Before. Not shown are 10 lines for
the dollar sign function, 7 lines for Class, and a bunch more for the
unnecessary enumerable methods.

You have to really dig in and do a bit of analysis to see how
convoluting things are here. Then compare with the rewritten example
at the bottom.

Abstract.Insertion = function(adjacency) {
  this.adjacency = adjacency;
}

Abstract.Insertion.prototype = {
  initialize: function(element, content) {
    this.element = $(element);
    this.content = content.stripScripts();

    if (this.adjacency && this.element.insertAdjacentHTML) {
      try {
        this.element.insertAdjacentHTML(this.adjacency, this.content);
      } catch (e) {
        var tagName = this.element.tagName.toLowerCase();
        if (tagName  ''tbody'' || tagName 
''tr'') {
          this.insertContent(this.contentFromAnonymousTable());
        } else {
          throw e;
        }
      }
    } else {
      this.range = this.element.ownerDocument.createRange();
      if (this.initializeRange) this.initializeRange();
      this.insertContent([this.range.createContextualFragment(this.content)]);
    }

    setTimeout(function() {content.evalScripts()}, 10);
  },

  contentFromAnonymousTable: function() {
    var div = document.createElement(''div'');
    div.innerHTML = ''''  this.content  ''
'';
    return $A(div.childNodes0.childNodes0.childNodes);
  }
}

var Insertion = new Object();

Insertion.Before = Class.create(); Insertion.Before.prototype Object.extend(new
Abstract.Insertion(''beforeBegin''), {
initializeRange: function() { this.range.setStartBefore(this.element);
}, });

insertContent: function(fragments) {
  fragments.each((function(fragment) {
    this.element.parentNode.insertBefore(fragment, this.element);
  }).bind(this));
}

The above code is strange enough with Class.create() and Object.extend
but what gets really strange is when you want to use all of this and
actually make an insertion before. To make a single insertion we have
to construct a new object that then makes the insertion during
initialization. This is not efficient.

new Insertion.Before(element, content);

A better way

The Prototype.js approach using the initializeRange() and
insertContent() is not far off the normal way of doing things in
JavaScript. This is the idea of having a prototypical object and
instances of this object with some properties that vary.

Below is the insertion code refactored a more usual JavaScript way.
Notice there is no need for support code like Prototype.js''
Class.create(), Object.extend, $() or any enumerable methods. This is
much more efficient, modular, maintainable and robust.

Note that this code is tested but not completely.

var Fork = {};

Fork.Inserter = function(adjacency) {
  this.adjacency = adjacency;
};

Fork.Inserter.prototype.insert = function(element, content) {
  this.element = (typeof element === "string") ?
                 document.getElementById(element) : element;
  this.content = Fork.stripScripts(content);

  if (this.element.insertAdjacentHTML) {
    try {
      this.element.insertAdjacentHTML(this.adjacency, this.content);
    } catch (e) {
      var tagName = this.element.tagName.toLowerCase();
      if (tagName === ''tbody'' || tagName ===
''tr'') {
        this.insertContent(this.contentFromAnonymousTable());
      } else {
        throw e;
      }
    }
  } else {
    this.range = this.element.ownerDocument.createRange();
    this.initRange();
    this.insertContent([this.range.createContextualFragment(this.content)]);
  }

  Fork.insertScripts(this.element);
};

Fork.Inserter.prototype.contentFromAnonymousTable = function() {
  var div = document.createElement(''div'');
  div.innerHTML = ''<table><tbody>'' + this.content
+ ''</tbody></table>'';
  return div.childNodes[0].childNodes[0].childNodes;
};

Fork.insertBefore = new Fork.Inserter(''beforeBegin'');

Fork.insertBefore.initRange = function() {
  this.range.setStartBefore(this.element);
};

Fork.insertBefore.insertContent = function(fragments) {
  for(var i=0;i<fragments.length;i++){
    this.element.parentNode.insertBefore(fragments[i], this.element);
  }
};

The best part comes when actually making an insertion.

Fork.insertBefore.insert(element, content);

No confusing need to instantiate a new object for every insertion.

On 22/07/06, Peter Michaux
<petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> But I would say they make your client-side pages less efficient,
> robust and maintainable.
But, you would be wrong, sorry.

-- 
Andrew Tetlaw
htp://tetlaw.id.au

Although I do not agree with you anywhere else on your thoughts about
prototype. Abstract.Insertion is the first thing I removed and replaced with
a few methods on Element.Methods. Like, prependChild, insertAfter,
insertAtIndex. They make more sense to me to be in Element.Methods instead
of their own ''Abstract Class''.

With that said I never took the time to find out why it is done like it is.

On 7/22/06, Peter Michaux
<petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> On 7/19/06, Todd Ross
<rails-spinoffs-25kFIyuv2iRiLUuM0BA3LQ@public.gmane.org> wrote:
> > Peter Michaux wrote:
> > > On 7/19/06, Todd Ross
<rails-spinoffs-25kFIyuv2iRiLUuM0BA3LQ@public.gmane.org> wrote:
> > >
> > >> but I still believe in Prototype-the-project.
> > >
> > > I''m curious why.
> >
> > I''ve already eluded to the why.  Its the cleanest, most
elegant
> > JavaScript code base that I''ve ever laid eyes on.
>
> It may be the cleanest and most elegant that you''ve seen but it is
not
> clean or elegant. For example, look at the insertion code
>
> Here is the code that for Insert.Before. Not shown are 10 lines for
> the dollar sign function, 7 lines for Class, and a bunch more for the
> unnecessary enumerable methods.
>
> You have to really dig in and do a bit of analysis to see how
> convoluting things are here. Then compare with the rewritten example
> at the bottom.
>
> Abstract.Insertion = function(adjacency) {
>   this.adjacency = adjacency;
> }
>
> Abstract.Insertion.prototype = {
>   initialize: function(element, content) {
>     this.element = $(element);
>     this.content = content.stripScripts();
>
>     if (this.adjacency && this.element.insertAdjacentHTML) {
>       try {
>         this.element.insertAdjacentHTML(this.adjacency, this.content);
>       } catch (e) {
>         var tagName = this.element.tagName.toLowerCase();
>         if (tagName  ''tbody'' || tagName 
''tr'') {
>           this.insertContent(this.contentFromAnonymousTable());
>         } else {
>           throw e;
>         }
>       }
>     } else {
>       this.range = this.element.ownerDocument.createRange();
>       if (this.initializeRange) this.initializeRange();
>       this.insertContent([this.range.createContextualFragment(this.content
> )]);
>     }
>
>     setTimeout(function() {content.evalScripts()}, 10);
>   },
>
>   contentFromAnonymousTable: function() {
>     var div = document.createElement(''div'');
>     div.innerHTML = ''''  this.content  ''
> '';
>     return $A(div.childNodes0.childNodes0.childNodes);
>   }
> }
>
> var Insertion = new Object();
>
> Insertion.Before = Class.create(); Insertion.Before.prototype >
Object.extend(new Abstract.Insertion(''beforeBegin''), {
> initializeRange: function() { this.range.setStartBefore(this.element);
> }, });
>
> insertContent: function(fragments) {
>   fragments.each((function(fragment) {
>     this.element.parentNode.insertBefore(fragment, this.element);
>   }).bind(this));
> }
>
> The above code is strange enough with Class.create() and Object.extend
> but what gets really strange is when you want to use all of this and
> actually make an insertion before. To make a single insertion we have
> to construct a new object that then makes the insertion during
> initialization. This is not efficient.
>
> new Insertion.Before(element, content);
>
> A better way
>
> The Prototype.js approach using the initializeRange() and
> insertContent() is not far off the normal way of doing things in
> JavaScript. This is the idea of having a prototypical object and
> instances of this object with some properties that vary.
>
> Below is the insertion code refactored a more usual JavaScript way.
> Notice there is no need for support code like Prototype.js''
> Class.create(), Object.extend, $() or any enumerable methods. This is
> much more efficient, modular, maintainable and robust.
>
> Note that this code is tested but not completely.
>
> var Fork = {};
>
> Fork.Inserter = function(adjacency) {
>   this.adjacency = adjacency;
> };
>
> Fork.Inserter.prototype.insert = function(element, content) {
>   this.element = (typeof element === "string") ?
>                  document.getElementById(element) : element;
>   this.content = Fork.stripScripts(content);
>
>   if (this.element.insertAdjacentHTML) {
>     try {
>       this.element.insertAdjacentHTML(this.adjacency, this.content);
>     } catch (e) {
>       var tagName = this.element.tagName.toLowerCase();
>       if (tagName === ''tbody'' || tagName ===
''tr'') {
>         this.insertContent(this.contentFromAnonymousTable());
>       } else {
>         throw e;
>       }
>     }
>   } else {
>     this.range = this.element.ownerDocument.createRange();
>     this.initRange();
>     this.insertContent([this.range.createContextualFragment(this.content
> )]);
>   }
>
>   Fork.insertScripts(this.element);
> };
>
> Fork.Inserter.prototype.contentFromAnonymousTable = function() {
>   var div = document.createElement(''div'');
>   div.innerHTML = ''<table><tbody>'' +
this.content + ''</tbody></table>'';
>   return div.childNodes[0].childNodes[0].childNodes;
> };
>
> Fork.insertBefore = new Fork.Inserter(''beforeBegin'');
>
> Fork.insertBefore.initRange = function() {
>   this.range.setStartBefore(this.element);
> };
>
> Fork.insertBefore.insertContent = function(fragments) {
>   for(var i=0;i<fragments.length;i++){
>     this.element.parentNode.insertBefore(fragments[i], this.element);
>   }
> };
>
> The best part comes when actually making an insertion.
>
> Fork.insertBefore.insert(element, content);
>
> No confusing need to instantiate a new object for every insertion.
> _______________________________________________
> Rails-spinoffs mailing list
> Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
>

_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs

Peter Michaux wrote:
> On 7/19/06, Todd Ross
<rails-spinoffs-25kFIyuv2iRiLUuM0BA3LQ@public.gmane.org> wrote:
>> Peter Michaux wrote:
>> > On 7/19/06, Todd Ross
<rails-spinoffs-25kFIyuv2iRiLUuM0BA3LQ@public.gmane.org> wrote:
>> >
>> >> but I still believe in Prototype-the-project.
>> >
>> > I''m curious why.
>>
>> I''ve already eluded to the why.  Its the cleanest, most
elegant
>> JavaScript code base that I''ve ever laid eyes on.
> 
> It may be the cleanest and most elegant that you''ve seen but it is
not
> clean or elegant. For example, look at the insertion code
You responded to one of my messages twice.  Once on 07/19 and again on
07/22.  Are you just sitting there stewing over the fact that people
disagree with you?  Go start a blog or something then.  In any case, I
consider it poor etiquette.

I think Prototype is clean.  Although, perhaps you''d be more
comfortable
with the word "consistent."  I think Prototype is elegant.  I *like* a
lot of the little tricks that it employs.  When I first understood
bind(), I thought it was brilliant.  All of your criticisms seem to be
leveled at its *efficiency*, which I never said it was.

I, personally, would rather see you opening bugs and submitting patches
to eliminate the inefficiencies that seem to make you so uncomfortable.

Todd Ross

On 7/22/06, Todd Ross
<rails-spinoffs-25kFIyuv2iRiLUuM0BA3LQ@public.gmane.org>
wrote:
>
> You responded to one of my messages twice.  Once on 07/19 and again on
> 07/22.
I had another idea

> Are you just sitting there stewing over the fact that people
> disagree with you?
No. It is not about disagreeing at all.

> I think Prototype is elegant.
Even the Insertion stuff?

> All of your criticisms seem to be
> leveled at its *efficiency*
Not at all. I''ve listed many others too.


Peter

On 7/22/06, Todd Ross
<rails-spinoffs-25kFIyuv2iRiLUuM0BA3LQ@public.gmane.org>
wrote:
>
> I, personally, would rather see you opening bugs and submitting patches
> to eliminate the inefficiencies that seem to make you so uncomfortable.
When Rails trac is stable, capable of accepting new tickets, and there
is sign of daily activity in Prototype.js commits I will submit.

Peter

The insertion stuff totally makes sense when you think that Proto &
Scripty were build as the visible client layer to Ruby on Rails.

I''ve always assumed that their approach to AJAX was to return HTML
fragments and insert them into the DOM.  If you look at it that way
all the insertion and script handling within innerHTML all makes
perfect sense.

On 23/07/06, Peter Michaux
<petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On 7/22/06, Todd Ross
<rails-spinoffs-25kFIyuv2iRiLUuM0BA3LQ@public.gmane.org> wrote:
> >
> > You responded to one of my messages twice.  Once on 07/19 and again on
> > 07/22.
>
> I had another idea
>
>
> > Are you just sitting there stewing over the fact that people
> > disagree with you?
>
> No. It is not about disagreeing at all.
>
>
> > I think Prototype is elegant.
>
> Even the Insertion stuff?
>
>
> > All of your criticisms seem to be
> > leveled at its *efficiency*
>
> Not at all. I''ve listed many others too.
>
>
> Peter
> _______________________________________________
> Rails-spinoffs mailing list
> Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
>

-- 
Andrew Tetlaw
htp://tetlaw.id.au

On 7/23/06, Andrew Tetlaw
<atetlaw-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> The insertion stuff totally makes sense when you think that Proto &
> Scripty were build as the visible client layer to Ruby on Rails.
>
> I''ve always assumed that their approach to AJAX was to return HTML
> fragments and insert them into the DOM.  If you look at it that way
> all the insertion and script handling within innerHTML all makes
> perfect sense.
Why does insertion require construction of a JavaScript object?  That
is a lot of work to perform an operation. The other DOM modifying
operations do not require instantiation.

On 24/07/06, Peter Michaux
<petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> Why does insertion require construction of a JavaScript object?  That
> is a lot of work to perform an operation. The other DOM modifying
> operations do not require instantiation.
Well, I ain''t got no problem with it. Not much more to say than that.

-- 
Andrew Tetlaw
htp://tetlaw.id.au

On 24/07/06, Andrew Tetlaw
<atetlaw-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> Not much more to say than that.
>
Except that Prototype makes me want to spread Rasberry Jam all over
myself and then roll around in a huge vat of.... Oh, sorry, I was
getting confused about which mailing list I was responding to.


-- 
Andrew Tetlaw
htp://tetlaw.id.au