To me Reagent is the ultimate answer to the markup/code mix. A single language, ClojureScript. Nothing is done in strings except text. I absolutely love it, but haven't been able to use on a production project yet.
[0] https://github.com/reagent-project/reagent#examples
In React is becoming a black boxreagent-project
reagent
Clojure2015–2024
reagent-project / reagent
reagent
A minimalistic ClojureScript interface to React.js
23Distinct people
23Mentions
0Explicit recommenders
4.9KGitHub stars
What to know before exploring
What it is
A minimalistic ClojureScript interface to React.js
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
- day8/re-frame · linked in 3 of the same discussions
- omcljs/om · linked in 3 of the same discussions
- tonsky/rum · 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 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 8:03:49 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 year23 dated mentions
Observed mentions: 2015-03-13 13:02:04 UTC to 2024-05-23 05:38:23 UTC.
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 |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 4 | 2 | 2 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-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
A simple ClojureScript interface to React.
Reagent provides a way to write efficient React components using (almost) nothing but plain ClojureScript functions.
Detailed intro with live examples
News
Documentation, latest release
Documentation, next release: API docs, Tutorials and FAQ
Community discussion and support channels
#reagent channel in Clojure Slack
Commercial video material
Learn Reagent Free, Learn Reagent Pro (Affiliate link, $30 discount)
Learn Re-frame Free, Learn Re-frame Pro (Affiliate link, $30 discount)
purelyfunctional.tv
Lambda Island Videos
Usage
To use Reagent in an existing project you add this to your dependencies in project.clj:
And provide React using npm (when using e.g. Shadow-cljs)
npm i react@19.2.3 react-dom@19.2.3
If there is a more recent minor or patch version of React available, it should
be safe to use it in your application.
If you want to keep using React 18 or older versions, you can
also use cljsjs packages to provide React.
Reagent isn't tied to only React-dom but should work with other renderers also.
Examples
Reagent uses Hiccup-like markup instead of JSX. It looks like this:
(defn some-component []
[:div
[:h3 "I am a component!"]
[:p.someclass
"I have " [:strong "bold"]
[:span {:style {:color "red"}} " and red"]
" text."]])
Since version 0.8: The :class attribute also supports collections of classes, and nil values are removed:
[:div {:class ["a-class" (when active? "active") "b-class"]}]
You can use one component inside another:
(defn calling-component []
[:div "Parent component"
[some-component]])
And pass properties from one component to another:
(defn child [name]
[:p "Hi, I am " name])
(defn parent []
[child "Foo Bar"])
You mount the component into the DOM like this:
(defn mount-it []
(rd/render [parent] (.-body js/document)))
assuming we have imported Reagent like this:
(ns example
(:require [reagent.core :as r]
[reagent.dom :as rd]))
State is handled using Reagent's version of atom, like this:
(defonce click-count (r/atom 0))
(defn state-ful-with-atom []
[:div {:on-click #(swap! click-count inc)}
"I have been clicked " @click-count " times."])
Any component that dereferences a reagent.core/atom will be automatically re-rendered.
If you want to do some setting up when the component is first created, the component function can return a new function that will be called to do the actual rendering:
(defn timer-component []
(let [seconds-elapsed (r/atom 0)]
(fn []
(js/setTimeout #(swap! seconds-elapsed inc) 1000)
[:div
"Seconds Elapsed: " @seconds-elapsed])))
This way you can avoid using React's lifecycle callbacks like getInitialState and componentWillMount most of the time.
But you can still use them if you want to, either using reagent.core/create-class or by attaching meta-data to a component function:
(defonce my-html (r/atom ""))
(defn plain-component []
[:p "My html is " @my-html])
(def component-with-callback
(with-meta plain-component
{:component-did-mount
(fn [this]
(reset! my-html (.-innerHTML (rd/dom-node this))))}))
See the examples directory for more examples.
Performance
React is pretty darn fast, and so is Reagent. It should even be faster than plain old javascript React a lot of the time, since ClojureScript allows us to skip a lot of unnecessary rendering (through judicious use of React's shouldComponentUpdate).
The ClojureScript overhead is kept down, thanks to lots of caching.
Code size is a little bigger than React.js, but still quite small. The todomvc example clocks in at roughly 79K gzipped, using advanced compilation.
About
The idea and some of the code for making components atom-like comes from pump.
The reactive-atom idea (and some code) comes from reflex.
The license is MIT.
Read the full README on GitHubWhat Hacker News says
3 sourcesWe just re-evaluated our choices and selected Fulcro. Below is a slightly edited version of how we came to this conclusion.
As a business building an extremely ambitious product on a tight budget, we
want to be able to:
* Focus as much time and thought on building features that bring value to our
customers, rather than, for example, building a bespoke protocol between the
browser and back-end if a better alternative is available.
* Share early iterations of our application with everyone in our organization
easily. Capture feedback and push out new iterations quickly.
* Be able to support new customers immediately. Our feature road-map will
always be in constant flux, but at no point should our ability to make
changes with confidence be compromised. In addition to feature development,
tests and automation must be priorities. Ou
Read the rest
r development and production
environments must match.
* Be ready to onboard new team members. "Works on my laptop" is never
acceptable. Enough of our application must be documented and automated so
that anyone with a technical background "reasonably proficient" in our work
can contribute without requiring hand-holding. Or course, we'd never turn
down a request for help.
Our requirements are:
* Clojure, Clojurescript, and Datomic are immutable choices. We love these
solutions for their simplicity and expressiveness. We believe these are the
best choices available for achieving our long-term business goals.
* Be measurable. Our work should be guided by data not guesswork.
* Be testable. The entire application should have 100% test coverage as
measured by its acceptance or integration tests (not unit tests). Changes
should be made with confidence.
* Be performant. As builders of both the front-end and back-end components, we
should encourage cooperation between them, not purposefully isolate
them. Our customers and the end-user experience should be our priorities,
not artificial divisions between software components or technical teams.
Each component of the application should cooperate to support progressive
enhancement where every URL is a real URL that, when requested, returns a
server-side rendered page view. Further actions by the user result in
browser-side changes through API calls and minimal component updates.
* Be pragmatic. We should be eager to innovate when the need arises. However,
we should be humble enough to understand that sometimes, as software
developers, we can become enamored with new toys that are entertaining, and
possibly educational, but offer little business value. We should choose
existing solutions to our problems that are acceptable enough over building
our own solutions simply because we want to. For example, a standards-based
protocol, like https://github.com/edn-query-language/eql, that allows
clients to craft their own queries with little to no server-side updates is
preferable to our current bespoke solution.
* Be documented and supported. Our choices should have active, helpful, and
inclusive development communities built around them.
Our choices are:
* Rum, https://github.com/tonsky/rum
Rum is a solid piece of software, created and maintained by @tonsky, that
provides a minimal wrapper around react for creating client-side components,
and supports server-side rendering. Although rum does not provide a protocol
between client and server, nor a client component state-management solution.
* Reagent, https://github.com/reagent-project/reagent
Together with Re-frame, https://github.com/Day8/re-frame, this is by far the
most popular choice for building reactive client components in
Clojurescript. These do not include the server-side solutions we need.
* Hoplon, http://hoplon.io
Hoplon was created in-house at AdZerk, and later spun-out as an open source
project. Hoplon is a complete solution although it uses a less intuitive
spreadsheet-like method for building applications with little obvious
advantage, and would not be compatible with Datomic without considerable
effort.
* Luminus, https://luminusweb.com
Luminus is a complete solution like Ruby-on-Rails, and is tightly coupled to
SQL. Like Hoplon, Luminus would not be compatible with Datomic without
considerable effort.
* Pedestal, http://pedestal.io
Pedestal is supported by Cognitect, the custodians of Clojure and the
creators of Datomic. Except Pedestal is best suited for building server-side
APIs, and applications that need to stream data in "near real-time" to large
numbers of concurrently connected clients.
* Fulcro, https://fulcro.fulcrologic.com/
Fulcro is based on Om.Next, provides both front-end and back-end components
that work well together, includes tools for building and debugging both,
supports server-side rendering, and is supported by a diverse
community. Paid commercial support is provided by the core developer team at
Fulcro Logic.
* Datomic Cloud, https://www.datomic.com
Datomic Cloud is a special version of the Datomic database that is tightly
integrated with AWS. Datomic Cloud includes a set of Cloud Formation
templates for running Datomic in AWS, and taking advantage of AWS specific
features, such as auto-scaling groups and load-balancers for distributing
traffic across a cluster of Datomic peers. Datomic Cloud also includes Ions,
https://docs.datomic.com/cloud/ions/ions.html, to help run Clojure functions
as AWS Lambdas. Cognitech claims Datomic Cloud is a suitable framework for
building complete applications. Unfortunately Datomic Cloud alone is
insufficient. Datomic Cloud lacks a framework for building and testing
client-side applications, and a protocol for interacting with Ions.
See also: Reagent. State is a first-class construct in Clojure/script, and forms associated with statefulness and state management are directly available. From that perspective, none of the front-ends presented appear complex.
https://github.com/reagent-project/reagent
In Things I wish I knew about state management when I started writing React apps