HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
swannodette
mori
Clojure2012–2015
swannodette / mori

mori

ClojureScript's persistent data structures and supporting API from the comfort of vanilla JavaScript

16Distinct people
18Mentions
0Explicit recommenders
3.4KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

ClojureScript's persistent data structures and supporting API from the comfort of vanilla JavaScript

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year18 dated mentions

Observed mentions: 2012-05-11 14:41:53 UTC to 2015-08-01 12:01:51 UTC.

0369122012-01-01 00:00:00 UTC to 2013-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments20122013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 4 mentions; 2 submissions, 2 comments20132014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 11 mentions; 0 submissions, 11 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2015

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20122012-01-01 00:00:00 UTC2013-01-01 00:00:00 UTC110
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC422
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC11011
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC202

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
mori A simple bridge to ClojureScript's persistent data structures and supporting APIs for vanilla JavaScript. Pull requests welcome. Breaking changes in 0.3.0 The API now uses idiomatic JavaScript naming conventions. Improvements to 0.3.0 Faster Mori is considerably faster across the board thanks to recent enhancements to the ClojureScript compiler. For users who would like to benchmark their immutable data structure implementations against Mori, Mori now exposes direct arity invokes which eliminates previous calling overheads from arity dispatching. See Benchmarking for more information. Mori hash maps now default to ClojureScript ArrayMaps that are automatically promoted to PersistentHashMaps as needed. ArrayMaps deliver considerably better performance at small sizes and when simple keys are at play. For example a Mori hash map with less than or equal to eight keys can now be built nearly an order of magnitude faster than Immutable.js 3.6.2 Maps. More ES6 All Mori collections support ES6 iteration via foo[Symbol.iterator] or foo["@@iterator"]. Differences from Immutable.js A functional API, data structures do not have public methods Faster, ClojureScript data structures have been subjected to more real world usage and continuous benchmarking for nearly 4 years Larger, gzipped the base Mori module is about 6K larger than Immutable.js Getting it You can install the latest release via npm: npm install mori The installed package contains a single optimized JavaScript file mori.js. Load mori in your Node.js programs as you would any other module: var mori = require("mori"); In a browser, you can load mori with a script tag, as you would any other JavaScript library: <script src="mori.js" type="text/javascript"></script> You can also load it as an AMD module, e.g. with RequireJS. Usage You can use it from your projects like so: var inc = function(n) { return n+1; }; mori.intoArray(mori.map(inc, mori.vector(1,2,3,4,5))); // => [2,3,4,5,6] Efficient non-destructive updates! var v1 = mori.vector(1,2,3); var v2 = mori.conj(v1, 4); v1.toString(); // => '[1 2 3]' v2.toString(); // => '[1 2 3 4]' var sum = function(a, b) { return a + b; }; mori.reduce(sum, mori.vector(1, 2, 3, 4)); // => 10 Lazy sequences! var _ = mori; _.intoArray(_.interpose("foo", _.vector(1, 2, 3, 4))); // => [1, "foo", 2, "foo", 3, "foo", 4] Or if it's more your speed, use it from CoffeeScript! inc = (x) -> x+1 r = mori.map inc, mori.vector(1,2,3,4,5) mori.intoArray r Documentation You can find extensive documentation and examples here. More Examples Efficient Freeze/Thaw For vectors and maps we provide an efficient thaw and freeze operations: var m = mori; // ~220ms with V8 version 3.29.80 MBP 2.26ghz for(var j = 0; j < 10; j++) { var s = new Date(); var arr = []; for(var i = 0; i < 10000000; i++) { arr.push(i); } print("Array push " + arr.length + " items " + ((new Date())-s)); gc(); } // ~70ms for(var j = 0; j < 10; j++) { s = new Date(); var mv = m._thaw(m.vector()); for(var i = 0; i < 10000000; i++) { mv = m._conj.f2(mv, i); } var v = m._freeze(mv); print("Mutable vector conj " + m.count(v) + " items " + ((new Date())-s)); gc(); } ES6 Map/Set inspired interfaces All Mori maps and sets support all the non-mutating methods of the proposed ES6 Map and Set interfaces. The main difference with the spec is that key lookup is based on value not reference. keys, values, and entries methods return the proposed mutable iterators: var m = mori; var h = m.hashMap("foo", 1, "bar", 2); h.has("foo"); // => true h.get("foo"); // => 1 var iter = h.keys(); iter.next(); // => {done: false, value: "foo"} This feature is subject to changes in the ES6 proposal. Transducers Mori includes Transducers. Zero allocation collection operations FTW: var m = mori; var a = []; for(var i = 0; i < 1000000; i++) { a.push(i); } // make it immutable var v = m.into(m.vector(), a); function time(f) { var s = new Date(); f(); console.log(((new Date())-s)+"ms"); } // ~190ms V8 version 3.29.80 MBP 2.26ghz time(function() { var xf = m.comp(m.map(m.inc), m.map(m.inc), m.map(m.inc)); return m.transduce(xf, m.completing(m.sum), 0, v); }, 10); // ~440ms time(function() { return a.map(m.inc).map(m.inc).map(m.inc).reduce(function(a,b){return a+b;}, 0); }, 10); Build Prerequisites You will first need to install the Java SDK, if it's not already installed on your system. On Windows, you will need to manually install Leiningen. On UNIX-like systems, Leiningen will be installed within the project automatically if the lein executable is not found on your path or if your lein version predates 2.0.0. Clone the repo git clone https://github.com/swannodette/mori.git cd mori On a UNIX-like system build with ./scripts/build.sh Alternatively using npm npm run-script build On Windows ./scripts/build.ps1 The build process will generate an optimized JavaScript file mori.js, which is suitable for use with Node.js, or in a Web browser or other JavaScript environments. You can also load it as an AMD module. Copyright (C) 2012-2015 David Nolen and contributors Distributed under the Eclipse Public License, the same as Clojure.
Read the full README on GitHub

What Hacker News says

18 sources
I've been playing around with getting Mori[0] more js-like, from more idiomatic function names and argument order (fn as the last argument, released) to playing around with a chaining API. Ideally we should be able to wrap javascript values, manipulate via idiomatic chaining (similar to Lodash), while getting most of the benefits from highly-tuned persistent data structures, lazy sequences, etc. e.g. expect(_([1,1,1,1,2,2,3,4,5,6,6]).distinct().conj(7).out()).toEqual([1,2,3,4,5,6,7]); Here's a small set of specs showing early ideas https://github.com/swannodette/mori/blob/8e82b15b35b2989d4a2... [0] https://github.com/swannodette/mori
In Lodash v3.0.0
Haskell and Clojure both use structure-sharing data structures, which allow immutability without the cost of copying the entire structure whenever you want to make an update. They also use laziness to improve the performance of their data structures. If you want an implementation of these ideas in JS, Immutable.js [0] or Mori [1] are the leading libraries. seamless-immutable doesn't use these techniques, so it probably wouldn't perform well on large data sets. The benefit of it is that the immutable objects can be used as drop-in replacements for their native JS equivalents in some situations. Full disclosure: I've contributed to Immutable.js [0] https://github.com/facebook/immutable-js [1] https://github.com/swannodette/mori
In Immutable JavaScript data structures, backwards-compatible with arrays, objects
> Some of the interviewees have been developing for over a decade and can't say what a linked list is, let alone contrast it with vector or an array. Jaw dropping. Some degree of this is acceptable - e.g. I wouldn't really expect a front-end dev to know browser-native DOM manipulation, because everyone uses some sort of shim (particularly jQuery), and modern-modern frameworks abstract away DOM manipulation entirely (think React). But that's a high-level API trade-off, rather than a foundational issue. OTOH it's far more serious when a dev doesn't know about Array.forEach and insists on using $.each for iteration, showing an inability to distinguish between native JS and jQuery. Part of the problem with JS and data structures in particular is that, AFAIK, there is not even a de facto collections standard. Google's Closure structs[1] might
Read the rest
come the closest, but generally brings a lot of baggage. js_cols[2] is pretty good. And then you have what I would consider "fringe" solutions like mori[3]. The bottom line is that even an autodidactic developer starting off in JavaScript land is going to have a much harder time learning about basic data structures than if they started off in Java land, which, while it has it's warts, does have a wonderful standard library for collections[4]. [1] http://docs.closure-library.googlecode.com/git/namespace_goo... [2] https://code.google.com/p/jscols/ [3] https://github.com/swannodette/mori [4] http://docs.oracle.com/javase/tutorial/collections/index.htm...
In Building OS X Apps with JavaScript
This is because mori is written in ClojureScript. For the most part, all mori is doing is exporting pieces of Clojure so that the native JavaScript environment can access them[1]. In Clojure, the naming convention is "foo-bar", and the cljs compiler translates that to "foo_bar". I can't imagine changing the cljs compiler or adding a piece to mori that must be maintained is important enough for this. I'd imagine Swannodette's answer would be "you should use ClojureScript anyway" :) [1] -- https://github.com/swannodette/mori/blob/master/src/mori.clj...
In Om Sweet Om: functional front-end engineering with ClojureScript and React
Would you articulate why it's a "no go" for you? Leiningen[1] takes away 99.9% of the pain of having to work directly with javac, maven, classpaths, etc. And lein-cljsbuild[2] offers a configuration-driven approach to compiling and testing. It's perfectly possible to create setups where node (plus grunt, gulp, shell scripts, make, etc.) "drives" leiningen, and vice versa. About a year ago I contributed such a setup[3] to David Nolen's mori library. [1] http://leiningen.org/ [2] https://github.com/emezeske/lein-cljsbuild [3] https://github.com/swannodette/mori/blob/master/package.json...
In The JavaScript Problem
In order to understand the frame of reference for Om, you really need to watch some Rich Hickey presentations [1][2] (or have a good understanding of functional programming). The first one is more relevant to your questions here, the second is just because Clojure programmers have very specific definitions of "simple" and "easy" and because it's a good talk. [1] http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hic... [2] http://www.infoq.com/presentations/Simple-Made-Easy That said, on to answering your questions: > If data changes, it needs to mutate, right? ... Data doesn't change in this model (see [1]). Incoming events (keyup, network request, page load) occur and your program responds to those events by producing a new, immutable set of data that you're going to use going forward. Om apps keep one reference to the root of the
Read the rest
data tree–Om examples use app-state as the name–which represents the official current state of the data. You can reasonably argue that swapping out app-state is changing data except that anything that had a reference to the previous root(s) still has that reference and you have to go dereference app-state to get the current value instead of having it changed out from under you. > If that's the way, how can you efficiently do updates on relatively large chunks of data? ... Or am I missing something and is it really not that bad? [3] http://eclipsesource.com/blogs/wp-content/uploads/2009/12/cl... Clojure(script)'s data structures use structural sharing. The above picture shows inserting a single node into the middle of the structure. The red outlined nodes are the parents which need to be copy+updated, as shown on the right with all the dotted lines being shared references. The most misleading thing about the picture is that the actual cljs trees have 32 branches at each node instead of 2 or 3 so the lookup time is log32 N (basically constant [4], impl in a systems language vs classic datastructures for comparison). In your Gmail example you'd have to make ~3 new nodes. [4] https://github.com/michaelwoerister/rs-persistent-datastruct... > In general, doesn't this make model code much much more complicated? It requires a different mindset and generally some helper code. In Clojure using Om it's pretty straightforward once you're over the initial hurdle. In javascript using Mori [5] it looks a lot like awkward Backbone with very heavy Underscore use. I've poked around at it and if I were going to try to adopt Mori+React for a real project I'd want to do some quality of life tweaks on Mori. Mostly setting a prototype on the Mori objects to get the feel closer to Backbone+Underscore and trying to get the data structure console output to be more useful. [5] https://github.com/swannodette/mori
In On "The Future of JavaScript MVC Frameworks"

Showing the 15 most recent of 18 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.