jQuery community,
Amazing work. I can't believe how fast jQuery has developed into
the best bottom-up JS library. 1.4 looks great. But as jQuery expands
to include things like lazy loading, it might be time for a sister
project that provides important, but less commonly needed
functionality in a standard and organized way.
Essentially, I would like to start a new branch of jQuery, akin to
jQuery UI, that provides a standard set of tools and 'classes' that
enable the development of more complex applications (by no means, does
jQuery Enterprise has to be the name, just the first thing I came up
with).
The project COULD include:
- A 'standard' way of organizing files
- Compression
- Documentation
- Testing
- Code generators
- Scaffolding for easily connecting to services
- Command line plug-in installation and dependency management.
- A powerful class system (based off Resig's class)
Obviously, these are all features of my project - JavaScriptMVC. But,
I am more than willing to sacrifice the name/leadership/everything for
the ability to explore these ideas with the jQuery community.
Furthermore, it seems all JavaScriptMVC users use it with jQuery
anyway!
If you are questioning if these features are necessary, they are!
I've worked on some very large projects with hundreds of custom JS
files and multiple developers. At some point, developers need a
repeatable way of building their applications and separating
concerns. JavaScriptMVC provides that to a few lucky souls. I'd like
to help jQuery provide that to everyone.
It will also will help keep jQuery's core small and applicable to as
many projects as possible.
Here's my rough plan:
1. Get your blessing and support. Blessing being SVN access to a new
branch. Support being interest and involvement from a few
contributors.
2. Engage top jQuery contributors and users on application development
best practices. I've slowly been interviewing some JS luminaries:
http://javascriptmvc.com/blog/?cat=36.
3. Build it. I have already started to convert JavaScriptMVC to
depend on jQuery (it's in JMVC's trunk). With support, this will take
less than a month.
That being said, I'm going to skip to step #2:
jQuery community,
What would you like to see in the jQuery "Framework"?
How do you organize your applications?
What sucks about testing, compression, documentation, etc?
I'd just like to speak up in favour of this proposal. Working on a
JavaScript/AIR project recently, I rolled my own JavaScript MVC
library on top of jQuery, largely because I didn't know that
JavaScriptMVC existed at the time I started, and I wanted to keep
jQuery at the heart of the project (rather than move to Dojo, Mootools
etc.). Having a 'jQuery Enterprise' project would be awesome and I'd
certainly be willing to contribute code and ideas where my own
development has covered areas not covered by JavaScriptMVC (though,
from what I can see, JMVC does everything my library does and more).
> jQuery community,
> Amazing work. I can't believe how fast jQuery has developed into
> the best bottom-up JS library. 1.4 looks great. But as jQuery expands
> to include things like lazy loading, it might be time for a sister
> project that provides important, but less commonly needed
> functionality in a standard and organized way.
> Essentially, I would like to start a new branch of jQuery, akin to
> jQuery UI, that provides a standard set of tools and 'classes' that
> enable the development of more complex applications (by no means, does
> jQuery Enterprise has to be the name, just the first thing I came up
> with).
> The project COULD include:
> - A 'standard' way of organizing files
> - Compression
> - Documentation
> - Testing
> - Code generators
> - Scaffolding for easily connecting to services
> - Command line plug-in installation and dependency management.
> - A powerful class system (based off Resig's class)
> Obviously, these are all features of my project - JavaScriptMVC. But,
> I am more than willing to sacrifice the name/leadership/everything for
> the ability to explore these ideas with the jQuery community.
> Furthermore, it seems all JavaScriptMVC users use it with jQuery
> anyway!
> If you are questioning if these features are necessary, they are!
> I've worked on some very large projects with hundreds of custom JS
> files and multiple developers. At some point, developers need a
> repeatable way of building their applications and separating
> concerns. JavaScriptMVC provides that to a few lucky souls. I'd like
> to help jQuery provide that to everyone.
> It will also will help keep jQuery's core small and applicable to as
> many projects as possible.
> Here's my rough plan:
> 1. Get your blessing and support. Blessing being SVN access to a new
> branch. Support being interest and involvement from a few
> contributors.
> 2. Engage top jQuery contributors and users on application development
> best practices. I've slowly been interviewing some JS luminaries:http://javascriptmvc.com/blog/?cat=36.
> 3. Build it. I have already started to convert JavaScriptMVC to
> depend on jQuery (it's in JMVC's trunk). With support, this will take
> less than a month.
> That being said, I'm going to skip to step #2:
> jQuery community,
> What would you like to see in the jQuery "Framework"?
> How do you organize your applications?
> What sucks about testing, compression, documentation, etc?
> jQuery community, > Amazing work. I can't believe how fast jQuery has developed into > the best bottom-up JS library. 1.4 looks great. But as jQuery expands > to include things like lazy loading, it might be time for a sister > project that provides important, but less commonly needed > functionality in a standard and organized way.
I want to be very clear that we aren't, necessarily, looking to move in that direction. The jQuery 1.4 roadmap is just a massive dump of all the ideas that we've received from users over the past months and years - it's in no way an indication of what we're working on or the ultimate direction we'll head in.
> jQuery community, > What would you like to see in the jQuery "Framework"? > How do you organize your applications? > What sucks about testing, compression, documentation, etc?
I'd argue that step 0 is answering the question: - What problems are you (and others) trying to solve that are difficult (or impossible) to achieve in jQuery today?
Step 1 is then answering: - Can those problems be solved using existing jQuery idioms and, if not, what features need to exist to make that possible.
What should be driven at is: "Do we really need new code, or is better documentation and a few choice features a better solution?"
We've been discussing this internally in the jQuery team during the past couple weeks and we came up with a plan for explaining how to tackle complex application development using the (poorly explained) resources that jQuery already provides. And then, from there, moving on to tackle code.
I have the outline of notes that I've written up including the different development concepts that jQuery tackles (such as Encapsulation, Reusability, Extensibility, and Modularity): http://docs.google.com/Doc?id=awtg3p8j2p2_92c7jk7kgj
Now I feel that if we make an honest attempt to survey and explain what jQuery does to build a complex application from there we'll arrive at an appropriate solution, realizing what the missing gaps are. A couple solutions could be: - jQuery + Debugging plugin - jQuery + Widget code (advanced plugin authoring) + Debugging plugin - jQuery + MVC-style framework
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. Good solutions exist - and many of them already exist in jQuery.
I would definitely appreciate your input on this, Justin, and others who've already replied (specifically those who can answer question 0 for us). Helping us to understand the exact problems that are being faced can help us to construct better documentation, better code, and ultimately a better experience for a jQuery developer.
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.
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.
> 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 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.
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.
> disclaimer: I've just built a pretty complex app (drag/drop, inline editing, > history support, popup windows) with jmvc & jquery
> I personally feel that jquery as it stands at the moment is superb for doing > all the nitty gritty details of dhtml sites, but as the scope of the > functionality in the site your are building grows towards that of a desktop > app, it still becomes too easy to get sucked into the Big Ball Of Mud (that > may say something about my discipline though....). There may be guidance > already out there for jquery, but it would be useful to have a project that > offers a cohesive bunch of tools that are considered the best starting point > for that type of site development. I think there are already some good > plugins that could be referenced, like the history plugin that I've recently > used.
I agree with you very strongly - and gives me all the more reason to keep working on the writeup that I've been working on (that I linked to, before). I like the suggestion of the History plugin, I think that's a great example of a plugin that helps to simplify complex applications.
On Tue, Feb 24, 2009 at 9:36 PM, John Resig <jere...@gmail.com> wrote:
>> 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.
This is my biggest contention with the widget framework at the moment and I am only left with the option of copy/pasting snippets due to lack of extensibility features. In fact, if I may be bold enough to say it, I think the widget framework wasn't well planned and I have a feeling that due to backward compatibility issues it will be a while before it can be cleaned up.
A design overhaul for widgets is my biggest wish for the upcoming release. Not only will it make it easy to extend plugins, but it will reduce the overall footprint of plugins which sometimes end up cramming in quite a lot.
Is this already on the radar and when should we set our expectations for an the widget architecture?
> This is my biggest contention with the widget framework at the moment > and I am only left with the option of copy/pasting snippets due to > lack of extensibility features. In fact, if I may be bold enough to > say it, I think the widget framework wasn't well planned and I have a > feeling that due to backward compatibility issues it will be a while > before it can be cleaned up.
> A design overhaul for widgets is my biggest wish for the upcoming > release. Not only will it make it easy to extend plugins, but it will > reduce the overall footprint of plugins which sometimes end up > cramming in quite a lot.
> Is this already on the radar and when should we set our expectations > for an the widget architecture?
As I mentioned in the previous email in this thread, this is something that I've started to work with the jQuery UI team on. The issue of extensible plugins is very real - and it's one that may only be solved with code. I pointed to a mock-up of jQuery.plugin which could be used for improving the extensibility of any plugin that uses it (including UI) and I'll certainly continue to work on it if, for nothing else, to make sure that UI has a good extensibility solution that doesn't compromise the current API.
On Tue, Feb 24, 2009 at 10:05 PM, John Resig <jere...@gmail.com> wrote:
>> This is my biggest contention with the widget framework at the moment >> and I am only left with the option of copy/pasting snippets due to >> lack of extensibility features. In fact, if I may be bold enough to >> say it, I think the widget framework wasn't well planned and I have a >> feeling that due to backward compatibility issues it will be a while >> before it can be cleaned up.
>> A design overhaul for widgets is my biggest wish for the upcoming >> release. Not only will it make it easy to extend plugins, but it will >> reduce the overall footprint of plugins which sometimes end up >> cramming in quite a lot.
>> Is this already on the radar and when should we set our expectations >> for an the widget architecture?
> As I mentioned in the previous email in this thread, this is something > that I've started to work with the jQuery UI team on. The issue of > extensible plugins is very real - and it's one that may only be solved > with code. I pointed to a mock-up of jQuery.plugin which could be used > for improving the extensibility of any plugin that uses it (including > UI) and I'll certainly continue to work on it if, for nothing else, to > make sure that UI has a good extensibility solution that doesn't > compromise the current API.
Saw that mail just as I sent out mine. Eagerly await this one. +1 for the history plugin. It was the reason why I joined the UI list it the first place.
> > 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.
Point well made. My only problem here is that without classes or some
kind of pattern to organise code, very large jQuery projects can
become unwieldy. Dividing things into MVC components is one way of
dealing with that complexity. Is there a better way that is a more
natural fit for jQuery?
> > 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).
Not specifically Rails, no - I've never used it. The code I've written
(which duplicates a lot of Justin's work) allows me to do stuff like
OrderModel->findById(4), which results in an Ajax request GET /orders/
4. A complete list of orders is available at /orders/ which supports
pagination using the Content-Range header. I can do var x = new
OrderModel; x.property = y; x.save(); and this will be POSTed to /
orders/. I think that this is sufficiently generic that, with some
configuration to allow for unusual REST implementations, it should
live in a standard library.
What I'd like to be able to do is link specific properties in my model
with values of elements in the DOM, so that when a text input box is
changed, this automatically updates my model etc. Obviously this can
all be done via a plugin and I'm not suggesting that it needs to be
part of jQuery core, but I think it could be good to have some
'official' plugins on a similar level to jQuery UI. This all really
focuses on the 'model' aspect of MVC - I'll come back to that in a
moment.
Basically, I'd like to get the ease of use with remote data sources
that jQuery gives me with the DOM. Searching, filtering, selecting,
loading, saving, the works.
> > 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.
As I said above, I think that, with some basic configuration, a REST
client is generic and not too dependent on server-side configuration.
I think this will be important for interfacing with data sources based
on CouchDB, Cloudkit, Persevere etc., as well as Rails/other
frameworks which are easily configured to serve JSON in a RESTful way.
> 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.
You're right, and the reason I use jQuery is because it's the best
library at what it does. I don't want to see jQuery burdened with
pointless features or ill-fitting paradigms. I think my case is
likely to become more common over time though, as non-standard
browsers become more common.
<<stuff about OO>>
100% agreed, OO is not necessarily the right way to go.
> 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.
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.
disclaimer: I've just built a pretty complex app (drag/drop, inline editing, history support, popup windows) with jmvc & jquery
I personally feel that jquery as it stands at the moment is superb for doing all the nitty gritty details of dhtml sites, but as the scope of the functionality in the site your are building grows towards that of a desktop app, it still becomes too easy to get sucked into the Big Ball Of Mud (that may say something about my discipline though....). There may be guidance already out there for jquery, but it would be useful to have a project that offers a cohesive bunch of tools that are considered the best starting point for that type of site development. I think there are already some good plugins that could be referenced, like the history plugin that I've recently used.
I think you could bundle all of this up into a jquery plugin though, without the need for it to be a branded jquery project.
> > jQuery community, > > Amazing work. I can't believe how fast jQuery has developed into > > the best bottom-up JS library. 1.4 looks great. But as jQuery expands > > to include things like lazy loading, it might be time for a sister > > project that provides important, but less commonly needed > > functionality in a standard and organized way.
> I want to be very clear that we aren't, necessarily, looking to move > in that direction. The jQuery 1.4 roadmap is just a massive dump of > all the ideas that we've received from users over the past months and > years - it's in no way an indication of what we're working on or the > ultimate direction we'll head in.
> > That being said, I'm going to skip to step #2:
> > jQuery community, > > What would you like to see in the jQuery "Framework"? > > How do you organize your applications? > > What sucks about testing, compression, documentation, etc?
> I'd argue that step 0 is answering the question: > - What problems are you (and others) trying to solve that are > difficult (or impossible) to achieve in jQuery today?
> Step 1 is then answering: > - Can those problems be solved using existing jQuery idioms and, if > not, what features need to exist to make that possible.
> What should be driven at is: "Do we really need new code, or is better > documentation and a few choice features a better solution?"
> We've been discussing this internally in the jQuery team during the > past couple weeks and we came up with a plan for explaining how to > tackle complex application development using the (poorly explained) > resources that jQuery already provides. And then, from there, moving > on to tackle code.
> I have the outline of notes that I've written up including the > different development concepts that jQuery tackles (such as > Encapsulation, Reusability, Extensibility, and Modularity): > http://docs.google.com/Doc?id=awtg3p8j2p2_92c7jk7kgj
> Now I feel that if we make an honest attempt to survey and explain > what jQuery does to build a complex application from there we'll > arrive at an appropriate solution, realizing what the missing gaps > are. A couple solutions could be: > - jQuery + Debugging plugin > - jQuery + Widget code (advanced plugin authoring) + Debugging plugin > - jQuery + MVC-style framework
> 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. Good solutions exist - and many of > them already exist in jQuery.
> I would definitely appreciate your input on this, Justin, and others > who've already replied (specifically those who can answer question 0 > for us). Helping us to understand the exact problems that are being > faced can help us to construct better documentation, better code, and > ultimately a better experience for a jQuery developer.
> 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,
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:
> > 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.
Justin Meyer 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.
> ...
I agree that the competing plugins and 3rd party libraries is an issue. But I don't think that's something that a "jQuery Enterprise" should be trying to, or would properly solve. jQuery.ui is a step towards solving the competing plugins issue for tabs, dialogs, and other UI related stuff. Enterprise might solve that issue for another select area. But ultimately that doesn't solve the real issue since there are still more and more types of plugins out competing and duplicating each other.
I think the real issue is that once a plugin author creates a plugin, it ultimately stays as /their plugin/, and how hard it is to create a central project (similar to jQuery.ui, but lighter) that isn't one author's project. If you want a comparison, take a look at MediaWiki, more specifically the /extensions/ folder in the SVN repo. MediaWiki.org does publicly list extensions from anywhere, however the ultimate goal of most extension authors is to get the extension checked into svn. Because ultimately once an extension is checked into svn it stops being a single extension tied down to one developer managing it. It becomes something managed by the community as a whole, anyone can either commit changes to it, or put up a bug report asking for changes to it. Ultimately even if the author disappears the extension still gets maintained according to the community's (sometimes fairly rigorous and strict) standards.
> 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.
> # 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.
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.
> 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.
This is a case where many of the problems (or complexities) that exist in advanced jQuery plugins are already taken care of: extensibility, encapsulation, and reusability.
I consider this to be a good example of introducing a selective piece of jQuery functionality that'll help developers but without doing a wholesale import of OOP techniques.
> Why do you think this would contribute to jQuery bloat anymore than > jQuery.UI does?
Because jQuery UI isn't, or doesn't, have the ability to become a dependency for nearly every plugin created. As I mentioned before, most developers look at the tool of Classes as the be-all and end-all of development patterns. Introducing that in a sanctioned manner will instantly make it a dependency of countless plugins, at which point we would be required to include it in core, out of necessity. It seems like it would be a much better option to produce a plugin/widget construction utility that solves all the problems that advanced jQuery developers encounter, in a style that meshes well with the jQuery philosophy, rather than a wholesale import of OOP concepts.
> - package and minimize multiple files (YUI Compressor)
- Could be solved much better as it is not integrated into the
'framework'. You have to 'double' include everything (once in your
page, another in your build script). You have to set your html to
switch from loading separate files to loading the combined in
production.
> - documentation (jQuery Documentation Wiki - already allows devs to
> have inline demos and can be extracted to external sources)
Unless I am misunderstanding something, does this allow me to document
my application, or is this just for jQuery? I am talking about
something similar to JSDoc.
> - testing (QUnit)
Does it handles synthetic events? Can it run server-side to ensure
sanity before checkin? Can you do point and click testing like
selenium?
> > 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).
Yes, these conventions are exactly what is needed. Documentation can
definitely do that, but so far I've not seen it for jQuery.
> > 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.
I mean, where should ajax calls happen in the client? In JMVC they
are in the Model, akin to ORM.
> > 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.
Yes, but where should that html go, etc. Yes, convention is needed.
I guess that is the central point we've arrived at.
JS is Object Oriented. So are we really just talking about classical
inheritance (and even more specific, _super) ?
I see how widget.js creates a plugin. But how does one expand on the
plugin?
I'm more than happy with widget.js if you can easily expand on the
widget. For example, quickly added a delegated hoverenter that will
show a tooltip, or change an existing function.
I don't think super is necessary at all. I've only used it a few
times, never needed it. But if you let go of _super, and you are able
to easily expand the widget, how is that different than what you are
considering OOP?
On Feb 24, 1:22 pm, John Resig <jere...@gmail.com> wrote:
> > 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.
> This is a case where many of the problems (or complexities) that exist
> in advanced jQuery plugins are already taken care of: extensibility,
> encapsulation, and reusability.
> I consider this to be a good example of introducing a selective piece
> of jQuery functionality that'll help developers but without doing a
> wholesale import of OOP techniques.
> > Why do you think this would contribute to jQuery bloat anymore than
> > jQuery.UI does?
> Because jQuery UI isn't, or doesn't, have the ability to become a
> dependency for nearly every plugin created. As I mentioned before,
> most developers look at the tool of Classes as the be-all and end-all
> of development patterns. Introducing that in a sanctioned manner will
> instantly make it a dependency of countless plugins, at which point we
> would be required to include it in core, out of necessity. It seems
> like it would be a much better option to produce a plugin/widget
> construction utility that solves all the problems that advanced jQuery
> developers encounter, in a style that meshes well with the jQuery
> philosophy, rather than a wholesale import of OOP concepts.
I'm a little scared of jumping into this, but I feel I'd like to make a few
quick points, as I've run up against these issues myself.
1. I've scheduled time for myself and my team to re-build the plugins site
next week. The goal initially is simply to re-create the existing
functionality in a more maintainable way, but I'd love to see features added
like the following:
- Developer uploads his JS, and a gzipped, compressed and/or minified
version is automatically generated
- Developer specifies in a structured way dependent plugins. This opens up
the potential for a plugin and their dependencies to be automatically
generated and downloaded.
2. I've been bumping up against the data issue for a few months now on
various projects. I admittedly have not spent time trying to do it *right*,
due to project constraints. I've built a jQuery plugin to manage the data
layer in my application, choosing to do it as a plugin for the reasons
explained above. If I had to do this task again right now, I'd choose to do
it the same way.
John's widget code presents a very interesting possibility though. If the
jQuery team adopted a few choice plugins, like a debugging plugin, a data
layer plugin, and by putting the widget code into the core, allowed these
plugins to be extended, I think a very powerful foundation would be provided
to developers.
jQuery is about providing choice, and with the size of the user base, all of
the choices that are made are magnified 100-fold. So, they cannot be taken
lightly.
3. Lastly, I'm involved with collecting and writing down the latest
information and practices of building jQuery plugins, and using jQuery in
large projects. The group of developers who use jQuery in large projects is
small, but important. Large projects are growing in number, and a good
foundation is needed, we just need to be careful.
On Tue, Feb 24, 2009 at 12:51, Justin Meyer <JustinBMe...@gmail.com> wrote:
> JS is Object Oriented. So are we really just talking about classical
> inheritance (and even more specific, _super) ?
> I see how widget.js creates a plugin. But how does one expand on the
> plugin?
> I'm more than happy with widget.js if you can easily expand on the
> widget. For example, quickly added a delegated hoverenter that will
> show a tooltip, or change an existing function.
> I don't think super is necessary at all. I've only used it a few
> times, never needed it. But if you let go of _super, and you are able
> to easily expand the widget, how is that different than what you are
> considering OOP?
> On Feb 24, 1:22 pm, John Resig <jere...@gmail.com> wrote:
> > > 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.
> > This is a case where many of the problems (or complexities) that exist
> > in advanced jQuery plugins are already taken care of: extensibility,
> > encapsulation, and reusability.
> > I consider this to be a good example of introducing a selective piece
> > of jQuery functionality that'll help developers but without doing a
> > wholesale import of OOP techniques.
> > > Why do you think this would contribute to jQuery bloat anymore than
> > > jQuery.UI does?
> > Because jQuery UI isn't, or doesn't, have the ability to become a
> > dependency for nearly every plugin created. As I mentioned before,
> > most developers look at the tool of Classes as the be-all and end-all
> > of development patterns. Introducing that in a sanctioned manner will
> > instantly make it a dependency of countless plugins, at which point we
> > would be required to include it in core, out of necessity. It seems
> > like it would be a much better option to produce a plugin/widget
> > construction utility that solves all the problems that advanced jQuery
> > developers encounter, in a style that meshes well with the jQuery
> > philosophy, rather than a wholesale import of OOP concepts.
Once the above conventions are finalized, that static plugin analyzer
can be written.
Once the widget code is done, the tutorial needs to be updated.
---
So, with that drawn in the sand, Justin, would you be interested in
working on the debugging plugin, the static analyzer, defining
conventions, all of the above?
Any/all of those would be a huge help and I'd imagine that if the work
is solid they should all become official jQuery projects/conventions.
Now I'm not discounting any additional code or patterns but we need to
start with what we have and make sure that we're working with the best
possible resources. If we define the above conventions and code we may
find that there is less of a need for a new project than we originally
thought - and we get the benefit of having excellently defined and
documented resources and conventions for people to use - so everyone
wins.
On Tue, Feb 24, 2009 at 2:41 PM, Justin Meyer <JustinBMe...@gmail.com> wrote:
>> - package and minimize multiple files (YUI Compressor)
> - Could be solved much better as it is not integrated into the
> 'framework'. You have to 'double' include everything (once in your
> page, another in your build script). You have to set your html to
> switch from loading separate files to loading the combined in
> production.
>> - documentation (jQuery Documentation Wiki - already allows devs to
>> have inline demos and can be extracted to external sources)
> Unless I am misunderstanding something, does this allow me to document
> my application, or is this just for jQuery? I am talking about
> something similar to JSDoc.
>> - testing (QUnit)
> Does it handles synthetic events? Can it run server-side to ensure
> sanity before checkin? Can you do point and click testing like
> selenium?
>> > 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).
> Yes, these conventions are exactly what is needed. Documentation can
> definitely do that, but so far I've not seen it for jQuery.
>> > 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.
> I mean, where should ajax calls happen in the client? In JMVC they
> are in the Model, akin to ORM.
>> > 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.
> Yes, but where should that html go, etc. Yes, convention is needed.
> I guess that is the central point we've arrived at.
|
