Hi Justin - > Thanks for your reply! You are absolutely right that we need to > discuss which problems are difficult to solve. > > Is it safe to say that you agree that jQuery says very little about > how to : > - package and minimize multiple flies > - document > - test > - dependency management > - log errors / debugging tools ? > > Often developers are forced to pick from many completing plugins or > 3rd party libraries. Similar to jQuery.UI this 'jQuery Enterprise' > would provide a standard set of tools and come in a single integrated > package. I think it's fair to say that this could bolster JS > development just as much as an Accordion or Datepicker.
I agree that those 5 points are important. Of those 5 I would categorize these 3 as solved, but documented poorly: - package and minimize multiple files (YUI Compressor) - documentation (jQuery Documentation Wiki - already allows devs to have inline demos and can be extracted to external sources) - testing (QUnit) For the last two I would say that there's still a lot of work to be done: - Dependency management (Most of the logic already exists in core but could be exposed in a more useful way - as might be done with a jQuery.require method) - Debugging (I think the case for a standalone jQuery debugging plugin is valid - drop it in and it helps you do development, throws more errors/warnings, provides a console, etc.) Of course, with dependency management we could be talking about a number of different things - The Dojo-style load dependencies dynamically on the client-side - A CPAN/Perl-style "check dependencies at runtime and complain if not present, or if incorrect version is used" - A server-side solution that builds the correct files with only the required code (which is something like the Sprocket Prototype project that was just released) > The issue is that the developer has far too many choices. Consider > the case of building a todo widget that connects to some backend > service. > > Where do I put the files? > What should I name the files? I'm not completely convinced that this is a huge problem - but at worst this could be solved through convention and documentation. > How/where should I respond to events? > How should I deal with state? > How can I maximize the chances of re-usability? All three of these are handled either through better documentation or with the widget/jQuery.plugin code that I showed earlier (it especially helps to deal with state and reusability, while responding to events would be more of a documentation issue). > Where should I be connecting to the service? That's probably outside the scope of anything that we would do, since it would probably define what needs to happen on the server-side. > How can I wrap the service data? (For example, maybe the todo has > passed it's completion date and you want to ask it .isPastDue(). This seems like another case of encapsulation or dealing with state (imo). > How can I create HTML in a readable manner? At best, something that's done through convention. > Getting to this point isn't a matter of documentation on jQuery's > part. If you have to document it to get people to use it, people > won't do it. You have to force people to do things a specific way > (hence why generators became part of JMVC). I disagree. The very fact that jQuery's documentation is good encourages people to code in that particular style. This actually brings up something else that we had discussed a while back, internally: An automated system for statically analyzing jQuery plugins. Almost everything that you discuss can be analyzed automatically and corrected (informing the user of the better techniques to use). The system could check for a test suite, check for documentation, check for the use of the widget architecture, check for dependencies, and even package the result. A lot of this comes back to much of the recent discussion surrounding the new plugins site. > In Scalable jQuery, you noted: > > # That the vast majority of what everyone does is directly related to > the DOM. > # That for the rare cases in which a pure-JavaScript structure is > required, the plain JavaScript language is sufficient for meeting most > needs. > > In my opinion, it is not rare on large projects. Much more logic goes > into if a button is visible or can be clicked than into creating it > and attaching an event. > > It's exactly because jQuery has done such an amazing job at solving IF > we can build anything that people need to know HOW. And, by pushing > what can be built on the client with bigger projects and more source, > an answer has become more important. > > So my answer to #0 is: > > It's difficult to test, package, debug, log, and document large jQuery > applications. > It's difficult to maintain, separate concerns, have consistent > development patterns, and provide re-usability of large jQuery > applications with developers of mixed skill levels. Currently it seems like most of this can be solved with documentation or tools for statically checking structure with the exception of two points: - Extensibility / Encapsulation - and Debugging Both of which will need some form of new code (jQuery.plugin, discussed before, and some sort of debugging plugin). > "But I think it's both silly and foolish to assume that the only > solution to the problem of complexity is to hit it with the > MVC/Classical inheritance stick. " > > They are always many ways of solving problems. And, I think it's > critical to have a broad discussion on how to enable maintainable code > with an eye toward reuse. But, in my opinion, it's unfair to dismiss > MVC/Inheritance as a 'stick' because they are such commonly used > patterns. They are commonly used, I would argue, because they are > successful. They work not necessarily because they are a good fit, > but a new developer can understand them easily. By the time they > reach the skill level of the people who read a jQuery Development > newsgroup, they will be able to pick their own patterns. Sure, but those are precisely the people who *shouldn't* be using those patterns to begin with. As I argued before, OOP tends to make simple applications more complex - and in the hands of someone who is a new developer that is only amplified. > Finally, John I can't thank you enough for not dismissing me > outright. It speaks to your character to listen to someone not > involved with jQuery propose an entirely new branch. I am but a mere > pebble thrower. After exploring jQuery's core, I'm convinced that it > provides the most elegant wrapping of the dom. After using JMVC on a > number of large project, I'm very confident that it comes close to > solving some #0's issues very well. My hope is that I can help jQuery > solve them just as elegantly as it does the DOM. Sure thing. I think it's good to have this discussion - hopefully we'll be able to get at the very root problems and tackle them at their core. --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 -~----------~----~----~----~------~----~------~--~---
