Related
I was full time java developers, now I also work on JavaScript. couple of years back when I started learning JavaScript, first library I tried was jquery like most of the people. But it made my life harder, and after sometime I started writing fairly large JavaScript app. It wasn't coming together for me using jquery. I had huge codebase without much of a structure. It was method blocks updating HTML blocks using selectors.
Then I tried mootools and obliviously as a java developer it appealed to me a lot. And I was able to write managible web apps having huge code base.
As per my understanding Mootools is not considered a preferred way to write JavaScript because it mimic conventional OO over default prototype-based OO language. So now to really understand javascript and desire of walking with the world, i decided to try other approaches, so again I turned back to jquery, and realise that only jquery is not enough. So started looking at current trending frameworks like backbone, spine, ember.js, sprouteCore. Strangly I found that these frameworks at their core tries to mimic conventional OO like mootools only by having constructors and creating a object of class and reusing this class object to create instance objects. So
Am I missing something?
Is mootools way really wrong?
Mootools project is very alive and releases new versions/features, but I don't
see many people talking about it on Internet, also there are no comparisions vs backbone/spine etc.
As per my understanding Mootools is not considered a preferred way to write JavaScript because it mimic conventional OO over default prototype-based OO language.
Where do you get that from? The greatest thing about javascript is that is so loosely typed (see what I did there) - you can write the same thing in a platitude of ways. There are also so many ways to abstract it and repackage it - and this applies from a simple new Array() vs [] to how you structure your app.
If you love JavaScript (or just know it and secretly hate it), you will be fine with MooTools. The API is mostly either native js or ES5 spec or - rarely - an extra utility that also feels 'natural'. The notable exception that stands out is Class. And the fact that you can abstract having to deal with prototypical inheritance by passing an object to a special constructor Type function that returns your instance is ... oh wait. It looks different but what it does pretty much sounds like normal javascript. Only easier -- why wouldn't you prefer that?
A lot is being made these days of the clientside MVC boom and this 'new way of developing apps'. Suddenly, jQuery folks were given the luxury of tap water! I have spoken to a lot of MooTools developers over this and (un)surprisingly discovered that most think MooTools rarely needs anything like that. I tend to agree with them. The only gaping hole is a view controller with templating but there are a fair few solutions.
The thing is, you cannot directly compare a MVC framework with MooTools, it is not the same. At all. You can compare the so called Model constructors vs Classes.
I have now spent a while researching various MVC framework solutions and patterns to see if our new app can be moulded into a 'best practice' shape.
Basically, I tried backbone.js (with and w/o a mootools adapter) and found it awkward to use after MooTools - it felt like a step back. When I say use I don't mean I can't use it but it feels awkward to extend and build on. I am sure it's just down to experience, though, have yet to read all the backbone patterns examples out there.
Typical issue I run into - wanted to have a special Model property that tells it to use localStorage to fetch/save. Not obvious how - examples tend to show you can either route Backbone.sync to one or the other but not both at the same time. I had to actually decorate the function and extend it, keeping the original referenced in case the model did not require localStorage. NOT the best / most obvious pattern to maintain and leaves me dependent on their changes not breaking my code.
In MooTools, I would have just extended my Model class and could have defined a custom Class Mutator property (like Binds or Implements). Done. Write what you know, they say, and not for nothing...
Another issue - it's tightly coupled with data and you cannot reuse models like classes - eg, a User model loads a user and renders through a User Edit view. You then want to create a new customer and suddenly, you cannot reuse the old object that easily and just render the same view but with empty values. I think it will also be down to inexperience on my part or bad architecture.
Ember.js I found slightly more moo-ish as an interface though It did not quite click either. Frankly, backbone was less trouble to setup.
There are other attempts. Composer is one - once again for mootools but it tries too hard to be backbone and is written by people that are relatively new to the framework so I would not call it mature. Knockout etc etc. There's a new one every day, literally.
Garrick Cheung released a framework called Neuro which has huge potential.
I wrote Epitome - a full MVP implementation based upon classes and events and wrapped in AMD modules, feel free to check it out. It also comes with a builder, documentation builder and many little goodies to get you started.
SeanMonstar released Shipyard, which is used by Mozilla Flight Deck - http://seanmonstar.github.com/Shipyard/. Whereas it's not native mootools, it's mootools-ish with mootools class etc - only w/o extending natives, so a great alternative.
BTW, try irc.freenode.net #mootools or the mail list and you will always get a good answer.
Anyway, enough on MVC. The points about MooTools have been made countless of times. Haters will be haters. Those that love it don't look back. If you are a programmer from an OOP background or are looking for something that renders itself well to patterns, do yourself a favour and stick with it. Exciting times are ahead. Roadmap for 1.5: AMD, for 2.0 (aka, Prime) Host object prototyping optional. These have been the two biggest talking-down points in the eyes of critics. No more 'dirty' prototypes so people can get on with using for ... in loops incorrectly on non-objects and without hasOwnProperty checks. Anyway...
Other things to worry about may be of importance. Like, the size of the 'community'. I think having a healthy community is a great thing but even if you look at jquery, the amount of actual contributors vs users is low. The ratio of quality CODE vs good looking effects is bad. The plugins you can use - a lot are not well written or dead and unsupported. When you draw the line, it's a lot less glamorous than you'd think!
I am not saying that mootools or other frameworks don't have these problems. It is fair to say MooTools people and especially the core devs are fairly private and less vocal about what they do. It may send the wrong impressions, I don't know. It certainly is no jQuery.
Ultimately - if you have the resources and the know-how, use what works best and what will scale. There are even these that use coffeescript and swear by it. Who am I to judge...
In the interests of full disclosure - you will find it MUCH harder to find a decent mootools dev when you recruit. Cannot be ignored...
I'm new to javascript (functional programming is okay for me, though) and I am wondering how jQuery got away with some of the design decisions they made. Is it just too much work to fix now or what? For instance, there seems use of strange symbols in strings when accessing elements in the DOM or weird function definitions for $, that are forcing me to check references every other time I want to get some basic data.
Can someone point me to a learning source where I can learn all of these nuances of jQuery (jQuery's examples just don't cut it, they're too spread out)? Maybe someone has a super good reference site/pdf for jQuery?
Thanks
EDIT:
And as a side point, in regards for learning, why the heck is the entire jquery.js file collapsed onto a single line? It is unreadable.
Try reading jQuery in Action, it's a really good book to get started with jQuery. Next to that you can also watch examples on jquery.com, but I did prefer the book to get started.
For JavaScript basics you can try w3schools.
In the beginning I had the same problem with the $ functions etc, but after I read the book it became all clear to me, and to be honest, I wouldn't use plain JavaScript without jQuery anymore for DOM manipulation.
For your edit: you have a compressed (or minified) version, which has all code on 1 line, most spaces removed etc to keep it small and a readable version. Both files can be found on the download page from jQuery.
The strange symbols you refer to are mostly CSS selectors, the standard way to address elements on the web. jQuery could've come up with its own conventions, but decided to go with what was standard and best known.
jQuery itself is surprisingly consistent. Once you wrap your head around the jQuery style you barely have to consult the documentation; things just work as you'd think they should.
The jQuery documentation is actually quite good and includes an example with every command. It also has a large user base, so a quick search will generally answer any questions you have. Google is your friend.
I'm guessing the issue is not jQuery, but a difference in javascript style compared to languages you're more familiar with. Watch Crockford's "Javascript: The Good Parts" for a reasonable introduction to good javascript style.
http://video.yahoo.com/watch/630959/2974197
Also check out Dustin Diaz's posts, I found his early screencasts where he'd build an app and talk about what he was doing very educational:
http://www.dustindiaz.com/
I think jqapi.com is a more useful jQuery API documentation resource than jquery.com
Compressed javascript uses less bandwidth to load up, and decreases load times. Use js beautifier to expand it.
jQuery is the greatest thing to happen to the DOM API, which is just awful to deal with. It also handles cross-browser issues and older versions, giving them functionality they otherwise wouldn't have.
The strange symbols in selectors are from CSS, not the fault of jQuery. The selectors API is now being built into browsers, so it's worth it to understand what they mean.
As for a functional programmer every imperative language is probably a failure in your eyes and mindbending to capture, with javascript and jquery probably on top of that list. They both have side effects all over. Jquery is really about manipulating the DOM so the side effects are the means and the goal, as opposed to proper functional programming.
If you're young enough you can still make the mind switch though :-)
start on jQuery Docs Main page...
You could try some other JavaScript frameworks to find out which one suits you best.
Although jQuery is pretty cool for most people, it's not the holy grail for everyone.
Maybe it's just not "your thing".
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I manage a group of programmers. I do value my employees opinion but lately we've been divided as to which framework to use on web projects.
I personally favor MooTools, but some of my team seems to want to migrate to jQuery because it is more widely adopted. That by itself is not enough for me to allow a migration.
I have used both jQuery and MooTools. This particular essay tends to reflect how I feel about both frameworks. jQuery is great for DOM Manipulation, but seem to be limited to helping you do that.
Feature wise, both jQuery and MooTools allow for easy DOM Selection and Manipulation:
// jQuery
$('#someContainer div[class~=dialog]')
.css('border', '2px solid red')
.addClass('critical');
// MooTools
$('#someContainer div[class~=dialog]')
.setStyle('border', '2px solid red')
.addClass('critical');
Both jQuery and MooTools allow for easy AJAX:
// jQuery
$('#someContainer div[class~=dialog]')
.load('/DialogContent.html');
// MooTools (Using shorthand notation, you can also use Request.HTML)
$('#someContainer div[class~=dialog]')
.load('/DialogContent.html');
Both jQuery and MooTools allow for easy DOM Animation:
// jQuery
$('#someContainer div[class~=dialog]')
.animate({opacity: 1}, 500);
// MooTools (Using shorthand notation, you can also use Fx.Tween).
$('#someContainer div[class~=dialog]')
.set('tween', {duration: 500})
.tween('opacity', 1);
jQuery offers the following extras:
Large community of supporters
Plugin Repository
Integration with Microsoft's ASP.NET and VisualStudio
Used by Microsoft, Google and others
MooTools offers the following extras:
Object Oriented Framework with Classic OOP emulation for JS
Extended native objects
Higher consistency between browsers for native functions support.
More easy code reuse
Used by The World Wide Web Consortium, Palm and others.
Given that, it seems that MooTools does everything jQuery does and more (some things I cannot do in jQuery and I can in MooTools) but jQuery has a smaller learning curve.
So the question is, why did you or your team choose jQuery over another JavaScript framework?
Note: While I know and admit jQuery is a great framework, there are other options around and I'm trying to take a decision as to why jQuery should be our choice versus what we use right now (MooTools)?
That's an odd question... I get the impression that...
you are very familiar with mootools and take full advantage of its OOP model, making your code easier to manage and support already.
you realise that jQuery's purpose is somewhat different and tweaked towards DOM manipulation and AJAX and that mootools does do everything jQuery does AND then some.
sounds as if you do not need to be using much in the way of 3-rd party plugins which makes the points of jQuery's popularity and support a bit less important.
Bottom line, is it the hype? jQuery is turning into one of these magical marketing buzzwords like 'AJAX', .NET and Web 2.0 — which is great for them but why do you need to justify staying with the framework that works so well for you? There's also the business considerations which I imagine will cover things like:
framework longevity, or is mootools likely to go away in the face of the ever growing jQuery — very doubtful, seeing as they just released 1.3 beta 1 and have 2.0 is in the pipelines for release by the end of the year.
cost of staff and their training (I imagine finding mootools programmers will be more difficult than these that slap jquery on their C.V / resume).
time (and cost) taken to maintain and extend your systems under each framework given your resources.
Both frameworks are great but I believe your interests are best served in staying with mootools.
Personally, jQuery does exactly what I need.
I try to do most of my stuff in my server-side code, which is well structured: it has proper OOP, layers, and an MVC architecture. When I need to do something with Javascript, I have found (so far) that jQuery has what I need. Frankly, that falls into three categories:
Simple DOM manipulation, usually showing/hiding stuff without hitting the server.
Ajax calls, nuff said.
UI perks, including modal popups, animations, fading transitions from/to hidden/shown. I am a hardcore backend coding guy, and I suck at UI stuff. I really like that jQuery lets me programmatically make stuff that looks appealing.
On top of that, the jQuery plugin library is huge, and I've found quite a few libraries that simplify my client-side work. Good stuff.
MooTools introduces OO thinking, which is nice, but not what I need. I want to keep my structuredness all on the backend, and not have to introduce that thinking to my client-side code. To me, client-side code is a very small piece of the emphasis and thinking about it from a Class-point-of-view is way overkill, and way more work. I feel like I'd be building two applications instead of one if I were to use what I'd think would be best practices for MooToools.
I think that sums up why its so popular, especially around here. By and large, we're backend code-y type people, and jQuery lets us make an appealing UI programmatically, and lets us focus on our backend core.
I'm not a fan of imposing classical object orientation onto JavaScript. There are so many ways to do it that one JavaScript Programmer might be using Base2 for OO, while another uses Prototype or Moo or JS.Class or Joose. Resig deliberately decided not to add classes to jQuery, and that has encouraged people to find more native JavaScript ways to solve problems.
As a result, it's easier for me to read JavaScript other jQuery writers write, and to write jQuery code that's easier for others to read. I typically don't try to emulate class OOP in JavaScript. Instead, I create objects on the fly and pass them around, and I have lots of arrays of objects. It's so easy to understand that I've even found myself carrying that thinking over to OOP languages!
For all I know Moo may very well have caught up with jQuery or surpassed it. But I can't spend my time tracking the 6 or 7 great JavaScript libraries to see which horse is ahead.
I think it's was largely a matter of timing. When masses of programmers jumped into AJAX, jQuery was the hot new cool thing that solved their problems.
Other libraries have largely caught up. YUI, ExtJS, Dojo, Moo--they're all great. But I can't use them all.
I work hard enough trying to figure out the ramifications of the new features of the library I do use. For instance, jQuery added Live events as of 1.3. This actually let me cut code from many pages. Does Moo offer that now too, and how am I supposed to know it happened, if it did?
I'm sure Moo is awesome. I'd love to have the time to learn it. But have you looked at Dojo? I had to use it on one project and found that it had pulled in most of the great ideas from jQuery as well. And it has pubsub and good support for Comet.
I sympathize with you. But your programmers are talking sense. Learning jQuery is good for their careers, and there are more books, examples, and fellow programmers to ask for help if they use jQuery.
If you decide to go jQuery after all, think hard before deciding whether to tack on an OO library. There are some cool ones (like JS.Class or Joose), but taking that step means isolating yourself from how most JavaScript programmers code.
I've been asking myself this very same question for a while now, by means of just trying to wrap my head around the argument. And with ever discussion I read, the overwhelming response has been "More widely adopted - therefore better".
I am one who uses both extensively. JQuery at work (adopted because it was "more widely adopted") and Mootools on personal projects. As a result, I constantly find myself feeling crippled when using JQuery; Be it with JSON support, element creation, event handling... and so on. At work, I find myself writing chains 75 events long... and I feel dirty as a result.
My main overall beef with JQuery though, is that there's a lack of consistency or practice where plug-ins and 3rd party developers are concerned. The anecdotal "More plug-ins are available" really doesn't help me when there's no consistency between the plug-ins, structurally or otherwise. It took me several weeks to learn the "accepted" plug-in model, and even then, I've adapted my own pragmatic style into it, as I find error and inefficiency within the current structures. It can be said that it's a 'Pro' that anyone can jump in and start JQuerying it up. However, I am more inclined to call that a 'Con', in that you will see 30 different ways to accomplish something, and it's difficult to pin an accepted standard.
So what does it mean to "Know JQuery", Does it mean you know how to rock a little .hide().show().fadeIn().fadeOut()?
When I have to get gangster on my JS at work, I miss me some Mootools. I mean no Native JSON support? C'mon......
In response to the "Widely adopted" response, we all know OSCommerce is the most "Widely Adopted" shopping cart, and we all know what a pile of shit that is. I'm in no way comparing JQuery to OSCommerce. I'm simply pointing out the faulty of "Widely Adopted" response.
As for plugins, the App store for apple has what... 100k apps? 50,000 are fart apps. Sure there's a lot of plugins to JQuery, but the ratio of trash to worth-while is great.
jQuery gives you access to crisp and concise functional programming methods. Since the release of method chaining in (LINQ) in C# 3.0 this works very well for .NET programmers. So the flow from one language to the next is easy. To be able to query the DOM for an object, or a list of objects, works much better for us. It is jQuery's selection power first that makes it so attractive, then the extendability of it, and of course all the built in features that come with it are nice. Also, the community behind is wonderful in that I first look to see if someone else did something and then attempt to do it myself if a solution was not found. And last...but certainly not least...the fact that Microsoft is going to include in in Visual Studio 10 and support it is great. Moo Tools, Prototype, etc. just can't compete with all of the above.
JS frameworks are so much alike, anyway. If you've been working with mootools for some time, stick to it. Knowing your framework is much more important than choosing one because of this or that.
In my opinion, mootools is better for advanced javascript programmers, while jquery is better for non-javascript programmers. That's what I think after reading both documentations, mind you, I didn't use any of them. jQuery lacks support for the core of javascript, function binding, object cloning, thread stacking, to name a few.
jQuery, like any framework, does what it does and if it doesn't fit your needs you should use something else. I don't use jQuery to do complicated programming in javascript, I use it because it makes DOM manipulation and CSS3 style stuff simple and 95% of the time that is what I need.
I have not looked at MooTools in a while either. But here are my points for JQuery:
Consistent programming model (there is a JQuery way that works)
Excellent documentation. When I started JQuery had the best documentation out there.
Extensive 3rd party plugings
Microsoft support -- I am an asp.net developer, this helps ease clients minds. Plus it ships with my tools now.
Lots of getting started guides.
JQuery's website looks nicer than MooTool's web site. I'm sorry that matters, but it does. Remember, many of these tools need to appeal to designers as well as developers.
YAGNI.
Yes, it's kinda out of place here, but that's the main reason jQuery has a larger base than MooTools. All those extras MooTools brings to the table are nice, but YAGNI.
It's not about best, it's about satisficing -- finding the adequate solution to the problem at hand. jQuery is easy to use, its primary aim is DOM manipulation. Since 95% of the people picking up javascript are doing so just to manipulate the DOM, there's no point in going through the longer MooTools learning curve. MooTools simply doesn't bring anything to the table for them that jQuery doesn't deliver with less effort.
MooTools demands more from you before you use it, jQuery lets you throw something together quickly. If you start writing large, heavy-duty js apps, you might run into some of the drawbacks of that approach, but again 95% of the folks writing js don't do that, so those things don't matter to them. They use a server-side language for the heavy-lifting and javascript for the DOM.
For that matter, they may not matter to your team, either. To take you through the lists, point by point (jQuery first):
Large community of supporters -- only slightly relevant to the project. Of more relevance to the team personally, because it speaks to life after you. If misfortune strikes (please, God, no) and your firm is gone, jQuery gets them more jobs than MooTools.
Plugin Repository -- very relevant, as it helps keep from reinventing the wheel.
Integration with Microsoft's ASP.NET and VisualStudio -- very relevant if you're a .NET shop. In fact, this alone should be the reason to switch if you do .NET.
Used by Microsoft, Google and others -- who cares?
Now for the MooTools list:
Object Oriented Framework with Classic OOP emulation for JS -- irrelevant, unless the nature of your projects makes that a plus. I don't know what you're building, but for web shops, this is only rarely relevant. Most web shops don't have enough code to make this a plus.
Extended native objects -- again irrelevant for most web shops
Higher consistency between browsers for native functions support. -- Relevant
More easy code reuse -- This conflicts a little with the jQuery advantage of a large repository. A large repository by itself speaks to reusing code. I suspect you're using a narrow definition of code reuse, here, that may not be relevant. I've reused a lot of the jQuery code I've built, as well as MT code.
Used by The World Wide Web Consortium, Palm and others. -- Irrelevant. The only relevance about who else is using what is if you're wanting a job there. There's more relevance in how many shops use it than in any particular shop using it.
There is no One True Way to approach javascript coding. Get your bias out of the way, and sit down with your team and get their bias out of the way as well. Talk turkey about the specific types of projects you're undertaking (and want to undertake) and the strengths of each library as applied to those cases. (How they might handle other cases doesn't matter, because those other cases don't exist.) You should arrive at a consensus from that.
(YAGNI = You Ain't Gonna Need It, if I need to explain it.)
I choose to use jQuery as our default UI library precisely because it does not extend or otherwise monkeypatch native objects, unlike prototype.js or mootools. Kick in the documentation angle and there really is no question as to which framework to use.
You kinda say it yourself:
Given that, it seems that MooTools does everything jQuery does and more (some things I cannot do in jQuery and I can in MooTools) but jQuery has a smaller learning curve.
Most of the extra stuff that MooTools does is stuff that we just don't need.
As you say yourself jQuery is easier to learn, which is actually more important for most people when choosing a framework.
What I DON'T need in JavaScript is definetely OOP and some ugly object emulation.
Last time I checked MooTools (maybe 1,5 years ago :-), it had browser incompatibilities with manipulating multiple select.
So jQuery is completely looks OK to me.
Not only is jQuery a nice library, but its creator, John Resig, also has some street cred as the author of Pro Javascript Techniques.
We have 2-3 copies of this book around our office.
jQuery is small (intentionally so) but can have functionality added to it through plugins.
The thing that made my experience with mootools a rather unpleasant one was the documentation and the stability of the API:
I simply wasn't able to find a documentation that related to the mootools-Version in use. Won't be that much of a problem if the API defined was stable. But due to some functions that disappeared in the newer Version (a ChangeLog was found after hours of searching) a migration wasn't possible either. After that, mootools was out of the race for me.
Like many others, I don't want to introduce class-based OOP into simple user-interface manipulations. Thats what I use jQuery for: not so complicated user-interface stuff.
When I have to build rich browser-side applications, I'd always switch to the big solutions (ExtJS, YUI, qooxdoo) that offer a variety of ready to use widgets.
Larger User Community and more wide-spread adoption makes a big difference when comparing tools/libraries that offer similar functionality and concepts. Larger community means more support, more examples, more good ideas, and more reusable code snippets, which is especially important when you're working on a rare scenario -- more likely someone else has encountered it before.
Secondly, in benchmarks I've seen, jQuery is faster than MooTools.
I also really like their emphasis on keeping a small core and adding functionality through plugins. Prevents the core library from getting really big and unwieldy.
I've never used MooTools personally but I have no doubt that its a fantastic library that offers some acceptable equivalent to most any jQuery feature or concept, but point #1 takes the cake for me.
Another reason: It's easier to sell jquery to management. Doing internal, asp.net based developement in a corporate environment the magic words are "it's supported by Visual Studio".
For one thing, that's not all it does. There are quite a few other features as well. For another, not everyone uses it. But I don't want to interrupt a good rant.
I have to second a lot of the answers...great documentation and community support is crucial. I used to hate js programming and would avoid it like the plauge, but now I've completely embraced it because of jquery and the quick learning curve.
It's not always about who has the best technology!
Mootools, does not function properly or does not function at all when using jquery prototype etc. Agreed there is absolutely no reason to use them simultaneously, but once in a while they do land up on the same page (ex. plugins, slideshows, widgets etc) and things stop working.
That in itself is unacceptable. So all props for jquery to not create unnecessary headaches!
Why did people start using fax machines? At a certain point the benefit increases exponentially.
I have a date picker library written for MooTools that I want to port to Prototype. It's looking to be a long arduous task and I'm wondering if anyone has seen or written guides on the differences between the two. A translation dictionary of sorts, where I can look up a Moo function and see the prototype equivalent, or vise-versa.
The same would also be nice for jQuery to Prototype.
I've wanted to find something like this for a while. It got so I wanted to make my own and a few weeks ago I started ArtLung Rosetta, an effort to have a "Hello World" page with various techniques in many major libraries. It's a work in progress.
However, a few weeks ago I came across this EXCELLENT resource by Matthias Schütz. The JavaScript Library Comparison Matrix. That reference site has syntax comparisons with links to relevant documentation for: DOM Ready, DOM Basics, DOM Filtering, DOM Manipulation, Effects, Transitions, Events, Custom Functions, Ajax, and Classes.
I enjoy comparing the various libraries approaches -- I find I learn a great deal about the libraries themselves, and my own programming style and how I can improve it by carrying out the same task in multiple frameworks.
I'll take a stab at this. If you haven't found any resources after a thorough google search, I'd say you're stuck with just opening up the API's of each and just consulting them back and forth and looking at the examples.
I'm actually going from Prototype to jQuery on a project right now. (Aside: I'm much happier with jQuery having used both for awhile.) My basic work flow is just referencing the API as needed.
I would be surprised if there was such a mapping of one to the other though. In either framework, there are many ways of doing any given task, and on top of that they work in different and important ways. Sure there's some 1:1 correspondence like "addClass" vs. "addClassName", but jQuery DOM manipulation typically works on sets of elements (which may be just a set of 1) while Prototype works on single elements (which may be wrapped by an each statement to work with sets).
Fortunately, both have pretty good and easy to use/reference API's.
Good luck.
As mentioned by Keith, there is no a 1:1 correspondance between the features provided by libraries.
Even more importantly: different frameworks require different mindsets. It's very little about renaming functions, it's more about writing the code in the style of another framework. Thinking like "What would be the jQuery way of doing this?"
If you're porting code from framework A to B and don't know B very well, you can easily end up with with something quite ugly.
I can't think of any guides on converting. But there have been a few Library1 versus Library2 blog posts where libraries are compared and contrasted. Probably worth hunting those down and reading them.
Duplicate: Which Javascript framework (jQuery vs Dojo vs … )?
I am totally new to JavaScript, but I want to implement Ajax features into my website. Which JS framework should I learn? Please recommend or which one you are using and why you use it?
jQuery is currently extremely popular, so you're probably going to have the most luck finding recent tutorials/plugins/etc for it, as opposed to one of the other frameworks. That's probably a fairly good selling-point from the perspective of someone new to this.
Microsoft apparently blessed jQuery, so for now that's your best bet.
I'm currently writing a paper on JavaScript frameworks. After all the research I've done so far, I can tell you this...
Seriously, nobody can tell you which framework is best for you. There's only one way to find out: try playing around with all the different libraries you're considering. It's a matter of personal preference.
See this excellent JavaScript Library Overview, a presentation by John Resig (who happens to be the lead developer of jQuery). It contains small code samples for all the listed frameworks. After viewing those, you'll probably know which framework to choose, depending on which coding style you prefer.
Also, this SO topic might be of interest.
Jquery is probably the best of the lot, it actually lets you "do more, write less"
One more for Jquery..Awesome plugins!!
Built in intellisense for jQuery in VS2008 (sp1 I think?) was one consideration for us, but essentially we've played with mootools, prototype, scriptaculous and jquery, and have found jquery to be the easiest for us all to understand/support.
We have a mixed team here, and even our business logic guys can pickup the logic/approach in jquery.
We also use telerik controls, and they've now announced more support for jquery - it certainly seems its star is in the ascension.
Try all of them, but if you're from a .net background, I think it's the logical choice at the moment.
I use jQuery now because it is easy and has lots of features. Before I was using prototype and scriptaculous.
I noticed Dojo wasn't included on your list. It's a framework that's geared to heavy-weight AJAXified pages.
http://dojotoolkit.org/
That said, JQuery appears to have the most momentum at the moment, and other frameworks (like Dojo) are working on putting more JQuery-like functionality into their product, so I would recommend learning that.
Im having a really good time with jQuery myself. Thers lots of good documentation and tutorials for it, which is excellent if your new to Javascript.
If its only the ajax features your after I recommend checking out http://docs.jquery.com/Ajax . Also the tutorials at Themeforest is really brilliant. For example the jquery tutorial for absolute beginners day 10 is showing you the basics of jQuery + Ajax.
FORK Ajax. It does the job well, and it's very small (5KB minified) and simple.
I'll plug Mootools. Of course the reason anyone prefers any of these over another is "I started using XYZ first."
jQuery is my go-to framework of choice, but you really have to look at each ones' strengths and see how they align with your project
The important thing is, use a framework -- really any framework. The benefits of using a framework, no matter which one, are so enormous. The best ones get rid of all or most of the cross-browser headaches you are bound to experience.
The best thing to consider is what you want the framework for. jQuery was designed to make manipulating the DOM easier. So if that is the main focus of what you want to be doing, then great. It is a super rad framework and it is really is amazingly natural and easy to pick up.
That having been said, it is worth considering what the others have to offer. Other frameworks like prototype and mootools are most interested in turning javascript into a more powerful programming language with richer object oriented programming capabilities and functionality for arrays, strings and numbers. I don't know enough to be able to compare/contrast prototype and mootools, but maybe someone else could fill in on that.
This is a great article that explains the difference between mootools and jquery - jqueryvsmootools.com/
The good news is that you don't necessarily have to decide. Although you might occasionally come up with bugs, you should be able to use jQuery with either mootools or prototype (see here). Basically just call jQuery.noConflict(); before any script on which you want to use jQuery and everything should work just fine. This allows you to use jQuery for all of it's slick DOM manipulation and rad UI library while also giving access to a more powerful framework when that is what you need.
Please let me know if I've missed anything here and I hope this helps.
When I was new to JavaScript, after a week I found out that life is much easier with a framework. Anyway, I did not even knew, what exactly they are for; I've got some glue about $() that it's a smart replacement for window.getElementById(), and I assumed that there are some other comfortable methods for other purposes, like AJAX request.
I did not wanted to spend lot of time on learning a framework, so I was decided that I will choose that which I fall in love first sight. Then I was spending about a whole month with googling. I have not missed any of the "big names", but I dropped them soon. The main reason of the dissatisfaction was their site, the documentation: after reading a whole page of text, I was yet as dumb as before. What is it for? What they do? What is the input, what is the aim, what is the output?
Then, I found DOMAssistant. It's small, perfect, and well-documented. Just take a look on the first paragraph of the opening page, it's a totally clear definition of the JS framework:
What is DOMAssistant?
The idea of DOMAssistant is to provide
a simpler and more consistent way to
script against the Document Object
Model (DOM) in web browsers. The idea
is that everything starts with the
element(s) in question, selected
through id or CSS selectors, and then
perform various methods on it, such as
adding or removing classes, events
etc.
So, I say, if you finally choose another, more fashionable framework, DOMAssistant is a must-to-see. And if you have no need for animated flying windows, it's also a good choice.