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