157

Chosen and Select2 are the two more popular libraries for extending selectboxes.

Both seem to be actively maintained, Chosen is older and supports both jQuery and Prototype.

Select2 is jQuery only, its documentation says Select2 is inspired by Chosen, but doesn't detail any improvements made (if any) or other reasons for the rewrite.

Two libraries have pretty much same feature set, the only comparison I've found is a somewhat inconclusive jsperf test page.

Does any of these libraries have any advantages over the other?

j0k
  • 22,600
  • 28
  • 79
  • 90
Boycott Russia
  • 11,818
  • 5
  • 28
  • 29
  • 11
    Your experience with pull requests is probably a good hint on why Select2 started as a rewrite, not a fork. I also noticed that Select2 has better (or at least longer) documentation. – Boycott Russia Nov 28 '12 at 04:50
  • 1
    When it matters or for the sake of difference Chosen is MIT while Select2 is Apache licensed. – EGL 2-101 Feb 26 '13 at 20:57
  • 2
    To be precise, Select2 is available under Apache license or GPL v2. `is licensed under the Apache License, Version 2.0 (the "Apache License") or the GNU General Public License version 2` – Boycott Russia Feb 27 '13 at 00:52

11 Answers11

92

As of Select2 3.3.1, below are what's documented in its README.md

What Does Select2 Support That Chosen Does Not?

  • Working with large datasets: Chosen requires the entire dataset to be loaded as option tags in the DOM, which limits it to working with small-ish datasets. Select2 uses a function to find results on-the-fly, which allows it to partially load results.
  • Paging of results: Since Select2 works with large datasets and only loads a small amount of matching results at a time it has to support paging. Select2 will call the search function when the user scrolls to the bottom of currently loaded result set allowing for the 'infinite scrolling' of results.
  • Custom markup for results: Chosen only supports rendering text results because that is the only markup supported by option tags. Select2 provides an extension point which can be used to produce any kind of markup to represent results.
  • Ability to add results on the fly: Select2 provides the ability to add results from the search term entered by the user, which allows it to be used for tagging.
Mr. 14
  • 9,228
  • 6
  • 37
  • 54
  • 2
    fwiw someone did work on an "add results on the fly" feature for Chosen: https://github.com/shezarkhani/chosen/tree/create_new_options I am using some kind of adaptation of it in the ExpressionEngine add-on [MX Select Plus](http://devot-ee.com/add-ons/mx-select) (it is how I got here as there is now a competing add-on using Select2). – notacouch Jun 10 '13 at 17:20
  • It should be noted though that Select2 doesn't have a fallback when Javascript is disabled, since the options are populated via AJAX. – deathlock Jul 25 '13 at 06:13
  • 10
    Nothing that pulls data via AJAX will work without Javascript. Select2 works fine with pre-populated values and doesn't have to use AJAX. – zachzurn Jul 26 '13 at 02:35
  • @notacouch What is "Matrix Support" and "Low Variables Support" and "SafeCracker support"? Are these concepts specific to ExpressionEngine? – John Zabroski May 23 '16 at 12:16
  • @JohnZabroski Yes, they're commercial EE 2.x add-ons (iirc SafeCracker may have been built in). – notacouch May 24 '16 at 14:32
40

IMHO Chosen is "maintained" but not "actively maintained". 341 issues and 51 pull requests for Chosen. Select2 has 128 issues and 25 pull requests. I think the pattern for these is basically

  • pick whichever one is superficially more appealing to you
  • use it in an app or two
  • bump up against customization problems or limitations
  • maybe try to work with the community via issues & pull requests
  • eventually get fed up and just build your own using what you learned in this process

Whichever one you pick, if your use case is exactly in their sweet spot, either one will work. If not, you'll eventually have to write your own or heavily customize these. In either case, the choice of which one specifically isn't all that important. I guess I'll side with @Andy Ray and @paul here that Select2 is probably the better initial choice.

Peter Lyons
  • 142,938
  • 30
  • 279
  • 274
  • 4
    In my view more issues means more people care and use. And bigger community tends to produce better code (this doesn't necessary apply to chosen). AngularJS: 397 issues, 49 pull reqs; joyent/node: 476 issues, 98 pull reqs. I wonder what the numbers would be for firefox, linux kernel or gcc. – Boycott Russia Dec 03 '12 at 21:51
  • Yeah it's just a heuristic. In theory, an autoselect widget should be several orders of magnitude lower complexity than something like joyent/node. These things turn out to be highly custom, so I get the sense that people are filing pull requests, which get ignored, and then they go maintain a separate fork or rewrite. YMMV. – Peter Lyons Dec 03 '12 at 22:00
  • Just a note if your plans are to go with a customization approach: Chosen has a significantly smaller amount of code (about 1/3rd), but is written in CoffeeScript and SASS (before being compiled to JS/CSS). If you're already familiar with CoffeeScript, then your choice is simple: Chosen will be easier to comprehend and customize. – Tim Dorr Oct 03 '13 at 14:42
  • @Peter Lyons These are some pretty bizarre metrics used to draw your conclusion (not that I disagree with your conclusion). Take a look at the number of contributors (Select2 = 239 v. Chosen = 73) but that might also be misleading, more isn't always better. The Pulse and Graphs of each GitHub project display commit history and frequency along with a ton of other useful stats to make an informed decision about which project may "maintained" vs. "undergoing active development." – cfx May 18 '14 at 06:19
  • FWIW, Chosen has had a lot of updates in the past couple of years. – Charles Wood Dec 02 '14 at 23:39
24

Another difference worth mentioning is that Chosen is developed in Sass and CoffeeScript whereas Select2 is plain CSS and JS. It is my personal option that Sass and CoffeeScript are unneeded layers of complexity which make debugging difficult.

After trying both I have decided to use neither - trying to get Select2 create item functionality turns out to be a very hairy affair as you simply can not do it when attached to <select> elements - it just didn't feel well thought out the hoops I would have to jump through.

I have settled on using selectize.js which just adds the new <option>...</option> element to the form's DOM - and that is sane. It does also use LESS - but I would bypass that and just tailor the compiled CSS directly in your project.

Daniel Sokolowski
  • 11,982
  • 4
  • 69
  • 55
  • 2
    `selectize.js` uses [less](http://lesscss.org/). Is that less of a technological dead end than `Sass` is? – Chris Wesseling Aug 28 '13 at 16:35
  • Nope, it's in the same domain but out of the three selectize.js needed the least tweaking to fit the project. – Daniel Sokolowski Aug 29 '13 at 03:26
  • selectize has visual issues on Firefox 28. – MEM Apr 22 '14 at 20:51
  • @MEM could you be more specific. – Daniel Sokolowski Apr 23 '14 at 13:55
  • In Firefox 28 (Mac OS X), you will notice an extra gray "margin or padding or border" below each input field. It's not an effect I suppose. It must be a visual inconsistency. It's clear once we look at them on FF, and the same glitch doesn't occur on Chrome for example. – MEM Apr 23 '14 at 15:11
  • The live examples at http://brianreavis.github.io/selectize.js/ don't have that issue in Firefox 28. Taking a guess here but I would inspect (in Firefox) your site's styles and also parse your CSS files through a validator to ensure there are no markup issues - home that helps. – Daniel Sokolowski Apr 24 '14 at 18:28
  • A agree that selectize is the best of the three, but whether a project's source files are in coffeescript, sass, less, etc should have little bearing on the decision to chose such a project. Heck, at least you're guaranteed that the resulting/compiled javascript and css will have perfect syntax and avoid common pitfalls that arise when writing js or css directly. – Ryan McGeary Jan 27 '16 at 19:54
19

chosen.js vs select2.js

  • MIT license for both
  • Dependencies:
    • Select2: jQuery
    • Chosen: tbc
  • Desktop browser support:
    • Select2: IE8+
    • Chosen: IE8+
  • Device support:
    • Select2: unclear
    • Chosen: disabled on iPhone, iPod Touch, & Android mobile devices
  • Weight (minified):
    • Select2: 57KB
    • Chosen: 27KB
  • Usage: Select2 supports more "fancy" UI (see 'templates')
  • Both code repos are available on Github
    • Select2: contributions: very active
    • Chosen: contributions: around 3x less than Select2

select2.js contributions chosen.js contributions

ps. I will try to update this answer when I find out more about the missing points

Community
  • 1
  • 1
Adriano
  • 19,463
  • 19
  • 103
  • 140
  • Select2 _should_ support mobile devices the same way as others. We try to make sure it works just as well, with all the intended functionality, on all devices. – Kevin Brown-Silva Mar 07 '15 at 01:45
  • 1
    I think the main reason select2 is more active is that they are working on select2 4.x, which is a major re-write. I honestly don't understand why people place so much emphasis on contributions. I wish GitHub had a cumulative flow diagram that tracked important things like code coverage and test cases, as well as mean response time for issues! (I use select2, btw, my point is just a general pet peeve about people focusing on contributions and the social engineering that is encouraged by charts above.) – John Zabroski May 23 '16 at 12:18
13

First, Let me tell you that Chosen and Select2 are two great plugin and this is my personal experience about Chosen. All what they are saying is true concerning Chosen.

The issue pointed by Pēteris Caune with the select is 2 years old and still there is no official fix. There is simply no good documentation for the API. It has been pointed out (watch issue 671) many time but there is still nothing. It took them almost 2 years to solve this issue where chosen would basically not work if you hid the div with overflow:hidden before showing it (and you have to use a witdh:X% option that you would basically never know if you don't look for the issue).

I'd say that the main problem is the fix speed like said DelvarWorld in issue 92:

My pull request fixes this issue, but like my other one and many of the ones for chosen they are being ignored. This project has too many contributors with too small of a code base.

I first picked Chosen for its MIT licence but I had all theses issues (dropdown cut, not finding the API, looking for hours for the overflow hidden), so I decided to switch to select2 because it has a better documentation, no dropdown cut bug and faster fixes.

phloopy
  • 5,563
  • 4
  • 26
  • 37
zipp
  • 1,116
  • 13
  • 27
9

One feature that works in Select2 but doesn't work in Chosen, is select inside element that has overflow: hidden or overflow: auto.

enter image description here

Corresponding issue for Chosen: https://github.com/harvesthq/chosen/issues/86

Pēteris Caune
  • 43,578
  • 6
  • 59
  • 81
6

Some differences I've found working with these two plugins:

  • With select2 you can search at any location in the option. For e.g. if you have an option called ABCDEFG and you type in CDE you will get that option in the search results but with chosen you have to type AB.. and so on to get the results.

  • I've found that with larger datasets, chosen seems to be faster than select2, especially in IE.

reggaemahn
  • 6,272
  • 6
  • 34
  • 59
  • 2
    Yes Chosen seems to search on words, that is typing `Kingdom` on their example page will return `United Kingdom` which seems a very logical way of doing it plus you can specify also `$("#element").chosen({ search_contains: true });`. – Daniel Sokolowski Aug 07 '13 at 19:12
  • 2
    I do agree with you and often that is the case ie. you'd be looking for words. But in many instances where you have things in brackets like 'xyz(abc)' if you type 'abc' you are also looking for 'xyz' which won't be returned. I guess, it boils down to the scenario you are using it in. In my web app I've used both of these where they were relevant. I like chosen a bit more only because of it's superior rendering speed in IE. – reggaemahn Aug 08 '13 at 08:19
5

Select2 supports mobile, whereas Chosen specifically disables itself on iPods, iPhones and mobile Android. If you want to use "extended" select boxes on mobile, this makes your choice easy.

danvk
  • 15,863
  • 5
  • 72
  • 116
  • @RezaRahmati thx for that. Did you try on an iPhone too by any chance? http://harvesthq.github.io/chosen/#faqs says "Chosen is disabled on iPhone, iPod Touch, and Android mobile devices". more on https://github.com/harvesthq/chosen/pull/1388 – Adriano Jan 26 '15 at 14:43
  • @adrienbe yes I have tested it on Samsung galaxy tab and iPad – Reza Jan 26 '15 at 17:59
  • @RezaRahmati what was the outcome? – Adriano Jan 27 '15 at 20:38
  • @AdrienBe It works, I have used it in http://medicfa.com/Users/Create?reloadList=false open it with the tablet and check the result – Reza Jan 28 '15 at 07:14
5

My experience with Select2 was great on desktop, but on touch mobile devices greatly varied, with some quirks always present. For example, on xperia st15i with ics and stock browser dropdown was always closing itself because of keyboard stealing focus. Only way to bring it open again is to touch the menu dozens of times, hold finger for a second and other voodoo magic. Or to start typing while the dropdown list is closed, and how many users will figure this out?

Selectize.js seems to be much smoother than Select2, but it also has issues on its own on mobile for e.g. when the value is selected or inputed it moves the page all the way to the left for some reason. Also, on older Android 2.x devices which do not support overflow, it is impossible to select past the few top options, since the keyboard does not pop-up. :(

Still have to test Chosen and it might be not such a bad idea to be disabled for mobile devices after all, but in the end good old dropdown works always and everywhere.

Update: now I have also tested Chosen as well, and it is better in one area: it does not work on mobile by default (great!), but it has filtering words issues. For example, does not search in the middle of the words, and if you use &nbsp hack for aligments, it will also ignore complete options. Back to drawing board.

dev101
  • 1,359
  • 2
  • 18
  • 32
  • To properly enable search in Chosen add `search_contains: true` to your options. See https://harvesthq.github.io/chosen/options.html – Sicco Jul 28 '16 at 12:07
1

Why I chose select2 over Chosen

The key feature select2 has, that no other control has auto-magically, is "Clear all" selections with the 'x' in the right-hand of the control. This is a killer feature for my application. I do not know why other select tag enhancement libraries lack this feature.

John Zabroski
  • 2,212
  • 2
  • 28
  • 54
0

Select2 supports AJAX Chosen Doesn't

Select 2 is little heavier in size compare to chosen.

I switched to Select2 because no official support for ajax operations.

Yash
  • 6,644
  • 4
  • 36
  • 26