8 ms·

Poll: Suggestions please, which JavaScript library?

• axod 18y ago
  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
  • gojomo 18y ago
    If you haven't even used any of the libraries, how do you know whether they help or give less "satisfactory" results?
    • axod 18y ago
      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.
      • gojomo 18y ago
        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.
        • axod 18y ago
          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.
  • nostrademons 18y ago
    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.
  • simonw 18y ago
    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.
    • axod 18y ago
      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.
    • collin 18y ago
      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/ http://www.robertpenner.com/easing/
• ashleyw 18y ago
  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....
• SwellJoe 18y ago
  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.
• chaostheory 18y ago
  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
• lux 18y ago
  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.
  • lux 18y ago
    I've also done a fair bit with Prototype/Scriptaculous, but it just seems clunky and excessive in comparison to jQuery now.
    • rufo 18y ago
      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.
      • sc 18y ago
        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.
        • rufo 18y ago
          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. :-)
• enki 18y ago
  Objective J + Cappucino
• bomberstudios 18y ago
  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.
  • collin 18y ago
    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: _.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'); }; You can see here the implementation is customized to the markup I needed for MY tree. CSS handles the rest, as it should. My favorite thing about jQuery is it makes doing things the right way very easy.
  • simonw 18y ago
    Out of interest, why would you suggest Prototype for "more advanced stuff"?
    • sc 18y ago
      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.
• jfornear 18y ago
  Mootools is easy to use, and I'm a noob.
  • jdavid 18y ago
    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.
• alexk 18y ago
  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.
• Harkins 18y ago
  My vote's on jQuery, but whatever you do, do it unobtrusively (one reference: http://simonwillison.net/static/2008/xtech/ 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.
• tgdavies 18y ago
  If your back end is Java, use GWT -- that gives you statically typed RPC calls between your client and server, which makes life easy.
  • IsaacSchlueter 18y ago
    > 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
    • axod 18y ago
      Are you saying java is a bad choice?
      • IsaacSchlueter 18y ago
        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.
        • hello_moto 18y ago
          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.
          • IsaacSchlueter 18y ago
            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.
• 3KWA 18y ago
  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
• anonym 18y ago
  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.
  • sc 18y ago
    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] }
• agotterer 18y ago
  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.
• scooter53080 18y ago
  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.
• hbien 18y ago
  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... : $('a.hide_these').hide(); Would hide all anchors with class 'hide_these'. You don't have to do any iterations or pass any anonymous functions. Traversing works the same way too: $('a.hide_these').parents('p') Would find all the paragraph tags that are parents to those anchors. 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).
  • jamongkad 18y ago
    $('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();
• pmorici 18y ago
  Google Web ToolKit
• dualogy 18y ago
  Not having used any so far, I have to say from the demos I'm most impressed with Dojo and extJS.
• bprater 18y ago
  Few libraries make me curl my toes in pleasure like jQuery does. I'm absolutely enamored with it!
• IsaacSchlueter 18y ago
  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.
  • midnightmonster 18y ago
    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.)
• thomasfl 18y ago
  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.
• jaxn 18y ago
  I also like ExtJS. You can use ExtJS in conjunction with YUI as well.
• tbear 18y ago
  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.
• JFred 18y ago
  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.
• justinbmeyer 18y ago
  How about JavaScriptMVC along with one of these frameworks. It will really help you organize and maintain your project.
• justinbmeyer 18y ago
  JavaScriptMVC also uses event delegation, which can really help performance and code organization.