Re: [jQuery] JQuery vs prototype
> what benefits of JQuery vs prototype?(http://www.prototypejs.org/) In reality, most js frameworks offer similar core functionality. What you're usually comparing is syntax and general coding approach, which vary quite a bit based on personal preferences. All frameworks are going to let you add a class to an element, for example, and all should do it without any problems. I think the key differences between jQuery and Prototype are: 1) Prototype encourages a class-based structure, which IMO is not very javascripty. If you want classes, look at Prototype. 2) jQuery encourages a coding style that is short and easy to read. The "look how easy it is with Prototype!" examples usually resemble obfuscated Perl more than Javascript to me. 3) Prototype is tied closely to the Ruby on Rails community. If you use Ruby on Rails, definitely choose Prototype. Outside of that community I see no reason to choose Prototype over other frameworks like jQuery or even Moo. If you must have a class-based design, look at Moo. If you like readable code, look at jQuery. Matt Kruse ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Quality control for plugins
>- javadoc commenting of plug-in external interface Using what tool? jsDoc? I've found that jsDoc works great for class-based structures, but not so well for stand-along functions or library interfaces like jquery plugins. There should be some standard javadoc-style syntax, but not necessarily exactly as used in jsdoc. In any event, I think all plugins should certainly have embedded API documentation, and the jquery.com site itself should be able to present each plugin's API docs in the same format, using the same tool. I would also suggest implementing additional jquery-specific doc tags for dependencies, etc. I've yet to find a tool that I really like to parse and report on these javadoc-style tags with the flexibility that I want. I don't even want a js parser - I can provide the full documentation, function name, parameters, etc within my comments. So I started writing a tool in php that will output the documentation on-the-fly. Of course, it's about 10% done, like most things I start... Matt ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Jquery can learn from Mootools for distribution its code
> Any chance of allowing it to package up some of the official plugins? It > would be really nice if I could customize my JQuery to automatically include > the Compat-1.0 plugin (for older code), Dimensions, and perhaps even > Interface. I actually registered myjquery.com specifically for this purpose. I'm going to try to work on an alternative distribution, much like "MyEclipse" and other tools that combines the core jQuery with the most common and useful plugins. Or maybe even let people choose their plugins and save their configuration. Then it would automatically pull the latest version of each every night and always have the latest and greatest set of tools available. If you ever want to update your core or plugins, you just go back to myjquery.com and re-download your configuration. Further, if the plugin documentation can be standardized, you would be able to create a full set of documentation specifically for the distribution that you have assembled. Maybe including a cheat sheet that is automatically created from your selected plugins. That would be slick. I use js primarily in internal webapps, and file size isn't that important. If I have a 75k library with everything I need rather than the 20k core and 10 plugin js files, that would be great for me. That's my intent, at least. In reality, I'm not sure I'll have time to even start implementing it. If anyone wants to take the idea and run with it, let me know ;) Matt Kruse ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Jquery can learn from Mootools for distribution its code
> Mootools distribution allows you to build a custom distribution with > just the functionality you need. > I would love it if we could do this with jquery. I think it's a bad idea. The MooTools download is very confusing, and you need to really know what you want/need in order to get a usable download. That's a lot of decisions to make for someone who may not be a js hacker and may just want a framework to work with. The benefit of having a single (small) package is that the same functionality is there all the time, every time. You don't have different versions of js files on different pages and being cached separately. You don't wonder why plugin X doesn't work, then realize that you have package Y of jQuery instead of package Z. Instead of plugins just requiring jQuery, they would require components A, B, and C of jQuery. It just adds a whole level of confusion. Matt Kruse ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Is the JQuery slowest?
> What is this base2 deal? http://dean.edwards.name/weblog/2007/03/yet-another/ Matt Kruse ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] NOTICE: Moving to Google Groups
> I've talked it over with a number of people and they feel that Google > Groups is an adequate substitute for both a mailing list and a > general-purpose forum, and I tend to agree. Google Groups is a fine alternative, although the web interface is quite horrible, IMO. I personally would have preferred an nntp interface, since my newsreader already handles threaded discussions better than email or google groups. Unfortunately everything seems to be moving to Google Groups which doesn't have an nntp interface and locks you into using their browser-based UI. Matt Kruse ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] anyone success to inegrate sortable with mysql/php?
> What is the jQuery interface going to look like? It will simply expose methods like .autosort() .autofilter() .autopage() .tablesort() .tablefilter() .tablepage() that hook into the jQuery syntax, either on document.ready or triggered manually. Ideally, I think the unobtrusive classname-driven functionality should be preferred, but the above style will be there in case more complex things need to be done. Are there any other hooks specifically into jquery that you think would be beneficial? Matt ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] anyone success to inegrate sortable with mysql/php?
>If something like AJAX DataGrid (http://www.phpclasses.org/browse/package/3610.html) can edit using AJAX, I'm sure some sorting can be done. Sorting via Ajax doesn't make much sense. >I still prefer to use PHP, and not AJAX for sorting, like I've done at http://www.atasteofdutch.com/catalog.htm If you want to go back to the server and sort using php (why?) then why would you need a javascript solution at all? Matt ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] anyone success to inegrate sortable with mysql/php?
> i see the scriptaculs thing that rule on the web... > maybe its because there are working examples of scriptacouls with php/mysql > integration? How would a client-side sorting plugin interact with php/mysql? Once the rows are delivered to the browser (independent of server-side technology) then it's all javascript from there, right? What kind of functionality are you looking for? I am almost done with my table sort/filter/page plugin at http://www.JavascriptToolbox.com/lib/table/ (updated last night to version .981) and if you have any suggestions about how to improve it to do what you're looking for, I'd like to hear it! Matt Kruse ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] ANNOUNCE: The treemap plugin
> Renato Formato schrieb: > > I wrote a jQuery plugin to show treemaps > > (http://en.wikipedia.org/wiki/Treemap) easily thanks to jQuery. > > Link: http://www.jquery.info/spip.php?article40 The documentation is pretty light, so it's hard to understand exactly what the table data structure needs to be and how to quickly implement a treemap. It would be nice to have some examples like "given this table, this is the result." My first attempt to use it has failed on this line in normalizeValues: if(data[i][1].constructor==Array) When feeding it a table like this: Name Size(Number) Value(Number) My goal is to show distribution of stocks and their relative performance like a financial Heat Map. The Size would be the size % of the total and Value would be the MTD% performance. Is this not the correct table layout? I would also suggest cleanly separating the Treemap logic from the jquery/html implementation. This way if I wanted to use your core logic for something entirely different and not jquery-ish or maybe using a different layout structure, I could still do so. Thanks for the plugin, I'm sure I will find uses for it in the near future! Matt ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
[jQuery] Why globalEval?
I was just reading through some of the jQuery code again to better learn its internals, and I'm not sure why the globalEval function exists in its current form. Whenever I want to eval something in the global context, I always do: Function(data)(); since the Function constructor doesn't create a closure. This seems much simpler than the current logic, expecially for Safari - but I admit that I haven't done much cross-browser checking. Do some browsers not support the above syntax, or is there some other reason for using the long globalEval logic? Matt Kruse [EMAIL PROTECTED] http://www.mattkruse.com/ ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Fastest selector for searching a single table column?
Beware - the cellIndex property will give misleading results if there are any colspan's in the row, or rowspan's that intersect with the row. See http://www.javascripttoolbox.com/temp/table_cellindex.html for an example of the problem. It will also always exist but be 0 in some versions of Safari. These are things I account for in my table lib so if you want to check out how I solve the problem you may want to do something similar. Matt Kruse > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Daemach > Sent: Saturday, March 10, 2007 5:19 PM > To: discuss@jquery.com > Subject: Re: [jQuery] Fastest selector for searching a single table > column? > > > > OK the cellindex property of the td inside which the text field resided would > get me the current column, at least in firefox... ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Matt Krause - table plugins
> Just a general question - How big of a data table is this script effective > for? At what point does it make more sense to go back to the server? For sorting I've used it on tables approaching 1,000 rows and the performance was just fine. The speed of the script is much better than most other sorting libs, I think. I don't think it makes sense to do extensive client-side paging - that works best via ajax, IMO. Matt ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Matt Krause - table plugins
> $("table").mattsTables({ // TableWide options
> ...
Why this as opposed to putting simple class names in the table like
..
?
> dateofbirth: {sortable:true, datatype:"date",filter:true, filtertype:
> "mm/" //creates 2 dropdowns },
I don't think any generalized solution is going to give you options like this.
But in my code, I give the option to filter by matching a string, a regular
expression, or by evaluation a function. You may have to manually create your
filters in this case, but almost anything would be possible. Perhaps some
pre-defined common filters would be in order.
Matt
ps: You're welcome to email me personally if you wish. I don't know if there is
list-wide interest in this topic or not, as it is not very jquery-ish at the
moment.
___
jQuery mailing list
discuss@jquery.com
http://jquery.com/discuss/
Re: [jQuery] Matt Krause - table plugins
> Matt, are you reading this list? Yes. > I am anxiously awaiting the jQuery port of > your table filtering/sorting functionality. Is this coming soon? Within a week or so, I hope. http://www.JavascriptToolbox.com/lib/tablenew/ is where it's at right now. I'm a bit torn about how much actual jQuery-specific functionality to add to it, since the primary goal is to be unobtrusive and simply add class names to tables. We'll see. Matt ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] jqueryplugins.com
>>Just some thoughts. I would really like information or discussion on the >>documentation/API side of things, as I am currently looking for the best way to >>document a jQuery API. >This definitely needs to be better documented. There is already a very >solid, consistent doc format for jQuery code. >From some of the plugins I've looked at, it looks jsdoc-ish. Is it documented anywhere? Is the script to process the docs available somewhere? When I release my first plugin, I want it to "conform to specs" as much as possible. Thanks, Matt ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] jqueryplugins.com
> I don't want to diminish your excitement but we're already in the > process of building a plugin repository to better manage the jQuery plugins. Speaking of which, is there any list of things you are building into the first release? A list of future enhancements? As I've been reading, experimenting, and developing, I had a few thoughts. If 20k is the jQuery limit, that means new development on the core library will probably be really limited, and the future of jQuery really lies in the plugins. Is this the vision? If so, then the plugins area certainly warrants a lot of attention. It is probably where many new jQuery users will be hooked because they can easily do X or Y, not because they can do the lower-level JS stuff easier with the core lib. With these thoughts in mind, I had few suggestions - some (or all!) of which I'm sure you're already considering: 1. The "official" list of plugins should get its own page and be clearly separated from other non-official plugins. They should meet some tough standards, be updated and supported, and avoid overlapping functionality as much as possible. It should be clear what is required for a plugin to be considered "official". 2. Official plugins should have a common naming convention, always have the same license as jQuery itself, and follow some similar coding guidelines. 3. Documentation should be consistent. There should be a single format which all plugins should follow - perhaps an enhanced version of jsdoc? This way the API for every plugin could be published using the same structure and format, and multiple libraries could be combined and documented together. 4. In line with #3, some meta-data should be consistent across all plugins so a dynamic list of plugins could be built. Name, description, author, last updated, etc. 5. There should definitely be a ratings system or some way for the best plugins to quickly rise to the top. From a user perspective, there's nothing worse than a long list of optional modules like exists now. If a user is looking for a plugin, they might lack the experience or knowledge to create the functionality on their own. So how are they supposed to pick the best and most appropriate plugin to accomplish a task? Those "in the know" need to help them do it by making the best ones most visible. Just some thoughts. I would really like information or discussion on the documentation/API side of things, as I am currently looking for the best way to document a jQuery API. Matt Kruse ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] Search Results Filtering
> What I am wondering is if anyone has done any work towards a > multi-criteria filter using sliders or something. I am thinking of > something like the search filters at Kayak.com: > http://www.kayak.com/s/flights.jsp?searchid=aS1IhssBOi8vUIpJHKwo&comp > leted=true That's a pretty slick interface, but the sliders are really just a UI way to select a filter range. The issue is really two pieces - the core functionality of filtering by multiple columns and criteria, and the UI to enable it. I am nearing completion of my jquery.table.js plugin which will include multi-column filtering ability. It can filter using either an exact value to match, regular expression, or a custom function to call. It's built off my beta version here: http://www.javascripttoolbox.com/lib/table/ This, together with some UI widgets, should allow you to do what you need. I will certainly announce it here when it's ready and I'm seeking feedback. I don't think it would be a good idea to have a single plugin that provides both the core table functionality and various UI widgets for filter selection. They seem best suited for different plugins, IMO. Matt ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] tables - is this possible ?
> I have a table populated by a php/mysql script. I've created an excel export > option which changes the header to ms-excel and refreshes the current page > by making another call to the mysql db to fetch the data. > So I thought, the table data is already embedded in the current html page; > why make another call to the mysql db to fetch the same data again? is not > possible to use javascript to scan the current html page for and > and create an excel file on the fly therefore saving bandwith ? Yes, it's possible - I do it all the time. The benefit of this approach is that if you allow client-side sorting, filtering, column hiding, etc, the user can download exactly what they see because the manipulated client-side table is exactly what they want. The problem is it can't be done _purely_ client-side, because there is no way for js to generate a document of a specific mime type. Because of this, you need to write a simple server-side component in your language of choice that accepts a form value containing content to echo back. It slaps the excel mime type on it and returns it as-is, and the user's browser (hopefully) opens excel to handle the response. My solution is for an IE-only webapp, so the code isn't very cross-browser, but I suppose you could generalize the approach. I do these steps: 1) Get the outerHTML of the table 2) Create a hidden iframe and write out the table as part of it 3) Get a reference to the new table and manipulate it using standard dom to clean it into something that excel will like. For example, a) Convert text inputs into plain text b) Convert checkboxes into an "X" if checked, else blank c) Convert select lists into their selected option's visible text d) Convert links to plain text e) Replace images with their [alt] text f) Make sure borders are on g) Put nowrap on every cell h) etc... 4) Get the outerHTML of the resulting table and set it into a textarea in the iframe 5) Submit the iframe form to the server, which echoes back the submitted content with the excel mime type It all happens very quickly and the resulting Excel output matches exactly to what the user sees on screen. Depending on your data, you may need to scrub your tables more to get dates in the right formats that excel will parse correctly or to remove other markup that will ugly up the excel. Once written, though, it becomes pretty reusable on almost any table with very good results. With the power of jQuery, I imagine that 'cleaning' the table would be extremely trivial and the resulting js file would be pretty small. I would add it to my general table library (which I'm going to release as a jQuery plugin soon) but since it requires a server-side component I think it needs to be separate. Hope that helps! Matt ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
Re: [jQuery] $.show() improvement
BenjaminWiegand wrote:
>
> the jquery function show() is at the moment making objects visible by
> running
> elm.style.display = 'block';
> This works just fine for all block elements (div, etc.) but causes some
> problems when running on inline elements like links or other elements like
> table-cells.
> I think it'd be better to do this:
> elm.style.display = get_type(elm);
> function get_type(elm) {
> obj = document.createElement(elm.tagName);
> $('body').append(obj);
> type = $.curCSS(obj, 'display');
> $(obj).remove();
> return type;
> }
>
First, if you take that route, you should definitely cache the default
display type per tag name. Creating elements repeatedly just to find out
their display property is a waste.
Matt
--
View this message in context:
http://www.nabble.com/%24.show%28%29-improvement-tf3228045.html#a8972945
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?
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?
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?
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?
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?
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] 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=1607&replies=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--tf3218550.html#a8938358 Sent from the JQuery mailing list archive at Nabble.com. ___ jQuery mailing list discuss@jquery.com http://jquery.com/discuss/
