Awesome. Great information, and I like and agree with your perspective. My hat is off! Thanks
On 12/1/06, Mislav <[EMAIL PROTECTED]> wrote: > > > Lately we have witnessed some repeated Prototype criticism in the > thread about Fork by Peter Michaux. Some other developers expressed > their concerns that they shared with Peter - the same concerns that I > keep hearing over and over in the past few months. Basically they can > be summed up to these points: > > 1) it augments Number, String, Array, HTMLElement and Function > prototype > 2) it is not namespaced > 3) its Event module is not robust enough > 4) Enumerable module is slow / is strange / sucks (pick any of these) > 5) strange inheritance scheme [1] > 6) Sam is not addressing the public enough or acknowledging > contributions > 7) it doesn't have official/up-to-date documentation > > In the following paragraphs I'm going to debunk these. I'm nothing more > than a Prototype contributor and enthusiast who, at one point, almost > ditched Prototype and created a fork (hybrid of YUI, mootools and > Prototype) for his personal use, but then recent updates proved things > were still rolling and won my attention back. Since then I dedicated my > spare time to try and make Prototype better instead of creating yet > another spinoff. > > So, here we go. I'll try to keep it as short as possible. References > can be found on the bottom. > > -------------------- > > 1) augment *.prototype - JavaScript is based on dynamic prototypal > inheritance and object prototypes are available for writing with a > reason. This way we can add utility methods directly to objects we need > them to operate on. That is true OOP and that is what Rails does to > Ruby built-in types without anyone crying about it. Instead, people > love it. It makes the code shorter, operations more concise and the > whole thing is easier to remember. > > People are actually afraid only of Array.prototype augmentation, > because they have been using them as associative arrays all this time. > This is wrong [2], so stop it. When you look at what Prototype does > with a mind unclouded with fear, you'll see that Number, String and > Function extensions are sweet, new Array methods are great, and that > was it does to extend DOM elements is brilliant. > > -------------------- > > 2) namespace - Prototype is, in fact, somehow namespaced. Its modules > are namespaced, to be exact: DOM stuff is in Element, xmlHttpRequest in > Ajax, and so on. There is no global namespace because it doesn't fit in > with its philosophy - Prototype is a low-level framework aimed at > making coding easier, not a nightmare. It also extends built-in objects > and you can't namespace _that_. > > Some of you say "it doesn't play along nicely with other frameworks". I > fail to see effort to "play along nicely" in other frameworks except > packing it all in a single namespace. If you want to namespace > Prototype for your project that uses YUI, MochiKit and Dojo at the same > time, you can easily do it by hand by taking 20 minutes of your time in > a text editor. But in the end, using multiple frameworks will > inevitably lead to feature duplication. > > YUI has everything namespaced, and everyone likes YUI. But everyone > hates writing "YUI.namespace.module.bla.foo.bar()" to access a > function. So what do people do? They bring often used functions to the > global namespace and name them conveniently. In Prototype, you don't > have to undertake effort to have that kind of convenience. > > -------------------- > > 3) Event module - True, it is pretty basic right now. It doesn't do > scope correction, work around Safari bugs, or provide the ability to > remove all the observers from an element... Or does it?? See ticket > #5786 [3] by Andrew and me that brings all this to Event, and more. > > This is open source. When you miss a feature you can either whine about > how YUI is better on your blog, or you can pull up your sleeves and get > it done. Event module is more than usable right now and is getting > better, so it is certainly no reason to ditch Prototype, unless you are > making a GMail-killer app or something on that scale. > > -------------------- > > 4) Enumerable - Iterating over Hashes, Ranges and Arrays in Prototype > is awesome! It reduces lengthy code full of endless loops and closures > you can easily get lost in otherwise. It comes at a price, though - > speed. Yes, using "each()" and friends (they all use "each" internally) > can considerably slow your loop. There is a benchmark [4] by Marius > Feraru; run it, observe the results. > > OK, let's power on our common sense now. Exactly how much iterations > are we going to need, anyway, and at what rate? The benchmark shows > that, roughly, I can iterate over an array with a 1000 elements about > 100 times in a second. That's not at all slow - it is fast! I can have > an array of 1000 HTML elements and iterate over all of them in just 10 > milliseconds. > > Your common sense should tell you by now that most of the time you > won't even have a 1000 elements in an array. You will iterate over 5, > 10, 20, sometimes 50 elements. I'm talking about more than 90% percent > of all cases here - in a big app when speed is critical, you can always > write an ordinary loop - who's stopping you? But in all other cases, > you can have the sweet, sweet sugar of Enumerable. > > It gets better. The ticket #6650 [5] proposes a speedup of Enumerable > methods by using JavaScript forEach (currently implemented in Firefox > 1.5). There is another thing - remember how you can throw $break and > $continue in an iterable? Do you know that for N iterations you need 1 > try/catch block for $break, but N of those blocks for $continue? Do you > know that you can continue with an ordinary return statement, and that > dropping $continue support in favor of return can speed up all > iterations by almost 40% percent? I'll be posting a patch for this > soon. > > For people worried about Hash implementation, see #6649 [13]. If the > patch gets applied you will be able to iterate over functions, use less > memory and have a "safe" type of Hash that you can store anything into. > > -------------------- > > 5) class inheritance - Currently Prototype utilizes Class.create() and > Object.extend() to get things done. Why do people have a problem with > this? OK, we're quite aware that this doesn't scale, but it served us > so well all this time and it's going to get much better in Prototype > 2.0 [6]. Remember, the "all-mighty" and powerful YUI doesn't have a > class inheritance scheme other than native JavaScript prototype > inheritance and manually juggling the prototype objects around when > subclassing ... But it still works and scales [7] pretty well, doesn't > it? > > -------------------- > > 6) Sam Stephenson - I admit I too miss having him around the list or > ticket discussions, but if people willingly fill in for him than this > is not a problem. And people are doing that - Justin Palmer is blogging > about Prototype development and roadmap [8] (something Sam clearly > doesn't have time for) and Thomas Fuchs (madrobby) is doing a great job > going through tickets, commenting and applying tested patches > regularly. Sam also occasionally pulls up his sleeves and applies a > "flurry of updates" [9] which alone is worth subscribing to the RSS log > [10] because there are awesome gems in there. > > Regarding patches lingering about for too long: this is not because Sam > or Thomas are lazy or indecisive. It is because patches are being > submitted in poor quality and/or without tests. Like in Rails, tested, > quality patches get applied sooner. > > -------------------- > > 7) API documentation - in the works [11]. Until released, read Justin > Palmer [8] and other resources [12] which served us so well all this > time. Documentation existed all this time, only it wasn't centralized > or written by Sam so people didn't realize it. > > -------------------- > > *Whew* There it is - all points covered. > > Currently the only thing I don't like in Prototype codebase is the > Insertion API and small things that pollute the global namespace like > Toogle.display() and Try.these(). But I have yet to come across a > JavaScript framework that matches the power of DOM manipulations in > Prototype. Form serialization is robust, Ajax is powerful but still > easy to use, and the Trac is full of ready patches that just wait being > decided on. All this is covered by tests built on a JavaScript unit > test library. > > Comments/questions appreciated. Please be short and to the point - > there are a lot of things that can be discussed here. Please don't > troll or point out to other frameworks. And please point out to valid > points of criticism I've missed. > > Just don't whine - make it work. > (And contribute.) > > -- > Mislav > > > references: > [1] > > http://encytemedia.com/blog/articles/2006/5/23/prototype-inheritance-madness > [2] > > http://www.andrewdupont.net/2006/05/18/javascript-associative-arrays-considered-harmful/ > [3] http://dev.rubyonrails.org/ticket/5786 > [4] http://gfx.neohub.com/benchmark/t/loops.html > [5] http://dev.rubyonrails.org/ticket/6650 > [6] http://sam.conio.net/articles/better-inheritance-for-prototype > [7] http://code.google.com/p/yui-ext/ > [8] http://encytemedia.com/development > [9] > > http://encytemedia.com/blog/articles/2006/9/5/the-flurry-continues-more-prototype-updates > [10] http://dev.rubyonrails.org/log/spinoffs/prototype/src?format=rss > [11] > > http://encytemedia.com/blog/articles/2006/10/31/prototype-a-call-for-documentation > [12] http://del.icio.us/mislav/prototype.js+documentation > [13] http://dev.rubyonrails.org/ticket/6649 > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
