Justin, I've been following your work for a while now, and I have to say I really dig JavascriptMVC. I think there are some amazing ideas in there, and I know I'll be keeping an eye on what you're doing.
@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. 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. 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. Some great progress has already been made, such as making jQuery.Event an extendable object, but I would really like to see that continue throughout core. Just some thoughts :) On Tue, Feb 24, 2009 at 7:35 AM, Rob Knight <themanhims...@robknight.org.uk>wrote: > > There are a few problems to which jQuery isn't a good solution at > present: > > 1) If you have to work with certain design patterns, either out of > personal preference or because that's how your organisation works, > jQuery will allow you to do that. For example, I rolled my own MVC > framework on top of jQuery with no problems. However, it would have > been beneficial to have had a known, well-supported MVC framework to > use off-the-shelf. For someone coming into JS development from other > areas where these frameworks are just part of the standard toolset, > jQuery can appear a bit too minimalist. > > 2) There's a lot of stuff being done in support for RESTful Ajax (the > RESTful JSON stuff is v. cool imo). Again, jQuery has no explicit > support beyond allowing you to do Ajax calls. This is great, but it > would save on development time if there were standard libraries that > could support common REST patterns. > > 3) I know jQuery UI supports widgets, but it's a long way off being a > comprehensive UI/widget framework. > > 4) No real support for data handling. That means ORM for stuff like > Adobe AIR SQL databases (or other SQL databases), no particular > support for ActiveResource-style use of remote data as a data source > (see #2). Basically, jQuery is awesome for handling the DOM, but what > if your data lives somewhere else, and most of your app revolves > around manipulating that data? > > However, none of these are really a good fit for jQuery core. Adding > them to jQuery core would increase code size, increase complexity, add > new paradigms and generally confuse everyone. The reason I love > jQuery and use it ahead of Dojo every time is because I can work out > how I'm going to use it in my head, only occasionally referring to the > docs. But I like Justin's idea of creating a layer on top of jQuery > that would provide a lot of the 'enterprise' stuff. I've been reading > Martin Fowler's Patterns of Enterprise Application Architecture > recently (it was a Christmas present!) and I'm struck by just how > useful those patterns are. It would be great to have some pattern > implementations that sit on top of jQuery. > > The project I'm working on at the moment (with the self-created MVC > framework) is an Adobe AIR app for internal use within a business as > part of an Enterprise Resource Planning system. It's a long way away > from being 'just' a website, and I think that having the kind of tools > that Justin talks about would be genuinely useful to me. Maybe I'm > not a typical user though. > > > -- Nate Cavanaugh --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
