js-sdsl: a JavaScript container library that benchmarks itself against the C++ standard library

The container set and what each one is built on

js-sdsl describes itself as a JavaScript standard data structure library which benchmarks against the C++ STL, and the included structures are listed with the data structure behind each.

There is a Stack, a first-in last-out container, and a Queue, first-in first-out. There is a PriorityQueue implemented using a heap, and a Vector described as a protected array whose properties such as length cannot be operated on directly, which is a deliberate way of keeping the internal representation from being corrupted. There is a LinkedList using non-contiguous memory addresses, and a Deque with O(1) time complexity for unshift or for getting elements by index.

The ordered containers are the ones that distinguish this from a general collection. The OrderedSet is a sorted set implemented using a red black tree, and the OrderedMap is a sorted map implemented the same way. Those are the structures JavaScript does not have, because the built-in Map and Set preserve insertion order rather than sorted order.

The hash containers are the deliberate opposite choice. The HashSet and HashMap are implemented by referring to the polyfill of the ES6 Set and the ES6 Map, which means they behave like the built-ins rather than like a bespoke implementation, and the topic tags list hashmap and hashset alongside map and set.

One package or many

The download section gives two ways in, and the second is the one that changes how you depend on the library.

The first is a direct download of a UMD bundle from a CDN, with the unminified file for development and the minified file for production. The second is an npm install:

npm install js-sdsl

The third option is the one worth reading about. The library also ships isolation packages containing only the containers you want, with a separate npm package per structure, such as @js-sdsl/stack, and the documentation lists each package with its npm entry, its size and its own documentation link.

That is an unusual packaging decision and a good one. A data structure library where you only need a deque should not cost you the weight of a red-black tree implementation, and a per container package makes that possible without the library having to rely on your bundler being clever enough to drop unused code. The trade is more packages in your dependency list, which is a real cost in a project that cares about supply chain surface.

The supported platforms table lists Edge, Firefox, Chrome, Safari, Opera and Node with the versions tested, from Edge 12 and Safari 10 and Opera 10 upward. The library is MIT licensed, the source is TypeScript, and the site is js-sdsl.org.

The benchmark claim and what it does and does not tell you

The benchmark section makes a fairly strong claim, that the library is being compared against other popular data structure libraries and that in some ways it is better than the best library, with the results on the benchmark analysis page of the project site.

The phrase to notice is the target. The project describes itself as a standard data structure library which benchmarks against the C++ STL, and the topic tags include stl-containers and rb-tree and red-black-tree. The framing is that these containers should behave the way the equivalent standard library types behave, and the benchmark page is where the comparison is made.

That is a useful design goal, because JavaScript's built-in Map and Set are not containers in the same sense. They preserve insertion order, they do not have logarithmic lookup on a sorted key, and the collections in this library fill the gap by giving you a red-black tree where the language gives you a hash table.

What a benchmark page does not tell you is which operations were measured and on what shape of data. A red-black tree wins on ordered traversal and loses to a hash table on point lookup, so a library that has both will show whichever number the comparison happened to measure. For a decision, the more useful question is which operation your code performs.

The project is MIT licensed, its last push was on 2026-04-14, and the last tagged release is v4.4.2 from July 2023, with v4.4.1 in June 2023 and v4.4.0 in March 2023, so the recent activity is on the default branch rather than in new tags.

Where js-sdsl is the wrong choice

The first limitation is that the container set is fixed. There is no graph, no trie and no spatial index, and the list above is the whole catalogue. If your need is a prefix search or a nearest-neighbour query, this library does not help and you are writing it yourself.

The second is the size comparison you should make carefully. For a handful of entries, the built-in Map with an array of sorted keys is simpler and faster, because the overhead of a dependency and a tree exceeds the benefit at that scale. The library pays for itself when the structure is load-bearing, which for most people means a priority queue in a scheduler, an ordered map with range scans, or a deque at both ends of a buffer.

The third is the release cadence, which is worth understanding rather than worrying about. The last tagged version is v4.4.2 from 2023, while the repository was pushed to in April 2026. That pattern means the code is maintained but the tags are behind, so a project that pins a version is pinning something older than the current work, and a project that follows the branch is taking unreleased changes. For a library with no dependencies of its own, that is a manageable risk, but it is a decision rather than a detail.

The alternative comparison is with writing the structures yourself, which many teams do once. The library earns its place when the same container is needed in several projects, when the type inference matters, and when the maintenance of a red-black tree is not something anyone on the team wants to own.

Editorial conclusion

js-sdsl fits a TypeScript project that needs an ordered map, a priority queue or a deque with real type inference and no runtime dependency, and that would rather not write the structures itself. It does not fit a project that needs an algorithm the library does not implement, and it does not replace a database index or a spatial structure. Before adopting it, check that the container you need is in the list, because the shipped set is fixed, and decide between the single package and the isolation packages, since the library ships both and the per container packages are the ones that keep a bundle small.

Frequently asked questions

Official sources

1. js-sdsl/js-sdsl on GitHub
2. License: MIT
3. Project website
4. README
5. Releases