Somewhat off-topic, but: "On the other hand, property lookups in Internet Explorer are just abysmal - and you'd be doing a ton of those if you were using nothing but OO techniques. You're damned if you do and damned if you don't in the land of Internet Explorer!" John, do you have any documentation or know of any online regarding this in more detail? Also, is this for all lookups (dot notation, and [] notation), and I'm guessing the speed hit is on execution, correct?
Just a bit more curious about this, because I'm truly curious which would be the worse hit in IE, 100 chubby closures, or 500 property lookups. Thanks John, Nate Cavanaugh Director of User Interface Engineering Liferay, Inc. Enterprise. Open Source. For life On Tue, Feb 24, 2009 at 8:46 AM, John Resig <jere...@gmail.com> wrote: > > > @John regarding his specific questions: > > Part of the issue isn't that there isn't any way to solve jQuery's > > shortcomings, it's that there are no really good ways to solve them. > > For instance, I know I can use closures to get around scoping issues in > > jQuery, but most enterprises are stuck on IE6, and a ton of closures > > floating in memory that have a bunch of variables stored in each copy > isn't > > ideal. My understanding of the JS memory model is no doubt flawed, but > even > > MS themselves try to steer people away from closures because of how > poorly > > they handle them. > > On the other hand, property lookups in Internet Explorer are just > abysmal - and you'd be doing a ton of those if you were using nothing > but OO techniques. You're damned if you do and damned if you don't in > the land of Internet Explorer! > > > Also, with extensibility, there are ways to overload methods. Sure I can > > rename an existing method to _something, and create a new one that > > references the old one, but that is NOT an ideal way to go about > extending > > an object, especially in a multi-developer scenario with different > scripts > > accessing the same objects. > > I agree with this. This was a big step that my proposed > jQuery.plugin/widget code helped to solve: > http://dev.jquery.com/~john/plugins/widget/widget.js > > It's very rough right now but it allows you to override existing > methods and alter their inputs in ways that are quite elegant. > > I'm going to be working with the UI team some more (since they've been > dealing with the issue of building complex, extensible, jQuery plugins > for while now) to try and solve some of their problems. > > > And the method should take advantage of Javascripts benefits. I don't > think > > every plugin developer understands that shoving object properties and > > methods onto instances is way less efficient than using the prototype. > Nor > > do I think they should have to understand. The system (like the current > > plugin system) should handle that for them. > > Agreed - also something the widget code helps with. > > See, I have no problem dropping 40 lines of code into core if it means > that it'll help in the construction of jQuery plugins - making them > dramatically simpler to develop complex ones - and extend them - > without sacrificing simplicity. > > --John > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-dev@googlegroups.com To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~----------~----~----~----~------~----~------~--~---
