Rails spinoffs - Nov 2006 - ANN: Fork a new JavaScript library for use with Rails

If you work with Rails but are unhappy with Prototype . . .

I''m excited about the launch of my new JavaScript library called Fork
at http://forkjavascript.org with the MIT license. Below are snips
from the front page of the Fork site...

Fork is a JavaScript library with Ajax, Events, DOM manipulation, etc.
Fork is a general purpose library with a few bonus lines in the Ajax
library specifically for use with Ruby on Rails however the library
can be happily used outside of Rails also.

advantages

    * an aspiration for the highest quality code
    * author documentation
    * in-browser unit/integration tests
    * namespaced code
    * does not augment JavaScript built-in prototypes
    * does not add a layer of sugar on top of JavaScript to make
writing JavaScript like writing in another language
    * Is minimizable with jsmin
    * MIT License

There are many JavaScript libraries out there. Why add another one to
the list? To create a quality library with a liberal license.

I like Ruby on Rails. I want Rails to have a better JavaScript
library. I (and many others!) think the Rails default Prototype
JavaScript library has many seriously poor design decisions and is
poorly coded. Suggestions to improve the Prototype code sit on the
Rails trac seemingly forever and author Sam Stephenson does not
interact openly with the community of Rails and Prototype users.
Because Prototype does not play well with other JavaScript libraries
it isn''t necessarily possible to use Prototype in combination with
Fork. This fact likely will never change because of Prototype''s
fundamental design. On the other hand, Fork does plays well with other
respectful libraries.

I like the Yahoo! UI library. Of the JavaScript libraries I''ve used it
has the best API. The YUI library has many valuable nuggets of
information about browser bugs and workarounds. The code approach of
YUI suits browser scripting well. However there are more than a few
places in the code where I''m left scratching my head and thinking
"why
did they do that?" Maybe that is how every developer looks at another
developers code. The YUI API is the starting point for much of the
Fork API.

Most libraries seem to develop too quickly. API''s are fixed from the
first alpha version and code is not allowed to morph for the early
part of it''s life. I like the general debian attitude of careful
growth because the browser execution environment is wildly varied and
deserves a certain degree of conservatism in the JavaScript we send to
it.

Most JavaScript libraries settle for "good enough" and don''t
seem to
aspire to the high level of quality to which the Fork library aspires.
By keeping an eye on other JavaScript libraries the good parts can be
brought into the Fork code.

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Dojotoolkit <http://dojotoolkit.org/foundation/>is the best I''ve
found, and
I''ve looked at nearly all of them... it also has all of the bullet
points
you mentioned..  and is extensible.  Just as importantly, it has a lot of
industry support and will be long lasting (not developed in the corner by 1
or two people).  Also works well with the easy to use
Prototype+Script.aculo.us libraries (the Script.aculo.us effects library is
great), so a developer can use the best of all.  Prototype has its benefits,
and I like using it as well, and the good news is that you can.

I don''t mean to burst your bubble, I''m sure you worked hard
and it''s
probably nice code, and if it works for you, great... but would like to say
good luck to those developers trying every js library that pops up (which
seems to be some sort of wheel-reinvention virus going around).  It can be a
huge time sink.  I''m personally sticking with those that are very
likely to
persist -- namely, Dojo and Prototype.  imho, I think a lot of developers
would be wise to add to foundations that are already solid, with solid
support, rather than reinventing the wheel.



On 11/29/06, Peter Michaux
<petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
>
> If you work with Rails but are unhappy with Prototype . . .
>
> I''m excited about the launch of my new JavaScript library called
Fork
> at http://forkjavascript.org with the MIT license. Below are snips
> from the front page of the Fork site...
>
> Fork is a JavaScript library with Ajax, Events, DOM manipulation, etc.
> Fork is a general purpose library with a few bonus lines in the Ajax
> library specifically for use with Ruby on Rails however the library
> can be happily used outside of Rails also.
>
> advantages
>
>     * an aspiration for the highest quality code
>     * author documentation
>     * in-browser unit/integration tests
>     * namespaced code
>     * does not augment JavaScript built-in prototypes
>     * does not add a layer of sugar on top of JavaScript to make
> writing JavaScript like writing in another language
>     * Is minimizable with jsmin
>     * MIT License
>
> There are many JavaScript libraries out there. Why add another one to
> the list? To create a quality library with a liberal license.
>
> I like Ruby on Rails. I want Rails to have a better JavaScript
> library. I (and many others!) think the Rails default Prototype
> JavaScript library has many seriously poor design decisions and is
> poorly coded. Suggestions to improve the Prototype code sit on the
> Rails trac seemingly forever and author Sam Stephenson does not
> interact openly with the community of Rails and Prototype users.
> Because Prototype does not play well with other JavaScript libraries
> it isn''t necessarily possible to use Prototype in combination with
> Fork. This fact likely will never change because of Prototype''s
> fundamental design. On the other hand, Fork does plays well with other
> respectful libraries.
>
> I like the Yahoo! UI library. Of the JavaScript libraries I''ve
used it
> has the best API. The YUI library has many valuable nuggets of
> information about browser bugs and workarounds. The code approach of
> YUI suits browser scripting well. However there are more than a few
> places in the code where I''m left scratching my head and thinking
"why
> did they do that?" Maybe that is how every developer looks at another
> developers code. The YUI API is the starting point for much of the
> Fork API.
>
> Most libraries seem to develop too quickly. API''s are fixed from
the
> first alpha version and code is not allowed to morph for the early
> part of it''s life. I like the general debian attitude of careful
> growth because the browser execution environment is wildly varied and
> deserves a certain degree of conservatism in the JavaScript we send to
> it.
>
> Most JavaScript libraries settle for "good enough" and
don''t seem to
> aspire to the high level of quality to which the Fork library aspires.
> By keeping an eye on other JavaScript libraries the good parts can be
> brought into the Fork code.
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi Mark,

On 11/29/06, Mark Holton
<holtonma-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> Dojotoolkit is the best I''ve found, and I''ve looked at
nearly all of them...
People I have talked with about Dojo have run as fast as they can away
from it because of code quality. I have looked at Dojo and the most
disturbing thing I saw was that demo pages load very slowly. Dojo
seems like the ultimate example of growing too fast and buggy.
> it also has all of the bullet points you mentioned..  and is extensible.
> Just as importantly, it has a lot of industry support and will be long
> lasting (not developed in the corner by 1 or two people).
They all start with a small group.
>  I don''t mean to burst your bubble, I''m sure you worked
hard and it''s
> probably nice code, and if it works for you, great... but would like to say
> good luck to those developers trying every js library that pops up (which
> seems to be some sort of wheel-reinvention virus going around).  It can be
a
> huge time sink.  I''m personally sticking with those that are very
likely to
> persist -- namely, Dojo and Prototype.  imho, I think a lot of developers
> would be wise to add to foundations that are already solid, with solid
> support, rather than reinventing the wheel.
I''m not trying to reinvent the wheel. Other people have shown the idea
of a wheel is useful. I''m carefully making a circular wheel. That
would be an improvement enough but I also want the wheel on high
quality bearings.

Why Gmail when Hotmail existed?
Why Rails when Struts existed?
Why Mephisto when Typo existed?

I think if you take a look at the Fork code you will see it is headed
in a high quality direction that other libs are not.

Peter

> On 11/29/06, Peter Michaux
<petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
a> >
> > If you work with Rails but are unhappy with Prototype . . .
> >
> > I''m excited about the launch of my new JavaScript library
called Fork
> > at http://forkjavascript.org with the MIT license. Below are snips
> > from the front page of the Fork site...
> >
> > Fork is a JavaScript library with Ajax, Events, DOM manipulation, etc.
> > Fork is a general purpose library with a few bonus lines in the Ajax
> > library specifically for use with Ruby on Rails however the library
> > can be happily used outside of Rails also.
> >
> > advantages
> >
> >     * an aspiration for the highest quality code
> >     * author documentation
> >     * in-browser unit/integration tests
> >     * namespaced code
> >     * does not augment JavaScript built-in prototypes
> >     * does not add a layer of sugar on top of JavaScript to make
> > writing JavaScript like writing in another language
> >     * Is minimizable with jsmin
> >     * MIT License
> >
> > There are many JavaScript libraries out there. Why add another one to
> > the list? To create a quality library with a liberal license.
> >
> > I like Ruby on Rails. I want Rails to have a better JavaScript
> > library. I (and many others!) think the Rails default Prototype
> > JavaScript library has many seriously poor design decisions and is
> > poorly coded. Suggestions to improve the Prototype code sit on the
> > Rails trac seemingly forever and author Sam Stephenson does not
> > interact openly with the community of Rails and Prototype users.
> > Because Prototype does not play well with other JavaScript libraries
> > it isn''t necessarily possible to use Prototype in combination
with
> > Fork. This fact likely will never change because of
Prototype''s
> > fundamental design. On the other hand, Fork does plays well with other
> > respectful libraries.
> >
> > I like the Yahoo! UI library. Of the JavaScript libraries
I''ve used it
> > has the best API. The YUI library has many valuable nuggets of
> > information about browser bugs and workarounds. The code approach of
> > YUI suits browser scripting well. However there are more than a few
> > places in the code where I''m left scratching my head and
thinking "why
> > did they do that?" Maybe that is how every developer looks at
another
> > developers code. The YUI API is the starting point for much of the
> > Fork API.
> >
> > Most libraries seem to develop too quickly. API''s are fixed
from the
> > first alpha version and code is not allowed to morph for the early
> > part of it''s life. I like the general debian attitude of
careful
> > growth because the browser execution environment is wildly varied and
> > deserves a certain degree of conservatism in the JavaScript we send to
> > it.
> >
> > Most JavaScript libraries settle for "good enough" and
don''t seem to
> > aspire to the high level of quality to which the Fork library aspires.
> > By keeping an eye on other JavaScript libraries the good parts can be
> > brought into the Fork code.
--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

I certainly disagree that Dojo''s code base is low quality, and I
believe
many others would disagree with that statement as well.  Best wishes with
your library.
I''m sticking with what I know are two very robust, and extensible
libraries.


On 11/29/06, Peter Michaux
<petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
>
> Hi Mark,
>
> On 11/29/06, Mark Holton
<holtonma-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> > Dojotoolkit is the best I''ve found, and I''ve looked
at nearly all of
> them...
>
> People I have talked with about Dojo have run as fast as they can away
> from it because of code quality. I have looked at Dojo and the most
> disturbing thing I saw was that demo pages load very slowly. Dojo
> seems like the ultimate example of growing too fast and buggy.
>
> > it also has all of the bullet points you mentioned..  and is
extensible.
> > Just as importantly, it has a lot of industry support and will be long
> > lasting (not developed in the corner by 1 or two people).
>
> They all start with a small group.
>
> >  I don''t mean to burst your bubble, I''m sure you
worked hard and it''s
> > probably nice code, and if it works for you, great... but would like
to
> say
> > good luck to those developers trying every js library that pops up
> (which
> > seems to be some sort of wheel-reinvention virus going around).  It
can
> be a
> > huge time sink.  I''m personally sticking with those that are
very likely
> to
> > persist -- namely, Dojo and Prototype.  imho, I think a lot of
> developers
> > would be wise to add to foundations that are already solid, with solid
> > support, rather than reinventing the wheel.
>
> I''m not trying to reinvent the wheel. Other people have shown the
idea
> of a wheel is useful. I''m carefully making a circular wheel. That
> would be an improvement enough but I also want the wheel on high
> quality bearings.
>
> Why Gmail when Hotmail existed?
> Why Rails when Struts existed?
> Why Mephisto when Typo existed?
>
> I think if you take a look at the Fork code you will see it is headed
> in a high quality direction that other libs are not.
>
> Peter
>
>
> > On 11/29/06, Peter Michaux
<petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> a> >
> > > If you work with Rails but are unhappy with Prototype . . .
> > >
> > > I''m excited about the launch of my new JavaScript
library called Fork
> > > at http://forkjavascript.org with the MIT license. Below are
snips
> > > from the front page of the Fork site...
> > >
> > > Fork is a JavaScript library with Ajax, Events, DOM manipulation,
etc.
> > > Fork is a general purpose library with a few bonus lines in the
Ajax
> > > library specifically for use with Ruby on Rails however the
library
> > > can be happily used outside of Rails also.
> > >
> > > advantages
> > >
> > >     * an aspiration for the highest quality code
> > >     * author documentation
> > >     * in-browser unit/integration tests
> > >     * namespaced code
> > >     * does not augment JavaScript built-in prototypes
> > >     * does not add a layer of sugar on top of JavaScript to make
> > > writing JavaScript like writing in another language
> > >     * Is minimizable with jsmin
> > >     * MIT License
> > >
> > > There are many JavaScript libraries out there. Why add another
one to
> > > the list? To create a quality library with a liberal license.
> > >
> > > I like Ruby on Rails. I want Rails to have a better JavaScript
> > > library. I (and many others!) think the Rails default Prototype
> > > JavaScript library has many seriously poor design decisions and
is
> > > poorly coded. Suggestions to improve the Prototype code sit on
the
> > > Rails trac seemingly forever and author Sam Stephenson does not
> > > interact openly with the community of Rails and Prototype users.
> > > Because Prototype does not play well with other JavaScript
libraries
> > > it isn''t necessarily possible to use Prototype in
combination with
> > > Fork. This fact likely will never change because of
Prototype''s
> > > fundamental design. On the other hand, Fork does plays well with
other
> > > respectful libraries.
> > >
> > > I like the Yahoo! UI library. Of the JavaScript libraries
I''ve used it
> > > has the best API. The YUI library has many valuable nuggets of
> > > information about browser bugs and workarounds. The code approach
of
> > > YUI suits browser scripting well. However there are more than a
few
> > > places in the code where I''m left scratching my head and
thinking "why
> > > did they do that?" Maybe that is how every developer looks
at another
> > > developers code. The YUI API is the starting point for much of
the
> > > Fork API.
> > >
> > > Most libraries seem to develop too quickly. API''s are
fixed from the
> > > first alpha version and code is not allowed to morph for the
early
> > > part of it''s life. I like the general debian attitude of
careful
> > > growth because the browser execution environment is wildly varied
and
> > > deserves a certain degree of conservatism in the JavaScript we
send to
> > > it.
> > >
> > > Most JavaScript libraries settle for "good enough" and
don''t seem to
> > > aspire to the high level of quality to which the Fork library
aspires.
> > > By keeping an eye on other JavaScript libraries the good parts
can be
> > > brought into the Fork code.
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

I certainly disagree that Dojo''s code base is low quality, and I
believe
many others would as well.
I wish you luck with your framework.

On 11/29/06, Peter Michaux
<petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
>
> Hi Mark,
>
> On 11/29/06, Mark Holton
<holtonma-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> > Dojotoolkit is the best I''ve found, and I''ve looked
at nearly all of
> them...
>
> People I have talked with about Dojo have run as fast as they can away
> from it because of code quality. I have looked at Dojo and the most
> disturbing thing I saw was that demo pages load very slowly. Dojo
> seems like the ultimate example of growing too fast and buggy.
>
> > it also has all of the bullet points you mentioned..  and is
extensible.
>
> > Just as importantly, it has a lot of industry support and will be long
> > lasting (not developed in the corner by 1 or two people).
>
> They all start with a small group.
>
> >  I don''t mean to burst your bubble, I''m sure you
worked hard and it''s
> > probably nice code, and if it works for you, great... but would like
to
> say
> > good luck to those developers trying every js library that pops up
> (which
> > seems to be some sort of wheel-reinvention virus going around).  It
can
> be a
> > huge time sink.  I''m personally sticking with those that are
very likely
> to
> > persist -- namely, Dojo and Prototype.  imho, I think a lot of
> developers
> > would be wise to add to foundations that are already solid, with solid
> > support, rather than reinventing the wheel.
>
> I''m not trying to reinvent the wheel. Other people have shown the
idea
> of a wheel is useful. I''m carefully making a circular wheel. That
> would be an improvement enough but I also want the wheel on high
> quality bearings.
>
> Why Gmail when Hotmail existed?
> Why Rails when Struts existed?
> Why Mephisto when Typo existed?
>
> I think if you take a look at the Fork code you will see it is headed
> in a high quality direction that other libs are not.
>
> Peter
>
>
> > On 11/29/06, Peter Michaux
<petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> a> >
> > > If you work with Rails but are unhappy with Prototype . . .
> > >
> > > I''m excited about the launch of my new JavaScript
library called Fork
> > > at http://forkjavascript.org with the MIT license. Below are
snips
> > > from the front page of the Fork site...
> > >
> > > Fork is a JavaScript library with Ajax, Events, DOM manipulation,
etc.
> > > Fork is a general purpose library with a few bonus lines in the
Ajax
> > > library specifically for use with Ruby on Rails however the
library
> > > can be happily used outside of Rails also.
> > >
> > > advantages
> > >
> > >     * an aspiration for the highest quality code
> > >     * author documentation
> > >     * in-browser unit/integration tests
> > >     * namespaced code
> > >     * does not augment JavaScript built-in prototypes
> > >     * does not add a layer of sugar on top of JavaScript to make
> > > writing JavaScript like writing in another language
> > >     * Is minimizable with jsmin
> > >     * MIT License
> > >
> > > There are many JavaScript libraries out there. Why add another
one to
> > > the list? To create a quality library with a liberal license.
> > >
> > > I like Ruby on Rails. I want Rails to have a better JavaScript
> > > library. I (and many others!) think the Rails default Prototype
> > > JavaScript library has many seriously poor design decisions and
is
> > > poorly coded. Suggestions to improve the Prototype code sit on
the
> > > Rails trac seemingly forever and author Sam Stephenson does not
> > > interact openly with the community of Rails and Prototype users.
> > > Because Prototype does not play well with other JavaScript
libraries
> > > it isn''t necessarily possible to use Prototype in
combination with
> > > Fork. This fact likely will never change because of
Prototype''s
> > > fundamental design. On the other hand, Fork does plays well with
other
> > > respectful libraries.
> > >
> > > I like the Yahoo! UI library. Of the JavaScript libraries
I''ve used it
> > > has the best API. The YUI library has many valuable nuggets of
> > > information about browser bugs and workarounds. The code approach
of
> > > YUI suits browser scripting well. However there are more than a
few
> > > places in the code where I''m left scratching my head and
thinking "why
>
> > > did they do that?" Maybe that is how every developer looks
at another
> > > developers code. The YUI API is the starting point for much of
the
> > > Fork API.
> > >
> > > Most libraries seem to develop too quickly. API''s are
fixed from the
> > > first alpha version and code is not allowed to morph for the
early
> > > part of it''s life. I like the general debian attitude of
careful
> > > growth because the browser execution environment is wildly varied
and
> > > deserves a certain degree of conservatism in the JavaScript we
send to
> > > it.
> > >
> > > Most JavaScript libraries settle for "good enough" and
don''t seem to
> > > aspire to the high level of quality to which the Fork library
aspires.
>
> > > By keeping an eye on other JavaScript libraries the good parts
can be
> > > brought into the Fork code.
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Peter,

Keep it up.  Everybody starts somewhere... I was happy with Alta Vista
until google caught my eye. :)

I think the thing that bothers me the most about prototype is the
total lack up communication from Sam.  Sam should learn a thing or two
from Thomas. :)

Andrew

On 11/29/06, Peter Michaux
<petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> Hi Mark,
>
> On 11/29/06, Mark Holton
<holtonma-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> > Dojotoolkit is the best I''ve found, and I''ve looked
at nearly all of them...
>
> People I have talked with about Dojo have run as fast as they can away
> from it because of code quality. I have looked at Dojo and the most
> disturbing thing I saw was that demo pages load very slowly. Dojo
> seems like the ultimate example of growing too fast and buggy.
>
> > it also has all of the bullet points you mentioned..  and is
extensible.
> > Just as importantly, it has a lot of industry support and will be long
> > lasting (not developed in the corner by 1 or two people).
>
> They all start with a small group.
>
> >  I don''t mean to burst your bubble, I''m sure you
worked hard and it''s
> > probably nice code, and if it works for you, great... but would like
to say
> > good luck to those developers trying every js library that pops up
(which
> > seems to be some sort of wheel-reinvention virus going around).  It
can be a
> > huge time sink.  I''m personally sticking with those that are
very likely to
> > persist -- namely, Dojo and Prototype.  imho, I think a lot of
developers
> > would be wise to add to foundations that are already solid, with solid
> > support, rather than reinventing the wheel.
>
> I''m not trying to reinvent the wheel. Other people have shown the
idea
> of a wheel is useful. I''m carefully making a circular wheel. That
> would be an improvement enough but I also want the wheel on high
> quality bearings.
>
> Why Gmail when Hotmail existed?
> Why Rails when Struts existed?
> Why Mephisto when Typo existed?
>
> I think if you take a look at the Fork code you will see it is headed
> in a high quality direction that other libs are not.
>
> Peter
>
>
> > On 11/29/06, Peter Michaux
<petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> a> >
> > > If you work with Rails but are unhappy with Prototype . . .
> > >
> > > I''m excited about the launch of my new JavaScript
library called Fork
> > > at http://forkjavascript.org with the MIT license. Below are
snips
> > > from the front page of the Fork site...
> > >
> > > Fork is a JavaScript library with Ajax, Events, DOM manipulation,
etc.
> > > Fork is a general purpose library with a few bonus lines in the
Ajax
> > > library specifically for use with Ruby on Rails however the
library
> > > can be happily used outside of Rails also.
> > >
> > > advantages
> > >
> > >     * an aspiration for the highest quality code
> > >     * author documentation
> > >     * in-browser unit/integration tests
> > >     * namespaced code
> > >     * does not augment JavaScript built-in prototypes
> > >     * does not add a layer of sugar on top of JavaScript to make
> > > writing JavaScript like writing in another language
> > >     * Is minimizable with jsmin
> > >     * MIT License
> > >
> > > There are many JavaScript libraries out there. Why add another
one to
> > > the list? To create a quality library with a liberal license.
> > >
> > > I like Ruby on Rails. I want Rails to have a better JavaScript
> > > library. I (and many others!) think the Rails default Prototype
> > > JavaScript library has many seriously poor design decisions and
is
> > > poorly coded. Suggestions to improve the Prototype code sit on
the
> > > Rails trac seemingly forever and author Sam Stephenson does not
> > > interact openly with the community of Rails and Prototype users.
> > > Because Prototype does not play well with other JavaScript
libraries
> > > it isn''t necessarily possible to use Prototype in
combination with
> > > Fork. This fact likely will never change because of
Prototype''s
> > > fundamental design. On the other hand, Fork does plays well with
other
> > > respectful libraries.
> > >
> > > I like the Yahoo! UI library. Of the JavaScript libraries
I''ve used it
> > > has the best API. The YUI library has many valuable nuggets of
> > > information about browser bugs and workarounds. The code approach
of
> > > YUI suits browser scripting well. However there are more than a
few
> > > places in the code where I''m left scratching my head and
thinking "why
> > > did they do that?" Maybe that is how every developer looks
at another
> > > developers code. The YUI API is the starting point for much of
the
> > > Fork API.
> > >
> > > Most libraries seem to develop too quickly. API''s are
fixed from the
> > > first alpha version and code is not allowed to morph for the
early
> > > part of it''s life. I like the general debian attitude of
careful
> > > growth because the browser execution environment is wildly varied
and
> > > deserves a certain degree of conservatism in the JavaScript we
send to
> > > it.
> > >
> > > Most JavaScript libraries settle for "good enough" and
don''t seem to
> > > aspire to the high level of quality to which the Fork library
aspires.
> > > By keeping an eye on other JavaScript libraries the good parts
can be
> > > brought into the Fork code.
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

On 11/29/06, Mark Holton
<holtonma-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> I certainly disagree that Dojo''s code base is low quality, and I
believe
> many others would disagree with that statement as well.
No doubt.
> Best wishes with your library.
Thank you.
> I''m sticking with what I know are two very robust, and extensible
libraries.
One nice thing about JavaScript is that all libraries are extensible.

Unfortunately Prototype is not robust which is why I have invested so
much time in creating an alternative.

Peter

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi Andrew,

On 11/29/06, Andrew Kaspick
<akaspick-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> Keep it up.  Everybody starts somewhere... I was happy with Alta Vista
> until google caught my eye. :)
Thanks.
> I think the thing that bothers me the most about prototype is the
> total lack up communication from Sam.  Sam should learn a thing or two
> from Thomas. :)
Agreed. Thomas is very friendly and helpful. But Scriptaculous depends
on Prototype and Thomas has said that it always will. So unfortunately
Scriptaculous is out for me.

Peter

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Peter Michaux wrote:
> If you work with Rails but are unhappy with Prototype . . .
> 
> I''m excited about the launch of my new JavaScript library called
Fork
> at http://forkjavascript.org with the MIT license. Below are snips
> from the front page of the Fork site...
I actually like the design of Prototype and Scriptaculous (for probably 
the same reasons you dislike it) but I understand that everyone has 
their own needs and opinions so I welcome another library.

One thing you may want to consider. Part of the reason so many people 
are into Prototype is because Rails has tight integration with 
Prototype. If you are looking for bigger adoption it might be useful to 
also provide some Rails integration. What would be great is if a plugin 
could override the javascript integration built into Rails to do the 
same thing with your library. That way a person could transparently 
switch to another Javascript library (such as yours).

Without the integration I would imagine most people will "go with the 
flow" and continue to use Prototype even if it is not their favorite.

Eric


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi Eric,

On 11/29/06, Eric Anderson <eric-ANzg6odk14w@public.gmane.org>
wrote:
>
> Peter Michaux wrote:
> > If you work with Rails but are unhappy with Prototype . . .
> >
> > I''m excited about the launch of my new JavaScript library
called Fork
> > at http://forkjavascript.org with the MIT license. Below are snips
> > from the front page of the Fork site...
>
> I actually like the design of Prototype and Scriptaculous (for probably
> the same reasons you dislike it) but I understand that everyone has
> their own needs and opinions so I welcome another library.
I understand the idea of liking one API over another. Fair enough.
However, I think that choosing an library because it has a nice API
but poor internals is an unfortunate choice. Browser scripting is such
a difficult deployment environment that going with the way browsers
like to do things is more important than making JavaScript work the
way developers want with sugar. I think the final results in a web
page are more important then slight changes in code friendliness with
buggy sugar.
> One thing you may want to consider. Part of the reason so many people
> are into Prototype is because Rails has tight integration with
> Prototype. If you are looking for bigger adoption it might be useful to
> also provide some Rails integration. What would be great is if a plugin
> could override the javascript integration built into Rails to do the
> same thing with your library. That way a person could transparently
> switch to another Javascript library (such as yours).
>
> Without the integration I would imagine most people will "go with the
> flow" and continue to use Prototype even if it is not their favorite.
You are right. The Ajax part of my library already does the necessary
REST tricks but I do need to have a plugin for link_to_remote and
form_for etc. The plugin should be relatively short. I am focusing on
quality JavaScript right now (for example, I''ve spent about 6 hours
researching opacity setting today.) Perhaps someone better versed in
the current Rails core would be willing to write a short plugin for
the action view helpers. It is literaly on my list of things to do but
a little down the list so if anyone is interested please let me know.

I am not interested in a plugin to add my DOM mutate functions
(prototype''s Event.replace, and insertion etc.) available through rjs
because Dan Webb''s new ejs templates are so much better than rjs and I
think Rails developers should be encouraged to use ejs (I think RJS
should be deprecated or at least moved to a plugin and ejs moved to
core).

http://www.danwebb.net/2006/11/24/minusmor-released

However is someone wanted to write a plugin for Fork rjs they could
very quickly. That is much easier then link_to_remote and form_for. I
could even supply the basic blocks as I''ve done this before.

Thanks,
Peter

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

The biggest difference between Prototype zealots and zealots of other
libraries, I''ve found, is that the former embraces the term
"philosophy
differences" whereas the latter prefers "poor design decisions." 
This
contrast in terminology mirrors the disparate reasons one would start a
new JavaScript library:

(1) To espouse one''s own coding philosophy.
(2) To "aspire to [a] high level of quality," suggesting that the
authors of other libraries are lazy or aren''t interested in doing good
work.

I make no value judgments about your code -- the parts I saw look quite
nice -- but we''ve all been doing this a while, and we''re all
quite
opinionated, so I recommend a change in tone.  Your initial e-mail
overshadows the seeming quality of your framework and makes you sound
like a self-infatuated person suffering from the late stages of
Not-Invented-Here syndrome.  I guarantee nobody adopts a library solely
on the library author''s assurance that his code is Really Awesome.

Cheers,
Andrew

On Nov 29, 12:55 pm, "Peter Michaux"
<petermich...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> If you work with Rails but are unhappy with Prototype . . .
>
> I''m excited about the launch of my new JavaScript library called
Fork
> athttp://forkjavascript.orgwith the MIT license. Below are snips
> from the front page of the Fork site...
>
> Fork is a JavaScript library with Ajax, Events, DOM manipulation, etc.
> Fork is a general purpose library with a few bonus lines in the Ajax
> library specifically for use with Ruby on Rails however the library
> can be happily used outside of Rails also.
>
> advantages
>
>     * an aspiration for the highest quality code
>     * author documentation
>     * in-browser unit/integration tests
>     * namespaced code
>     * does not augment JavaScript built-in prototypes
>     * does not add a layer of sugar on top of JavaScript to make
> writing JavaScript like writing in another language
>     * Is minimizable with jsmin
>     * MIT License
>
> There are many JavaScript libraries out there. Why add another one to
> the list? To create a quality library with a liberal license.
>
> I like Ruby on Rails. I want Rails to have a better JavaScript
> library. I (and many others!) think the Rails default Prototype
> JavaScript library has many seriously poor design decisions and is
> poorly coded. Suggestions to improve the Prototype code sit on the
> Rails trac seemingly forever and author Sam Stephenson does not
> interact openly with the community of Rails and Prototype users.
> Because Prototype does not play well with other JavaScript libraries
> it isn''t necessarily possible to use Prototype in combination with
> Fork. This fact likely will never change because of Prototype''s
> fundamental design. On the other hand, Fork does plays well with other
> respectful libraries.
>
> I like the Yahoo! UI library. Of the JavaScript libraries I''ve
used it
> has the best API. The YUI library has many valuable nuggets of
> information about browser bugs and workarounds. The code approach of
> YUI suits browser scripting well. However there are more than a few
> places in the code where I''m left scratching my head and thinking
"why
> did they do that?" Maybe that is how every developer looks at another
> developers code. The YUI API is the starting point for much of the
> Fork API.
>
> Most libraries seem to develop too quickly. API''s are fixed from
the
> first alpha version and code is not allowed to morph for the early
> part of it''s life. I like the general debian attitude of careful
> growth because the browser execution environment is wildly varied and
> deserves a certain degree of conservatism in the JavaScript we send to
> it.
>
> Most JavaScript libraries settle for "good enough" and
don''t seem to
> aspire to the high level of quality to which the Fork library aspires.
> By keeping an eye on other JavaScript libraries the good parts can be
> brought into the Fork code.

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi Andrew,

On 11/29/06, Andrew Dupont
<google-TiabPMV39B5K4mp1Ns0Z8Q@public.gmane.org>
wrote:
>
> The biggest difference between Prototype zealots and zealots of other
> libraries, I''ve found, is that the former embraces the term
"philosophy
> differences" whereas the latter prefers "poor design
decisions."
I have always thought that Prototype enthusiasts have to call them
philosophy differences because they wouldn''t very well call their
chosen library poorly designed.

> This contrast in terminology mirrors the disparate reasons one would start
a
> new JavaScript library:
>
> (1) To espouse one''s own coding philosophy.
This is not me. I am developing a good library I can use for work. I
also want to share it because quality JavaScript is hard to come by
and I want Rails to benefit.

> (2) To "aspire to [a] high level of quality," suggesting that the
> authors of other libraries are lazy or aren''t interested in doing
good
> work.
I wouldn''t suggest they are lazy or uninterested although it might be
true of some. I don''t know. I think they are probably busy and
don''t
get around to it. I also think that some people maybe like making
fancy, exciting UI''s but their personalities are not suited to the
kind of tedious and frustrating research that is necessary for
building cross-browser code library. It requires about 20 or more
browser versions on various operating systems.

> I make no value judgments about your code -- the parts I saw look quite
> nice -- but we''ve all been doing this a while, and we''re
all quite
> opinionated, so I recommend a change in tone.  Your initial e-mail
> overshadows the seeming quality of your framework and makes you sound
> like a self-infatuated person suffering from the late stages of
> Not-Invented-Here syndrome.  I guarantee nobody adopts a library solely
> on the library author''s assurance that his code is Really Awesome.
One time here I tried to explain the places where I saw Prototype has
problems but the suggestions fell mostly on deaf ears. I did receive
an email of appreciation that someone was finally saying something on
this spinoffs list. Another person, who was very angry with me during
that discussion, emailed me an apology yesterday (months later) and
stated that he has stopped using Prototype. I now know of even more
weak spots in Prototype then I did at that time. So far I have decided
not to create a web page that lists all the spots I''m talking about
because I don''t want to evoke more flaming and I really don''t
have
time. I won''t be using Prototype.

It seems the Prototype community is very defensive about the code base
because they like how it feels to program with Prototype. They
maintain their alegence even in light of what I think is well reasoned
criticisim about where the library will fail.

I don''t expect anyone to adopt Fork based on my claim of aspiring to
high quality code. I hope my claim encourages them to take a look and
see for themselves that the code is good. And if they can tell me why
it is not good then I would really like to know. And if I agree then I
will make changes.

Peter

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Andrew Dupont wrote:
> The biggest difference between Prototype zealots and zealots of other
> libraries, I''ve found, is that the former embraces the term
"philosophy
> differences" whereas the latter prefers "poor design
decisions." ...
>
>   
>> On Nov 29, 12:55 pm, "Peter Michaux"
<petermich...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:...
>>
>> advantages
>>
>>     * an aspiration for the highest quality code
>>     * author documentation
>>     * in-browser unit/integration tests
>>     * namespaced code
>>     * does not augment JavaScript built-in prototypes
>>     * does not add a layer of sugar on top of JavaScript to make
>> writing JavaScript like writing in another language
>>     * Is minimizable with jsmin
>>     * MIT License
>>     
Andrew,
Very well put.  I agree that most of these "advantages" are really 
philosophy preferences.  I''ve been using prototype + scriptaculous 
heavily for almost a year now, (outside of Ruby) and none of these 
"advantages" mean anything for my coding situations.

Just wanted to voice my agreement.

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

On 11/29/06, Peter Michaux
<petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>     * an aspiration for the highest quality code
>     * author documentation
>     * in-browser unit/integration tests
>     * namespaced code
>     * does not augment JavaScript built-in prototypes
>     * does not add a layer of sugar on top of JavaScript to make
> writing JavaScript like writing in another language
>     * Is minimizable with jsmin
>     * MIT License
>
> There are many JavaScript libraries out there. Why add another one to
> the list? To create a quality library with a liberal license.
I agree with you on many points:

* YUI made the best design decisions in their widgets
* YUI''s non-widget code has some strangeness
* prototype''s modifications to built in objects is unacceptable (only
because of design flaws in JS)
* dojo''s quality varies (it''s not bad, it varies)
* I care very much about high quality code, api, and architecture

but I disagree that the result is a new library.

I''ll toss in MochiKit as the library you should have used/modified
instead of rolling your own. I suppose that the ''sugar''
comment is the
reason for rejecting MochiKit, but iterators are a part of JS (as of
1.7) and aren''t required, comparison has to be solved somehow, I
can''t
imagine someone preferring the normal DOM over MochiKit.DOM,
MochiKit.Signal has an api that''s fairly close to yours except it
normalizes the event rather than providing access functions, and
MochiKit.Visual is a port of Scriptaculous, which you''ve mentioned you
like. That leaves MochiKit.Async. I''ll admit that deferreds are weird,
but weird enough to write a new library? Eh.

As to writing new stuff, I dislike scriptaculous'' effects architecture
and wrote my own. I''m also slowly porting the YUI widgets that I like
over to MochiKit. I''m working against the MochiKit.Visual code and
scriptaculous stuff, but that''s a much smaller task than re-learning
all the weird browser issues and writing a completely new framework
without a clear goal other than being better than everybody else.

I was at a talk with Paul Graham and he mentioned that "doing X but
better" wasn''t a great way to pitch a startup. Sure, you might
actually be better, but how are we supposed to know that you''re
actually better until you prove it? The other libraries have a vision:

* prototype - We love prototype hacking and come with rails (was a first mover)
* MochiKit - We make javascript suck less (we love syntax sugar) (first mover)
* TIBCO - We provides bazillions of components but you need(ed) to pay
us money (first mover, recently open sourced)
* Dojo - We are the omnibus of frameworks, we do it all, anywhere, for
as many people as possible (early)
* YUI - We think the web needs design patterns (and we have Doug Crockford)
* GWT - We''re Google. We do Javascript in Java.
* Mootools - Size matters. We do it smaller.

All these projects have mindshare and userbases. The first movers have
been around for a year and a half, the remainder for at least a couple
months. All but maybe Moo and prototype (which I''m not sure about)
have multiple developers backing the project and enough momentum that
they''re not going to die anytime soon. Most are MIT or BSD licensed.
I''m not saying that you can''t carve a niche, but
you''re entering a
fairly crowded space with a new and unproven project. Good luck.

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

On 11/29/06, Ken Snyder <ksnyder-evSXmdsRj0TQT0dZR+AlfA@public.gmane.org>
wrote:
>
> Andrew Dupont wrote:
> > The biggest difference between Prototype zealots and zealots of other
> > libraries, I''ve found, is that the former embraces the term
"philosophy
> > differences" whereas the latter prefers "poor design
decisions." ...
> >
> >
> >> On Nov 29, 12:55 pm, "Peter Michaux"
<petermich...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:...
> >>
> >> advantages
> >>
> >>     * an aspiration for the highest quality code
> >>     * author documentation
> >>     * in-browser unit/integration tests
> >>     * namespaced code
> >>     * does not augment JavaScript built-in prototypes
> >>     * does not add a layer of sugar on top of JavaScript to make
> >> writing JavaScript like writing in another language
> >>     * Is minimizable with jsmin
> >>     * MIT License
> >>
> Andrew,
> Very well put.  I agree that most of these "advantages" are
really
> philosophy preferences.  I''ve been using prototype + scriptaculous
> heavily for almost a year now, (outside of Ruby) and none of these
> "advantages" mean anything for my coding situations.
If your coding situation ever changes to where you will be injecting
small bits of code into an already large site with lots of varied, old
and bad JavaScript then you probably won''t be able to use Prototype
and sleep well. The augmentation of built in prototypes and the lack
of a namespace could really burn you. And then if you have to stop
using Prototype and Scriptaculous you have to invent new code or learn
a new library.

Peter

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi Karl,

On 11/29/06, Karl Guertin
<grayrest-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> I''ll toss in MochiKit as the library you should have used/modified
> instead of rolling your own. I suppose that the ''sugar''
comment is the
> reason for rejecting MochiKit,
Yes
> but iterators are a part of JS
not cross-browser in today''s browser environment.
> (as of 1.7)
Which so far is only in Firefox 2.0 as far as I know which means it
could be 7-10 years before we can use iterators for public internet
sites.
> and aren''t required, comparison has to be solved somehow, I
can''t
> imagine someone preferring the normal DOM over MochiKit.DOM,
> MochiKit.Signal has an api that''s fairly close to yours except it
> normalizes the event rather than providing access functions
That is fine design decision but I don''t want the bulk of creating a
new object to wrap the event object. It seems wasteful. I''m not 100%
hung up on event.stopPropagation() instead of stopPropagation(event).
> , and
> MochiKit.Visual is a port of Scriptaculous, which you''ve mentioned
you
> like.
I only think Scriptaculous is a good resource to look at for ideas and
browser bug clues.
> That leaves MochiKit.Async. I''ll admit that deferreds are weird,
> but weird enough to write a new library? Eh.
>
> As to writing new stuff, I dislike scriptaculous'' effects
architecture
> and wrote my own. I''m also slowly porting the YUI widgets that I
like
> over to MochiKit. I''m working against the MochiKit.Visual code and
> scriptaculous stuff, but that''s a much smaller task than
re-learning
> all the weird browser issues and writing a completely new framework
> without a clear goal other than being better than everybody else.
I think if you look carefully in the Prototype and Scriptaculous code
you will find they have not solved the browser wierdness well in many
places. I can''t say much about the mochikit code because I
don''t know
it well but here is a piece of mochikit code that could use attention

  var ua=navigator.userAgent.toLowerCase();
  if((typeof
(opera)!="undefined"&&parseFloat(opera.version())<9)||(ua.indexOf("safari")!=-1&&self.computedStyle(elem,"position")=="absolute")){
  c.x-=b.offsetLeft;
  c.y-=b.offsetTop;
  }

It''s easy to take pot shots at code like this but I''ve become
so
disappointed by the JavaScript I have seen that it is easier just to
research the ideas from scratch and write a new library with the bonus
of the API I want.

> I was at a talk with Paul Graham and he mentioned that "doing X but
> better" wasn''t a great way to pitch a startup. Sure, you
might
> actually be better, but how are we supposed to know that you''re
> actually better until you prove it?
>
> The other libraries have a vision:
>
> * prototype - We love prototype hacking and come with rails (was a first
mover)
> * MochiKit - We make javascript suck less (we love syntax sugar) (first
mover)
> * TIBCO - We provides bazillions of components but you need(ed) to pay
> us money (first mover, recently open sourced)
> * Dojo - We are the omnibus of frameworks, we do it all, anywhere, for
> as many people as possible (early)
> * YUI - We think the web needs design patterns (and we have Doug Crockford)
> * GWT - We''re Google. We do Javascript in Java.
> * Mootools - Size matters. We do it smaller.
>
> All these projects have mindshare and userbases. The first movers have
> been around for a year and a half, the remainder for at least a couple
> months. All but maybe Moo and prototype (which I''m not sure about)
> have multiple developers backing the project and enough momentum that
> they''re not going to die anytime soon. Most are MIT or BSD
licensed.
> I''m not saying that you can''t carve a niche, but
you''re entering a
> fairly crowded space with a new and unproven project.
You have valid points but I am not starting Fork for profit so the
situation is a little different then a start up. There are Rails
developers who don''t like Prototype. I might provide a solution for
them.
> Good luck.
Thanks

Peter

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

On 11/29/06, Peter Michaux
<petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> not cross-browser in today''s browser environment.
Not the point. The point is that iterators aren''t "some other
language".
> Which so far is only in Firefox 2.0 as far as I know which means it
> could be 7-10 years before we can use iterators for public internet
> sites.
I use iterators today. ;]
> I only think Scriptaculous is a good resource to look at for ideas and
> browser bug clues.
Fair enough.
> I think if you look carefully in the Prototype and Scriptaculous code
> you will find they have not solved the browser wierdness well in many
> places. I can''t say much about the mochikit code because I
don''t know
> it well but here is a piece of mochikit code that could use attention
>
>   var ua=navigator.userAgent.toLowerCase();
>   if((typeof
>
(opera)!="undefined"&&parseFloat(opera.version())<9)||(ua.indexOf("safari")!=-1&&self.computedStyle(elem,"position")=="absolute")){
>   c.x-=b.offsetLeft;
>   c.y-=b.offsetTop;
>   }
Aside from having no safari version check (and it probably being
better to check for WebKit rather than Safari), I see no problem with
that code. It''s there specifically to work around problems in
particular user agents. You have to check user agents to do that. Is
there something else that you object to?

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi Karl,

On 11/29/06, Karl Guertin
<grayrest-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >   var ua=navigator.userAgent.toLowerCase();
> >   if((typeof
> >
(opera)!="undefined"&&parseFloat(opera.version())<9)||(ua.indexOf("safari")!=-1&&self.computedStyle(elem,"position")=="absolute")){
> >   c.x-=b.offsetLeft;
> >   c.y-=b.offsetTop;
> >   }
>
> Aside from having no safari version check (and it probably being
> better to check for WebKit rather than Safari), I see no problem with
> that code. It''s there specifically to work around problems in
> particular user agents. You have to check user agents to do that. Is
> there something else that you object to?
If you say "Aside from . . ." then it seems that you also think that
this code needs some attention.

Browser sniffing in general is the problem

http://jibbering.com/faq/faq_notes/not_browser_detect.html

navigator.userAgent should be avoided like the plague. The only
exception I''ve been able to think of is if I want a border to be red
in IE and blue in Safari and I don''t really care if it is red or blue
in either browser. That is, I don''t care if navigator.userAgent is
lying.

Peter

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

On Nov 29, 5:09 pm, "Peter Michaux"
<petermich...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>I have always thought that Prototype enthusiasts have to call them
> philosophy differences because they wouldn''t very well call their
> chosen library poorly designed.
For a split second after I read this I was convinced you were trolling.
> I wouldn''t suggest they are lazy or uninterested although it might
be
> true of some. I don''t know. I think they are probably busy and
don''t
> get around to it. I also think that some people maybe like making
> fancy, exciting UI''s but their personalities are not suited to the
> kind of tedious and frustrating research that is necessary for
> building cross-browser code library. It requires about 20 or more
> browser versions on various operating systems.
First of all, you seem to be referring almost entirely to Sam in the
above paragraph, based on what little he reveals about himself to the
public.  It''s not for me to defend Sam against allegations of poor
community maintenance; I think "having a day job" is enough.  But
that''s why Thomas helps out (and, man, has he been doing awesome work
on the bug tracker recently), and that''s why Prototype Core was
created.

Plenty of bugfixing is going on these days, most of it by Thomas --
leaving Sam to swoop in every few weeks and make a flurry of
big-picture commits.  To suggest that Prototype (or Dojo, or Mochikit,
or YUI) does not take browser compatibility seriously enough is to
erect a ludicrous straw man.
> One time here I tried to explain the places where I saw Prototype has
> problems but the suggestions fell mostly on deaf ears. I did receive
> an email of appreciation that someone was finally saying something on
> this spinoffs list. Another person, who was very angry with me during
> that discussion, emailed me an apology yesterday (months later) and
> stated that he has stopped using Prototype. I now know of even more
> weak spots in Prototype then I did at that time. So far I have decided
> not to create a web page that lists all the spots I''m talking
about
> because I don''t want to evoke more flaming and I really
don''t have
> time. I won''t be using Prototype.
Every man has the freedom to choose his own library.  But this is
starting to feel like a heated argument over a TV show.  If this were a
"Lost" mailing list and you posted about how you''d never
liked the
show, then started trying to convince individual members of the list
that they were wrong and you were right, I think the surrealness of
this exchange would be more apparent.

There is no "right" or "wrong" library, in the same way that
there is
no "right" or "wrong" language; use what makes you happy. 
But you seem
to be saying that a library choice is more than a simple matter of
taste.
> It seems the Prototype community is very defensive about the code base
> because they like how it feels to program with Prototype. They
> maintain their alegence even in light of what I think is well reasoned
> criticisim about where the library will fail.
I will admit that I like "how it feels" to program with Prototype, but
never before have I been made to feel *dirty* for it.  You''ve awakened
the guilt of my Catholic upbringing!


To make a larger point: yes, I understand how there are environments
where Prototype does not make sense, and where a fully-namespaced
solution would be far more suitable.  I have a great respect for
MochiKit and would probably use it if I could not use Prototype for
whatever reason.

But we''re all grown-ups here, and we''ve all made that decision
as
individuals, weighing the drawbacks of Prototype against the details of
the environment in which it will be used.  It''s grating, then, to read
the words of someone who thinks he''s better equipped to decide for me.

Incidentally, I think Prototype stands on its own merits apart from
Rails (many major non-RoR sites use it), but I support the idea of
abstracting the JS helper methods from any particular framework. Change
your talking points and I guarantee you''ll be far better-received, both
on this list and in the Rails community at large.


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

On 11/29/06, Peter Michaux
<petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> If you say "Aside from . . ." then it seems that you also think
that
> this code needs some attention.
Sure, the lack of a version check might be a problem if the WebKit
team changes the behavior in a future version. On the other hand,
putting a known version number will definitely cause it to break if
the WebKit team doesn''t fix it in the next Safari update, so I can
understand why it''s done. I''ll admit that I''m not
familiar enough with
this issue to tell whether the changes I mentioned are necessary or
not, hence the qualification before the suggestions.

It''s my personal preference to check rendering engines for gecko and
webkit to account for alternate browsers based on those platforms, but
I don''t consider code "poor quality" if the author
doesn''t feel the
same way. One of these days, I''ll get a test environment set up like
Alex Russell''s [1] so I can definitively fix issues like this. Until
then, I''ll just have to live with the code written by people who did
test and fix the issues and trust the community built around the
framework for bug reports.

[1] http://alex.dojotoolkit.org/?p=588
> navigator.userAgent should be avoided like the plague.
I figured this was your gripe. It is wrong. You should most certainly
do object/feature detection when deciding whether a browser is able to
perform a specific task. The article you linked describes exactly the
reasons why and MochiKit certainly does this .

The code you pasted above does not do this. It corrects a known error
in a particular pair of user agents. There is only one way to fix
errors that you know occur in a particular user agent and that is...
checking the user agent string. You can''t do this with object/feature
detecting because the browser is lying to you.

In theory someone could change their correct user agent to a specific
older version of a non-working useragent and incorrectly get the fix,
but in this day and age, I don''t believe UA switching is widely done.
In any event, UA switchers get what they deserve. If you think this
solution is unnecessarily ugly, you haven''t been doing web development
long enough.

Regards.

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

> Browser sniffing in general is the problem
>
> http://jibbering.com/faq/faq_notes/not_browser_detect.html
>
> navigator.userAgent should be avoided like the plague. The only
> exception I''ve been able to think of is if I want a border to be
red
> in IE and blue in Safari and I don''t really care if it is red or
blue
> in either browser. That is, I don''t care if navigator.userAgent is
> lying.
>
> Peter
In an ideal world: yes. Unfortunately, it is a necessity when object
detection is not possible (usually when a method or property exists but
gives incorrect values)... and can also be a pragmatic design decision
when speed is an issue.


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

On 11/29/06, Karl Guertin
<grayrest-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> If you think this
> solution is unnecessarily ugly, you haven''t been doing web
development
> long enough.
Apologies for the ad-hom. It was uncalled for. My excuse is that I
have a headache, but that''s a poor excuse.

I don''t want this thread to be a flame war, so I''m bowing out.
I do
wish you well on Fork, a high-quality open source option is always
appreciated when starting a new project.

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

With prototype I know I can count on understandable function names, 
unlinke your fooParser functions.

http://dev.forkjavascript.org/browser/trunk/public/javascripts/fork/mutate.js

But, that may just be me.




--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

On 11/29/06, Ian Tyndall <ityndall-ue636x8T32g@public.gmane.org>
wrote:
>
> With prototype I know I can count on understandable function names,
> unlinke your fooParser functions.
>
>
http://dev.forkjavascript.org/browser/trunk/public/javascripts/fork/mutate.js
>
> But, that may just be me.
That needs fixing. I''ll change it tonight. But look at the code around
it. It works many times where Prototype fails.

Peter

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi Tobie,

On 11/29/06, tobie <tobie.langel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> > Browser sniffing in general is the problem
> >
> > http://jibbering.com/faq/faq_notes/not_browser_detect.html
> >
> > navigator.userAgent should be avoided like the plague. The only
> > exception I''ve been able to think of is if I want a border to
be red
> > in IE and blue in Safari and I don''t really care if it is red
or blue
> > in either browser. That is, I don''t care if
navigator.userAgent is
> > lying.
> >
> > Peter
>
> In an ideal world: yes. Unfortunately, it is a necessity when object
> detection is not possible (usually when a method or property exists but
> gives incorrect values)...
There are many times when people think feature detection is not
possible but it is. It is hard work to avoid browser sniffing
sometimes but in a core JavaScript library I think navigator.userAgent
should be out unless there is some extreme situation encountered and
then a big warning in the docs should be put in place.
> and can also be a pragmatic design decision
> when speed is an issue.
When speed is an issue and the client knows the tradeoffs then
navigator.userAgent may be a useful tactic.

Peter

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi Karl,

On 11/29/06, Karl Guertin
<grayrest-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> There is only one way to fix
> errors that you know occur in a particular user agent and that is...
> checking the user agent string.
This isn''t true. Perhaps there is another way to code the solution
that avoids the error all together. Perhaps you can try using the
feature and then checking whether or not it did the right thing. There
are many options and it depends on the situation.

> In theory someone could change their correct user agent to a specific
> older version of a non-working useragent and incorrectly get the fix,
> but in this day and age, I don''t believe UA switching is widely
done.
I agree. I don''t think  individuals are changing there UA string. But
various browsers in use are still lying and that trend doesn''t seem to
be coming to a halt.

Peter

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi Andrew,

On 11/29/06, Andrew Dupont
<google-TiabPMV39B5K4mp1Ns0Z8Q@public.gmane.org>
wrote:
>
> For a split second after I read this I was convinced you were trolling.
>
> > I wouldn''t suggest they are lazy or uninterested although it
might be
> > true of some. I don''t know. I think they are probably busy
and don''t
> > get around to it. I also think that some people maybe like making
> > fancy, exciting UI''s but their personalities are not suited
to the
> > kind of tedious and frustrating research that is necessary for
> > building cross-browser code library. It requires about 20 or more
> > browser versions on various operating systems.
>
> First of all, you seem to be referring almost entirely to Sam in the
> above paragraph,  based on what little he reveals about himself to the
> public.
I was not refering to Sam.
> It''s not for me to defend Sam against allegations of poor
> community maintenance; I think "having a day job" is enough.
I agree, having a day job is a very good reason. Life outside of
JavaScript is more important.

> Every man has the freedom to choose his own library.
You are right about this, of course.

<snip>
> There is no "right" or "wrong" library, in the same way
that there is
> no "right" or "wrong" language; use what makes you
happy.  But you seem
> to be saying that a library choice is more than a simple matter of
> taste.
Choosing a library is much more than a simple matter of taste.

<snip>
> But we''re all grown-ups here, and we''ve all made that
decision as
> individuals, weighing the drawbacks of Prototype against the details of
> the environment in which it will be used.  It''s grating, then, to
read
> the words of someone who thinks he''s better equipped to decide for
me.
I am not better equiped to decide than you. I want to providing an
alternative to people using Rails that don''t like Prototype.
> Incidentally, I think Prototype stands on its own merits apart from
> Rails (many major non-RoR sites use it), but I support the idea of
> abstracting the JS helper methods from any particular framework. Change
> your talking points and I guarantee you''ll be far better-received,
both
> on this list and in the Rails community at large.
This is the tricky part. I want to present a compelling JavaScript
library for Rails. Rails already has a library. So what makes mine
different? I am trying to do a better job. "Better" is comparative so
I need to say better than what.

Peter

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi Ian,

On 11/29/06, Peter Michaux
<petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On 11/29/06, Ian Tyndall <ityndall-ue636x8T32g@public.gmane.org>
wrote:
> >
> > With prototype I know I can count on understandable function names,
> > unlinke your fooParser functions.
$(), $$(), $R(), $H(), $R(), $F()? These seem quite cryptic to me.

> >
http://dev.forkjavascript.org/browser/trunk/public/javascripts/fork/mutate.js
> >
> > But, that may just be me.
>
> That needs fixing. I''ll change it tonight. But look at the code
around
> it. It works many times where Prototype fails.
Fixed. Thanks for the suggestion. I was concerned with good algorithm
first and when I finished that I forgot about the fooParser functions.
I named them "foo" because that stands out like a sore thumb as
needing attention.

Thanks again.
Peter

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

On Nov 29, 10:16 pm, "Peter Michaux"
<petermich...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> Choosing a library is much more than a simple matter of taste.
You''ve lost me here.  Some libraries may be "better" than
others, in
the sense that "The Office" is a lot better than "According to
Jim,"
but not to the point where I seek out "According to Jim" fans and call
them inferior.  We use the framework, we obviously like it, and we get
stuff done with it, in spite of the fact that it appears to offend your
sensibilities.
> I am not better equiped to decide than you. I want to providing an
> alternative to people using Rails that don''t like Prototype.
You need to re-read the stuff you''ve written in this thread. 
You''ve
suggested that choosing Prototype over another framework is
"unfortunate," and you''ve done so without qualifiers, so I
assume you
mean that as a blanket statement.

Again I''ll say: I think providing an alternative, Rails-integrated JS
framework is a great idea.  I think it''d be useful for people who need
a namespaced library and don''t care about making JS feel more
Ruby-like. The only objection I have is with your dogmatism.


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

On 11/29/06, Andrew Dupont
<google-TiabPMV39B5K4mp1Ns0Z8Q@public.gmane.org>
wrote:
>
> On Nov 29, 10:16 pm, "Peter Michaux"
<petermich...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > Choosing a library is much more than a simple matter of taste.
>
> You''ve lost me here.
Choosing a library is complex. Is the library riddled with bugs? Can
the library already do what you need it to do? Is the library written
in a way that makes extension easy? Does the library have
documentation?
> > I am not better equiped to decide than you. I want to providing an
> > alternative to people using Rails that don''t like Prototype.
>
> You need to re-read the stuff you''ve written in this thread. 
You''ve
> suggested that choosing Prototype over another framework is
> "unfortunate," and you''ve done so without qualifiers, so
I assume you
> mean that as a blanket statement.
"However, I think that choosing an library because it has a nice API
but poor internals is an unfortunate choice."

This is a general statement. For me it applies to Prototype.

Peter

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

>
> "However, I think that choosing an library because it has a nice API
> but poor internals is an unfortunate choice."
>
> This is a general statement. For me it applies to Prototype.
>
> Peter

So if this is really true, why would you not spend your time  
improving the internals of prototype...maybe a little harder, but  
this is true whenever you don''t work with your own code...and will be  
true for contributors to your code.

>
> >

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

On 11/29/06, Deco Rior <decorior-w9xKMqPX1QdNhnlO7+U8Og@public.gmane.org>
wrote:
>
> > "However, I think that choosing an library because it has a nice
API
> > but poor internals is an unfortunate choice."
> >
> > This is a general statement. For me it applies to Prototype.
> >
> > Peter
>
>
> So if this is really true, why would you not spend your time
> improving the internals of prototype...
I don''t believe in augmenting built-in object prototypes and I want a
namespaced library. Both those points aside, many people have been
frustrated with the Prototype community input process over the past
year. Not just me. Things may be improving.

Peter

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Peter,

I take that as an offence. Good luck with your libary, but please  
don''t FUD around in this group.

Thanks.

Thomas


Am 29.11.2006 um 22:38 schrieb Peter Michaux:
> I understand the idea of liking one API over another. Fair enough.
> However, I think that choosing an library because it has a nice API
> but poor internals is an unfortunate choice.
--
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





--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Ian Tyndall wrote:
> With prototype I know I can count on understandable function names,
> unlinke your fooParser functions.
>
>
http://dev.forkjavascript.org/browser/trunk/public/javascripts/fork/mutate.js
>
> But, that may just be me.
Probably.  What should prototype''s visible method do?

-- 
Fred


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Thomas Fuchs wrote:
[posting order restored]
> Am 29.11.2006 um 22:38 schrieb Peter Michaux:
> > I understand the idea of liking one API over another. Fair enough.
> > However, I think that choosing an library because it has a nice API
> > but poor internals is an unfortunate choice.
>
> I take that as an offence.
Why? I understood Peter''s statement as saying Prototype has poor
internals and that it is unfortunate if people select a library without
understanding its technical limitations.  I think both assertions can
be supported quite easily.

How does that offend you personally?

-- 
Fred


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi Thomas,

On 11/30/06, Thomas Fuchs
<t.fuchs-moWQItti3gBl57MIdRCFDg@public.gmane.org>
wrote:
>
> Am 29.11.2006 um 22:38 schrieb Peter Michaux:
>
> > I understand the idea of liking one API over another. Fair enough.
> > However, I think that choosing an library because it has a nice API
> > but poor internals is an unfortunate choice.
>
> I take that as an offence.
I hope you don''t take it personally. I don''t mean any
criticism that way.
> Good luck with your libary,
Thanks.
> but please don''t FUD around in this group.
The term "FUD" has unfortunately been overused in the Rails world as a
catch all to deflect unwanted criticism. I think this could only be
detrimental to the improvement of Rails, Prototype and Scriptaculous.

To make criticism concrete here are a few examples.

-----------

In the following code snip the first link doesn''t work but the second
does. Given the logic for making the second link work is already in
Prototype why not have the first one work too? As far as I remember,
Element.update is in a similar situation and there are other problems
when trying to replace or update a tbody element.

<table>
  <tbody id=''tableBody''>
    <tr
id="rowOne"><td>a</td><td>b</td></tr>
    <tr><td>c</td><td>c</td></tr>
  </tbody>
</table>

<p><a href="#"
onclick="Element.replace(''rowOne'',
''<tr><td>e</td><td>f</td></tr>'');return
false;">change row</a></p>
<p><a href="#" onclick="new
Insertion.Bottom(''tableBody'',
''<tr><td>y</td><td>z</td></tr>'');return
false;">insert row</a></p>

----------

I cannot find any match for "dblclick" in Prototype 1.5RC1. What
happens when a developer uses Prototype''s event API to attach a
dblclick, doesn''t have a Mac with Safari 1.3 and a site user has
Safari 1.3? Is their Prototype documentation warning for this
situation? The more important situation is the click/preventDefault
with Safari and I couldn''t find anything for that in Prototype. I have
to do Safari 1.3 testing by phone now so cannot verify these problems
but it doesn''t look like Prototype is handling them.

----------

In the following code snip, what happens if the event does not
support.pageX and does support event.clientX but both attempts to get
scrollLeft return null? The scrollLeft value will type convert to zero
and the returned value will be just clientX which will be wrong if the
page has been scrolled.

pointerX: function(event) {
  return event.pageX || (event.clientX +
    (document.documentElement.scrollLeft || document.body.scrollLeft));
},

It is not necessary to check if event.pageX exists each time this
function is run. Checking just the first time is sufficient. Perhaps
this is just a stylistic bias on my part but this would be a minor
piece in improving performance in a demanding situation like dragdrop
where pointerX() is run frequently.

----------

There are also design decisions like augmenting the Array prototype
which means I cannot safely use Prototype with existing code that uses
a for-in loop on an array.

-----------

You may be able to dismiss some or all of the above criticisms however
I think these are just a few examples that build the case against
Prototype being high quality. There are many other examples like the
ones above. I think Prototype''s track record has to be considered.
Because of this track record, by default I now doubt that Prototype
code works until I read and test it carefully myself. I am uncertain
that Prototype will fix all the problems it has (minus the design
decisions). I would be very afraid to launch a mission critical site
using Prototype that was to run on a wide variety of user agents I
don''t have.

Peter

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

> The term "FUD" has unfortunately been overused in the Rails world
as a
> catch all to deflect unwanted criticism. I think this could only be
> detrimental to the improvement of Rails, Prototype and Scriptaculous.
>
> To make criticism concrete here are a few examples.
[snip]

Why the hell don''t you do what open source is about and contribute to  
prototype and make an effort to eliminate the flaws you found.  
Starting your own project to fix concrete drawbacks in another open  
source project is utter nonsense.


David

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Agree, and well said.
On 11/30/06, David Zülke <dz-c16oUwy5/3O+XT7JhA+gdA@public.gmane.org>
wrote:
>
>
> > The term "FUD" has unfortunately been overused in the Rails
world as a
> > catch all to deflect unwanted criticism. I think this could only be
> > detrimental to the improvement of Rails, Prototype and Scriptaculous.
> >
> > To make criticism concrete here are a few examples.
>
> [snip]
>
> Why the hell don''t you do what open source is about and contribute
to
> prototype and make an effort to eliminate the flaws you found.
> Starting your own project to fix concrete drawbacks in another open
> source project is utter nonsense.
>
>
> David
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Not to side with anyone, but as has been stated many times before, a
lot of feature improvements, bug fixes for prototype seem to sit in
trac without much acknowledgement or feedback.
Thomas is very good with Scriptaculous (as well as helping with
prototype), but I don''t think I''ve ever seen a single post
from Sam
and that does hurt prototype in it''s own way.  Some of you obviously
disagree and hey, think what you like.
I myself have posted a few questions regarding issues with prototype
and never received any feedback on it.  I''m not going out to build a
new javascript lib myself, but it can be discouraging.
This is a spinoff list and Peter is spinning off his own lib.  If it
succeeds, great, if it fails then lesson learnt.
Instead of knocking Peter down, why not let him be (it''s open source,
he can do what he wants) or suggest ways to improve the dialogue
between the prototype maintainers and it''s users.
My 2c,
Andrew
On 11/30/06, Mark Holton
<holtonma-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> Agree, and well said.
>
>
> On 11/30/06, David Zülke <dz-c16oUwy5/3O+XT7JhA+gdA@public.gmane.org>
wrote:
> >
> > > The term "FUD" has unfortunately been overused in the
Rails world as a
> > > catch all to deflect unwanted criticism. I think this could only
be
> > > detrimental to the improvement of Rails, Prototype and
Scriptaculous.
> > >
> > > To make criticism concrete here are a few examples.
> >
> > [snip]
> >
> > Why the hell don''t you do what open source is about and
contribute to
> > prototype and make an effort to eliminate the flaws you found.
> > Starting your own project to fix concrete drawbacks in another open
> > source project is utter nonsense.
> >
> >
> > David
> >
> >
> > > >
> >
>
--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

So... if Peter really wants to make his mark, can he at least try to  
keep the API the same or compatible with Prototype.
After over 12 months of investment, the barrier to migrate with a  
major code change to another library would be daunting. In any case  
it would need to be something with some muscle behind it (by that I  
mean, contributers, funding, third-party certification).
No matter how good the code is, unless I have some degree of  
certainty that the next version of IE will not break it we cannot  
commit.
Our product is based on a long life-cycle. That is we are not a  
boutique that can quickly pick the technology du jour.
Deco
P.S. My admiration of WebObjects
On Nov 30, 2006, at 12:51 PM, Andrew Kaspick wrote:
>
> Not to side with anyone, but as has been stated many times before, a
> lot of feature improvements, bug fixes for prototype seem to sit in
> trac without much acknowledgement or feedback.
>
> Thomas is very good with Scriptaculous (as well as helping with
> prototype), but I don''t think I''ve ever seen a single
post from Sam
> and that does hurt prototype in it''s own way.  Some of you
obviously
> disagree and hey, think what you like.
>
> I myself have posted a few questions regarding issues with prototype
> and never received any feedback on it.  I''m not going out to build
a
> new javascript lib myself, but it can be discouraging.
>
> This is a spinoff list and Peter is spinning off his own lib.  If it
> succeeds, great, if it fails then lesson learnt.
>
> Instead of knocking Peter down, why not let him be (it''s open
source,
> he can do what he wants) or suggest ways to improve the dialogue
> between the prototype maintainers and it''s users.
>
> My 2c,
> Andrew
>
> On 11/30/06, Mark Holton
<holtonma-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> Agree, and well said.
>>
>>
>> On 11/30/06, David Zülke
<dz-c16oUwy5/3O+XT7JhA+gdA@public.gmane.org> wrote:
>>>
>>>> The term "FUD" has unfortunately been overused in the
Rails
>>>> world as a
>>>> catch all to deflect unwanted criticism. I think this could
only be
>>>> detrimental to the improvement of Rails, Prototype and  
>>>> Scriptaculous.
>>>>
>>>> To make criticism concrete here are a few examples.
>>>
>>> [snip]
>>>
>>> Why the hell don''t you do what open source is about and  
>>> contribute to
>>> prototype and make an effort to eliminate the flaws you found.
>>> Starting your own project to fix concrete drawbacks in another open
>>> source project is utter nonsense.
>>>
>>>
>>> David
>>>
>>>
>>>>>
>>>
>>
>
> >
--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi Deco,

On 11/30/06, Deco Rior <decorior-w9xKMqPX1QdNhnlO7+U8Og@public.gmane.org>
wrote:
>
> So... if Peter really wants to make his mark, can he at least try to
> keep the API the same or compatible with Prototype.
The API is similar in some places but can''t stay the same. I am
writing a namespaced library.

For example,

new Insertion.Bottom(id, html)

becomes

FORK.Mutate.insertBottom(id, html)

> After over 12 months of investment, the barrier to migrate with a
> major code change to another library would be daunting.
Fork probably isn''t ready yet for this situation but eventually I
think the work would be worth it.

> In any case
> it would need to be something with some muscle behind it (by that I
> mean, contributers, funding, third-party certification).
Perhaps one day. Not many open source software projects start with
this much muscle.

> No matter how good the code is, unless I have some degree of
> certainty that the next version of IE will not break it we cannot
> commit.
I too need this code to work with IE 7.


Peter

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

First, of all, good luck. This is a big endeavour, and if you feel  
you can be successful we should applaud you for your enthusiasm. A  
little arrogance comes we the territory I think (but you did make me  
cringe a little).


On Nov 30, 2006, at 5:22 PM, Peter Michaux wrote:
>
> Hi Deco,
>
> On 11/30/06, Deco Rior
<decorior-w9xKMqPX1QdNhnlO7+U8Og@public.gmane.org> wrote:
>>
>> So... if Peter really wants to make his mark, can he at least try to
>> keep the API the same or compatible with Prototype.
>
> The API is similar in some places but can''t stay the same. I am
> writing a namespaced library.
Appreciate the NameSpace. That is easy to search and replace.

But don''t expect us to require complex regex to make the transfer,  
and if you do then supply the conversion scripts.  Most migration  
technologies fail, not because of the feature vs. feature comparison,  
but because the barrier to migrate is too high.
>
> For example,
>
> new Insertion.Bottom(id, html)
>
> becomes
>
> FORK.Mutate.insertBottom(id, html)
>
>
>> After over 12 months of investment, the barrier to migrate with a
>> major code change to another library would be daunting.
>
> Fork probably isn''t ready yet for this situation but eventually I
> think the work would be worth it.
Um...how big an app do you think we have? Any major code change is  
very costly, mostly in QA. We essentially are about 80% through our  
rewrite based on AJAX. A major code change is where we cannot simply  
script the code, and requires us to potentially touch each file.

You should have seen the agony we went through in making the decision  
to get away from WebObjects!
>
>
>> In any case
>> it would need to be something with some muscle behind it (by that I
>> mean, contributers, funding, third-party certification).
>
> Perhaps one day. Not many open source software projects start with
> this much muscle.
And you cannot build a mission critical solution on a startup open- 
source. Try and get SAS 70 certification on libraries with version 0.2a!

>
>
>> No matter how good the code is, unless I have some degree of
>> certainty that the next version of IE will not break it we cannot
>> commit.
>
> I too need this code to work with IE 7.
Just an example...the point is that a library that is not maintained  
because of one key developer is a risk.

In many ways this has made us look at DOJO, since SUN, IBM, and  
MICROSOFT are all vested heavily. Say what you want about the code,  
but the bottom line is that we can do everything we need to do even  
though it is not elegant. It is funny, PHP kinda of falls into the  
same category ;-)

Plus we use lasso which has its advantages also.

One dumb question...what is there to stop someone getting a branch of  
prototype source and going off and making a better version? If Sam  
doesn''t have time, that is okay...Do we need a Linus?

>
>
> Peter
>
> >

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

One more thing...

What is this "for use with rails."

I would not tie to a certain development environment.

d
On Nov 30, 2006, at 5:22 PM, Peter Michaux wrote:
>
> Hi Deco,
>
> On 11/30/06, Deco Rior
<decorior-w9xKMqPX1QdNhnlO7+U8Og@public.gmane.org> wrote:
>>
>> So... if Peter really wants to make his mark, can he at least try to
>> keep the API the same or compatible with Prototype.
>
> The API is similar in some places but can''t stay the same. I am
> writing a namespaced library.
>
> For example,
>
> new Insertion.Bottom(id, html)
>
> becomes
>
> FORK.Mutate.insertBottom(id, html)
>
>
>> After over 12 months of investment, the barrier to migrate with a
>> major code change to another library would be daunting.
>
> Fork probably isn''t ready yet for this situation but eventually I
> think the work would be worth it.
>
>
>> In any case
>> it would need to be something with some muscle behind it (by that I
>> mean, contributers, funding, third-party certification).
>
> Perhaps one day. Not many open source software projects start with
> this much muscle.
>
>
>> No matter how good the code is, unless I have some degree of
>> certainty that the next version of IE will not break it we cannot
>> commit.
>
> I too need this code to work with IE 7.
>
>
> Peter
>
> >

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

On 11/30/06, Deco Rior <decorior-w9xKMqPX1QdNhnlO7+U8Og@public.gmane.org>
wrote:
>
> One more thing...
>
> What is this "for use with rails."
>
> I would not tie to a certain development environment.
Fork is not tied to Rails at all. However it does do a few tricks that
the Rails world likes: Rest hack in Ajax lib and the Dom mutation
methods. Nothing needs to be changed to use Fork outside of Rails.

Peter

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Also not sure how this plays out, but support for Comet would be one  
thing that I would be looking at. I am not sure how much overlap  
there might be but I would research it.

Deco

P.S. Should this get off the rails list ASAP?


On Nov 30, 2006, at 6:02 PM, Peter Michaux wrote:
>
> On 11/30/06, Deco Rior
<decorior-w9xKMqPX1QdNhnlO7+U8Og@public.gmane.org> wrote:
>>
>> One more thing...
>>
>> What is this "for use with rails."
>>
>> I would not tie to a certain development environment.
>
> Fork is not tied to Rails at all. However it does do a few tricks that
> the Rails world likes: Rest hack in Ajax lib and the Dom mutation
> methods. Nothing needs to be changed to use Fork outside of Rails.
>
> Peter
>
> >

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Dojo is not associated with Microsoft in any way.  Not that I know of. 
I''m
not sure where you are getting that from.
http://dojotoolkit.org/foundation/

From my understanding, Dojo is funded by IBM, Sun and others shown above
though, and your point is a good one -- well funded open source libraries
are long lasting.  (but Microsoft has it''s own "Atlas"
toolkit... not
working collaboratively with open source, they don''t
''usually'' do that, no)


On 11/30/06, Deco Rior <decorior-w9xKMqPX1QdNhnlO7+U8Og@public.gmane.org>
wrote:
>
>
> First, of all, good luck. This is a big endeavour, and if you feel
> you can be successful we should applaud you for your enthusiasm. A
> little arrogance comes we the territory I think (but you did make me
> cringe a little).
>
>
> On Nov 30, 2006, at 5:22 PM, Peter Michaux wrote:
>
> >
> > Hi Deco,
> >
> > On 11/30/06, Deco Rior
<decorior-w9xKMqPX1QdNhnlO7+U8Og@public.gmane.org> wrote:
> >>
> >> So... if Peter really wants to make his mark, can he at least try
to
> >> keep the API the same or compatible with Prototype.
> >
> > The API is similar in some places but can''t stay the same. I
am
> > writing a namespaced library.
>
> Appreciate the NameSpace. That is easy to search and replace.
>
> But don''t expect us to require complex regex to make the transfer,
> and if you do then supply the conversion scripts.  Most migration
> technologies fail, not because of the feature vs. feature comparison,
> but because the barrier to migrate is too high.
> >
> > For example,
> >
> > new Insertion.Bottom(id, html)
> >
> > becomes
> >
> > FORK.Mutate.insertBottom(id, html)
> >
> >
> >> After over 12 months of investment, the barrier to migrate with a
> >> major code change to another library would be daunting.
> >
> > Fork probably isn''t ready yet for this situation but
eventually I
> > think the work would be worth it.
>
> Um...how big an app do you think we have? Any major code change is
> very costly, mostly in QA. We essentially are about 80% through our
> rewrite based on AJAX. A major code change is where we cannot simply
> script the code, and requires us to potentially touch each file.
>
> You should have seen the agony we went through in making the decision
> to get away from WebObjects!
>
> >
> >
> >> In any case
> >> it would need to be something with some muscle behind it (by that
I
> >> mean, contributers, funding, third-party certification).
> >
> > Perhaps one day. Not many open source software projects start with
> > this much muscle.
>
> And you cannot build a mission critical solution on a startup open-
> source. Try and get SAS 70 certification on libraries with version 0.2a!
>
>
> >
> >
> >> No matter how good the code is, unless I have some degree of
> >> certainty that the next version of IE will not break it we cannot
> >> commit.
> >
> > I too need this code to work with IE 7.
>
> Just an example...the point is that a library that is not maintained
> because of one key developer is a risk.
>
> In many ways this has made us look at DOJO, since SUN, IBM, and
> MICROSOFT are all vested heavily. Say what you want about the code,
> but the bottom line is that we can do everything we need to do even
> though it is not elegant. It is funny, PHP kinda of falls into the
> same category ;-)
>
> Plus we use lasso which has its advantages also.
>
> One dumb question...what is there to stop someone getting a branch of
> prototype source and going off and making a better version? If Sam
> doesn''t have time, that is okay...Do we need a Linus?
>
>
> >
> >
> > Peter
> >
> > >
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi Deco,

On 11/30/06, Deco Rior <decorior-w9xKMqPX1QdNhnlO7+U8Og@public.gmane.org>
wrote:
>
> First, of all, good luck.This is a big endeavour, and if you feel
> you can be successful we should applaud you for your enthusiasm.
Thank you.
> A
> little arrogance comes we the territory I think (but you did make me
> cringe a little).
I don''t intend to be arrogant at all. I want to share the best
possible library I can make that I use and will use. I wouldn''t have
started if I was satisfied with the existing libraries so to say I am
going to try to do better will, unfortunately, come across as arrogant
to some.

> On Nov 30, 2006, at 5:22 PM, Peter Michaux wrote:
> >> After over 12 months of investment, the barrier to migrate with a
> >> major code change to another library would be daunting.
> >
> > Fork probably isn''t ready yet for this situation but
eventually I
> > think the work would be worth it.
>
> Um...how big an app do you think we have?
I don''t know. I thought you were implying a very big code base.
> Any major code change is
> very costly, mostly in QA. We essentially are about 80% through our
> rewrite based on AJAX. A major code change is where we cannot simply
> script the code, and requires us to potentially touch each file.
For the Ajax changes I think you could script the changes from
Prototype to Fork. The API is not wildly that different.

I have not read the Prototype Ajax code in detail or in quite a long
time. I never had a problem with that part of Prototype and wouldn''t
have started Fork for the sake of a different Ajax library.


> >> In any case
> >> it would need to be something with some muscle behind it (by that
I
> >> mean, contributers, funding, third-party certification).
> >
> > Perhaps one day. Not many open source software projects start with
> > this much muscle.
>
> And you cannot build a mission critical solution on a startup open-
> source. Try and get SAS 70 certification on libraries with version 0.2a!
I would have to learn more about that. I haven''t heard of SAS 70
before and just took a look at their site. Right now the focus is on
quality code. Thanks for the suggestion.

> One dumb question...what is there to stop someone getting a branch of
> prototype source and going off and making a better version? If Sam
> doesn''t have time, that is okay...Do we need a Linus?
With an MIT license nothing is stopping anyone as far as I know.

Peter

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

The list is called rails-spinoffs... if we go on the name of the
mailing list alone, then I think this conversation is in the right
place.

PHP, ASP, etc people use this list too... we''re not all rails folk
here (although I am).

On 11/30/06, Deco Rior <decorior-w9xKMqPX1QdNhnlO7+U8Og@public.gmane.org>
wrote:
>
> P.S. Should this get off the rails list ASAP?
>
--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi Deco,

On 11/30/06, Deco Rior <decorior-w9xKMqPX1QdNhnlO7+U8Og@public.gmane.org>
wrote:
>
> Also not sure how this plays out, but support for Comet would be one
> thing that I would be looking at. I am not sure how much overlap
> there might be but I would research it.
I had a look at Comet when some of the earlier Dojo articles came out.
It looked like it had quite a few problems. The 37Signals campfire web
chat application uses server polling every three seconds instead of
Comet. DHH presented something called Armageddon that used real Flash
sockets for server push. I think he decided against using this because
polling was sufficient.

I think that something like Comet probably wouldn''t be a core part of
Fork. I am thinking about a way to release extensions to Fork that sit
on top if that happens. Kind of like Scriptaculous on Prototype. This
way people could contribute new features but they wouldn''t go into
Fork core until they have been proven and belong in core. Much like
Rails plugins are a proving ground now.
> P.S. Should this get off the rails list ASAP?
If you like . . .

http://groups.google.com/group/forkjavascript

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Yes, we use server polling as well.

But the ability to push is certainly a normal evolution, and I expect  
that a technology will provide this.

Deco


On Nov 30, 2006, at 6:21 PM, Peter Michaux wrote:
>
> Hi Deco,
>
> On 11/30/06, Deco Rior
<decorior-w9xKMqPX1QdNhnlO7+U8Og@public.gmane.org> wrote:
>>
>> Also not sure how this plays out, but support for Comet would be one
>> thing that I would be looking at. I am not sure how much overlap
>> there might be but I would research it.
>
> I had a look at Comet when some of the earlier Dojo articles came out.
> It looked like it had quite a few problems. The 37Signals campfire web
> chat application uses server polling every three seconds instead of
> Comet. DHH presented something called Armageddon that used real Flash
> sockets for server push. I think he decided against using this because
> polling was sufficient.
>
> I think that something like Comet probably wouldn''t be a core part
of
> Fork. I am thinking about a way to release extensions to Fork that sit
> on top if that happens. Kind of like Scriptaculous on Prototype. This
> way people could contribute new features but they wouldn''t go into
> Fork core until they have been proven and belong in core. Much like
> Rails plugins are a proving ground now.
>
>> P.S. Should this get off the rails list ASAP?
>
> If you like . . .
>
> http://groups.google.com/group/forkjavascript
>
> >

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Deco Rior wrote:
> First, of all, good luck.
Full agreement on that.

[...]
> On Nov 30, 2006, at 5:22 PM, Peter Michaux wrote:
> > On 11/30/06, Deco Rior
<decorior-w9xKMqPX1QdNhnlO7+U8Og@public.gmane.org> wrote:
> >> So... if Peter really wants to make his mark, can he at least try
to
> >> keep the API the same or compatible with Prototype.
> >
> > The API is similar in some places but can''t stay the same. I
am
> > writing a namespaced library.
>
> Appreciate the NameSpace. That is easy to search and replace.
>
> But don''t expect us to require complex regex to make the transfer,
> and if you do then supply the conversion scripts.  Most migration
> technologies fail, not because of the feature vs. feature comparison,
> but because the barrier to migrate is too high.
The only way that would work is to make Fork a namespaced version of
Prototype, and that clearly isn''t what Peter is doing.
> >> After over 12 months of investment, the barrier to migrate with a
> >> major code change to another library would be daunting.
> >
> > Fork probably isn''t ready yet for this situation but
eventually I
> > think the work would be worth it.
>
> Um...how big an app do you think we have? Any major code change is
> very costly, mostly in QA. We essentially are about 80% through our
> rewrite based on AJAX. A major code change is where we cannot simply
> script the code, and requires us to potentially touch each file.
>
> You should have seen the agony we went through in making the decision
> to get away from WebObjects!
Then I''ll guess that you aren''t using Prototype for anything
critical either.
> >> In any case
> >> it would need to be something with some muscle behind it (by that
I
> >> mean, contributers, funding, third-party certification).
> >
> > Perhaps one day. Not many open source software projects start with
> > this much muscle.
>
> And you cannot build a mission critical solution on a startup open-
> source. Try and get SAS 70 certification on libraries with version 0.2a!
Again, Prototype won''t help you there either - the Yahoo! or Google
stuff might though.

[...]
> One dumb question...what is there to stop someone getting a branch of
> prototype source and going off and making a better version? If Sam
> doesn''t have time, that is okay...Do we need a Linus?
Nothing, however you''d first have to be reasonably happy with the
2,000 or so lines of Prototype as it is now and with the fundamentals,
otherwise you will never be happy with the result.  It also doesn''t
solve any of the issues you raised above - a forked Prototype may cause
more heartache than it cures.

The developers of Prototype have made some contentious architectural
decisions.  Users should be aware of those and accept the limitations
that they enforce - lack of namespacing and extension of built-in
objects being two of the better known ones, I''d also add the
evalScripts method to the list (I think the concept is fundamentally
flawed).  And yes, I think Peter is wrong to support it.

Pretty much all of your concerns with Peter''s library are equally
shared with Prototype, which seems to have 1.5 support personnel who do
stuff from time to time when their day job permits.

Lastly, I don''t think this is a Fork versus Prototype thing: one
doesn''t have to lose for the other to succeed.  Competition is good,
mono-cultures are bad.


-- 
Rob


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi Rob,

On 11/30/06, RobG <rgqld-AFFH1GffN5hPR4JQBCEnsQ@public.gmane.org> wrote:
> The developers of Prototype have made some contentious architectural
> decisions.  Users should be aware of those and accept the limitations
> that they enforce - lack of namespacing and extension of built-in
> objects being two of the better known ones, I''d also add the
> evalScripts method to the list (I think the concept is fundamentally
> flawed).  And yes, I think Peter is wrong to support it.
Can you please elaborate? I am not completely fixed on this method but
because of the problems that Safari causes (can''t set the text
property of a script element), eval may be the cross browser way to go
and insure other unknown browsers can handle it as well. Instead of
evaluating

function foo(){}

you can write

window.foo = function(){}

to ensure the evaluated code really does go in the global space where intended.

Thanks,
Peter

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Yes, in general I agree with you.

We do use prototype, since at that time it seemed to have a good  
development community, and support structure. The dependance on a  
small group is a risk. I did not say we would not make the change,  
but it is not just about how good the code is, ease of migration is  
important.

The lack of progress on features, as well as the architectural  
limitations is an ongoing concern.


On Nov 30, 2006, at 6:37 PM, RobG wrote:
>
> Deco Rior wrote:
>> First, of all, good luck.
>
> Full agreement on that.
>
> [...]
>> On Nov 30, 2006, at 5:22 PM, Peter Michaux wrote:
>>> On 11/30/06, Deco Rior
<decorior-w9xKMqPX1QdNhnlO7+U8Og@public.gmane.org> wrote:
>>>> So... if Peter really wants to make his mark, can he at least  
>>>> try to
>>>> keep the API the same or compatible with Prototype.
>>>
>>> The API is similar in some places but can''t stay the same.
I am
>>> writing a namespaced library.
>>
>> Appreciate the NameSpace. That is easy to search and replace.
>>
>> But don''t expect us to require complex regex to make the
transfer,
>> and if you do then supply the conversion scripts.  Most migration
>> technologies fail, not because of the feature vs. feature comparison,
>> but because the barrier to migrate is too high.
>
> The only way that would work is to make Fork a namespaced version of
> Prototype, and that clearly isn''t what Peter is doing.
>
>>>> After over 12 months of investment, the barrier to migrate with
a
>>>> major code change to another library would be daunting.
>>>
>>> Fork probably isn''t ready yet for this situation but
eventually I
>>> think the work would be worth it.
>>
>> Um...how big an app do you think we have? Any major code change is
>> very costly, mostly in QA. We essentially are about 80% through our
>> rewrite based on AJAX. A major code change is where we cannot simply
>> script the code, and requires us to potentially touch each file.
>>
>> You should have seen the agony we went through in making the decision
>> to get away from WebObjects!
>
> Then I''ll guess that you aren''t using Prototype for
anything
> critical either.
>
>>>> In any case
>>>> it would need to be something with some muscle behind it (by
that I
>>>> mean, contributers, funding, third-party certification).
>>>
>>> Perhaps one day. Not many open source software projects start with
>>> this much muscle.
>>
>> And you cannot build a mission critical solution on a startup open-
>> source. Try and get SAS 70 certification on libraries with version  
>> 0.2a!
>
> Again, Prototype won''t help you there either - the Yahoo! or
Google
> stuff might though.
>
> [...]
>> One dumb question...what is there to stop someone getting a branch of
>> prototype source and going off and making a better version? If Sam
>> doesn''t have time, that is okay...Do we need a Linus?
>
> Nothing, however you''d first have to be reasonably happy with the
> 2,000 or so lines of Prototype as it is now and with the fundamentals,
> otherwise you will never be happy with the result.  It also
doesn''t
> solve any of the issues you raised above - a forked Prototype may  
> cause
> more heartache than it cures.
>
> The developers of Prototype have made some contentious architectural
> decisions.  Users should be aware of those and accept the limitations
> that they enforce - lack of namespacing and extension of built-in
> objects being two of the better known ones, I''d also add the
> evalScripts method to the list (I think the concept is fundamentally
> flawed).  And yes, I think Peter is wrong to support it.
>
> Pretty much all of your concerns with Peter''s library are equally
> shared with Prototype, which seems to have 1.5 support personnel  
> who do
> stuff from time to time when their day job permits.
>
> Lastly, I don''t think this is a Fork versus Prototype thing: one
> doesn''t have to lose for the other to succeed.  Competition is
good,
> mono-cultures are bad.
>
>
> -- 
> Rob
>
>
> >

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---