# jquery-ui-rails: jQuery UI in the Rails asset pipeline > jquery-ui-rails packages the jQuery UI assets, JavaScript, stylesheets and images, so that a Rails application can require the components it uses through the asset pipeline instead of downloading a custom build by hand. The gem can also require a single widget, which matters because the whole of jQuery UI weighs 51 KB minified and gzipped and takes a while to execute. **jquery-ui-rails/jquery-ui-rails** — jQuery UI for the Rails asset pipeline - Repository: https://github.com/jquery-ui-rails/jquery-ui-rails - Stars: 1,119 · Forks: 240 - Language: Ruby - License: NOASSERTION - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/jquery-ui-rails-jquery-ui-rails ## A packaging gem, and what it actually removes The description of the project is short: a gem that packages the jQuery UI assets, JavaScripts, stylesheets and images, for the Rails asset pipeline, so you never have to download a custom package through the web interface again. That is the whole scope, and it is worth being clear about it. This is not a fork of jQuery UI, not a component library with Rails conventions, and not a set of view helpers. It is the upstream jQuery UI files, placed where the asset pipeline can find them, with the require directives that the pipeline understands. For an application that predates modern front end tooling, that is a genuinely useful service. The alternative workflow, downloading a zip from the jQuery UI site, unpacking it into vendor/assets, and remembering to do it again for every upgrade, is exactly the kind of task that rots. The project tracks upstream closely. The release list shows v8.0.1 with jQuery UI 1.14.2 dated 2026-09-22, v8.0.0 with jQuery UI 1.14.1 from 2025-06-25, and v7.0.0 from 2023-03-01. So the gem's major version has moved to 8 while the bundled jQuery UI is at 1.14.2, and the pairing is documented in a VERSIONS.md file that maps gem versions to jQuery UI versions. The last push was on 2026-09-22, the same day as the newest release, so the project is current. The primary language is Ruby, and the licence is a custom one that GitHub cannot classify, with the terms in the LICENSE file. ## Require one widget, not the whole library The README's advice is not to require everything, and the reason is stated with a number. The jQuery UI code weighs 51 KB, minified and gzipped, and takes a while to execute, so for production applications it is recommended to include only the modules the application actually uses. Dependencies are automatically resolved. The example is the datepicker. In application.js: ```javascript //= require jquery-ui/widgets/datepicker ``` and in application.css: ```css /* *= require jquery-ui/datepicker */ ``` Note the difference between the two paths, because it catches people out. The JavaScript lives under a widgets subdirectory, the CSS does not. The README calls this out explicitly, noting the absence of a widgets subdirectory in the CSS case. There is a dependency structure underneath. UI Core has core, widget and position, and the README says you usually do not need to require these directly, since they are pulled in by the other JavaScript modules as needed. The same is true of the core and theme stylesheets: you might want to require them if you use no widget modules at all but still want jQuery UI's basic theming CSS, and otherwise they arrive as dependencies. The stylesheet for a widget is not optional, though. For all of the widgets, the README says to remember to require their matching CSS files in application.css as well. ## Interactions, widgets and one effect exception The asset list is organised the way jQuery UI itself is, which makes it easy to find things but also means the directory structure is part of the interface. The interaction modules are mouse, draggable, droppable, resizable, selectable and sortable, and there is a small asymmetry to remember. For all of them except jquery-ui/mouse and jquery-ui/droppable, you need to require the matching CSS file as well. The mouse and the droppable need no stylesheet. The widget modules are accordion, autocomplete, button, datepicker, dialog, menu, progressbar, selectmenu, slider, spinner, tabs and tooltip, and every one of them needs its CSS. The effects are the odd one out. There is a single directive, jquery-ui/effect.all, that pulls in the whole set, and the alternative is to list the individual effects yourself, from effect-blind through effect-bounce, effect-clip, effect-drop, effect-explode, effect-fade, effect-fold, effect-highlight, effect-puff, effect-pulsate, effect-scale, effect-shake, effect-size, effect-slide and effect-transfer. That structure has a cost, and it is the cost every asset list has: you are choosing between one line that is too much and a list you have to keep in step with what the application actually uses. The gem resolves the JavaScript dependencies, but it cannot know which of your pages use which widget. ## The i18n modules have to be asked for twice Datepicker has optional i18n modules for non-US locales, named jquery-ui/datepicker-xx[-YY], and the example pairs them with the main widget: ```javascript //= require jquery-ui/widgets/datepicker //= require jquery-ui/i18n/datepicker-pt-BR ``` There is a note attached to that, and it is a genuinely useful piece of advice. You still need to include the main datepicker module, and it is not required automatically, for performance reasons. The README links the issue discussion behind that decision. So the datepicker in a non-US locale takes two deliberate lines in application.js rather than one, and a developer who adds only the i18n line has not included the widget itself. That is the kind of detail that makes packaging gems worth reading the README for. The i18n modules are also the reason the asset list is per-locale rather than a single file, since a German datepicker and a Brazilian one are different builds, and an application with several locales has to decide at build time which to include. ## The version naming changed under 6.0, and the README says where to look The gem has a compatibility warning at the top, and it is not about Ruby versions. This gem is incompatible with the jquery-rails gem before version 3.0.0, and the README warns that strange things will happen if you use an earlier version, suggesting you run bundle list to check that you either are not using jquery-rails or are at least on 3.0.0. There is a second warning, about the file layout itself. Due to directory structure changes between jQuery UI 1.10, 1.11 and 1.12, if you use a gem version lower than 6.0 you will have to use a different naming for the files to require, and the README links to the READMEs of the 5.0 and 4.2 versions for those users. That is a considerate piece of documentation. The require paths changed when upstream jQuery UI reorganised its directories, and a gem that keeps a single set of instructions would strand the users on older versions. The cost of that care is that the current README is not the one you want if you are on an old gem, which is exactly why the links to the older READMEs are there. The practical rule for a reader is simple: check VERSIONS.md for the jQuery UI version your gem release bundles, and if you are below 6.0, read the README that matches your gem version rather than this one. ## Rebuilding the assets when you need to Most of the code in the repository lives in the Rakefile, and the assets in the gem are built rather than committed by hand. The setup instructions for a contributor are five commands: ```bash git clone git://github.com/jquery-ui-rails/jquery-ui-rails.git cd jquery-ui-rails git submodule update --init bundle install bundle exec rake # rebuild assets ``` The submodule step is the one that is easy to miss, and it is also what the commands in the next section depend on. The repository carries a git submodule pointing at the official jQuery UI repository, so the upstream sources are available locally, and the project describes itself as contributor-friendly on the strength of that arrangement, with a blog post about contributor-friendly gems linked from the README. The hack on jQuery UI itself is the interesting part of the workflow. Because the official jQuery UI sources are present as a submodule, a change to the upstream JavaScript can be made in the same working tree, rebuilt, and tested in a real application, rather than being proposed upstream and waited on. That is the reason the submodule exists, and it is a much better arrangement than the usual split where the packager cannot fix anything in the library it packages. The README separates the two kinds of bug report as well. Bugs in jQuery UI itself go to the jQuery UI Development Center, and bugs in the gem distribution go to the GitHub issue tracker. ## Where jquery-ui-rails is the wrong choice The first wrong-tool case is a new Rails application with no front end decision made yet. jQuery UI is a dated choice, and this gem does not change that. Its value is entirely in the maintenance of an existing jQuery UI setup, and a team starting fresh should pick a component library that matches what the rest of the stack is doing. The second is a project that has already moved to a JavaScript bundler. A Rails application with webpacker, esbuild or importmap does not need the asset pipeline to deliver jQuery UI, and a gem that only teaches the asset pipeline is then a legacy dependency that has to be kept alive for one page. The third is a team that wants a Rails-native widget library. This gem supplies files, not integration. There are no view helpers, no form builders, no generators, and no Rails conventions for how a datepicker should be attached to a model. A project that wants that has to write it, and then the gem is only half the answer. There is also a licensing point to confirm for a commercial project. The project licence is recorded as a custom licence that GitHub cannot classify, so before shipping a product that includes these assets, read the LICENSE file rather than assuming a standard identifier. ## Conclusion Adopt jquery-ui-rails if you are maintaining a Rails application that already uses jQuery UI and the manual download step is a recurring annoyance, and start by requiring only the widgets you use, since the full bundle is 51 KB minified and gzipped. Do not adopt it for a new Rails application that has not chosen a front end, since jQuery UI is a dated choice and the gem is a packaging convenience rather than a maintained widget library. Before you upgrade, check VERSIONS.md for which jQuery UI version the gem release bundles, read the naming note for anything below version 6.0 of the gem, and note that the project licence is a custom one recorded in the LICENSE file rather than a standard identifier. ## FAQ ### How do I add jquery-ui-rails to a Rails application? Add gem 'jquery-ui-rails' to the Gemfile, then require the modules you need in application.js and application.css, for example //= require jquery-ui/widgets/datepicker in JavaScript and *= require jquery-ui/datepicker in CSS. All images required by jQuery UI are served through the asset pipeline automatically. ### Why should I require only the modules I use? The README states that the jQuery UI code weighs 51 KB minified and gzipped and takes a while to execute, so for production applications it recommends including only the modules the application actually uses. Dependencies are resolved automatically, and the full bundle is available as //= require jquery-ui if you want it. ### Which jQuery UI version does a jquery-ui-rails release bundle? The mapping is documented in VERSIONS.md. The listed releases are v8.0.1 with jQuery UI 1.14.2 from 2026-09-22, v8.0.0 with jQuery UI 1.14.1 from 2025-06-25, and v7.0.0 from 2023-03-01. ### Do I need to require the datepicker before its i18n module? Yes. The README notes that you still need to include the main datepicker module and that it is not required automatically, for performance reasons, so a non-US locale needs both //= require jquery-ui/widgets/datepicker and the i18n module. ### How do I rebuild the assets when contributing to jquery-ui-rails? Clone the repository, run git submodule update --init to fetch the official jQuery UI sources, run bundle install, and then bundle exec rake to rebuild the assets. Most of the code lives in the Rakefile, and the submodule lets you hack jQuery UI itself in the same working tree. ## Sources - [Issues](https://github.com/jquery-ui-rails/jquery-ui-rails/issues) - [jquery-ui-rails/jquery-ui-rails on GitHub](https://github.com/jquery-ui-rails/jquery-ui-rails) - [README](https://github.com/jquery-ui-rails/jquery-ui-rails/blob/master/README.md) - [Releases](https://github.com/jquery-ui-rails/jquery-ui-rails/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jquery-ui-rails-jquery-ui-rails