I confused this with https://github.com/omcljs/om
In The Om Programming Languageomcljs
om
Clojure2013–2026
omcljs / om
om
ClojureScript interface to Facebook's React
61Distinct people
67Mentions
0Explicit recommenders
6.6KGitHub stars
What to know before exploring
What it is
ClojureScript interface to Facebook's React
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
- reagent-project/reagent · linked in 3 of the same discussions
- ckirkendall/kioo · linked in 2 of the same discussions
- r0man/sablono · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 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 year67 dated mentions
Observed mentions: 2013-12-22 19:43:54 UTC to 2026-02-25 19:11:18 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 31 | 1 | 30 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 18 | 5 | 13 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Om
NOTE: This project is no longer under active development. If you'd like to use
a library that's well maintained that was inspired by some of the ideas
presented here see Fulcro
A ClojureScript UI framework and
client/server architecture over Facebook's
React.
Om UIs are out of the box snapshotable and undoable and these operations have
no implementation complexity and little overhead.
Om borrows ideas liberally from Facebook's
Relay and Netflix's
Falcor with a dash of inspiration from
Datomic pull syntax to avoid the typical
incidental complexity that arises from client/server state management.
Dependency Information
Latest release: 1.0.0-beta1
Leiningen and Boot
dependency information:
[org.omcljs/om "1.0.0-beta1"]
Maven dependency information:
<dependency>
<groupId>org.omcljs</groupId>
<artifactId>om</artifactId>
<version>1.0.0-beta1</version>
</dependency>
Example
(ns example
(:require [goog.dom :as gdom]
[om.dom :as dom]
[om.next :as om :refer [defui]]))
(defui Hello
Object
(render [this]
(dom/h1 nil "Hello, world!")))
(def hello (om/factory Hello))
(.render js/ReactDOM (hello) (gdom/getElement "example"))
Tutorials
There is an Quick Start tutorial that will introduce you to the core
concepts of Om
here. There are
also a variety of other guides here.
Documentation
There is documentation here
Contributing
Please contact me via email to request an electronic Contributor
Agreement. Once your electronic CA has been signed and returned to me
I will accept pull requests.
Community
If you are looking for help please get in touch either on the
clojurians.slack.com #om channel or the
om-cljs Google Group.
References
Worlds: Controlling the Scope of Side Effects
A Functional I/O System
Directness and Liveness in the Morphic User Interface Construction Environment
Learnable Programming
Relay
Falcor
GraphQL
Datomic pull syntax
Copyright and license
Copyright © 2013-2017 David Nolen
Licensed under the EPL (see the file epl.html).
Read the full README on GitHubWhat Hacker News says
67 sourcesNot sure if it is still the case, but Circle used Clojure/Om [1]... when I heard them say they did that so many years ago, I knew right away it would end up being something nobody wanted to work on.
Sure enough, just checked, Om was abandoned [2] and the person blogging about how great everything was is long gone [3]. This is the absolute definition of tech debt.
[1] https://circleci.com/blog/how-circleci-processes-4-5-million...
[2] https://github.com/omcljs/om
[3] https://circleci.com/blog/why-we-use-om-and-why-were-excited...
In I fell in love with low-JSOne thing I really want to make sure with Crank is that sync stays sync and async stays async. One of my early formative programming experiences was having to track down a race condition in an om app I was working on which was caused by the renderer making my sync code asynchronous.
https://github.com/omcljs/om/issues/173
In Crank.js – Write JSX-driven components with functions, promises and generatorsThere is an interesting synergy at play amongst UI as s-exprs, functional programming, and components/vdom where the whole is more valuable than the sum of its parts. I was surprised to find no mention of Reagent[1] nor Om[2] both ClojureScript interfaces to React. They share a remarkable similarity with Umbrella especially the s-expr syntax. However, Reagent[1] and Om[2]'s language choice pushes the functional composition further.
I'm interested to see this how this combination of ideas spreads outside the browser and into other applications of UI. As for myself, I've been experimenting with a writing a terminal emulator/component lib[3] using Clojure that is inspired by Reagent/Om and React Native. It's been satisfying seeing the way these ideas compose.
[1] - https://reagent-project.github.io/
[2] - https://github.com/omcljs/om
[3] - h
In Show HN: Thi.ng/hdom – S-expression based, pure ES6 UI/VDOM componentsThere are a couple Clojurescript interfaces to React: Om (https://github.com/omcljs/om) and Reagent (https://reagent-project.github.io/) are two I'm familiar with.
For an example of how a Clojurescript project would be built using these libraries, I'd recommend checking out re-frame: https://github.com/Day8/re-frame
In My struggle to learn Reacthttps://www.datomic.com/get-datomic.html starter version
https://github.com/tonsky/datascript Datascript is also neat, it's an in-browser DB with datalog query syntax. There's some neat stuff possible with om.next + datascript: https://github.com/omcljs/om/wiki/DataScript-Integration-Tut...
In Datomic CloudDepends whether you learn best by reading [1], answering some interactive questions/koans [2], or downloading and playing around with a ToDoMVC app example [3][4][5] or a mixture of the above. Feel free to join the #clojurian Slack channel [6] if you need help.
As a beginner, I recommend you looking at the Reagent [7] or Rum [8] React library first, than you can look at something more complex and full-featured like Om [9] later (whose author is also a ClojureScript core contributor @swannodette).
PS: You can also learn by implementing a Dashboard like this [10]. Disclaimer: I am the author of this library.
[1] http://funcool.github.io/clojurescript-unraveled/
[2] http://clojurescriptkoans.com/
[3] http://todomvc.com/examples/reagent/
[4] https://github.com/reagent-project/reagent/tree/master/examp...
[5] https://github.com/gadfly361/cljs-
Read the rest
This is quite a large question to answer.
From viewpoint of compiler, there is no much distinction between local and external packages. Clojure (and so ClojureScript compiler) is built on to of JVM and uses Maven dependencies so that is where most of the dependencies come from. From viewpoint of compiler, all files are in JVM classpath (or in directories specified in Cljs compiler options).
Om declares it's dependencies in project.clj file: https://github.com/omcljs/om/blob/master/project.clj#L13
- om.dom, based on the name, compiler will look for om/dom.cljs/cljc files in classpath, and in this case the file is local to the project
- cljsjs.react is foreign-library (https://clojurescript.org/reference/packaging-foreign-deps) provided by external cljsjs/react package. Compiler indexes all these foreign-libraries at start, so when it encou
Read the rest
nters require to one of them knows what to do
- goog.dom is Closure module provided by Google Closure library (https://github.com/google/closure-library), which is dependency of ClojureScript. Compiler will look for goog/dom.js file if no .cljs or .cljc by the name is found.
How does Clojurescript lookup for a module you declare?
For example, in https://github.com/omcljs/om/blob/c68e668a73cc534ecfdc71d631... (couldn't think of any Clojurescript library), you have `[om.dom`, `[cljsjs.react`, `[goog.dom`. Where does the compiler look for these things? How does it knows one is a local module and the other an external package?
I need to know this so I can implement it in https://github.com/fiatjaf/module-linker
In ClojureScript Is Not An Island: Integrating Node ModulesI suppose. When you update and depend on a global atom your functions aren't pure, at all, in any sense.
Why are you even using FP at that point?
Global application state should be represented in a single root storage; the application data store (ie. database), and the interactions with it should be controlled and sanitised.
If you have a thousand little places across your code base updating and reading from the database, that's horrible code too, in java or in clojure...
Modern UI frameworks are carefully controlled access and update to the display state for a UI; they happen in a controlled and orderly manner specifically to prevent the chaos you get otherwise; if not, you're doing it wrong.
This section in the om docs covers their solution, which is quite elegant: https://github.com/omcljs/om/wiki/Quick-Start-(om.next)#glob...
(notice,
Read the rest
you don't just reach out and update atoms directly by hand; there's nothing wrong with having a global application state; that's a good thing, but directly interacting with it is not)
About this:
"In many ways ClojureScript has and continues to be ahead of the JavaScript mainstream with respect to best practices. Concepts which are only starting to break into the mainstream such as immutability, single atom application state, and agile UI development via robust hot-code reloading are old news to ClojureScript users. "
To my mind, the most compelling thing about Javascript-in-Clojure is working with Om Next. I say this as someone who has recently done some big projects with React.
I think it would be accurate to say that over the last 2 years React has been the Javascript framework that had the biggest impact on how people think about working with Javascript. You look at how much Angular tried to reinvent itself to be a bit more like React.
There are a lot of interesting ideas in React, and I learned a lot while working
Read the rest
with it, yet I hate working with it. It is ridiculously verbose. And I hate the way it handles mutations -- it's as if React was trying to be Functional, but then decided to go back and be Object Oriented when it came to mutations.
But I don't mean to go off on a tangent. There are a lot of good ideas in React. Especially GraphQL, which arose as part of the React effort, but which I think will have a long life quite independent of React. React might some day fade away and be forgotten, but GraphQL's critique of the RESTful style is likely to change the way the industry thinks about APIs over the net.
But as I said, React is verbose. I like where Om Next is going -- in terms of immutability and data flow, it has the same basic outlook as React, but Om Next is simpler and it is truer to the Functional paradigm.
If I do any further work with ClojureScript, it will be because of Om Next.
https://github.com/omcljs/om/wiki/Quick-Start-(om.next)
Start with Figwheel[1] to enable hot-loading code and live reloading:
lein new figwheel <app-name>
I have used Reagent[2] since I'm only doing prototypes and don't have to worry about production quality. Om/Om Next[3] seems like it would be worth checking out since it does a bunch of clever things that Reagent doesn't. Reagent is very straightforward and therefore might be the better starting point, seeing as you're just starting out.
Like the sibling comment pointed out, Reagent uses Hiccup-style data structures to represent HTML. Om can be configured to do the same, but doesn't out of the box last time I checked. Either way, the Hiccup syntax looks like this:
[:div [:h1 "Hello world"]]
It's just regular arrays with symbols, strings and what-have-you, meaning you can construct them using standard Clojure functions in any way you se
Read the rest
e fit.
Add either Reagent or Om to your project.clj, and off you go.
[1]: https://github.com/bhauman/lein-figwheel
[2]: https://github.com/reagent-project/reagent
[3]: https://github.com/omcljs/om
Smart people already have developed general solutions to this problem- This problem is the main reason "graph queries" were independently invented by both Facebook and Netflix.
See here for an exact solution to the problem posed in OP, using the OmNext graph query language: https://github.com/omcljs/om/wiki/Components,-Identity-&-Nor...
In Data denormalization is broken> Why not just use Clojure?
I guess as a professional Python developer, it would take some time to get used to all the parentheses. I've used Emacs for 20+ years, but outside of elisp I've never been comfortable with s-exprs.
I had never heard of om.next. I think this is what you mean: https://github.com/omcljs/om ?? correct?
> And managing complexity is not something you can benchmark in toy projects - every single framework is virtually the same at such a small scale.
Well, looking at how much garbage was needed to implement todomvc in Backbone kept me from considering it any further :)
In Blazing Fast HTML: Elm vs. React vs. Angular vs. EmberFor some people, the best things about React are some of the libraries written on top of it, such as Om for ClojureScript, that allow them to enjoy its architectural ideas without writing javascript at all.
https://github.com/omcljs/om
In React EnlightenmentShowing the 15 most recent of 67 sources. Enable JavaScript to search and browse every indexed mention.