Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
Yesterday, I posted a follow-up via GG; not sure what had happened-- probably a GG bug or word filter in jQuery mailing list? Anyway, FWIW... On Feb 13, 11:58 am, John Resig [EMAIL PROTECTED] wrote: snip 3) Attaching properties to DOM elements is really really slow. Doing speed tests comparing this technique against storing elements in an array, and iterating over them on a case-by-case basis, the array (jQuery) way is always faster. I'm just trying to understand: jQuery source: // And bind the global event handler to the element element[on + type] = this.handle; It looks to me that the event is been really attached. Am I wrong? snip 4) Any chance of a jQuery-lite, without all the css selector logic? Or is that kind of Sonny without Cher? We've been considering it - however, it's hard to gauge what's open for removal, and what's not. Instead, we're probably going to try and provide a really-strong download page that'll let you add/remove particular sub-features that you want (for example, if you didn't want basic XPath support, you could remove it.) That's in the works right now. Any plan to merge/borrow selector code from DOMQuery? or a providing the option via plugin? snip we're looking to alleviate this in a number of ways: - A solid plugin repository - The ability to rate, and comment on, plugins - Effective multi-category categorization of plugins - Finding, and recommending, similar plugins snip This is *exactly* I was thinking after looking at the current repository:-) and even thought of asking for svn account:-) What about? +plugins\foo\foo.jquery.js +\docs\README + \demo\demo1.html demo2.html No jquery.js inside And tagging whenever jQuery version is released? Personally I'm not for categorising of plugins in svn repository; may be in community pages it could be done. -- ?php echo 'Just another PHP saint'; ? Email: rrjanbiah-at-Y!comBlog: http://rajeshanbiah.blogspot.com/ ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
It looked to me (I could be wrong) that if I have 10 text inputs of the same name, I will only get the value of the first one if I do a fieldValue(). Is this incorrect? Hmm, no, that's correct. Thanks for pointing that out! But this way, the library can be used either stand-alone or as a jQuery plugin. Someone could extend it to work with their own framework of choice as well. For basic functionality, I just don't see a reason to tie the core logic to a specific framework. Other than losing the ability to use jQuery's functionality within the module logic, is there any reason not to take the strategy above? That sounds like a good strategy. I'm looking forward to seeing it. Cheers! Mike ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
6) Finally, can anyone comment on introducing jQuery into a team of web developers with low to moderate javascript experience, building webapps or web sites that could run into the millions of dollars? Is jQuery robust enough and easy enough to deploy that it's an easy win? I showed jQuery to a colleague with little-moderate JS knowledge, though he's a good programmer in general. He immediately got it, and now he won't ever let go :) I think the beauty of jQuery lies in it's simplicity and two part nature; use selector - do something with result andreas ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
Matt Kruse wrote:
1) There seems to be a lot of emphasis on using selectors and
pseudo-selectors to access everything. It makes code short and simple, but
is it really the most efficient?
Reusing selectors helps performance.
You can reuse a selection by storing selected elements in a variable,
like this:
var $p = $('p');
You can then run as many operations as you like on $p, without any more
selections.
Most of the time, you can take it a step further, and hang onto
selections across
multiple elements/function invocations using closures:
$(document).ready(function(){
var $p = $('p');
$('a').bind('click', function(){
$p.doSomething();
});
});
This way, unless the dom changes, you only have to make the selection
once. :-)
Luke
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
Matt, I think your final statement sealed the deal when I was deciding. This list is packed with experienced, patient, and helpful jQuery gurus. I've been developing for nearly a decade and have subscribed to a lot of lists over those years, and the degree of helpfulness you see on here is rare indeed. They don't jump on people for asking dumb questions or doing things differently, but there is still a good amount of constructive advice when its warranted. Being one of the moderately experienced js programmers you mention, I have frequently gotten answers to questions mere minutes after posting--not to mention all the questions that were answered (before I even knew I had them) while reading other posts. By the way Matt, I bookmarked your website years ago and used your JS libraries quite a bit--right up until I adopted jQuery! Thanks for making those things available. -Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Kruse Sent: Monday, February 12, 2007 9:28 PM To: discuss@jquery.com Subject: [jQuery] jQuery Design Decisions? Comparison to MooTools? I've been working with JS since it was created, and I've written a lot of my own libs and utilities. I'm now taking a serious look at existing frameworks simply because the effort of writing, debugging, and documenting my own code is too time consuming. Of the more mature and robust frameworks available, I think jQuery and MooTools offer the kind of approach that fits well with my thinking. There are differences between the two, but they are very similar in many respects. I'm leaning towards standardizing on jQuery because it packs a lot of functionality into a small package, is well documented, has a professional feel to it, is growing rather than shrinking, doesn't try to shove a class-based OO approach into JS where it doesn't belong, and has some great plugins and effects available for it. I am evaluating jQuery for two purposes: 1) To be used in a number of webapp projects by different teams, with costs in the millions. I don't want to pick a framework that will be gone and unsupported tomorrow, or one that moderately experienced js programmers wouldn't be able to pick up quickly. 2) My own use, to ease my pain. I'd like to take things like my fast and robust table sorting (and filtering, paging, etc) routines and map them into the jQuery namespace as plugins (I tried to comment on the zebra striping showdown and show my version but I think I was moderated out!). I have my own library that I've been working with/on for quite a while (even registered JavascriptElements.com) and I considered branching parts of jQuery into my own version. But, I'm sick of re-inventing the wheel - jQuery seems adequately round. I want to re-invent the steering wheel instead. With these things in mind, I have some general questions about the design decisions in jQuery: 1) There seems to be a lot of emphasis on using selectors and pseudo-selectors to access everything. It makes code short and simple, but is it really the most efficient? 2) Why encapsulate elements in a jQuery object rather than extending HTMLElement? Using the latter, you gain the ability to use built-in methods and properties of the elements, and you only have to worry about hacking it to work for IE (but hopefully not IE8!). 3) Some of the functions in jQuery seem to be magic in that they do and return a lot of different things depending on how they are called. This seems very Perl-ish to me, and that's one of the things that ended up making Perl so insanely incomprehensible to many. Why overload so many methods, rather than giving them their own understandable names? 4) Any chance of a jQuery-lite, without all the css selector logic? Or is that kind of Sonny without Cher? 5) What is the max compressed file size you want to stay under? Will plugins and other extensions be pulled into the main source file at some point? Or is the goal to keep the current core functionality as-is and depend on plugins for any extended functionality? Is there any concern that the framework will become fragmented (again, like Perl) so developers never know which set of plugins (modules) they need to do the job? 6) Finally, can anyone comment on introducing jQuery into a team of web developers with low to moderate javascript experience, building webapps or web sites that could run into the millions of dollars? Is jQuery robust enough and easy enough to deploy that it's an easy win? I tried to ask similar comparison questions on the MooTools forum, but the developers and community there seem to have a bit of an attitude problem: http://forum.mootools.net/topic.php?id=1607replies=12 I appreciate the tone and professionalism of the jQuery site and community. It's a big plus. Thanks! -- View this message in context: http://www.nabble.com/jQuery-Design-Decisions--Comparison-to-MooTools--tf321 8550.html#a8938358 Sent from the JQuery mailing list archive at
Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
Matt, You 've been one of my js heroes for years, welcome on board! alex -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Sent: mardi 13 février 2007 15:11 To: 'jQuery Discussion.' Subject: Re: [jQuery] jQuery Design Decisions? Comparison to MooTools? Matt, I think your final statement sealed the deal when I was deciding. This list is packed with experienced, patient, and helpful jQuery gurus. I've been developing for nearly a decade and have subscribed to a lot of lists over those years, and the degree of helpfulness you see on here is rare indeed. They don't jump on people for asking dumb questions or doing things differently, but there is still a good amount of constructive advice when its warranted. Being one of the moderately experienced js programmers you mention, I have frequently gotten answers to questions mere minutes after posting--not to mention all the questions that were answered (before I even knew I had them) while reading other posts. By the way Matt, I bookmarked your website years ago and used your JS libraries quite a bit--right up until I adopted jQuery! Thanks for making those things available. -Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Kruse Sent: Monday, February 12, 2007 9:28 PM To: discuss@jquery.com Subject: [jQuery] jQuery Design Decisions? Comparison to MooTools? I've been working with JS since it was created, and I've written a lot of my own libs and utilities. I'm now taking a serious look at existing frameworks simply because the effort of writing, debugging, and documenting my own code is too time consuming. Of the more mature and robust frameworks available, I think jQuery and MooTools offer the kind of approach that fits well with my thinking. There are differences between the two, but they are very similar in many respects. I'm leaning towards standardizing on jQuery because it packs a lot of functionality into a small package, is well documented, has a professional feel to it, is growing rather than shrinking, doesn't try to shove a class-based OO approach into JS where it doesn't belong, and has some great plugins and effects available for it. I am evaluating jQuery for two purposes: 1) To be used in a number of webapp projects by different teams, with costs in the millions. I don't want to pick a framework that will be gone and unsupported tomorrow, or one that moderately experienced js programmers wouldn't be able to pick up quickly. 2) My own use, to ease my pain. I'd like to take things like my fast and robust table sorting (and filtering, paging, etc) routines and map them into the jQuery namespace as plugins (I tried to comment on the zebra striping showdown and show my version but I think I was moderated out!). I have my own library that I've been working with/on for quite a while (even registered JavascriptElements.com) and I considered branching parts of jQuery into my own version. But, I'm sick of re-inventing the wheel - jQuery seems adequately round. I want to re-invent the steering wheel instead. With these things in mind, I have some general questions about the design decisions in jQuery: 1) There seems to be a lot of emphasis on using selectors and pseudo-selectors to access everything. It makes code short and simple, but is it really the most efficient? 2) Why encapsulate elements in a jQuery object rather than extending HTMLElement? Using the latter, you gain the ability to use built-in methods and properties of the elements, and you only have to worry about hacking it to work for IE (but hopefully not IE8!). 3) Some of the functions in jQuery seem to be magic in that they do and return a lot of different things depending on how they are called. This seems very Perl-ish to me, and that's one of the things that ended up making Perl so insanely incomprehensible to many. Why overload so many methods, rather than giving them their own understandable names? 4) Any chance of a jQuery-lite, without all the css selector logic? Or is that kind of Sonny without Cher? 5) What is the max compressed file size you want to stay under? Will plugins and other extensions be pulled into the main source file at some point? Or is the goal to keep the current core functionality as-is and depend on plugins for any extended functionality? Is there any concern that the framework will become fragmented (again, like Perl) so developers never know which set of plugins (modules) they need to do the job? 6) Finally, can anyone comment on introducing jQuery into a team of web developers with low to moderate javascript experience, building webapps or web sites that could run into the millions of dollars? Is jQuery robust enough and easy enough to deploy that it's an easy win? I tried to ask similar comparison questions on the MooTools forum, but the developers and community there seem to have a bit of an attitude problem: http://forum.mootools.net
Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
Matt, First off, a warning that this response doesn't address any of your specific questions; I'm still semi-new to jQuery and thus I'll leave the big questions for others. However, if you don't read anymore past this, just count this as a vote of confidence for the jQuery community! Before I forget, nice work on JavascriptElements.com. I like your advice in your Best Practices: Avoid prototype.js. That got a chuckle out of me, because I too just recently decided to find a JS framework for many of the reasons that you are now; I was having to spend too much time reinventing the wheel with every implementation. Even if I had a preexisting solution, or I found one, 9 times out of 10 it was already outdated by today's environment. I would end up spending more time actually trying to modify the code than actually implementing it, which of course is a huge time-waster. I checked out many frameworks, and I couldn't believe that prototype had no documentation! I thought I was just missing it, or didn't get it, but I had neither the time nor desire to seek for it so I quickly dropped prototype. The other frameworks I found were mostly bloated, filled will endless features when all I wanted was some basic functionality, with the option to add-on to that if needed, and there's where jQuery fit the bill. I've been a developer for several years and have been exposed to many different development communities in that time; usually forums, IRC, mailing lists, etc., and I will say that the jQuery is without a doubt the best community I've found for those seeking _help_. The answer may actually be in the API reference, but the people here seem to understand that perhaps the user simply didn't understand the API, or that they need some prodding in the right direction, or an extended example, and the community here is more than willing to provide that to users (and usually the theory behind it) WITHOUT making them feel like idiots. Honestly, it seems like many communities thrive on the elitist attitude, and seem to think that by driving off users by making them feel dumb will somehow improve their codebase. But I digress. If you do decide to adopt jQuery, here's some sites that I'm fond that makes the APIshall I say fun? :) http://visualjquery.com/ http://jquery.bassistance.de/api-browser/ http://joern.jquery.com/api-draft/cat.xml On 2/12/07, Matt Kruse [EMAIL PROTECTED] wrote: I've been working with JS since it was created, and I've written a lot of my own libs and utilities. I'm now taking a serious look at existing frameworks simply because the effort of writing, debugging, and documenting my own code is too time consuming. Of the more mature and robust frameworks available, I think jQuery and MooTools offer the kind of approach that fits well with my thinking. There are differences between the two, but they are very similar in many respects. I'm leaning towards standardizing on jQuery because it packs a lot of functionality into a small package, is well documented, has a professional feel to it, is growing rather than shrinking, doesn't try to shove a class-based OO approach into JS where it doesn't belong, and has some great plugins and effects available for it. I am evaluating jQuery for two purposes: 1) To be used in a number of webapp projects by different teams, with costs in the millions. I don't want to pick a framework that will be gone and unsupported tomorrow, or one that moderately experienced js programmers wouldn't be able to pick up quickly. 2) My own use, to ease my pain. I'd like to take things like my fast and robust table sorting (and filtering, paging, etc) routines and map them into the jQuery namespace as plugins (I tried to comment on the zebra striping showdown and show my version but I think I was moderated out!). I have my own library that I've been working with/on for quite a while (even registered JavascriptElements.com) and I considered branching parts of jQuery into my own version. But, I'm sick of re-inventing the wheel - jQuery seems adequately round. I want to re-invent the steering wheel instead. With these things in mind, I have some general questions about the design decisions in jQuery: 1) There seems to be a lot of emphasis on using selectors and pseudo-selectors to access everything. It makes code short and simple, but is it really the most efficient? 2) Why encapsulate elements in a jQuery object rather than extending HTMLElement? Using the latter, you gain the ability to use built-in methods and properties of the elements, and you only have to worry about hacking it to work for IE (but hopefully not IE8!). 3) Some of the functions in jQuery seem to be magic in that they do and return a lot of different things depending on how they are called. This seems very Perl-ish to me, and that's one of the things that ended up making Perl so insanely incomprehensible to many. Why overload so many methods, rather than giving them their own understandable names? 4) Any
Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
Matt, Just my two cents. JQuery's selectors and transversing got me hooked, its abstracted AJAX functions made me stay. If you're looking to introduce jQuery to a group of developers, why not have them develop the same application in plain jane js and then using jQuery. Compare the flexibility and document sizes for doing the same tasks. Show them they'll never have to loop through a group of nodes to apply a function or have to know what onreadystatechange means. One piece of advice though, jQuery can handle just about everything, so you may end up turning inexperienced JavaScript users into expert jQuery programmers, who are are only vaguely aware of how JavaScript works or what it does. I'd get everybody up to speed on what's available in JavaScript (JavaScript: The Definitive Guide, perhaps?) and then show them how jQuery will make everything easier. - jake On 2/13/07, Paul [EMAIL PROTECTED] wrote: Matt, I think your final statement sealed the deal when I was deciding. This list is packed with experienced, patient, and helpful jQuery gurus. I've been developing for nearly a decade and have subscribed to a lot of lists over those years, and the degree of helpfulness you see on here is rare indeed. They don't jump on people for asking dumb questions or doing things differently, but there is still a good amount of constructive advice when its warranted. Being one of the moderately experienced js programmers you mention, I have frequently gotten answers to questions mere minutes after posting--not to mention all the questions that were answered (before I even knew I had them) while reading other posts. By the way Matt, I bookmarked your website years ago and used your JS libraries quite a bit--right up until I adopted jQuery! Thanks for making those things available. -Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Kruse Sent: Monday, February 12, 2007 9:28 PM To: discuss@jquery.com Subject: [jQuery] jQuery Design Decisions? Comparison to MooTools? I've been working with JS since it was created, and I've written a lot of my own libs and utilities. I'm now taking a serious look at existing frameworks simply because the effort of writing, debugging, and documenting my own code is too time consuming. Of the more mature and robust frameworks available, I think jQuery and MooTools offer the kind of approach that fits well with my thinking. There are differences between the two, but they are very similar in many respects. I'm leaning towards standardizing on jQuery because it packs a lot of functionality into a small package, is well documented, has a professional feel to it, is growing rather than shrinking, doesn't try to shove a class-based OO approach into JS where it doesn't belong, and has some great plugins and effects available for it. I am evaluating jQuery for two purposes: 1) To be used in a number of webapp projects by different teams, with costs in the millions. I don't want to pick a framework that will be gone and unsupported tomorrow, or one that moderately experienced js programmers wouldn't be able to pick up quickly. 2) My own use, to ease my pain. I'd like to take things like my fast and robust table sorting (and filtering, paging, etc) routines and map them into the jQuery namespace as plugins (I tried to comment on the zebra striping showdown and show my version but I think I was moderated out!). I have my own library that I've been working with/on for quite a while (even registered JavascriptElements.com) and I considered branching parts of jQuery into my own version. But, I'm sick of re-inventing the wheel - jQuery seems adequately round. I want to re-invent the steering wheel instead. With these things in mind, I have some general questions about the design decisions in jQuery: 1) There seems to be a lot of emphasis on using selectors and pseudo-selectors to access everything. It makes code short and simple, but is it really the most efficient? 2) Why encapsulate elements in a jQuery object rather than extending HTMLElement? Using the latter, you gain the ability to use built-in methods and properties of the elements, and you only have to worry about hacking it to work for IE (but hopefully not IE8!). 3) Some of the functions in jQuery seem to be magic in that they do and return a lot of different things depending on how they are called. This seems very Perl-ish to me, and that's one of the things that ended up making Perl so insanely incomprehensible to many. Why overload so many methods, rather than giving them their own understandable names? 4) Any chance of a jQuery-lite, without all the css selector logic? Or is that kind of Sonny without Cher? 5) What is the max compressed file size you want to stay under? Will plugins and other extensions be pulled into the main source file at some point? Or is the goal to keep the current core functionality
Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
Mr. Kruse, I'd like to take a minute to respond to your well thought out post. Item 6 is the only one I think I can speak authoritatively on. I'm a msdn.microsoft.com/vfoxpro/ Visual Foxpro developer working at a multi location clinic developing intranet applications that fill the gaps left by our commercial software. While Foxpro is not traditionally a web app, I use a http://www.west-wind.com server side framework that is a joy to use. When it came to a client side framework, my choices were not so clear cut. At first I searched for specific widgets. Tabs, ajax, panels, etc. I ended up with 30+ javascript files in my html. Side note: Yeah I know, bad programmer, no donuts. Anyways, while looking for one that does it all I tried moo, prototype, scriptaculous (sp?), and YUI. None of them spoke to me as a programmer. jQuery was the only one that had it all. And to boot, a community unlike any other. I did more with jQuery in one afternoon then I could any of the other javascript frameworks. To be fair, I even tried your ajax toolbox and was left scratching my head. jQuery makes my sites come alive faster, easier, and cleaner then ever before. I think the logic of it will make it very easy for your team, no matter their background. Good luck on your future projects. Shaun Kester SKfox.net Matt Kruse wrote: Finally, can anyone comment on introducing jQuery into a team of web developers with low to moderate javascript experience, building webapps or web sites that could run into the millions of dollars? Is jQuery robust enough and easy enough to deploy that it's an easy win? -- View this message in context: http://www.nabble.com/jQuery-Design-Decisions--Comparison-to-MooTools--tf3218550.html#a8949022 Sent from the JQuery mailing list archive at Nabble.com. ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
Matt Kruse schrieb: I am evaluating jQuery for two purposes: I think one point yet deserves a litte more focus: jQuery's core is small, but it has already a ton of plugins available. Still, it is quite likely that you have some requirement that isn't covered fully by an available plugin. In that case, you can start from scratch (well, with jQuery as basis isn't exactly scratch) or take a plugin that does parts of what you need, and modify it. The latter is the approach that I used so far for 3 of the 4 plugins I released. I think this works particuarily well because writing plugins is nicely documented (http://docs.jquery.com/Plugins/Authoring), in addition to lots of good example code (http://docs.jquery.com/Plugins). Not everyone sticks with the coding styles and patterns presented there, but a lot do. That enables you to quickly understand any plugin you find, and improve it. The authoring guide itself was written by looking at plugin code, checking for common and useful patterns, similar to the way Design Patterns are documented in the Java world, or anywhere else. I haven't seen a community were developers learnd that much from others as jQuery's. The bloody newbies that asked basic questions months or even weeks ago, are now answering complex question themselve. Hope to see some jQuery-powered plugins and sites from you soon :-) -- Jörn Zaefferer http://bassistance.de ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
Jörn Zaefferer schrieb: Matt Kruse schrieb: I am evaluating jQuery for two purposes: Just discovered your use unary operator tip (http://www.javascripttoolbox.com/bestpractices/#plus). Great! Much more succinct then a parseInt(value). I don't really like the term Best Practice because so often they are mere Good Practice, as there often are better approaches that noone had thought of. But in case of that page, I must fully agree. -- Jörn Zaefferer http://bassistance.de ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
I haven't seen a community were developers learnd that much from others as jQuery's. The bloody newbies that asked basic questions months or even weeks ago, are now answering complex question themselve. And some of them even make it to the project team. ;o) ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
Matt, Welcome! I have been a huge fan of your work. I am hoping youd adopt jQuery instead of others... itll be great to have another js guru (amongst the many) in the camp. Michael -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jörn Zaefferer Sent: Tuesday, February 13, 2007 11:39 AM To: jQuery Discussion. Subject: Re: [jQuery] jQuery Design Decisions? Comparison to MooTools? Jörn Zaefferer schrieb: Matt Kruse schrieb: I am evaluating jQuery for two purposes: Just discovered your use unary operator tip (http://www.javascripttoolbox.com/bestpractices/#plus). Great! Much more succinct then a parseInt(value). I don't really like the term Best Practice because so often they are mere Good Practice, as there often are better approaches that noone had thought of. But in case of that page, I must fully agree. -- Jörn Zaefferer http://bassistance.de ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/ ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
Just discovered your use unary operator tip (http://www.javascripttoolbox.com/bestpractices/#plus). Great! Much more succinct then a parseInt(value). Be very careful using the + operator this way. +32px returns NaN parseInt(32px) returns 32 ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
On Feb 13, 2007, at 4:25 PM, Dave Methvin wrote: Just discovered your use unary operator tip (http://www.javascripttoolbox.com/bestpractices/#plus). Great! Much more succinct then a parseInt(value). Be very careful using the + operator this way. +32px returns NaN parseInt(32px) returns 32 Heh. I was wondering about that. You saved me the trouble of having to test it. :) Cheers, --Karl _ Karl Swedberg www.englishrules.com www.learningjquery.com ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
Thank you to everyone for all your responses. I have indeed decided to go
with jQuery as a base for future work, so I also plan to contribute to the
project with my own plugins, etc.
I like the summary of jQuery that has been expressed like this:
$('selectSomething').doSomething()
It seems that the library has heavy emphasis on the selectSomething in its
core, and depends a lot on plugins for the doSomething part. I can forsee
writing my own jQuery++ or whatever that adds a lot more functionality
that I consider to be core rather than depending on multiple plugins.
Is there a better official form plugin? The one listed is weak for basic
form functions, so I plan to adapt my own form functions into jQuery style
and make it a plugin. I can't live without isChanged() on form fields!
I really don't like the idea of forking jQuery, but I'd much rather have
less selectSomething logic and more doSomething logic, so maybe at some
point I'll prepare a version of about the same size (or bigger) with
emphasis on the opposite end. Or maybe not. jQuery does things about 80% the
way I would do it myself, so I guess I have to sacrifice the 20% and do
things the jQuery way. I need to write a blog entry titled How I Learned To
Stop Worrying And Love The jQuery!
I also plan to adapt my table sort/filter/autofiler/page/stripe/etc
functions into a plugin. The existing table sorter seems to do the job, but
I like to have all my table functionality in one place, and I think I handle
it a little faster and more robustly in my code, so look for that at some
point if you're interested.
I've found a version of a Cheat Sheet but it's not nearly as cool as the
latest Prototype cheat sheet. I was hoping to find a cool color printable
sheet to hang on my wall as a reference. The API is great, but a bit too
long-winded to hang on a wall ;)
Thanks again,
Matt
--
View this message in context:
http://www.nabble.com/jQuery-Design-Decisions--Comparison-to-MooTools--tf3218550.html#a8953902
Sent from the JQuery mailing list archive at Nabble.com.
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
dave.methvin wrote:
Just discovered your use unary operator tip
(http://www.javascripttoolbox.com/bestpractices/#plus).
Great! Much more succinct then a parseInt(value).
Be very careful using the + operator this way.
+32px returns NaN
parseInt(32px) returns 32
True, but in this case you aren't really type-converting to a number, you're
actually wanting to extract a number from a string. That's a different case.
And someone might then wonder why they try parseInt(10.5em) but it doesn't
work as expected.
And one of the main reasons to recommend + over parseInt() is because many
people try to do parseInt('09') and get the wrong result and can't figure
out why. In this case, +09 works as expected.
Matt
--
View this message in context:
http://www.nabble.com/jQuery-Design-Decisions--Comparison-to-MooTools--tf3218550.html#a8953990
Sent from the JQuery mailing list archive at Nabble.com.
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
I find having the doSomething part as separate plugins works very
nicely and allows me to be flexible with different sites and not load
a bunch of stuff I'm not actually using. I then just create an ant
task to put all the files into one and compress.
--
Brandon Aaron
On 2/13/07, Matt Kruse [EMAIL PROTECTED] wrote:
Thank you to everyone for all your responses. I have indeed decided to go
with jQuery as a base for future work, so I also plan to contribute to the
project with my own plugins, etc.
I like the summary of jQuery that has been expressed like this:
$('selectSomething').doSomething()
It seems that the library has heavy emphasis on the selectSomething in its
core, and depends a lot on plugins for the doSomething part. I can forsee
writing my own jQuery++ or whatever that adds a lot more functionality
that I consider to be core rather than depending on multiple plugins.
Is there a better official form plugin? The one listed is weak for basic
form functions, so I plan to adapt my own form functions into jQuery style
and make it a plugin. I can't live without isChanged() on form fields!
I really don't like the idea of forking jQuery, but I'd much rather have
less selectSomething logic and more doSomething logic, so maybe at some
point I'll prepare a version of about the same size (or bigger) with
emphasis on the opposite end. Or maybe not. jQuery does things about 80% the
way I would do it myself, so I guess I have to sacrifice the 20% and do
things the jQuery way. I need to write a blog entry titled How I Learned To
Stop Worrying And Love The jQuery!
I also plan to adapt my table sort/filter/autofiler/page/stripe/etc
functions into a plugin. The existing table sorter seems to do the job, but
I like to have all my table functionality in one place, and I think I handle
it a little faster and more robustly in my code, so look for that at some
point if you're interested.
I've found a version of a Cheat Sheet but it's not nearly as cool as the
latest Prototype cheat sheet. I was hoping to find a cool color printable
sheet to hang on my wall as a reference. The API is great, but a bit too
long-winded to hang on a wall ;)
Thanks again,
Matt
--
View this message in context:
http://www.nabble.com/jQuery-Design-Decisions--Comparison-to-MooTools--tf3218550.html#a8953902
Sent from the JQuery mailing list archive at Nabble.com.
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
Be very careful using the + operator this way.
+32px returns NaN
parseInt(32px) returns 32
True, but in this case you aren't really type-converting to a number,
you're actually wanting to extract a number from a string.
Yeah, I just saw the gleam in Jörn's eye and knew he was thinking about
changing the parseInt/parseFloat to + in jQuery core. There are a lot of
places where strings with trailing units are converted to numbers, and +
isn't appropriate there.
And one of the main reasons to recommend + over parseInt()
is because many people try to do parseInt('09') and get the
wrong result and can't figure out why. In this case, +09
works as expected.
My favorites are the pathological inputs like 08E1 that give you 0 from
parseInt and 800 from +/parseFloat.
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
Brice Burgess schrieb: I really don't like the idea of forking jQuery, but I'd much rather have less selectSomething logic and more doSomething logic, so maybe at some point I'll prepare a version of about the same size (or bigger) with emphasis on the opposite end. Or maybe not. jQuery does things about 80% the way I would do it myself, so I guess I have to sacrifice the 20% and do things the jQuery way. I need to write a blog entry titled How I Learned To Stop Worrying And Love The jQuery! No, I don't like the idea of forking either in fact it is infuriating. This is not a community that is going to balk at your changes. jQuery can easily be extended with your own methods. Its core functionality can also be changed. You can make these changes available to us without forking the thing splitting a community. See the dimensions plugin in how it extends the $.width() $.height() methods for an example; JavaScript makes is extremely easy to extend existing funcitonality, so I don't think there is really a need to fork. In addition, once you get used to the selectors, its not unlikely that you don't want to miss them. I also plan to adapt my table sort/filter/autofiler/page/stripe/etc functions into a plugin. The existing table sorter seems to do the job, but I like to have all my table functionality in one place, and I think I handle it a little faster and more robustly in my code, so look for that at some point if you're interested. It would be nice to see a fast efficient abstracted stripping plugin. There is one in tablesorter. There is also one available in rikrikrik's most excellent quicksearch plugin; http://rikrikrik.com/jquery/quicksearch/ That is now also available in jQuery's plugin repository: http://jquery.com/dev/svn/trunk/plugins/quicksearch/ I haven't made any serious changes, but fixed a few problems that prevented the plugin to be used without the $ alias or compress it. I've found a version of a Cheat Sheet but it's not nearly as cool as the latest Prototype cheat sheet. I was hoping to find a cool color printable sheet to hang on my wall as a reference. The API is great, but a bit too long-winded to hang on a wall ;) http://jquery.bassistance.de/api-browser/ is a nice API ref that's downloadable. Downloadable and printable, so you could just modify the print stylesheet to fit your needs (and wall size). -- Jörn Zaefferer http://bassistance.de ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
There's a whole mess of Forms plugins:
http://docs.jquery.com/Plugins#Forms
All of them focus on different tasks (although, there's currently a bunch of
validation plugins).
I think you'll find that it's trivial to extend jQuery with plugins, and
really make it your own.
--John
On 2/13/07, Matt Kruse [EMAIL PROTECTED] wrote:
Thank you to everyone for all your responses. I have indeed decided to go
with jQuery as a base for future work, so I also plan to contribute to the
project with my own plugins, etc.
I like the summary of jQuery that has been expressed like this:
$('selectSomething').doSomething()
It seems that the library has heavy emphasis on the selectSomething in its
core, and depends a lot on plugins for the doSomething part. I can forsee
writing my own jQuery++ or whatever that adds a lot more functionality
that I consider to be core rather than depending on multiple plugins.
Is there a better official form plugin? The one listed is weak for basic
form functions, so I plan to adapt my own form functions into jQuery style
and make it a plugin. I can't live without isChanged() on form fields!
I really don't like the idea of forking jQuery, but I'd much rather have
less selectSomething logic and more doSomething logic, so maybe at some
point I'll prepare a version of about the same size (or bigger) with
emphasis on the opposite end. Or maybe not. jQuery does things about 80%
the
way I would do it myself, so I guess I have to sacrifice the 20% and do
things the jQuery way. I need to write a blog entry titled How I Learned
To
Stop Worrying And Love The jQuery!
I also plan to adapt my table sort/filter/autofiler/page/stripe/etc
functions into a plugin. The existing table sorter seems to do the job,
but
I like to have all my table functionality in one place, and I think I
handle
it a little faster and more robustly in my code, so look for that at some
point if you're interested.
I've found a version of a Cheat Sheet but it's not nearly as cool as the
latest Prototype cheat sheet. I was hoping to find a cool color printable
sheet to hang on my wall as a reference. The API is great, but a bit too
long-winded to hang on a wall ;)
Thanks again,
Matt
--
View this message in context:
http://www.nabble.com/jQuery-Design-Decisions--Comparison-to-MooTools--tf3218550.html#a8953902
Sent from the JQuery mailing list archive at Nabble.com.
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
Hi Matt, It seems that the library has heavy emphasis on the selectSomething in its core, and depends a lot on plugins for the doSomething part. I can forsee writing my own jQuery++ or whatever that adds a lot more functionality that I consider to be core rather than depending on multiple plugins. Is there a better official form plugin? The one listed is weak for basic form functions, so I plan to adapt my own form functions into jQuery style and make it a plugin. I can't live without isChanged() on form fields! I really don't like the idea of forking jQuery, but I'd much rather have Hopefully you'll create an extension to the jQuery core that would encompass this enhanced functionality before forking a very solid project. Its really important to the team that we offer a consistent experience for all jQuery users and to date, the jQuery project has been extremely successful because of the wealth of community contributions that developers have submitted in the form of extensions and plugins. We're definitely looking forward to your contributions. I think I speak for most jQuery developers, though, in that I sleep well knowing that the core is being well managed and maintained by the jQuery project development team. They're some of the best developers out there. emphasis on the opposite end. Or maybe not. jQuery does things about 80% the way I would do it myself, so I guess I have to sacrifice the 20% and do things the jQuery way. I need to write a blog entry titled How I Learned To Stop Worrying And Love The jQuery! The great thing about jQuery is that you don't have to sacrifice. The plugin architecture makes it very adaptable to different coding styles and needs. I also plan to adapt my table sort/filter/autofiler/page/stripe/etc functions into a plugin. The existing table sorter seems to do the job, but I like to have all my table functionality in one place, and I think I handle it a little faster and more robustly in my code, so look for that at some point if you're interested. I'd love to see it. I've found a version of a Cheat Sheet but it's not nearly as cool as the latest Prototype cheat sheet. I was hoping to find a cool color printable sheet to hang on my wall as a reference. The API is great, but a bit too long-winded to hang on a wall ;) Send me the link to the PT one and we'll see what we can do. A cheat sheet is on the task list but as with everything, finding the time to get it all done is tough. Rey... ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
Dave Methvin schrieb: True, but in this case you aren't really type-converting to a number, you're actually wanting to extract a number from a string. Yeah, I just saw the gleam in Jörn's eye and knew he was thinking about changing the parseInt/parseFloat to + in jQuery core. There are a lot of places where strings with trailing units are converted to numbers, and + isn't appropriate there. Now that you mention it... :-) Actually I just added it to my ever-extending repository of available JS tricks. -- Jörn Zaefferer http://bassistance.de ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
Rey Bango-2 wrote: Send me the link to the PT one and we'll see what we can do. This one is nice: http://snook.ca/files/prototype_1.5.0_snookca.pdf as is this one: http://www.snook.ca/archives/javascript/prototype_disse/ Although sometimes cheat sheets end up just being a list of methods and parameters. IMO, a good cheat sheet lists everything, but expands on items that are often or easily confused. For example, I don't have much of a need to reference a cheat sheet for addClass(Str) - it's prett obvious. But some of the animation methods or Ajax methods certainly justify another line of explanation or example. Just something to jog the memory, but not a replacement for the API. At some point I can also look into creating a cheat sheet if it's not yet done. Matt -- View this message in context: http://www.nabble.com/jQuery-Design-Decisions--Comparison-to-MooTools--tf3218550.html#a8955012 Sent from the JQuery mailing list archive at Nabble.com. ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
Matt Kruse schrieb:
Is there a better official form plugin? The one listed is weak for basic
form functions, so I plan to adapt my own form functions into jQuery style
and make it a plugin. I can't live without isChanged() on form fields!
I think it's a bit unfair to call that plugin weak. I haven't seen a
solution that let's you create completely unobtrusive and accessible
Ajax forms with one line of code:
$('form').ajaxForm();
A lot of work has been put into that plugin so far.
-- Klaus
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
I just wanted to chime in on a few observations made. If you choose a library on a small set of criteria ( does it do what I need?, is it easy to do what I need?, how much do I need to learn to use it? and what sort of resources are available to help me learn it? ) what you find is that jquery is the only one that has a good answer for each. I think one of the strongest traits the community here has is that they like to help eachother. The fact that answering a question or mocking up a demonstration for someone in jquery is 10x easier than another library encourages people to write code to answer new users questions. I don't speak for anyone but myself, but that alone was invaluable to me. Seeing a few 'one-liners' and going from there to writing plugins of my own felt so natural and easy. That and the dev team - especially John and his maturity and respect towards other framework developers.. I was sold. I won't go back to prototype. Ever. Prototype is dead, long live Jquery. -- View this message in context: http://www.nabble.com/jQuery-Design-Decisions--Comparison-to-MooTools--tf3218550.html#a8955191 Sent from the JQuery mailing list archive at Nabble.com. ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
Yep. Jonathan Snook does a great job of creating those. I read his blog all the time. Lets see what can be done. Thanks for the links. Rey Matt Kruse wrote: Rey Bango-2 wrote: Send me the link to the PT one and we'll see what we can do. This one is nice: http://snook.ca/files/prototype_1.5.0_snookca.pdf as is this one: http://www.snook.ca/archives/javascript/prototype_disse/ Although sometimes cheat sheets end up just being a list of methods and parameters. IMO, a good cheat sheet lists everything, but expands on items that are often or easily confused. For example, I don't have much of a need to reference a cheat sheet for addClass(Str) - it's prett obvious. But some of the animation methods or Ajax methods certainly justify another line of explanation or example. Just something to jog the memory, but not a replacement for the API. At some point I can also look into creating a cheat sheet if it's not yet done. Matt ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
I agree with Klaus.
Matt, you may really want to try digging into it as Mike Alsup really
put a ton of functionality into the plugin. I think you may not have
fully reviewed it. If there's something that you think could be useful,
then you should post it here so that Mike can provide some feedback.
Rey...
Klaus Hartl wrote:
Matt Kruse schrieb:
Is there a better official form plugin? The one listed is weak for basic
form functions, so I plan to adapt my own form functions into jQuery style
and make it a plugin. I can't live without isChanged() on form fields!
I think it's a bit unfair to call that plugin weak. I haven't seen a
solution that let's you create completely unobtrusive and accessible
Ajax forms with one line of code:
$('form').ajaxForm();
A lot of work has been put into that plugin so far.
-- Klaus
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Kruse Subject: Re: [jQuery] jQuery Design Decisions? Comparison to MooTools? I've found a version of a Cheat Sheet but it's not nearly as cool as the latest Prototype cheat sheet. I was hoping to find a cool color printable sheet to hang on my wall as a reference. The API is great, but a bit too long-winded to hang on a wall ;) Matt - Good point... I think I'll go work on that now... *opens up Illustrator* -ALEX ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
If there's something that you think could be useful, then you should post it here so that Mike can provide some feedback. By all means. The form plugin, like most others, is a work in progress. It's not done, but what's there so far has proven to be robust, fast and useful. Input on additions and changes is always welcome. Mike ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
Awesome Alex!! Thanks for doing this. :o) Rey Alex Cook wrote: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Kruse Subject: Re: [jQuery] jQuery Design Decisions? Comparison to MooTools? I've found a version of a Cheat Sheet but it's not nearly as cool as the latest Prototype cheat sheet. I was hoping to find a cool color printable sheet to hang on my wall as a reference. The API is great, but a bit too long-winded to hang on a wall ;) Matt - Good point... I think I'll go work on that now... *opens up Illustrator* -ALEX ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/ ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
malsup wrote: If there's something that you think could be useful, then you should post it here so that Mike can provide some feedback. By all means. The form plugin, like most others, is a work in progress. I didn't mean to be insulting when I said it was 'weak' - I'm sure it is technically solid. But it lacks common functionality that I would expect, such as getting the default value of a control, checking to see if a control or a form has been modified, manipulating select box options, setting form field values, returning an array of values from fieldValue(), etc. It seems targeted mostly at making forms ajaxy, which is great, but I was looking for a more general set of robust form tools on which other functionality can be layered. Btw, the link to the plugin from this page: http://docs.jquery.com/Plugins doesn't work! Matt -- View this message in context: http://www.nabble.com/jQuery-Design-Decisions--Comparison-to-MooTools--tf3218550.html#a8957759 Sent from the JQuery mailing list archive at Nabble.com. ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
I didn't mean to be insulting when I said it was 'weak' - I'm sure it is technically solid. But it lacks common functionality that I would expect, No offense taken, no worries. You bring up some great points. I suspect some of the functionality you mentioned is spread across some of the other form-based plugins, although I can't say for sure. The form plugin does focus on ajax and serialization, although fieldValue and clearForm are more utility based. Not sure what you meant about the array of values returned from fieldValue (it returns an array for selects or checkboxes). Are you planning to write a plugin to support the features you mentioned? It would be a great companion and/or alternative to the current form plugin. Great feedback! Thanks. Mike ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
Hi Matt, I just tried http://docs.jquery.com/Plugins and it came up. It may have been a temporary hiccup. Try it again. Rey... Matt Kruse wrote: malsup wrote: If there's something that you think could be useful, then you should post it here so that Mike can provide some feedback. By all means. The form plugin, like most others, is a work in progress. I didn't mean to be insulting when I said it was 'weak' - I'm sure it is technically solid. But it lacks common functionality that I would expect, such as getting the default value of a control, checking to see if a control or a form has been modified, manipulating select box options, setting form field values, returning an array of values from fieldValue(), etc. It seems targeted mostly at making forms ajaxy, which is great, but I was looking for a more general set of robust form tools on which other functionality can be layered. Btw, the link to the plugin from this page: http://docs.jquery.com/Plugins doesn't work! Matt ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
malsup wrote:
Not sure what you meant about
the array of values returned from fieldValue (it returns an array for
selects or checkboxes).
It looked to me (I could be wrong) that if I have 10 text inputs of the same
name, I will only get the value of the first one if I do a fieldValue(). Is
this incorrect?
malsup wrote:
Are you planning to write a plugin to support the features you
mentioned?
Most definitely. Even if it's not popular, I would at least use it for
myself. I've used my own code for so long that I'm most comfortable with its
interface and behavior, so that's the big incentive for me. I have separate
modules now for form functions (value, default value, setting value,
ischanged, etc), for selectbox manipulation (move options up and down, sort,
add, remove), for check box groups, for dependent select boxes, and
transferring options between select boxes. So I definitely don't have to
start from scratch. I just have to revisit and rework some of the code I
already have (it needs cleaned up anyway).
My goal would be to tweak these stand-alone modules but not make them
exclusively jQuery. Instead, add a check at the bottom to see if jQuery is
also being used, then plug those methods into the jQuery object.
Something like:
var Form={
getValue: function(field) { ... }
}
if (jQuery) {
jQuery.fn.getValue=function() {
var v=[];
for (var i=0, max=this.length; i max; i++) {
v.push(Form.getValue.call(Form,this[i]));
}
return v;
}
}
Please forgive me if that's _way off_ from how it should work, I haven't
really read through the Plugins docs yet so I'm only guessing and using a
bit of your code ;)
But this way, the library can be used either stand-alone or as a jQuery
plugin. Someone could extend it to work with their own framework of choice
as well. For basic functionality, I just don't see a reason to tie the core
logic to a specific framework. Other than losing the ability to use jQuery's
functionality within the module logic, is there any reason not to take the
strategy above?
Ah, and FWIW, I think the jQuery community should standardize on all plugins
taking the name jSomething, just for consistency. It always looks way more
cool when all plugins and extensions have the same naming structure. Makes
the whole thing look like a more cohesive unit rather than a jumbled bunch
of modules, IMO :)
Matt
--
View this message in context:
http://www.nabble.com/jQuery-Design-Decisions--Comparison-to-MooTools--tf3218550.html#a8958367
Sent from the JQuery mailing list archive at Nabble.com.
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
Gotcha. John Resig wrote: Rey - He was referring to the URL pointing to the forms plugin, on the plugin page. I just fixed it (a couple URLs were broken). It should be working now. --John On 2/13/07, Rey Bango [EMAIL PROTECTED] wrote: Hi Matt, I just tried http://docs.jquery.com/Plugins and it came up. It may have been a temporary hiccup. Try it again. Rey... Matt Kruse wrote: malsup wrote: If there's something that you think could be useful, then you should post it here so that Mike can provide some feedback. By all means. The form plugin, like most others, is a work in progress. I didn't mean to be insulting when I said it was 'weak' - I'm sure it is technically solid. But it lacks common functionality that I would expect, such as getting the default value of a control, checking to see if a control or a form has been modified, manipulating select box options, setting form field values, returning an array of values from fieldValue(), etc. It seems targeted mostly at making forms ajaxy, which is great, but I was looking for a more general set of robust form tools on which other functionality can be layered. Btw, the link to the plugin from this page: http://docs.jquery.com/Plugins doesn't work! Matt ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/ ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/ ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
Matt, Waning: The following is written by a NON-programmer. jQuery to me is the evolution of CSS, not the evolution of JavaScript. When I discovered CSS, I fell in love with it because of the :hover tag. It just worked. I didn't need to learn programming. It was like magic. To me, jQuery and CSS act exactly alike in this manner. jQuery has more features, but the model works the same for me. When I think of CSS, I am *not* just thinking how it LOOKS, I am thinking how it ACTS. So the selector model is a perfect fit. I drank the Kool-Aid on jQuery because of the slideDown() function. It just worked, and I didn't need to learn to program. I made the intuit.cominteractivity by myself. I actually tried to do this type of thing with mootools, dojo, YUI and Prototype before jQuery. Only jQuery worked for me because it was so much like CSS, that I could learn it. Some other factors I have really enjoyed.: 1. The API has *examples*. This is so simple, yet YUI doesn't have it. I have no idea why. 2. The community is really friendly. They allow off-topic discussions and even allow newbies tro ask how to do the simplest task. I have yet to see someone say, READ THE API. 3. Plugins. Active development. Not only are they growing rapidly. They actually take feedback and build them into the plugins! 4. Programmer approved. I do ultimately have to work with people who know what they are talking about. When they see my code they know what I meant to do and how the thing works, so they can take the next steps. I get depressed when I say to a programmer, I want it to slide down, but not evenly, I want it to bounce a little at the end, and also fade in during the slide. The reason I get depressed is that for YEARS the answer was We don't have time, we will have to get to that later. Now, I do it myself and they are happy because they could focus on more pressing functional issues. It also has had the happy side effect of making interactivity accessible to the programmers. They have been much more willing to experiment with UX effects because it so fast to prototype. Right now, I am working with YUI and YUI-ext. It took me 3 hours to figure out the syntax to make something hide using display, not visibility. I feel horrible. Ok, Im rambling. I hope this was a little helpful. Glen Very jQuery ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] jQuery Design Decisions? Comparison to MooTools?
Hey Matt -
Thanks for the post. It looks like you've spent a lot of time really
considering the issues. I agree, choosing a library is non-trivial.
I'll try to answer a bunch of your questions, be sure to let me know
if I missed any.
1) There seems to be a lot of emphasis on using selectors and
pseudo-selectors to access everything. It makes code short and simple, but
is it really the most efficient?
most efficient? The absolute fastest way to traverse the document
would be to write pure DOM code, by hand. Short of that, jQuery is
incredibly fast. We've been in a friendly competition with Dojo and
Ext over the speed of our selectors. We're all getting to the point of
not being able to become any faster. I think that's pretty reasonable
:-)
In short, we can never be as fast as unadulterated DOM code, but we're
very close - so close that you'll be hard pressed to find a noticeable
difference.
2) Why encapsulate elements in a jQuery object rather than extending
HTMLElement? Using the latter, you gain the ability to use built-in methods
and properties of the elements, and you only have to worry about hacking it
to work for IE (but hopefully not IE8!).
A couple reasons:
1) This functionality does not exist in IE, nor is it completely
duplicable in IE. For example, look at this piece of code taken from
the official Prototype documentation:
// this will error out in IE:
$('someElement').parentNode.hide()
// to make it cross-browser:
$($('someElement').parentNode).hide()
We pride ourselves on complete cross browser stability. We'll take
consistency and speed over pure features any day. You should never
have to write an ugly cross-browser hack when using jQuery - and
that's a big thing to consider. Since HTMLElement doesn't afford us
that ability (yet), we've stayed away.
2) Assuming that we could get some form of HTMLElement to work, the
entire concept is leaky. Attaching properties to elements at runtime
means that you have to remove them before the elements are removed
from the DOM; otherwise you get memory leaks (another thing we try to
avoid).
3) Attaching properties to DOM elements is really really slow. Doing
speed tests comparing this technique against storing elements in an
array, and iterating over them on a case-by-case basis, the array
(jQuery) way is always faster.
4) Finally, and perhaps most importantly, it simply doesn't embody the
jQuery philosophy. jQuery is designed to match a set of elements. This
set can have 0 elements, or a hundred - it makes no difference to
jQuery. For example:
$(div.foo).hide();
There could be no divs on the page - or no divs that have that
particular class, I don't know that, nor do I have to worry about that
being the case.
And again with finding elements by ID:
$(#test).css(color, red);
There may be no element like that on the site, but you don't have to
worry about that. Whereas, in most other libraries you'd have to write
something like this:
var elem = $(test);
if ( elem )
elem.css(color, red);
We definitely tend to opt for simplicity on this point.
3) Some of the functions in jQuery seem to be magic in that they do and
return a lot of different things depending on how they are called. This
seems very Perl-ish to me, and that's one of the things that ended up making
Perl so insanely incomprehensible to many. Why overload so many methods,
rather than giving them their own understandable names?
Some of these came from some of our early growing pains. .load() can
mean two different things, as does .toggle(). These were mistakes, but
clarifying them is really rough (as it would require a fairly harsh
API change to some very-popular features). That's not to say that they
won't be changed some day (jQuery 2?).
However, the design decision to pick concise names in favor of truly
explanatory names does have a taste of Perl, to be honest. I guess
that's just how we've gone along - it's what we particularly enjoy.
4) Any chance of a jQuery-lite, without all the css selector logic? Or is
that kind of Sonny without Cher?
We've been considering it - however, it's hard to gauge what's open
for removal, and what's not. Instead, we're probably going to try and
provide a really-strong download page that'll let you add/remove
particular sub-features that you want (for example, if you didn't want
basic XPath support, you could remove it.) That's in the works right
now.
In the meantime, the selector logic is, effectively, the strong core
of jQuery - it's what makes it what it is, as a library. Frequently,
developers will find themselves in the Give an ID to everything on
the page mindset, but that's not what we're about. It's all about
building a flexible selector that can work on semantic content - no
extra crufty attributes, or repetitive code, required.
5) What is the max compressed file size you want to stay under? Will plugins
and other extensions be pulled into the main source file at some point? Or
is the goal to keep the current core
