Fancytree: a jQuery tree grid for keyboard, editing and drag and drop

What Fancytree solves, and who it is for

Rendering a hierarchical dataset in a browser is easy until the tree has to behave like a widget. Selection has to survive filtering. Checkbox state has to cascade to children. A node has to be editable in place. Rows have to be draggable onto other rows. Large branches have to load on demand instead of in one payload. Fancytree is a jQuery plugin that covers that whole list: its description names keyboard support, inline editing, filtering, checkboxes, drag and drop, and lazy loading.

The audience is narrow and specific. Fancytree is for teams with an existing jQuery codebase, or for server-rendered applications that want a tree grid without adopting a component framework. The repository ships a demo directory full of sample pages and JSON fixtures, plus a live demo linked from the README, so the intended evaluation path is opening a browser, not reading an API reference first.

How the plugin is structured: extensions, source data and asynchronous nodes

Fancytree is one core plugin plus optional extension modules. The core handles the node model, rendering and events. Extensions are loaded separately and enabled by name, which is why the README's ES6 quickstart imports the edit and filter modules and then lists them in the extensions option. Nothing in the core pulls those features in for you.

The data side is the source option. The demo directory contains fixtures for the shapes the plugin accepts: plain JSON trees (demo/ajax-tree-plain.json), nested product and taxonomy data (demo/ajax-tree-products.json, demo/ajax-tree-taxonomy.json), XML (demo/ajax-sub.xml, demo/ajax-tree.xml), and DOM-based sources (demo/ajax-tree-dom.json). When a node's children are not loaded yet, the plugin requests them from a URL instead of receiving them up front, which is the lazy loading path the description advertises.

The README adds one operational caveat that is easy to miss: loading and initialization may be asynchronous, so the nodes may not be accessible yet at the moment createTree returns. Code that immediately walks the tree after initialization is therefore racing the data source.

Installing Fancytree and building a first filtered tree

The package is published as jquery.fancytree, and the README's quickstart is written for a module loader. It imports jQuery, a skin stylesheet, the createTree factory, and the extension modules you intend to use. The package.json main field points at ./dist/modules/jquery.fancytree.js, and the published files list contains only dist, so the modules are the entry points rather than the src directory.

import $ from "jquery";

import 'jquery.fancytree/dist/skin-lion/ui.fancytree.less';  // CSS or LESS

import {createTree} from 'jquery.fancytree';

import 'jquery.fancytree/dist/modules/jquery.fancytree.edit';
import 'jquery.fancytree/dist/modules/jquery.fancytree.filter';

After the imports, the tree is created against a selector, with the extensions array naming the modules that were just imported and a source object supplying the nodes. The README shows the shape of that call and repeats the asynchronous note: nodes may not exist yet when the call returns.

const tree = createTree('#tree', {
  extensions: ['edit', 'filter'],
  source: {...},
  ...
});
// Note: Loading and initialization may be asynchronous, so the nodes may not be accessible yet.

For a non-module page, the README points elsewhere rather than showing a script-tag snippet: it links to the wiki for module loader support and to the jsdoc API page for createTree. There is also a demo/fancytree-server.js file in the repository, which suggests the demo pages expect a local server rather than file:// access.

Where Fancytree stops being the right tool

The README's own NOTE is the first limitation, and it is a deliberate one: Fancytree is considered feature-complete. The code is still maintained and bugfixes will be committed, but the project says not to expect new major features. A team planning a roadmap around new tree capabilities is planning around something the maintainer has explicitly ruled out.

The second limitation follows from the first. The project recommends upgrading to Wunderbaum for a modernized and more capable alternative. That is the maintainer describing the successor, not a third party speculating about one.

There is also a metadata discrepancy worth knowing before you file paperwork. The repository's licence is reported as NOASSERTION, while package.json declares MIT and includes a licenses entry pointing at LICENSE.txt. The package metadata and the repository metadata disagree, and only the licence file itself settles it.

Finally, Fancytree is a jQuery plugin. In a codebase that has removed jQuery, or in an application built on a component framework, adding jQuery back to get a tree is a poor trade. The plugin does not exist without it.

Fancytree versus Wunderbaum, and versus building your own tree

The README names the alternative directly: Wunderbaum, from the same author, described as modernized and more capable, with an upgrade recommended for exactly that reason. The difference in approach is not a feature checklist, it is the dependency. Fancytree is built on jQuery and is distributed as jQuery plugin modules, which is why its quickstart imports jQuery first. Wunderbaum is presented as the successor for teams that do not want that constraint. If you are choosing today and have no jQuery dependency forcing your hand, the maintainer's own note points away from Fancytree.

The other alternative is a hand-rolled tree, and the honest comparison is cost. Keyboard navigation, cascading checkboxes, drag and drop between nodes, and lazy loading are each individually tractable and collectively a project. Fancytree's value is that these behaviours already exist and are exercised by the demo pages in the repository, from the confirm and context menu samples to the grid scrollbar sample. The trade is that you inherit jQuery and a plugin whose feature set is frozen.

Maintenance, releases and upgrade cost

The repository is not archived, and the last push was on 2026-09-12. That is recent activity, and it is consistent with the README's promise of ongoing bugfixes rather than new features. The release history tells a similar story: v2.38.5 in April 2025, v2.38.4 in December 2024, v2.38.3 in February 2023. The gaps are uneven, and the version in package.json is 2.38.6-0, which is ahead of the most recent published tag. Anyone pinning a version should check the changelog rather than assume the package version matches the latest release.

The upgrade cost is mostly about the extension imports. Because features such as edit and filter live in separate modules that must be imported and then named in the extensions array, upgrading the core without updating the module imports leaves you with a tree that silently lacks the behaviour you expected. The build itself is Grunt-based, with a Gruntfile.coffee at the repository root and a devDependencies list covering eslint, prettier, qunit and jsdoc. That matters only if you fork and rebuild; consumers installing from npm receive the dist directory.

On licensing: package.json declares MIT, and the repository's licence metadata reports NOASSERTION. Read LICENSE.txt in the repository to determine the actual terms. That is a factual step, not legal advice.

Editorial conclusion

Adopt Fancytree if you already ship jQuery and need a tree grid with checkboxes, filtering, inline editing and lazy loading without a build step beyond the modules you import. Do not adopt it if you are starting a new front end on a modern framework, or if you expect new major features: the README states the project is feature-complete and recommends Wunderbaum instead. Before committing, verify the licence file in the repository, since the GitHub metadata reports NOASSERTION while package.json declares MIT, and confirm the release you pin against the changelog.

Frequently asked questions

Official sources

1. Issues
2. mar10/fancytree on GitHub
3. Project website
4. README
5. Releases