Hi Mislav, Mislav wrote:
> 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. Rails and Prototype execute in two completely different environments. In Rails the code needed to extend these built-in classes is already on the server. With Prototype the added sugar has to be transmitted to the client. Also there could be an exotic browser bug related to the sugar code that is not detected during testing. > -------------------- > > 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_. I don't think you can say that Prototype is "somehow namespaced" because it doesn't define it's own namespace and stick too it. If using many different namespaces is considered namespcing then all JavaScript is somehow namespaced. For no necessary reason functions are attached to the Element object (not Element.prototype) and these functions could have just as easily been in an object called ProtoElement. I can't see how calling a library that augments built-in prototypes can be considered namespaced at all. That is the ultimate move against namespacing. A JavaScript library doesn't have to be namespaced in green field projects but the decision could be regretted later when third party components are available but unusable do to the lack of namespacing. Of course, using a library without namespacing in a legacy code situation is asking for trouble. > YUI has everything namespaced, and everyone likes YUI. But everyone > hates writing "YUI.namespace.module.bla.foo.bar()" to access a > function. I don't hate it. It isn't fun like a circus ride but I do appreciate the benefits. > 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. With a namespaced library the option is there for the developer to make the appropriate decision given the particular page being developed. > -------------------- > > 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. I hope the situation of user contributions to Prototype is improving. > -------------------- > > 4) Enumerable - Iterating over Hashes, Ranges and Arrays in Prototype > is awesome! I don't think it is awesome. I think the syntax is clumsy. Having to define a function to run a loop is a major kludge to me. > It reduces lengthy code full of endless loops It doesn't reduce code length by much http://peter.michaux.ca/article/48 and along with this minor reduction in loop lengths, much library code has to be downloaded to implement the sugar. > and closures you can easily get lost in otherwise. A experienced JavaScript developer coming to a project using Prototype for the first time will be confused by the iterators when for loops could have been used. I can easily see how this argument can be disregarded but the sugar iterators do not make loops look simpler to everyone. > 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? With a slow computer and demanding animation or dragdrop behavior of complex structures I want to have as efficient code as possible during these operation. At these times you can stop using the sugar but right now the sugar is part of the underlying Prototype and Scriptaculous library so it is difficult to stop that sugar unless patches are accepted to Prototype and Scriptaculous. > It gets better. The ticket #6650 [5] proposes a speedup of Enumerable > methods by using JavaScript forEach (currently implemented in Firefox > 1.5). Unfortunately Firefox is probably only 10-20% of general users so for now and for some sort of relatively meaningless comparison multiply the savings/excitement by 0.2 at best. Also this means that you will have to have two versions of the sugar implementation. If JavaScript 1.7 catches on in other browsers then in about 5 years there will be real iterators available for use. > -------------------- > > 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? YUI has the best JavaScript inheritance mechanism I have encountered that gives the closest Ruby-like behavior possible. It is simple and reinforces the ideas of prototype based inheritance when a developer is using it. http://kevlindev.com/tutorials/javascript/inheritance/index.htm http://peter.michaux.ca/article/1 http://peter.michaux.ca/article/49 http://peter.michaux.ca/article/50 > 7) API documentation - in the works [11]. For me, one of the most valuable software development steps is the reflection and evaluation I must make when writing API documentation. It forces me to review the product of my work and if I cringe even a little when I am explaining any part of the API then I know I got it wrong. It is the time where I can see if the API as a whole is consistent. I think API documentation is probably more important then tests because fixing the internals later is easier then asking people to change their library calls. > *Whew* There it is - all points covered. But not debunked without tradeoffs that could be judged as unacceptable. Every library will have tradeoffs. For a long time I wanted and tried to like Prototype because it has the Rails stamp of approval and tight Rails integration but I just can't make it work for me. That's why I've gone my own way and started a new library for use with Rails that can just as easily be used outside of Rails and when I'm working with legacy code. Peter -------- http://forkjavascript.org --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
