Hi Mislav, On 12/3/06, Mislav Marohnić <[EMAIL PROTECTED]> wrote: > On 12/3/06, tobie <[EMAIL PROTECTED]> wrote: > > > > Peter, > > > > What is it exactly that you are trying to do? Drive Prototype users > > away from Prototype to your own library? > > He has the right to criticize the framework. His points are valid, although > he sounds like the library is completely hopeless - that's the part I don't > like.
It is not completely hopeless. Prototype/Scriptaculous might be fine for a green field project that will never use third party JavaScript. I was taught to never say never. > > 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. > > Since when do we fear browser bugs? We will work around them We should fear browser bugs. We can only work around the ones we know about but we don't want to need to revisit working websites when a new bug appears if we can help it. Adding unnecessary code only increases the "length of the chain" and the chance of a weak link. It is true that the Prototype sugar mostly involves only JavaScript 1.5 features and not host objects. It is reasonable to expect that a browser can execute the JavaScript language and so the sugar should not have problems. However I think maintaining concise code that uses "short chains" is a wiser approach over all. > > 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. > > That was me. I didn't understand Enumerable until Justin blogged about it. I > found it strange at first - now I love it. You have to be open minded. I was open minded and after looking at the tradeoffs I made a choice. It seems being decided and opposite to someone elses decision equals closed minded. <shrug> With Enumerable you get a different way of thinking that may make you feel good when you program. However you get decreased performance, are tied to a particular library for basic language function, that library must be downloaded and any code maintainer must have knowledge of that library to maintain the derivative code. The decreased perfomance is the big hit for me. Why need several function calls, a function definition and a try catch block for each iteration when JavaScript has a for loop? I think this is working too hard to save only a few characters of code and to feel good. My job is to write the most robust code I can and the Enumerable stuff does not support that goal. DHH wrote a great April fools joke that I think applies to Prototype use of sugar http://www.loudthinking.com/arc/000582.html > About the bottlenecks, we'll try to work on it. The thing is you don't have to. Just use loops. Finished. The time could be better spent on fixing bugs and improving workarounds or refactoring other parts of Prototype. > For large arrays and huge > number of loops I revert to using for loops, but that's very rare. > > > 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. > > I don't see why Prototype doesn't. It just has sugar added to it - > Class.create(), Object.extend() > > > > 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. > > I've been reading your blog since before Fork. Your level of JavaScript > knowledge is admirable. Perhaps with all that ideas how to make a better > framework you can certainly come up with occasional patches/suggestions for > the Prototype framework on the ticket system, too? It's far from hopeless, > believe me ;) You can watch YUI, Fork or any of the other libraries for workarounds and novel ideas with nice implementation and migrate those changes to Prototype. I want a namespaced library and so won't be spending my time writing patches particular to Prototype. I think someone needs to dive in and rewrite Prototype's implementation with more consistency and call it Prototype 2 with some API changes if necessary. In the rewrite, the Enumerable stuff could be provided but not actually used by the library itself so perfomances can be best when needed. Along the way all tradeoffs could be noted and consistent documentation written. For someone that understands all of Prototype well and another library like YUI this entire process might take a month. It would be huge improvement and users of Prototype would know what they are getting into when they start using. 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 -~----------~----~----~----~------~----~------~--~---
