jQuery Gridly: drag, drop and resize on a grid of bricks

A grid of tiles you can move and resize

Gridly is a jQuery plugin to enable dragging and dropping as well as resizing on a grid, and that single sentence covers the whole feature set.

The mechanism is a container element and a set of children. The children are the tiles, the container is the grid, and the plugin works out the geometry from the tile sizes and the three configuration numbers. It is the sort of component that a dashboard or a page builder needs and that a general purpose layout library would handle with more configuration than the problem deserves.

The era of the project is visible in the README from the first line of the installation section, which loads jQuery 2.0.2 from the Google CDN. The primary language of the repository is CoffeeScript, the copyright notice covers 2013 to 2015 and names Kevin Sylvestre, the licence is MIT, the default branch is master, and the package manifest is at version 1.3.0 with its main entry pointing at the built plugin file, javascripts/jquery.gridly.js. There are no GitHub releases, and the last push was on 2026-04-02.

The homepage is a project page at ksylvest.github.io/jquery-gridly, and the repository has a Travis CI badge for its status, which is the older of the two continuous integration services that GitHub projects used to display.

The install is copying two directories

There is no package manager step in the primary path. To install, you copy the javascripts and the stylesheets directories into your project and add a snippet to the header:

<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.0.2/jquery.min.js" type="text/javascript"></script>
<script src="javascripts/jquery.gridly.js" type="text/javascript"></script>
<link href="stylesheets/jquery.gridly.css" rel="stylesheet" type="text/css" />

That is the whole integration. Two files and a stylesheet, with the plugin's own directory names carried into the project so that the relative paths in the snippet keep working.

The fact that the snippet reaches for a CDN for jQuery rather than telling you to use your own copy is worth noting, because in a page that already loads jQuery you would delete that line. It is also a reminder of the constraints the plugin was written under: a jQuery 2.x API, a global script tag, and no module system.

The repository layout follows the same philosophy. There is a javascripts/ directory and a stylesheets/ directory, and alongside them an index.html and an index.haml for the demo page, a images/ directory, and a packages/ directory, so the project carries its own demo site rather than pointing at one hosted elsewhere.

Bower and rails-assets, for the two ecosystems that wanted it

Beyond the copy-the-files route, the README documents two integrations for the ecosystems that were common at the time.

The first is Bower, and the plugin is registered under bower.io to simplify integration:

npm install -g bower
bower install gridly

The second is rails-assets, registered to simplify integration with Ruby on Rails applications. The Gemfile gains a source and a gem:

+ source 'https://rails-assets.org'
...
+ gem 'rails-assets-gridly'

And then the plugin is required the way Sprockets requires things, with a wildcard comment in the stylesheet and a require directive in the JavaScript:

/*
 ...
 *= require gridly
 ...
*/

//= require jquery
...
//= require gridly

Both of those mechanisms are now largely historical, which is worth saying plainly, because the README presents them as the convenient options. The repository still carries the files for them: a bower.json at the root, a Gemfile and a Gemfile.lock, and a Rakefile for the Ruby-side tasks.

There is also a gridly.jquery.json file, which is the plugin registry manifest, and a package.json for the npm name jquery.gridly. So the plugin was registered in four different package systems, which is a good illustration of what distribution looked like for a front-end library a decade ago.

The markup contract is a container and a set of bricks

Setting up a grid is easy, as the README says, and the example is the whole contract.

The markup is a container with the gridly class, and inside it a set of children with the brick class and a size modifier:

<div class="gridly">
  <div class="brick small"></div>
  <div class="brick small"></div>
  <div class="brick large"></div>
</div>

The small and large modifiers are not part of the plugin, they are your own styles, and the README gives them as CSS with a width and a height, 140 pixels for the small brick and 300 for the large one. The plugin measures the tiles, so the sizes come from your stylesheet and the grid works out the layout from them.

Then one call to initialise:

<script>
  $('.gridly').gridly();
</script>

So the plugin's contract is: a class on the container, a class on each tile, your own sizing rules, and a jQuery call. There is no template, no options object required, and no data attribute in the markup. The size of the API is the main reason the plugin is pleasant to use, and it is also the reason it is easy to mistake for something more capable than it is.

Three numbers decide the geometry

Gridly uses a fairly standard pattern for handling grids and offers three configuration options for sizing: base, gutter and columns.

$('.gridly').gridly({
  base: 60, // px
  gutter: 20, // px
  columns: 12
});

The base is the unit the grid is computed in, the gutter is the space between tiles, and the columns is how many of those units fit across. With a base of 60 pixels, a gutter of 20 and twelve columns, the grid is a twelve column layout whose rows are sixty pixels of tile plus twenty of gap.

That is a very small configuration surface, and it is a deliberate one. There is no option for alignment, no option for a fixed number of rows, no option for masonry behaviour, and no option for per-tile spans. A tile that is wider than the base simply occupies more than one column, which is how the two sizes in the example, one base unit and five, line up with the twelve column grid.

For a dashboard of tiles that are all the same size, this is enough. For anything where the tiles need to flow into the gaps without leaving holes, a masonry layout, the plugin will not do it, and you will want something else.

Callbacks around the drag, and a runtime switch

There are two lifecycle callbacks, and they are passed at initialisation under a callbacks key:

$('.gridly').gridly({
  callbacks: { reordering: reordering , reordered: reordered }
});

The reordering callback is called before the drag and drop starts, with the elements in their starting position, and the reordered callback is called after it ends, with the elements in their ending position. Both receive the set of elements involved, which is what you need to persist the new order or to update a model.

There is also a way to turn dragging on and off after initialisation, which is the kind of thing you need when a tile becomes read-only or when a modal takes over the page:

$('.gridly').gridly('draggable', 'off'); // disables dragging
$('.gridly').gridly('draggable', 'on');  // enables dragging

The second line is quoted with a mismatched quote in the README, a missing apostrophe, so copying it literally will not parse. It is a small thing, and the kind of thing that only matters if you copy and paste, which is a fair argument for reading the source of a plugin this old rather than trusting its documentation.

CoffeeScript, a Cakefile, and what to check before using it

The contributing section is unusually strict and is the clearest signal of how the project is run.

Gridly is maintained in CoffeeScript, all contributions need to be submitted in CoffeeScript, and the project includes a Cakefile that can be used to compile all assets, with cake watch named as the command. The README links to the CoffeeScript site and to a library of CoffeeScript resources for anyone learning the language.

So the build story is a Cakefile rather than a modern bundler, and the repository root has the Cakefile, a Rakefile, a Gemfile and a Gemfile.lock, which is the Ruby toolchain of the period. A contributor today needs a CoffeeScript compiler and a Caketime build, and the compiled output lands in javascripts/ and stylesheets/.

What to check before using the plugin, then. First, the jQuery version your page loads, because the snippet in the README is written for jQuery 2.0.2 and the plugin calls a jQuery API from that era. Second, whether the file-based install fits your build, or whether you want the bower or npm path, and note that the npm package name is jquery.gridly with the main entry pointing at the built file. Third, the licence and the copyright, which is MIT with a notice covering 2013 to 2015, so the code is old enough that reading it before trusting it with a layout is reasonable advice rather than an insult.

And finally, the version. The manifest says 1.3.0, there are no GitHub releases to compare it against, and the last commit is from April 2026, so the repository is being touched without a release cadence. If you need a maintained grid with drag and drop, this is a small, well-scoped and pleasant piece of code, but it is not the project that is being actively developed.

Editorial conclusion

Adopt jQuery Gridly if you have a jQuery page with a grid of tiles and need drag, drop and resize without taking on a framework, because the whole contract is two directories, a container class and one call. Do not adopt it for a new project, because the installation snippet still pulls jQuery 2.0.2 from a CDN, the source is CoffeeScript compiled with a Cakefile, and the package version has been 1.3.0 for years, so you are choosing a plugin from another era. Before you use it, check the jQuery version your page already loads, since the plugin targets a jQuery API from 2013, and decide whether the file-based install or a package manager fits your build.

Frequently asked questions

Official sources

1. Issues
2. ksylvest/jquery-gridly on GitHub
3. License: MIT
4. Project website
5. README