Poll: Suggestions please, which JavaScript library?
61 comments
It really depends on whether you like Javascript or not, and whether or not your new library-based code has to play nicely with non-library javascript.
jQuery is an interesting language. But I feel like it's no more "javascript" than C is assembly. It uses a lot of conventions and syntactic sugar that is not standard in the language. It's a cool and elegant, but there's a learning curve at both ends; first, you need to learn it, and then it becomes so habitual that you forget how to write "regular" javascript.
YUI, on the other hand, feels a bit more like plain old JS, which some people like and some people don't. The main problem with YUI is a lack of overall consistency in naming and whatnot. YUI 3 is coming out soon-ish, and addresses a lot of that stuff quite nicely. YUI does a really good job of not cluttering up your environment with too much gargbage--everything is under one global YAHOO object, so it's a friendly neighbor.
Avoid prototype at all costs. It monkeys around with the core object types, and adds scores of globals, which pretty much ensures that, unless ALL of your code uses prototype, and always will, you'll get unexpected behavior in some cases.
YUI was built first and foremost for use at Yahoo. It'd be hard to find a library that's more play-tested or scrutinized for performance than that. Personally, I find the core YUI libs a lot more useful than the widgets. They tend to be a bit over generalized in a lot of cases, and I can usually get better results by rolling my own.
Disclaimer: I'm a webdev at Yahoo, and I've been using YUI since its pre-OSS days.
jQuery is an interesting language. But I feel like it's no more "javascript" than C is assembly. It uses a lot of conventions and syntactic sugar that is not standard in the language. It's a cool and elegant, but there's a learning curve at both ends; first, you need to learn it, and then it becomes so habitual that you forget how to write "regular" javascript.
YUI, on the other hand, feels a bit more like plain old JS, which some people like and some people don't. The main problem with YUI is a lack of overall consistency in naming and whatnot. YUI 3 is coming out soon-ish, and addresses a lot of that stuff quite nicely. YUI does a really good job of not cluttering up your environment with too much gargbage--everything is under one global YAHOO object, so it's a friendly neighbor.
Avoid prototype at all costs. It monkeys around with the core object types, and adds scores of globals, which pretty much ensures that, unless ALL of your code uses prototype, and always will, you'll get unexpected behavior in some cases.
YUI was built first and foremost for use at Yahoo. It'd be hard to find a library that's more play-tested or scrutinized for performance than that. Personally, I find the core YUI libs a lot more useful than the widgets. They tend to be a bit over generalized in a lot of cases, and I can usually get better results by rolling my own.
Disclaimer: I'm a webdev at Yahoo, and I've been using YUI since its pre-OSS days.
I like both Javascript and jQuery. In what way is jQuery not "javascript"? To me, it feels as though jQuery really embraces js much more so than some other libs that try to pretend that it's java or some other lang.
Well, I don't feel like YUI tries to make JS into Java. The goal of YUI is to add some extra APIs under a single global object, and pretty much let you write your code however you want. It's a library that quietly does nothing if you don't use it, and it doesn't ask you to change how you do things.
jQuery is, of course, Javascript. John Resig didn't invent functional closures or chaining. But it seems like jQuery is designed to change the way that you write Javascript. It even says so on http://jquery.com/ It's a set of conventions, and they're not standard. I'm not saying that they're bad (in fact, I really like the jQuery style and think it's very elegant.) But there's a learning curve there, and not every javascripter is a programming language geek who would get off on learning a new style.
jQuery is, of course, Javascript. John Resig didn't invent functional closures or chaining. But it seems like jQuery is designed to change the way that you write Javascript. It even says so on http://jquery.com/ It's a set of conventions, and they're not standard. I'm not saying that they're bad (in fact, I really like the jQuery style and think it's very elegant.) But there's a learning curve there, and not every javascripter is a programming language geek who would get off on learning a new style.
On the server side (Helma/Rhino) I do a lot of functional-style JavaScript anyway, so jQuery feels very natural to me. It does have a lot of sugar, but playing with the DOM needs it. Crockford described the DOM as having been written by people who like Java[-esque things] and hold JavaScript and its style in contempt. I can't speak to the history, but the actual W3C DOM standards are such that that could certainly be true. The W3C DOM is not plain old JS. The W3C DOM is a verbose, clumsy API direct-ported from (essentially) Java into JavaScript.
> then it becomes so habitual that you forget how to write "regular" javascript.
I wish that were true. Unfortunately, I still have to drop back to W3C DOM for performance often enough. For a recent feature I added, 6 lines of jQuery becomes 24 lines of JavaScript, but the speed goes from unacceptable to acceptable. (What am I doing that jQuery's not fast enough? In this case keystroke-by-keystroke search and manipulation of a 6000-cell table.)
> then it becomes so habitual that you forget how to write "regular" javascript.
I wish that were true. Unfortunately, I still have to drop back to W3C DOM for performance often enough. For a recent feature I added, 6 lines of jQuery becomes 24 lines of JavaScript, but the speed goes from unacceptable to acceptable. (What am I doing that jQuery's not fast enough? In this case keystroke-by-keystroke search and manipulation of a 6000-cell table.)
> 6 lines of jQuery becomes 24 lines of JavaScript, but the speed goes from unacceptable to acceptable
Have you tried JQuery 1.2.6 yet? I've also had to drop down to raw DOM for performance, but I've found that many features that were unacceptably slow with 1.2.3 (mousemove events, $.map) have gotten quite usable. Events no longer copy the whole event object, map is linear time instead of quadratic, and I've heard $.extend got a major speed boost which'll speed up construction of all jQuery objects.
Have you tried JQuery 1.2.6 yet? I've also had to drop down to raw DOM for performance, but I've found that many features that were unacceptably slow with 1.2.3 (mousemove events, $.map) have gotten quite usable. Events no longer copy the whole event object, map is linear time instead of quadratic, and I've heard $.extend got a major speed boost which'll speed up construction of all jQuery objects.
Map was quadratic before?! It seems like it would take deliberate effort to make it anything other than linear.
$.map has an interesting quirk in its spec: it flattens returned arrays into the result. This was implemented by calling concat() with each result, but concat creates a new array for its return value. So each iteration was creating a new array and copying over the previous values, which makes for a quadratic runtime in most JS runtimes.
(Curiously, in the benchmarks folks did in the Reddit thread, it looked like Firefox was not quadratic - which implies that Firefox either has some clever optimizations going on or does crazy things with concat().)
(Curiously, in the benchmarks folks did in the Reddit thread, it looked like Firefox was not quadratic - which implies that Firefox either has some clever optimizations going on or does crazy things with concat().)
hey, I'm looking for people who are interested in server side javascript and jquery to help give some input on a framework I'm working on. The framework is about a month old but the core concept is already there.
if you or anyone is interested send me a email (tunde.ashafa AT gmail)
if you or anyone is interested send me a email (tunde.ashafa AT gmail)
> then it becomes so habitual that you forget how to write "regular" javascript.
This is high praise indeed, and suggests to me that a) the standard DOM APIs are poorly designed, and b) that jQuery’s API is very well designed, and meshes much better with the language.
This is high praise indeed, and suggests to me that a) the standard DOM APIs are poorly designed, and b) that jQuery’s API is very well designed, and meshes much better with the language.
Yeah, it was intended as such :)
As I write most of my Javascript at Yahoo, and we can assume that Yahoo webdevs know Javascript, but not necessarily jQuery, YUI is a much better choice. (Just addressing the language conventions, not nec. the library implementation.)
As I write most of my Javascript at Yahoo, and we can assume that Yahoo webdevs know Javascript, but not necessarily jQuery, YUI is a much better choice. (Just addressing the language conventions, not nec. the library implementation.)
> "jQuery is an interesting language. But I feel like it's no more "javascript" than C is assembly."
To me, jQuery feels like a better javascript than javascript itself. Manipulating the DOM with plain old javascript is what feels like using C. All the quirky function names, all the weird browser variance. It's like being in college again, trying to get C++ I wrote in Windows to compile in Linux.
While jQuery is merely a library at the moment, I have to wonder if there would be any drastic speed improvement (other than negating the download time) if someone implemented the jQuery API as a browser plugin (or just tacked it on to the JS spec itself). I'm not saying that this would have any immediate practical application (since no one installs plugins anyway), but the idea sounds just silly enough to be interesting at least.
To me, jQuery feels like a better javascript than javascript itself. Manipulating the DOM with plain old javascript is what feels like using C. All the quirky function names, all the weird browser variance. It's like being in college again, trying to get C++ I wrote in Windows to compile in Linux.
While jQuery is merely a library at the moment, I have to wonder if there would be any drastic speed improvement (other than negating the download time) if someone implemented the jQuery API as a browser plugin (or just tacked it on to the JS spec itself). I'm not saying that this would have any immediate practical application (since no one installs plugins anyway), but the idea sounds just silly enough to be interesting at least.
+1 for YUI. The Yahoo team has done an astonishingly good job of demonstrating what javascript looks like if you treat it as a language worth using well, as opposed to forcing it to pretend it's something it's not (eg. prototype). I've been working with it for a year and a half, recently migrated a substantial Rails app from Prototype/Scriptaculous, and couldn't be happier.
I use Dean Edwards's base2. I like it because it is very simple, and because it adheres to standards; that is, rather than creating a map and a forEach of its own, with its own semantics, it implements them according to the Javascript standard (or proposals, don't recall if they have yet been adopted) for browsers that don't yet support them natively (anything but Mozilla, I think). It also cleans up DOM manipulation so that you can use standards-compliant methods and it will work on non-compliant browsers (all the way back to IE5).
Similarly, for DOM querying, it implements the W3 Selectors API rather than reinventing the wheel.
I really like this approach. base2 doesn't provide anything in the way of widgets (though I think there may be some code along these lines in the Subversion repository, implementing some of the HTML5 components) -- for most of what I do, widgets aren't available anyway or would need to be extended, so I end up writing my own. And it's easy enough to use a YUI or other widget with base2 when it makes more sense.
For animation, I've used animation.js and found it simple and fast.
Similarly, for DOM querying, it implements the W3 Selectors API rather than reinventing the wheel.
I really like this approach. base2 doesn't provide anything in the way of widgets (though I think there may be some code along these lines in the Subversion repository, implementing some of the HTML5 components) -- for most of what I do, widgets aren't available anyway or would need to be extended, so I end up writing my own. And it's easy enough to use a YUI or other widget with base2 when it makes more sense.
For animation, I've used animation.js and found it simple and fast.
Thanks for this. I've been looking for something less bloated than jQuery and Prototype. I like native code, but don't always have time to handle every browser incompatibility.
> anything but Mozilla, I think
WebKit also handles things well:
[].map
function map() { [native code] }
[].forEach
function forEach() { [native code] }
> anything but Mozilla, I think
WebKit also handles things well:
[].map
function map() { [native code] }
[].forEach
function forEach() { [native code] }
jQuery is fast, lightweight and easy to master.
For more advanced stuff, your best bet is Prototype.
Dojo, YUI (and ExtJS, not on your list) are good if you have a massive team of JavaScript developers and need standards and solid documentation, but are overkill for 90% of projects.
For more advanced stuff, your best bet is Prototype.
Dojo, YUI (and ExtJS, not on your list) are good if you have a massive team of JavaScript developers and need standards and solid documentation, but are overkill for 90% of projects.
I've done ExtJS and jQuery for the same project recently.
Ext has a nice DataStore object for accessing remote data. And Ext has all those great "rich" components. But I found it wasn't much more work to do my own components in jQuery. (Tree is very simple to implement in jQuery from scratch)
The sense of control I have with jQuery is nice.
The main code to handle my own trees:
My favorite thing about jQuery is it makes doing things the right way very easy.
Ext has a nice DataStore object for accessing remote data. And Ext has all those great "rich" components. But I found it wasn't much more work to do my own components in jQuery. (Tree is very simple to implement in jQuery from scratch)
The sense of control I have with jQuery is nice.
The main code to handle my own trees:
_.fn.toggleTreeNode = function(animate) {
var node = this.filter('button');
if(animate) {
node.siblings('ol').slideToggle(animate)
}
else {
node.siblings('ol').toggle();
}
node.parent().toggleClass('closed');
};
My favorite thing about jQuery is it makes doing things the right way very easy.
Out of interest, why would you suggest Prototype for "more advanced stuff"?
Prototype has class-creation helpers galore, whereas jQuery expects you to do things the old-fashioned way.
There's a lot of jQuery love and Prototype hate out there, which I don't quite get. Both are fantastic; both are bloated.
There's a lot of jQuery love and Prototype hate out there, which I don't quite get. Both are fantastic; both are bloated.
My vote's on jQuery, but whatever you do, do it unobtrusively (one reference: http://simonwillison.net/static/2008/xtech/ ).
It's easy if you do it from the start, and there's a real savings in maintenance costs.
It's easy if you do it from the start, and there's a real savings in maintenance costs.
I started my current project in ExtJS and a few weeks in, I switched to YUI. The ExtJS components look great, and are fairly easy to use if you use them in the standard way. However, I found that as soon as I wanted to do something custom I got totally lost in the 'ExtJS' way. While the YUI components are not quite as polished looking, I have a much easier time extending/reworking them. One thing I like about both frameworks is they provide layout management, so it is very easy to have a 100%width/height viewport layout that the framework manages (YUI's LayoutManager is in beta...so I guess I hope they don't scrap it before it reaches production level.)
I will add that the ExtJS forums are very active and pretty helpful...as are the YUI ones. I've asked several questions in both and gotten good responses each time.
I will add that the ExtJS forums are very active and pretty helpful...as are the YUI ones. I've asked several questions in both and gotten good responses each time.
I really like jQuery because it's lightweight but I think it really fits your needs perfectly. For DOM manipulation in jQuery you just use CSS selectors, so... :
I've only used a few animations from jQuery (like sliding/fading) but the framework also lets you do your own custom animations using CSS (your element will gradually morph to the styles you define).
$('a.hide_these').hide();
$('a.hide_these').parents('p')
I've only used a few animations from jQuery (like sliding/fading) but the framework also lets you do your own custom animations using CSS (your element will gradually morph to the styles you define).
$('a.hide_these').parents('p')
or if you want to hide all the anchors of class hide_these then you could do this.
$('p > a.hide_these').hide();
or if you want to hide all the anchors of class hide_these then you could do this.
$('p > a.hide_these').hide();
Prototype is terrific. The problem is most developers dont utilize 90% of the functionality. Thus making it a bloated library. Read through the documentation frequently. You will pick up on nice new functions that will make life so much easier. Go with JQuery if you are looking for basic use prototype if you want the extra goodies.
ExtJS is the one we actually use in our products...the widgets are just too awesome to skip. I'm not entirely on-board with the way things work. It's a very OO style project, and feels kinda like working with Swing or some other Java toolkit. A bit verbose at times. But, the library has so much coverage, it'd take us an extra six months to a year to develop those bits and pieces using jQuery, which I find more fun and natural to use.
YUI is a close runner up, and if I were starting today I might go with it. The widgets are fantastic, the documentation is fantastic, and the community is large. It also feels more like JavaScript than ExtJS.
As jQuery UI develops it'll probably become a contender in that space, as well. But, for now, I'm just adding it to our websites in a few places where it is useful--that's the other negative about ExtJS: It's a "drink the Kool-aid" kind of library. I've had a hard time integrating it in little bits and pieces, and it's turned out that everything is going to have to be converted to use ExtJS for it to all work together.
YUI is a close runner up, and if I were starting today I might go with it. The widgets are fantastic, the documentation is fantastic, and the community is large. It also feels more like JavaScript than ExtJS.
As jQuery UI develops it'll probably become a contender in that space, as well. But, for now, I'm just adding it to our websites in a few places where it is useful--that's the other negative about ExtJS: It's a "drink the Kool-aid" kind of library. I've had a hard time integrating it in little bits and pieces, and it's turned out that everything is going to have to be converted to use ExtJS for it to all work together.
Few libraries make me curl my toes in pleasure like jQuery does. I'm absolutely enamored with it!
If your back end is Java, use GWT -- that gives you statically typed RPC calls between your client and server, which makes life easy.
> If your back end is Java, use GWT
...and then take a long hard look at your life, and see if you can figure out where it went so wrong.
;P
;P
Are you saying java is a bad choice?
Yes, that's exactly what I'm saying.
It's a language specifically designed to make it very difficult to do anything interesting.
PHP (the language, not the implementation) has some very deep problems, in my opinion. But at least you can sketch out a rough solution, and gradually turn it into something more polished.
I think the best design is done by coding little sketches that gradually become more and more complete, and are cheap enough to throw away; not by drawing complex UML diagrams and then carefully casting them into perfect code. That's just impossible, and the result is a lot of bloated crap that is very difficult to change when (inevitably) your design changes.
It's a language specifically designed to make it very difficult to do anything interesting.
PHP (the language, not the implementation) has some very deep problems, in my opinion. But at least you can sketch out a rough solution, and gradually turn it into something more polished.
I think the best design is done by coding little sketches that gradually become more and more complete, and are cheap enough to throw away; not by drawing complex UML diagrams and then carefully casting them into perfect code. That's just impossible, and the result is a lot of bloated crap that is very difficult to change when (inevitably) your design changes.
Writing AdSense or GMail in Ruby/Python/PHP will force you to pay the "tax" later on and the tax will be huge before you know it. You'll end up with a scratch re-write like it or not.
I'm not sure what you're trying to say here. Is the "tax" the upfront cost of writing code that uses static typing? If so, I most strongly disagree.
Static typing is not a silver bullet. The claim that not using a static typed language for anything complex will result in a "scratch rewrite" is absurd.
Static typing is not a silver bullet. The claim that not using a static typed language for anything complex will result in a "scratch rewrite" is absurd.
jQuery has been a huge time saver for me, highly recommended. I did look at pretty much all of these before settling on it, and haven't regretted it at all. jQuery is amazingly easy to get started with, very concise, but also amazingly expressive and flexible without sacrificing readability or conciseness.
I've also done a fair bit with Prototype/Scriptaculous, but it just seems clunky and excessive in comparison to jQuery now.
Yes... there's nothing really wrong with Prototype; it's just that jQuery feels far leaner (both in terms of API and in codesize) while doing most of what I typically need out of Prototype/Scriptaculous.
I'd say either of them would be fine, but there does seem to be more momentum behind jQuery as of late.
I'd say either of them would be fine, but there does seem to be more momentum behind jQuery as of late.
But that's just it, it just "feels" far leaner. jQuery, uncompressed and unminified, is almost as bulky as Prototype (100 KB vs. 124).
Prototype does a lot in that extra 24 KB, is faster on some benchmarks, and I just like the way the code looks. If you just minify and gzip Prototype, you're looking at a much lighter footprint.
In the end, none of the frameworks are very lean: though Mootools and YUI are at least modular.
Prototype does a lot in that extra 24 KB, is faster on some benchmarks, and I just like the way the code looks. If you just minify and gzip Prototype, you're looking at a much lighter footprint.
In the end, none of the frameworks are very lean: though Mootools and YUI are at least modular.
That's not true though... jQuery, without any plugins, supports basic animation out-of-the-box (enough for the applications that I have been writing lately). Prototype requires scriptaculous on top of that if you want to write effects, which at a minimum is an additional 40kb for the effects module.
I know that prototype and scriptaculous provide more functionality, but my point is that jQuery is providing enough of what I need from both libraries while still being smaller.
Seriously though - I've written both and I'd find it hard to go wrong with either. jQuery is more the way I've been leaning of late, but were it to suddenly disappear off the face of the earth tomorrow I'd be fine with Prototype/Scriptaculous. To each, his own. :-)
I know that prototype and scriptaculous provide more functionality, but my point is that jQuery is providing enough of what I need from both libraries while still being smaller.
Seriously though - I've written both and I'd find it hard to go wrong with either. jQuery is more the way I've been leaning of late, but were it to suddenly disappear off the face of the earth tomorrow I'd be fine with Prototype/Scriptaculous. To each, his own. :-)
I agree with you entirely :)
I actually find both to be a bit heavy. I don't necessarily want animations out of the box, so that makes jQuery a bit more bloated to me.
I also don't necessarily want all that Prototype offers for all of my projects.
I actually find both to be a bit heavy. I don't necessarily want animations out of the box, so that makes jQuery a bit more bloated to me.
I also don't necessarily want all that Prototype offers for all of my projects.
Objective J + Cappucino
Very few of us have extensive experience in more than one library. JavaScript muddled along without standard libraries for a long time.
I use Ruby on Rails, which has support for Prototype/Scriptaculous, so that's what I use. I like it a lot better than straight JavaScript. The thing that the libraries do well at is papering over browser differences. One good aspect is they collect "fixes" and tricks that have been spread all over the web and concentrate them one place.
I'm mystified why Prototype doesn't download in minified format. It's easy and useful to do but I'm sure most folks don't think of it.
I use Ruby on Rails, which has support for Prototype/Scriptaculous, so that's what I use. I like it a lot better than straight JavaScript. The thing that the libraries do well at is papering over browser differences. One good aspect is they collect "fixes" and tricks that have been spread all over the web and concentrate them one place.
I'm mystified why Prototype doesn't download in minified format. It's easy and useful to do but I'm sure most folks don't think of it.
I've played with MochiKit and jQuery. Like them both but have been doing more stuff with jQuery lately ... can't comment on the others :P Checked them out quickly and none appealed to me :P
There is of course the other option of not using any of them and programming custom things in javascript. I'm not sure if this takes longer or not - I haven't used any of the above libraries - but I think you get a more satisfactory result.
DOM manipulation is pretty simple with the javascript dom functions, as is animation, although it depends on how custom you need it, and how much you're worried about speed/bloat/etc
DOM manipulation is pretty simple with the javascript dom functions, as is animation, although it depends on how custom you need it, and how much you're worried about speed/bloat/etc
I disagree. Achieving smooth animation without a library is extremely difficult. If you look at what the modern libraries actually do you'll see that they have two features which are tricky to implement from scratch: frame rate limiting and easing. Frame rate limiting means that if you are running lots of complex animations at once the libraries will drop frames to ensure that all animations complete in the allocated time. Easing gives you a pleasing speed-up / slow-down effect during your animation which makes them look far more natural. This is a fair amount more complicated than simple animations set up just using setTimeout.
Of course, you can roll that stuff yourself - but why duplicate all of that effort?
Also, DOM manipulation with the regular DOM is amazingly inconvenient when compared to manipulation using a library such as jQuery. The DOM is a pretty verbose API with a lot of weird quirks (removing a node: "theNode.parentNode.removeChild(theNode)") - jQuery provides a much more sensible API, which in turn means that I find myself using DOM manipulation a lot more since it isn't such a pain to do.
Of course, you can roll that stuff yourself - but why duplicate all of that effort?
Also, DOM manipulation with the regular DOM is amazingly inconvenient when compared to manipulation using a library such as jQuery. The DOM is a pretty verbose API with a lot of weird quirks (removing a node: "theNode.parentNode.removeChild(theNode)") - jQuery provides a much more sensible API, which in turn means that I find myself using DOM manipulation a lot more since it isn't such a pain to do.
Timed animation isn't that tough.
Just track the actual number of frames an animation has taken so far and the number of frames it needs to take to complete in the time taken. For bonus points re-average your framerate each time an animation ends by keeping track of the number of frames an animation actually was able to take.
And as far as easing goes...
http://www.robertpenner.com/easing/
Just track the actual number of frames an animation has taken so far and the number of frames it needs to take to complete in the time taken. For bonus points re-average your framerate each time an animation ends by keeping track of the number of frames an animation actually was able to take.
And as far as easing goes...
http://www.robertpenner.com/easing/
How are they tricky to implement from scratch :/ The animation effects you talk about are pretty simple mathematics.
eg
function timerMethod() { currentFrame = (currentTime - startTime) * numFrames / animationDuration; }
And to do 'easing' as you call it, you could just use sin/cos, or a small lookup table.
The main reason to duplicate effort is to firstly learn how these things work, and secondly to get a better solution matched more optimally to your use case.
I personally like the DOM... theNode.parentNode.removeChild(theNode) makes quite a lot of sense. But it's probably a matter of taste that one.
eg
function timerMethod() { currentFrame = (currentTime - startTime) * numFrames / animationDuration; }
And to do 'easing' as you call it, you could just use sin/cos, or a small lookup table.
The main reason to duplicate effort is to firstly learn how these things work, and secondly to get a better solution matched more optimally to your use case.
I personally like the DOM... theNode.parentNode.removeChild(theNode) makes quite a lot of sense. But it's probably a matter of taste that one.
If you haven't even used any of the libraries, how do you know whether they help or give less "satisfactory" results?
because using any library is always going to be less optimal than a custom solution.
When I started learning js I just decided it would be worth more to learn js, rather than any library. Now I know js there seems little benefit on learning one of the js libs.
Of course this is all just my personal opinion and experience.
When I started learning js I just decided it would be worth more to learn js, rather than any library. Now I know js there seems little benefit on learning one of the js libs.
Of course this is all just my personal opinion and experience.
because using any library is always going to be less optimal than a custom solution
I strongly disagree. The library authors, and fellow users, have discovered and worked-around browser and Javascript gotchas and performance bottlenecks that it could take you years of custom work to independently discover.
I strongly disagree. The library authors, and fellow users, have discovered and worked-around browser and Javascript gotchas and performance bottlenecks that it could take you years of custom work to independently discover.
Not really true. And you can always look at the source of libraries if there do happen to be some gotchas or bottlenecks (I think the number of these is really overstated).
The issue is, they make general libraries that cover hundreds of use cases. Because they cover that many, they are very general, and useful to lots of people, but they are non-optimal. They have extra things you won't need. They have extra arguments to functions you don't need. Bloat.
The issue is, they make general libraries that cover hundreds of use cases. Because they cover that many, they are very general, and useful to lots of people, but they are non-optimal. They have extra things you won't need. They have extra arguments to functions you don't need. Bloat.
I fall back on raw JavaScript DOM manipulation for performance-critical stuff, which is a decent-sized chunk when you're doing arcade games in JavaScript. You can get decent results, but I wouldn't recommend it unless you really are performance-constrained. You end up spending a lot more time than you'd like on browser-specific bugs. If you're just trying to put up a UI to respond to your user's clicks, you're much better off with a lightweight X-platform library like JQuery or Base2.
Prototype gives you power to develop custom interfaces and supports various idioms - events, cross-platform layout, positioning, classes, not just fancy widgets, use Prototype when you need total control over your interface.
I prefer jQuery. It's the fastest growing javascript library. It's the newest javascript library on the list. It runs fast, and most importantly; it has a very simple and readable syntax.
I've used JQuery once or twice, but I will definatly look into it more, been hearing good things about it, and this poll just backs it all up.
But using a lot of Prototype in the past....
But using a lot of Prototype in the past....
We love Ext JS.. We've been using it for about 3 months. Its awesome. Nothing else like it in quality, elegance, and end product.
How about JavaScriptMVC along with one of these frameworks. It will really help you organize and maintain your project.
JavaScriptMVC also uses event delegation, which can really help performance and code organization.
Not having used any so far, I have to say from the demos I'm most impressed with Dojo and extJS.
i think the main reason people use prototype is that it has very strong integration with rails and symphony... if it weren't for that; I probably would have switched to jquery a long time ago
I also like ExtJS. You can use ExtJS in conjunction with YUI as well.
Mootools is easy to use, and I'm a noob.
mootools is a great framework, and rainbow moo is a great color chooser, but jQuery is just as easy to use, has better performance and faster updates to the core.
i think jQuery has a lot to offer above mootools, but mootools does a good job of looking really clean.
i think jQuery has a lot to offer above mootools, but mootools does a good job of looking really clean.
Google Web ToolKit
Which one do you like and why?