Quick comments: On OOP and not being convinced. What other approaches are you hinting at? OOP being well understood is a valid argument only because inheritance and OO does provide reuse. If you have something that does work in many cases, you are allowed to factor in popularity and understandability.
Why do you think this would contribute to jQuery bloat anymore than jQuery.UI does? On Feb 24, 12:40 pm, Justin Meyer <justinbme...@gmail.com> wrote: > John, > 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. > > On to separating concerns and providing reuse, > > It's very possible to separate concerns with jQuery/Prototype, or any > other library, server or clientside. However, a good 'framework' > forces that upon developers (but lets them escape it if necessary) in > one standard way. > > 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? > How/where should I respond to events? > How should I deal with state? > How can I maximize the chances of re-usability? > Where should I be connecting to the service? > 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(). > How can I create HTML in a readable manner? > > Giving this problem and jQuery to a novice developer will not result > in similar code twice. If you want to enable broad code sharing, all > these questions should have an answer. The jQuery/JMVC project I am > consulting on now has about 300 files. If there is functionality I > need to modify, I know, almost w/o exception where it has to be and > how it is built. > > 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). > > 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. > > On > > "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. > > 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. > > On Feb 24, 12:36 pm, John Resig <jere...@gmail.com> wrote: > > > > Point well made and understood. > > > > Perhaps what we're looking for here can be achieved without the > > > wholesale adoption of an MVC framework. Perhaps the UI/widget > > > framework can do a lot of the visual controller stuff anyway, allowing > > > people to create abstract 'objects' (without full OOP) for controlling > > > visual elements. Obviously DOM manipulation provides us with a view > > > component, and people are free to create templating systems or > > > whatever else they like on top of that. The real area where progress > > > can be made, imo, is in data handling. That means, for example, being > > > able to define a 'model' with certain fields, tying those fields to > > > DOM elements, and automatically validating the input in those elements > > > against the rules within the model, then calling a simple function to > > > persist the model data to the server, or load a new model and display > > > that instead, etc. I think that this would be sufficiently useful > > > that a 'jQuery Data' plugin that aims to make this kind of task as > > > easy as DOM manipulation is already would be worth pursuing. Full MVC > > > would be one extension of this approach, but not essential to it. > > > If I had to guess and put percentages on the jQuery user base I would > > say that they break down something like this: > > - 95% of jQuery user's needs are perfectly met by current jQuery > > code/plugins (19 out of 20 users) > > - 4% of jQuery user's create complex interactions - would possibly > > benefit from a widget architecture > > - 1% of jQuery users have a need for both complex widgets and a means > > of tying them to an existing data model > > > I'd like to propose taking two steps (mostly on my end): > > 1) Writing up a solid overview of how to make the best use of current > > jQuery technology (for extensibility, encapsulation, etc.) > > 2) Work on refining the widget code with the ultimate goal of having > > it be ready for jQuery UI 1.8 - but releasing it separately so that > > people can start to play around with it and see if it'll benefit their > > plugins/writing style. > > > Once we tackle those two points (#1 will help those in the 95% to > > realize how to best use their current tools, #2 will help the demands > > of the other 4%) we can safely start to look at some sort of data > > abstraction code. My biggest concern with a data abstraction is that > > it usually requires some sort of specific set up on the server to > > benefit from it. Would everyone be able to benefit from this addition > > regardless of server construction? (PHP users? .NET users? ColdFusion > > users? Rails users? etc.) > > > So while I will continue in this direction for now, I'd still love > > more feedback: Cases of where complex applications worked well in > > jQuery, examples where they did not. Knowing the exact set of use > > cases that might exist would help us to quantify the amount of work > > that we should put in and where. > > > --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 -~----------~----~----~----~------~----~------~--~---
