> 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.
I'm not convinced by this argument. "Because it's what we're familiar with" does not imply that it's the best solution - or even a good solution - neither does "everyone else is doing it." I've been doing JavaScript development for a while now and I'm becoming less-and-less convinced that the traditional MVC/Classical inheritance styles of development (carried over from Java or Ruby, for example) do not translate to JavaScript/DOM well and can, in fact, be improved upon in some dramatic ways. I will fully concede that there might a portion of the jQuery development audience that might be interested in this structure since it's what they're most familiar with, but that doesn't mean that they can't be re-educated. jQuery itself has a very bizarre structure, if you're coming to it from a normal classical-style language. There are no classes, seemingly no inheritance, and the syntax is just strange - but that hasn't stopped it from having some very-large uptake, even amongst highly-skilled developers. So while I think the classical-style inheritance may be of benefit to some other frameworks (since that's how they're designed) I'm not convinced that it would be of benefit to jQuery or jQuery users. > 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. Can you expand on this? We already do a pretty good job of this. I think there's a bug filed to try and improve upon our content-type checking and data determination. It sounds like you're using Ruby/Rails so you can feel pretty safe in knowing that we're going to have the best solution here (especially since one of our team members, Yehuda Katz, is a Rails core contributor). > 3) I know jQuery UI supports widgets, but it's a long way off being a > comprehensive UI/widget framework. Absolutely - and it's a definite work in progress. The UI team is getting larger, becoming more efficient, well-organized, all around a central plan for a strong UI/widget framework. I have good confidence that they will continue to do well. > 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? I disagree on the client-side SQL database/ActiveResource style stuff. The client-side SQL stuff is used so infrequently (on specialized WebKit platforms, only) as to relegate it only to plugin status, at best. As far as the ActiveResource stuff goes - much of that dictates how your server-side application should be structured and how it should return data. jQuery has never been about that (dictating what your page should look like or what server-side language you should use) and it's flourished because of that. That being said, I will agree with your point about mapping remote data and manipulating it. I know of a number of techniques that developers have used (transmitting metadata inline, in HTML, sending JSON blocks, etc.) and I think this could be documented much better. I would like to explore documenting it first, before looking to implementing more code. > 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. I would consider your case to be a specialty case - much like the jQuery users who embed jQuery in Firefox extensions, or server-side in platforms like Jaxer. We want to support you (make sure the code doesn't break) but outside of that we need to keep true to our primary goal: Cross-browser JavaScript/DOM development. I think it's especially important to note another reason why I'm hesitant about having another code base - especially one that provides classical inheritance/MVC patterns. As I mentioned before, the prospect of object-oriented programming is very enticing for many developers - it's what they know and understand (OOP is a staple of modern programming education). Including any sort of sanctioned OOP techniques will instantly shift many developers to using it - whether they need it, or not. Object-Oriented Programming is a hammer and to a developer that's only ever used a hammer every problem looks like a nail (especially the problem of developing web applications). OOP has a great ability: It can make complicated problems manageable and simple problems complicated. I've seen far too many projects bloat uncontrollably under layers and layers of obfuscation when only a simple goal is needed - and can be achieved simply. jQuery is all about tackling the problems that affect most developers. We started the UI project since most developers have a need for easy-to-use components and widgets - especially ones that can be extended in an effective manner. However, I would argue that most developers do *not* have a need to build complex applications. All developers like to think that their problems are sufficiently complex to warrant it, but that is rarely the case. Thus, my concern is that a feature that would, really, only benefit a very small portion of the jQuery audience would, in fact, "infect" the larger jQuery development community, dramatically increasing the complexity of most jQuery code as a result. This brings up an other point: If there was a sanctioned MVC/Classical inheritance/OOP piece of code for jQuery it would become a huge dependency burden for most users and developers. Since most developers would see this tool and try to apply it to their problem, most plugins would instantly have an other required piece of code for jQuery users to download -- and at that point we would be forced to include it in core anyway. In short: Having any sort of sanctioned OOP technique breeds more complexity for the majority of jQuery applications, increases the dependency structure of most jQuery plugins, and generally creates an untenable situation in which any sort of sanctioned code would inevitably have to be integrated in to core. Not to mention the fact that I really dislike trying to solve programming problems by throwing more code at them. Sometimes the only thing required is better documentation. --John --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jQuery Development" 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/jquery-dev?hl=en -~----------~----~----~----~------~----~------~--~---
